• Your Mathematica version

11.2.0 for Microsoft Windows (64-bit) (September 11, 2017)

• Your FeynCalc version

9.3.0 (development) (154268bb6edd4fc701a0127af60245ac572d63ff)

When performing a 2-loop tensor reduction using FCMultiLoopTID I noticed that unevaluated symbols FeynCalc`Tdec`Private`CC were returned in the result.

The loop integral in question is (q1,q2 are the loop momenta and k1 is an external momentum):

(q2_mu1 q1_mu2 q1_mu3 q1_mu4 q1_mu5) / (q2^2 . q1^2 . (q1+q2)^2 . (q2-k1)^2 . (k1+q1)^4)

After some investigations I managed to find that the Tdec function generated these CC symbols. The corresponding Tdec call is:

Tdec[{{q2, mu1}, {q1, mu2}, {q1, mu3}, {q1, mu4}, {q1, mu5}}, {k1} , UseTIDL->False]

Looking further I noted that for the tensor reduction, 14 different "CC" symbols are generated, then a system of 14 equations is built. The problem that happens there is that only 11 of these 14 equations appear to be independent, the other ones are redundant, and as a result only 11 "CC" symbols can be solved. The remaining 3 are the ones that show up in the final result.

I attach in the compressed ZIP archive two notebooks with Tdec verbosity level enabled, one with this example and another one with a different example that works on the contrary (for comparison purposes): Tdec[{{q2, mu1}, {q1, mu2}, {q1, mu3}, {q1, mu4}}, {k1} , UseTIDL->False] .

Tdec_issue.zip

I've downloaded FeynCalc and placed it into a separate folder. My attempt to load the package, however, fails as follows:

I'm using Mathematica 10.0.1.0 on OS X 10.10.1.

In the meanwhile I'm using FeynCalc 8.2.0, installed with the command Import["http://www.feyncalc.org/install.m"].

• Your Mathematica version

11.3.0 for Linux x86 (64-bit) (March 7, 2018)

• Your FeynCalc version

9.2.0

• Did you try to reinstall FeynCalc (stable version) using the automatic installer to make sure that you have the latest bugfixes?

Yes

• Please provide a minimal working example that illustrates the problem. Please explain the difference between the current behavior and the expected behavior.

$LoadFeynArts=True;
<<FeynCalc`
$FAVerbose = 0;
FAPatch[PatchModelsOnly -> True]

When I ran the codes above, Mathematica returned an error to me

First::nofirst: {} has zero length and no first element.

And when I ran without FAPatch[PatchModelsOnly -> True] , that is

$LoadFeynArts=True;
<<FeynCalc`
$FAVerbose = 0;

No error returned. Maybe, there is a bug in FAPatch[PatchModelsOnly -> True]

Best wishes!

• Your Mathematica version

11.0.1 for Mac OS X x86 (64-bit) (September 21, 2016)

• Your FeynCalc version

9.2.0

• Did you try to reinstall FeynCalc (stable version) using the automatic installer to make sure that you have the latest bugfixes?

Yes

• Please provide a minimal working example that illustrates the problem. Please explain the difference between the current behavior and the expected behavior.

Without setting Transversality -> True, Pair[Momentum[k + P], Momentum[Polarization[k + P, I]]] // Calc returns 0. However, inputs like Pair[Momentum[k +2 P], Momentum[Polarization[k +2 P, I]]] return nonzero results as expected.

• Your Mathematica version

11.1.1 for Microsoft Windows (64-bit) (April 18, 2017)

• Your FeynCalc version

9.2.0

• Did you try to reinstall FeynCalc (stable version) using the automatic installer to make sure that you have the latest bugfixes?

Yes

• Please provide a minimal working example that illustrates the problem. Please explain the difference between the current behavior and the expected behavior.

The function FCFAConvert seems to have problems with substituting indices in FASUNF(a,b,c,d). For example, when the following code is evaluated

t4 = CreateTopologies[0, 4];
gggg = InsertFields[t4, {V[5], V[5], V[5], V[5]} -> {}, 
 InsertionLevel -> {Classes}, Model -> "SMQCD"];
ggggAmp = 
FCFAConvert[CreateFeynAmp[gggg, PreFactor -> 1], 
IncomingMomenta -> {p1, p2, p3, p4}, DropSumOver -> True, 
SUNIndexNames -> {a, b, c, d, e}, 
LorentzIndexNames -> {Subscript[\[Mu], 1], Subscript[\[Mu], 2], 
  Subscript[\[Mu], 3], Subscript[\[Mu], 4], Subscript[\[Mu], 5], 
  Subscript[\[Mu], 6]}]

the first amplitude comes up with a factor -f^($AL$14645cd) f^(ab$AL$14645)-f^($AL$14646bd) f^(ac$AL$14646) . Although the expression itself seems to be valid, the label $AL$(some number) is very odd.

Hi,
In Feyncalc 9.0.0 when I tried to evaluate; (Mathematica 10.2.0.0 MacOS)
Tr[DiracSigma[GA[a],GA[b]].GA[a].GA[b]
I get -48i.

However when I tried the same command with FeynCalc 9.2.0 I get; (Mathematica 11.0.1.0 MacOS)
tr(\sigma^{ab} . \gamma^a . \gamma^b)
It does not evaluate but simply writes the output.

On the other hand, when I evaluate
Tr[GA[a].GA[b]]
I get the correct result.

It seems the problem is due to DiracSigma. Is there a change in the new version or am I missing some trivial things?

How can I solve it?

Thanks in advance.

Selcuk

Screen shot of mathematica notebook showing the problem with Contract.

Contract[exp1,exp2] != Contract[exp2,exp1]

Hi feyncalc,
I wanted to ask if the behaviour below is intended for DoPolarizationSums. The 'non-commutativity' I am seeing of DoPolarizationSums and the Lorentz index contraction operations easily caught me out. So long as I carry out all polarisation sums first with contract->false and only afterwards contract the final result, I get an answer I like. Note in D=4 there is no issue.
Cheers, Keith.
P.S. I like this function.

ScalarProduct[p1, p1] = 0;
ScalarProduct[p2, p2] = 0;
testExpression =
Pair[LorentzIndex[[Alpha]1, D],
Momentum[Polarization[p1, I, Transversality -> True], D]] Pair[
LorentzIndex[[Alpha]1, D],
Momentum[Polarization[p1, -I, Transversality -> True], D]] Pair[
LorentzIndex[[Alpha]2, D],
Momentum[Polarization[p2, I, Transversality -> True], D]] Pair[
LorentzIndex[[Alpha]2, D],
Momentum[Polarization[p2, -I, Transversality -> True], D]];

DoPolarizationSums[DoPolarizationSums[testExpression, p1, n], p2, n]
DoPolarizationSums[
DoPolarizationSums[testExpression, p1, n, Contract -> False], p2, n,
Contract -> False] // Contract

First return value is 2D-4 , the second is (D-2)^2 .

Hi,
Is it possible to do explicit SU(3) calculation with Feyncalc? I can only obtain result depending on N, CA e CF and i can't substitute them with their value for N=3.
Thanks for the help,
Luca

• Your Mathematica version

11.2.0 for Microsoft Windows (64-bit) (September 11, 2017)

• Your FeynCalc version

The described problem appearing starting revision:
9.3.0 (development) (05732bb0e5780b83210fc21790fd541c7a43ae38) -- "FCLoopBasisExtract is now using FCLoopBasisIntegralToTopology."

With other colleagues I'm performing a 2-loop scalar integral calculation; due to the topology of the diagram (bubble diagram that will be == 0) and the fields involved (and using R-xi gauge) I encounter at some point the following quantity (which is the term in xi^1 in the expression):

FAD[q1, q1 - k1, q1 - k1, q1 - k1, q2] SPD[k1 - q1, k1 + q1] SPD[q1 - k1, q1 + k1]

Calling FCMultiLoopTID on it: FCMultiLoopTID[%, {q1, q2}] fails and displays the following error:

During evaluation of In[1]:= FCLoopBasisIntegralToTopology::failmsg: Error! FCLoopBasisIntegralToTopology has encountered a fatal problem and must abort the computation. The problem reads: The input expression does not seem to be a valid scalar loop integral.

Out[1]= $Aborted

Adding the following diagnostic patch on FeynCalc:

diff --git a/FeynCalc/LoopIntegrals/FCLoopBasis.m b/FeynCalc/LoopIntegrals/FCLoopBasis.m
index 38ec7768..17d18f82 100755
--- a/FeynCalc/LoopIntegrals/FCLoopBasis.m
+++ b/FeynCalc/LoopIntegrals/FCLoopBasis.m
@@ -244,6 +244,7 @@ FCLoopBasisIntegralToTopology[expr_, lmoms_List, OptionsPattern[]]:=
                ];

                If[     !MemberQ[{Times,FeynAmpDenominator,Pair,CartesianPair,TemporalPair},Head[exp]] || FreeQ2[exp,lmoms],
+               Print["(1) exp = ", InputForm[exp], " ; lmoms = ", InputForm[lmoms]];
                        Message[FCLoopBasisIntegralToTopology::failmsg,"The input expression does not seem to be a valid loop integral."];
                        Abort[]
                ];
@@ -284,6 +285,7 @@ FCLoopBasisIntegralToTopology[expr_, lmoms_List, OptionsPattern[]]:=
                ];

                If[     !FreeQ2[rest,lmoms] || !FreeQ2[tmp,{LorentzIndex,CartesianIndex,TemporalIndex}],
+               Print["(2) rest = ", InputForm[rest], " ; tmp = ", InputForm[tmp], " ; lmoms = ", InputForm[lmoms]];
                        Message[FCLoopBasisIntegralToTopology::failmsg,"The input expression does not seem to be a valid scalar loop integral."];
                        Abort[]
                ];

helps finding where the error is displayed and in which conditions:

During evaluation of In[1]:= (2) rest = (Pair[Momentum[k1, D], Momentum[k1, D]] - Pair[Momentum[q1, D], Momentum[q1, D]])*(-Pair[Momentum[k1, D], Momentum[k1, D]] + Pair[Momentum[q1, D], Momentum[q1, D]]) ; tmp = {FeynAmpDenominator[PropagatorDenominator[Momentum[q2, D], 0], PropagatorDenominator[Momentum[q1, D], 0], PropagatorDenominator[-Momentum[k1, D] + Momentum[q1, D], 0], PropagatorDenominator[-Momentum[k1, D] + Momentum[q1, D], 0], PropagatorDenominator[-Momentum[k1, D] + Momentum[q1, D], 0]]} ; lmoms = {q1, q2}

During evaluation of In[1]:= FCLoopBasisIntegralToTopology::failmsg: Error! FCLoopBasisIntegralToTopology has encountered a fatal problem and must abort the computation. The problem reads: The input expression does not seem to be a valid scalar loop integral.

Out[1]= $Aborted

NOTE: In latest FeynCalc versions FCLoopBasisIntegralToTopology has been renamed into FCLoopBasisIntegralToPropagators.

Errors also happen with the following expressions (coming from other diagrams):

FAD[q1, q1 - k1, q2, q1 + q2] SPD[2 k1 - q1, q1 + 2 q2] produces:

In[2]:= FCMultiLoopTID[%, {q1, q2}]

During evaluation of In[2]:= (2) rest = Pair[Momentum[k1, D], Momentum[2*q1 + 4*q2, D]] + Pair[Momentum[q1, D], Momentum[-q1 - 2*q2, D]] ; tmp = {FeynAmpDenominator[PropagatorDenominator[Momentum[q2, D], 0], PropagatorDenominator[Momentum[q1, D], 0], PropagatorDenominator[Momentum[q1, D] + Momentum[q2, D], 0], PropagatorDenominator[-Momentum[k1, D] + Momentum[q1, D], 0]]} ; lmoms = {q1, q2}

During evaluation of In[2]:= FCLoopBasisIntegralToPropagators::failmsg: Error! FCLoopBasisIntegralToPropagators has encountered a fatal problem and must abort the computation. The problem reads: The input expression does not seem to be a valid scalar loop integral.

Out[2]= $Aborted

FAD[q1, q1 - k1, q1 - k1, q1 - q2 - k1, q2] SPD[k1 + q1, q1 - q2 - k1] SPD[k1 + q1, q2] produces:

In[3]:= FCMultiLoopTID[%, {q1, q2}]

During evaluation of In[3]:= (2) rest = -Pair[Momentum[k1, D], Momentum[k1 + q2, D]] + Pair[Momentum[q1, D], Momentum[q1 - q2, D]] ; tmp = {FeynAmpDenominator[PropagatorDenominator[Momentum[q2, D], 0], PropagatorDenominator[Momentum[q1, D], 0], PropagatorDenominator[-Momentum[k1, D] + Momentum[q1, D], 0], PropagatorDenominator[-Momentum[k1, D] + Momentum[q1, D], 0], PropagatorDenominator[-Momentum[k1, D] + Momentum[q1, D] - Momentum[q2, D], 0]], Pair[Momentum[k1 + q1, D], Momentum[q2, D]]} ; lmoms = {q1, q2}

During evaluation of In[3]:= FCLoopBasisIntegralToPropagators::failmsg: Error! FCLoopBasisIntegralToPropagators has encountered a fatal problem and must abort the computation. The problem reads: The input expression does not seem to be a valid scalar loop integral.

Out[3]= $Aborted

• Your Mathematica version

11.2.0 for Microsoft Windows (64-bit) (September 11, 2017)

• Your FeynCalc version

9.3.0 (development) (7cc253f8329342eba934b8167396c9712cffea4f)

During a loop computation in dimensional regularization in Breitenlohner-Maison scheme (1-loop scalar self-energy with fermion loop and chiral couplings; k1 is the external momentum), I obtain a result whose divergent part structurally looks like:

I ( Pair[Momentum[k1, -4 + D], Momentum[k1, -4 + D]] * (product_of_Yukawas) + Pair[Momentum[k1, D], Momentum[k1, D]] * (other_product_of_Yukawas) ) / EpsilonUV

(I neglected here the factors of Pi etc...).
Note that when I compute the same process using the "usual" (aka. naive) gamma_5 scheme I obtain the usual result:

I ( Pair[Momentum[k1, D], Momentum[k1, D]] * (other_product_of_Yukawas) ) / EpsilonUV

Then I used ChangeDimension[divPart, 4] to turn the external momentum back to 4-dimension, but this has as an effect to turn also the Pair[Momentum[k1, -4 + D], Momentum[k1, -4 + D]] to Pair[Momentum[k1, 4], Momentum[k1, 4]], therefore messing with the result.

The question is then, is it the correct usage of ChangeDimension, or its expected behaviour, or am I doing something wrong here, aka. should I do something else to filter out all the D-4-dimensional momenta?
(I know that if I replace D by 4 this will transform these momenta to Momentum[k1,0] which will provide the "correct" behaviour, but this may mess with other things...)

Hello Again,
I just use GitHub in order to upload a minimal working example to highlight the issues commented on the mailing list "E0 scalar function".
As said, for the E0 scalar function, I get an overall minus sign with respect to the one I find implementing the Denner-Dittmaier algorithm in FeynCalc and also with respect to the LoopTools E0[ee0,pi...,,mi,...] implementation.
I show that numerically for a particular point of the phase-space in my problem.
Because GitHub does not allow *.nb extensions I just compressed that into an allowed zip file, I hope that works. Alternativley, find the MWE.nb file at
https://github.com/PabloSanchezPuertas/Mathematica
MWE.zip

I have installed FeynCalc 8.2 in Mathematica 10. But I keep receiving error messages when I try to load the programme.

I was trying to make a PaVe function pattern

PaVe[0,{a_,b_,c_},{d_,e_,f_}]

If I evaluate it twice, if will go into infinite loop

`$IterationLimit::itlim: Iteration limit of 4096 exceeded.

$RecursionLimit::reclim2: Recursion depth of 4096 exceeded during evaluation of Refresh[TraditionalFormDump`$UseNewTraditionalForm,None].

$RecursionLimit::reclim2: Recursion depth of 4096 exceeded during evaluation of Refresh[TraditionalFormDump`$UseNewTraditionalForm,None].

$RecursionLimit::reclim2: Recursion depth of 4096 exceeded during evaluation of BoxForm`MakeTraditionalBoxes(Pattern).

General::stop: Further output of $RecursionLimit::reclim2 will be suppressed during this calculation.`

First of all, thanks for your great work on this package!

I am having issues doing calculations when using FeynArts models with explicit Dirac indices. For instance, consider the minimal working example below. When using GenericModel->"Lorentz", everything works as expected. When using GenericModel->"Dirac", DiracTrick throws

Error! DiracTrick has encountered a fatal problem and must abort the computation. The problem reads: Incorrect combination of dimensions and g^5 scheme!

when trying to apply things like TID to the amplitude, even though everything is D-dimensional.

• Your Mathematica version

11.3.0 for Linux x86 (64-bit) (March 7, 2018)

• Your FeynCalc version

9.2.0

• Did you try to reinstall FeynCalc (stable version) using the automatic installer to make sure that you have the latest bugfixes?

Yes

• Please provide a minimal working example that illustrates the problem. Please explain the difference between the current behavior and the expected behavior.

$LoadFeynArts = True;
<< FeynCalc`;
top = CreateTopologies[1, 1 -> 1, ExcludeTopologies -> {Tadpoles}];
ins = InsertFields[top, {F[1, {1}]} -> {F[1, {1}]}, InsertionLevel -> {Particles},
  Model -> "QED", GenericModel -> "Dirac"];
amp = CreateFeynAmp[ins];
fcamp = FCFAConvert[amp,
  IncomingMomenta -> {p}, OutgoingMomenta -> {q}, LoopMomenta -> {k},
  DropSumOver -> True, UndoChiralSplittings -> True, ChangeDimension -> D,
  List -> False, SMP -> True]
TID[fcamp, k]

This works for GenericModel -> "Lorentz" instead of "Dirac".

• Your Mathematica version

11.3.0 for Microsoft Windows (64-bit) (March 7, 2018)

• Your FeynCalc version

9.4.0 master (fb9fc9a5935a3f18694d26df1b6076fe67c63e56)

• Did you try to reinstall FeynCalc (stable version) using the automatic installer to make sure that you have the latest bugfixes?

Using git master repo checkout

As part of some 2-loop calculation in the BMHV scheme for a self-energy (and containing loop of chiral fermions), the following integrand is generated:

FVD[l1, mu1] FVD[l1, mu2] FVD[l2, nu1] FVD[l2, nu2] FVD[l2, nu3]
    FAD[l1, l2, l2, l1 - p, l1 - p, l1 + l2 - p]

The opened Lorentz indices in the momenta come from the uncontraction step, made in FCMultiLoopTID[], because these momenta were originally contracted with 4-dimensional metrics.

Due to the high number of indices this triggers the usage of Tdec, which unexpectedly fails:

<snip...>

Requesting integral of type(l1	\[Mu]1
l1	\[Mu]2
l2	\[Nu]1
l2	\[Nu]2
l2	\[Nu]3

){FeynCalc`Tdec`Private`extMom(p)}in TIDL

Unfortunately, this decomposition formula is not available in TIDL.

Tdec::slow: Tdec is computing a decomposition that is not available in TIDL. This might take quite some time. If this integral often appears in your computations, it is recommended to compute it once and then save the result to the TIDL directory.

< ... snip ...>

During evaluation of In[38]:= ReplaceAll::reps: {Dispatch[FerSolve({....})]} is neither a list of replacement rules nor a valid dispatch table, and so cannot be used for replacing.

During evaluation of In[38]:= Tdec::failmsg: Error! TID has encountered a fatal problem and must abort the computation. The problem reads: The solution to the system of linear equations is incorrect.

Out[38]= $Aborted

</snip>

The current multiloop symmetrizer is inefficient and slow. It should be completely removed and
replaced by Pak's algorithm

Recently, I encountered an issue with ComplexConjugate complaining that the Dirac chain contained illegal object. The message was not clear as to what in particular was not allowed, but I eventually found that it was the presence of SUNFIndex; however, I believe this to be an error in the following example:

Spinor[-Momentum[p2], MassFu[Index[I3Gen, 2], SUNFIndex[Col2]], 1]
 . DiracGamma[7]
 . Spinor[Momentum[p3], MassFQ[Index[I3Gen, 3], SUNFIndex[Col3]], 1]

The SUNFIndex is (in intent) only distinguishing between the masses of the quarks of different colour charges (which of course in an unbroken SU(3) should be identical).

• Your Mathematica version: 12.0.0 for Linux x86 (64-bit) (April 7, 2019)

• Your FeynCalc version: 9.3.0 (commit ee04fd3b)

• Mathematica version

Mathematica 11.2.0.0

• FeynCalc version

FeynCalc 9.2.0. FeynArts 3.1 patched for use with FeynCalc. FeynHelpers 1.1.0 loaded
FeynRules 2.3.32

When I use them

FR$Parallel = False;
$FeynRulesPath = SetDirectory[$UserBaseDirectory <> "/Applications/FeynRules"];
<< FeynRules`;

(* Not important*)

and

$LoadAddOns = {"FeynHelpers"};
$LoadFeynArts = True;
<< FeynCalc`;
$FAVerbose = 0;

(* Not important*)

I have to call Quit[] to restart the kernel before use the package, otherwise

Symbol *** appears in multiple contexts {FeynCalc`,FeynRules`}; definitions in context FeynCalc` may shadow or be shadowed by other definitions.

I wonder if there exists conflict between FeynCalc 9.2.0 and FeynRules 2.3.32, or FeynArts 3.1 patched in FeynCalc has already patched FeynRules? If patched, how to call it?
Thank you

• Your Mathematica version

8.0.4.0 for Microsoft Windows (64-bit) (2011)
11.2.0 for Microsoft Windows (64-bit) (September 11, 2017)

• Your FeynCalc version

9.3.0 (development) (d953b1aae71d54cd834f386ca4584cb515f2652c)

When performing 2-loop calculations, a tensor reduction is performed on an (Lorentz-index uncontracted) expression, and in fine the following Tdec command is executed:

Tdec[{{q1, $3050}, {q1, $3489}, {q2, $3047}, {q2, $3488}} , {k1}, Dimension -> D, List -> False, UseTIDL -> False]

This line fails with the following error:
Tdec::failmsg: Error! TID has encountered a fatal problem and must abort the computation. The problem reads: The solution to the system of linear equations is incorrect.

However, running instead:

Tdec[{{q1, mu}, {q1, nu}, {q2, rho}, {q2, sig}} , {k1}, Dimension -> D, List -> False, UseTIDL -> False]

or even:

Tdec[{{q1, $3050}, {q1, $3489}, {q2, $3047}, {q2, mu}} , {k1}, Dimension -> D, List -> False, UseTIDL -> False]

works perfectly!

The problem seems to be related with the "format" of the Lorentz indices used in the momenta list in the Tdec call (the dollar-variables).

Hi. Is it possible to correct the documentation on DoPolarizationSums at [1] (that is, Documentation/English/ReferencePages/Symbols/DoPolarizationSums.nb)? The syntax it lists has not been valid for years. I've found the explanation for the new syntax at [2]. The help message for DoPolarizationSums seems to be correct too -- just using that would be an improvement.

[1] https://feyncalc.github.io/FeynCalcBook/ref/DoPolarizationSums.html
[2] http://www.feyncalc.org/forum/0844.html

• Your Mathematica version

9.0 for Mac OS X x86 (64-bit) (February 13, 2013)

• Your FeynCalc version

9.2.0

• Did you try to reinstall FeynCalc (stable version) using the automatic installer to make sure that you have the latest bugfixes?

Yes, the FeynCalc is installed using the automatic installer just yesterday.

• Please provide a minimal working example that illustrates the problem. Please explain the difference between the current behavior and the expected behavior.

• Current behavior:

In[]:= A0[m1]
Out[]= m1 B0[0, m1, m1]

• expected behavior:

In[]:= A0[m1]
Out[]= m1 + m1 B0[0, m1, m1]

Have not yet checked other function carefully. Maybe also has some problem with B1 or B11.

Thanks for your great work on FeynCalc.

When I use TID to do HiggstoGluonGluon oneloop calculation, the result was wrong, and it was same with the calculation that I used Oneloop with oneloopsimplify which was not recommend by developer.

Then I set $LimitTo4=True, the result of OneLoop with OneLoopSimplify was True(agree with my derivation) and the result of TID was still wrong.

I take apart the amplitude into pieces, and I found the one which cause the problem, that is

FeynAmpDenominator[PropagatorDenominator[Momentum[k,D]],PropagatorDenominator[Momentum[k,D]+Momentum[p1,D]],PropagatorDenominator[Momentum[k,D]+Momentum[p1,D]+Momentum[p2,D]]] Pair[LorentzIndex[mu,D],Momentum[k,D]] Pair[LorentzIndex[nu,D],Momentum[k,D]]

in which "k" is loop momentum, and we set all mass to zero, that means p1.p1=0, p2.p2=0.

four different ways

1. $LimitTo4=False (default) , use Oneloop with oneloopsimplify
2. $LimitTo4=False (default) , use TID

3. $LimitTo4=True, use Oneloop with oneloopsimplify

4. $LimitTo4=True, use TID

we found only the third way gave the right answers(agreed with my derivation)

• Mathematica 11.3

11.3.0 for Microsoft Windows (64-bit) (March 7, 2018)

• FeynCalc 9.2.0

9.2.0

• Did you try to reinstall FeynCalc (stable version) using the automatic installer to make sure that you have the latest bugfixes?

Yes

• oneloop calculation "k" is loop monentum, and we set all mass to zero, that means p1.p1=0, p2.p2=0 p1.p2=p1p2
• 1. $LimitTo4=False (default) , use Oneloop with oneloopsimplify --> wrong

FCClearScalarProducts[];
ScalarProduct[p1, p1] = 0;
ScalarProduct[p2, p2] = 0;
ScalarProduct[p1, p2] = p1p2;
$LimitTo4 = False;  
wt = FeynAmpDenominator[PropagatorDenominator[Momentum[k, D]], 
   PropagatorDenominator[Momentum[k, D] + Momentum[p1, D]], 
   PropagatorDenominator[
    Momentum[k, D] + Momentum[p1, D] + Momentum[p2, D]]] Pair[
   LorentzIndex[mu, D], Momentum[k, D]] Pair[LorentzIndex[nu, D], 
   Momentum[k, D]]  
worng = wt // OneLoopSimplify[#, k] & // OneLoop[k, #] & // 
   PaVeReduce // ChangeDimension[#, D] &
   

• 2. $LimitTo4=False (default) , use TID --> wrong

FCClearScalarProducts[];
ScalarProduct[p1, p1] = 0;
ScalarProduct[p2, p2] = 0;
ScalarProduct[p1, p2] = p1p2;
$LimitTo4 = False;
wt = FeynAmpDenominator[PropagatorDenominator[Momentum[k, D]], 
PropagatorDenominator[Momentum[k, D] + Momentum[p1, D]], 
PropagatorDenominator[
 Momentum[k, D] + Momentum[p1, D] + Momentum[p2, D]]] Pair[
LorentzIndex[mu, D], Momentum[k, D]] Pair[LorentzIndex[nu, D], 
Momentum[k, D]]
worng = wt // TID[#, k] & // ToPaVe[#, k] & // PaVeReduce // 
ChangeDimension[#, D] &

• 3. $LimitTo4=True,use Oneloop with oneloopsimplify --> right

FCClearScalarProducts[];
ScalarProduct[p1, p1] = 0;
ScalarProduct[p2, p2] = 0;
ScalarProduct[p1, p2] = p1p2;
$LimitTo4 = True;
wt = FeynAmpDenominator[PropagatorDenominator[Momentum[k, D]], 
PropagatorDenominator[Momentum[k, D] + Momentum[p1, D]], 
PropagatorDenominator[
 Momentum[k, D] + Momentum[p1, D] + Momentum[p2, D]]] Pair[
LorentzIndex[mu, D], Momentum[k, D]] Pair[LorentzIndex[nu, D], 
Momentum[k, D]]
right = wt // OneLoopSimplify[#, k] & // OneLoop[k, #] & // 
PaVeReduce // ChangeDimension[#, D] &

• 4. $LimitTo4=True, use TID --> wrong

FCClearScalarProducts[];
ScalarProduct[p1, p1] = 0;
ScalarProduct[p2, p2] = 0;
ScalarProduct[p1, p2] = p1p2;
$LimitTo4 = True;
wt = FeynAmpDenominator[PropagatorDenominator[Momentum[k, D]], 
PropagatorDenominator[Momentum[k, D] + Momentum[p1, D]], 
PropagatorDenominator[
 Momentum[k, D] + Momentum[p1, D] + Momentum[p2, D]]] Pair[
LorentzIndex[mu, D], Momentum[k, D]] Pair[LorentzIndex[nu, D], 
Momentum[k, D]]

wrong = wt // TID[#, k] & // ToPaVe[#, k] & // PaVeReduce // 
ChangeDimension[#, D] &;
wrong = wrong /. D -> 4 // ChangeDimension[#, D] &

• we expect to get the third answers ($LimitTo4=True,use Oneloop with oneloopsimplify) , there should be a term which is not contain B0/C0.

(I \[Pi]^2 Subscript[B, 0](2 p1p2,0,0) (p1p2 g^(munu)-2 p2^mu p1^nu-2 p1^mu p2^nu+3 p1^mu p1^nu-p2^mu p2^nu))/(4 p1p2)+I \[Pi]^2 p1^mu p1^nu Subscript[C, 0](0,0,2 p1p2,0,0,0)+(I \[Pi]^2 (p1p2 g^(munu)-p2^mu p1^nu-p1^mu p2^nu))/(4 p1p2)

https://github.com/Tpengfu/Bug-in-FeynCalc

4ways.zip

• Your Mathematica version

11.2.0 for Microsoft Windows (64-bit) (September 11, 2017)

• Your FeynCalc version

9.3.0 (development)

• Did you try to reinstall FeynCalc (stable version) using the automatic installer to make sure that you have the latest bugfixes?

Latest development HEAD repository

I am computing UV divergent parts of some amplitudes expressed in terms of Passarino-Veltman 1-loop functions, using the FeynCalc function PaVeUVPart[], and noticed that the returned results did not agree with the ones obtained through FeynCalc/Package-X PaXEvaluate[] or through FormCalc:

In[1]:= $LoadAddOns = {"FeynHelpers"};
In[2]:= << FeynCalc`

In[3]:= myAmp = B0[p12, 0, 0];

In[4]:= Simplify@Normal@Series[Simplify@PaVeUVPart[myAmp] /. {D -> 4 - 2 Epsilon}, {Epsilon, 0, 0}]
Out[4]= 1/Epsilon

In[5]:= Expand@PaXEvaluate[myAmp]
Out[5]= 1/Epsilon + Log[-(Mu^2/(\[Pi] p12))] - Gamma + 2

which is OK, as well as:

In[6]:= myAmp = PaVe[0, 0, {0, p12, p12}, {0, 0, 0}]; (** C00 function **)

In[7]:= Simplify@Normal@Series[Simplify@PaVeUVPart[myAmp] /. {D -> 4 - 2 Epsilon}, {Epsilon, 0, 0}]
Out[7]= 1/(4 Epsilon)

In[8]:= Expand@PaXEvaluate[myAmp]
Out[8]= 1/(4 Epsilon) + 1/4 Log[-Mu^2/(\[Pi] p12)] - Gamma/4 + 1/2

However:

In[6]:= myAmp = C0[0, p12, p12, 0, 0, 0];

In[7]:= Simplify@Normal@Series[Simplify@PaVeUVPart[myAmp] /. {D -> 4 - 2 Epsilon}, {Epsilon, 0, 0}]
Out[7]= 0

In[8]:= Expand@PaXEvaluate[myAmp]
Out[8]= -1/(Epsilon p12) - Log[-(\[Pi] Mu^2)/p12]/p12 + Gamma/p12 + 2 Log[\[Pi]]/p12

is NOT OK (PaX gives the correct result however).

Similar problem also appear for D0 functions, for example with: D0[0, p12, 0, p12, p12, p12, 0, 0, 0, 0] (PaX returns -2/(Epsilon p12^2) for the div-part, while PaVeUVPart[] returns 0).

This problem happens because the massless case of C0 and D0 (and possibly their families Cij, Dijkl etc...) is singular; this can be seen when evaluating these functions by hand using Feynman parametrization: one needs to keep the full D-dimensional dependence for the powers of the Feynman parameters, which, after integration, turn into a product of Gamma functions that depend on D. Then, by expanding over Epsilon = (4-D)/2, one obtains the 1/Epsilon poles as expected.

Is it possible to set the output format type as TraditionalForm every time the package is loaded? Such as insert SetOptions[EvaluationNotebook[],CommonDefaultFormatTypes->{"Output"->TraditionalForm}] in it?

Hi, I'm a beginner in the use of FeynCalc. I'm trying to compute basic amplitude but i'm having problem when i face the vector polarization sum. I'm using Mathematica 10 and FeynCalc 9.0.1. Here an example of the problem:

In[2]:= expr =
PolarizationVector[k, [Mu]] PolarizationVector[k, [Nu]];

In[3]:= expr

Out[3]= Pair[LorentzIndex[[Mu]], Momentum[Polarization[k, I]]] Pair[
LorentzIndex[[Nu]], Momentum[Polarization[k, I]]]

In[4]:= DoPolarizationSums[expr, k, n]

Out[4]= Pair[LorentzIndex[[Mu]], Momentum[Polarization[k, I]]] Pair[
LorentzIndex[[Nu]], Momentum[Polarization[k, I]]]

As you can see DoPolarizationSums does nothing at all and i don't know what i'm doing wrong.
Thanks for the help,
Luca Mantani

• Your Mathematica version

11.2.0 for Microsoft Windows (64-bit) (September 11, 2017)

• Your FeynCalc version

9.2.0

• Did you try to reinstall FeynCalc (stable version) using the automatic installer to make sure that you have the latest bugfixes?

Yes

• Please provide a minimal working example that illustrates the problem. Please explain the difference between the current behavior and the expected behavior.

The problem is that in installation.m the option CommonDefaultFormatTypes is set for $FrontEnd. And, since the explanation how to reset it is not correct in all version ( it should be CurrentValue[$FrontEnd, {CommonDefaultFormatTypes, "Output"}] = StandardForm) the problem is that for all subsequent Mathematica FrontEnd sessions the default output format type is TraditionalForm. The fix is to use CurrentValue[$FrontEndSession, {CommonDefaultFormatTypes, "Output"}] = TraditionalForm in install.m . Then any subequent Mathematica FrontEnd session will not be influenced by FeynCalc. (the other setting of $FrontEnd is probably just fine).

https://feyncalc.github.io/FeynCalcBook/ref/FCRenameDummyIndices.html
gives 404 ...

I installed FeynCalc using the install script:

https://raw.githubusercontent.com/FeynCalc/feyncalc/master/install.m

The documentation wasn't available until I restarted Mathematica.

Suggest adding RebuildPacletData[] at the end of the install script to fix this.

The output of DiracSimplify appears to replace certain patterns in its input. I have a trivial example below showing the issue. I don't know if i is the only culprit though.

DiracSimplify[SpinorU[p[i], m[i]]]

produces

Spinor[Momentum[p[2]], m[2], 1]

which is incorrect (the simplification is trivial), and it should instead be returning:

Spinor[Momentum[p[i]], m[i], 1]

In[51]:= SpinorVBar[k2,m]//FCI //StandardForm
Out[51]//StandardForm= Spinor[-Momentum[k2],m,1]

Whereas

In[52]:= SpinorVBar[k2]//FCI //StandardForm
Out[52]//StandardForm= Spinor[Momentum[k2],0,1]

Why is there a difference in sign of the momenta in these two cases ?

Similarly

In[67]:= Spinor[-k2].GA[[Mu]].Spinor[k1] //FCI //StandardForm
Out[67] Spinor[-Momentum[k2],0,1].DiracGamma[LorentzIndex[[Mu]]].Spinor[Momentum[k1],0,1]

Whereas

In[66]:= SpinorVBar[k2]. GA[[Mu]].SpinorU[k1] //FCI //StandardForm
Out[66]=Spinor[Momentum[k2],0,1].DiracGamma[LorentzIndex[[Mu]]].Spinor[Momentum[k1],0,1]

Missing documentation for SPE, GAE, MTE.

"Isolated" expressions are not converted to nice Fortran files as described here
http://www.feyncalc.org/FeynCalcBook/Write2/

Mathematica 10.1.0 for Linux x86 (64-bit)
Copyright 1988-2015 Wolfram Research, Inc.

In[1]:= !!t.m

Needs["FeynCalc`"];
(* assuming you use Fortran 90 or newer*)
$FortranContinuationCharacter = "";
t2 = x + Collect2[((a-c)^2 + (a-b)^2)^2,a,IsolateNames -> L];
Write2["t2.f", r = t2, FormatType -> FortranForm]
FilePrint @ "t2.f"
Print["t2 = ", t2 // InputForm];
Print["DownValues[L] = ", DownValues[L] // InputForm];

In[2]:= <<t.m
Loading FeynCalc from /home/rolfm/.Mathematica/Applications/FeynCalc/
$PrePrint is set to FeynCalcForm. Use FI and FC to change the display format.
FeynCalc 9.0.0. For help, type ?FeynCalc, use the help browser or visit www.feyncalc.org.
        L(24D1)= L(24D1)
        L(25D1)= L(25D1)
        L(26D1)= L(26D1)
        r = 4D0*a**4 + x - 8D0*a**3*L(24D1) + 8D0*a**2*L(25D1) -
       4D0*a*L(24D1)*L(26D1) + L(26D1)**2

t2 = 4*a^4 + x - 8*a^3*HoldForm[L[24]] + 8*a^2*HoldForm[L[25]] - 4*a*HoldForm[L[24]]*HoldForm[L[26]] + HoldForm[L[26]]^2
DownValues[L] = {HoldPattern[L[24]] :> b + c, HoldPattern[L[25]] :> b^2 + b*c + c^2, HoldPattern[L[26]] :> b^2 + c^2}

Looks like there is something wrong with PV reduction of tensor integral coefficient functions when compared with the same functions calculated with LoopTools directly, here is a code sample:

toLT = {FeynCalc`PaVe[0, {}, {mm_}] -> LoopTools`A0[mm], 
   FeynCalc`PaVe[0, 0, {}, {mm}] -> LoopTools`A00[mm], 
   FeynCalc`C0[a___] -> LoopTools`C0[a], 
   FeynCalc`B0[a___] -> LoopTools`B0[a], 
   FeynCalc`A0[a___] -> LoopTools`A0[a], 
   FeynCalc`PaVe[x___] -> LoopTools`PaVe[x]};

tests = {
   TEST[0, {3}, {1, 2}],
   TEST[0, 0, {3}, {1, 2}],
   TEST[1, 1, {3}, {1, 2}],
   TEST[0, {1}, {1, 1}],
   TEST[0, 0, {1}, {1, 1}],
   TEST[1, 1, {1}, {1, 1}]
   };

Print["FA: ", 
    SeriesCoefficient[# /. 
        TEST[x___] -> FeynCalc`PaVe[x, PaVeAutoReduce -> True] /. 
       toLT /. D -> 4 - 2 ep, {ep, 0, 0}], 
    " LT:", # /. TEST[x___] -> LoopTools`PaVe[x]] & /@ tests;

and its output:

FA: 0.0569409 LT:0.0569409

FA: 0.136399 LT:0.469732

FA: 0.041684 LT:-0.0694271

FA: 0.186201 LT:0.186201

FA: 0.213217 LT:0.490995

FA: 0.333333 LT:0.0555556

• Your Mathematica version

11.3.0 for Microsoft Windows (64-bit) (March 7, 2018)

• Your FeynCalc version

9.4.0 master (a3aab44faccb7e68d0fab29a626b1ddc47667725)

• Did you try to reinstall FeynCalc (stable version) using the automatic installer to make sure that you have the latest bugfixes?

Using git master repo checkout

Using FCMultiLoopTID[] returns unexpected results when the provided amplitude contains explicit evanescent (in D-4 dimensions) or 4-dimensional structures. This causes problems in analytical calculation of (2+) loop amplitudes in e.g. BMHV scheme.
This problem also shows up, at 1-loop level, when comparing the tensor reduction obtained via the usual TID[] function, and by FCMultiLoopTID[] with 1 momentum specification.

The observed effect is that it appears, that somehow FCMultiLoopTID[] "replaces" all occurrences of loop momenta (when evanescent or 4-dimensional projections of these are present) to their fully d-dimensional counterparts.
See the attached notebook (in zip archive) for explicit examples, as well as for a "workaround".

FeynCalc_bug_FCMultiLoopTID.zip

The instruction DiracSimplify[ Spinor[p1, m1].(DiracSlash[p2]).DiracMatrix[7].Spinor[p2, m2]] produces the following worng result
-(m2_Spinor[Momentum[p1], m1, 1] . Spinor[Momentum[p2], m2, 1])/2 -
m2_Spinor[Momentum[p1], m1, 1] . DiracGamma[5] . Spinor[Momentum[p2], m2, 1]
1/2 is missing. FeynCal v8.2 produces the right result.
I am using mathemetica 9, linux or windows. thanks.

Dear FeynCalc Authors,
Using FCFAConvert with a Feynarts model file that contains Majorana Fermions does not work.
It appears that "MajoranaSpinor", a feynarts object, is not recognized by FeynCalc.

please advise,
best,

Kirtimaan

Is there a way to explicitly define the components of a FourVector?
For example, I wanted to create a fourvector p=(0,1,0,0). I naively tried something like:
FV[p,mu];
p[0]=0;
p[1]=1;
p[2]=0;
p[3]=0;

and than tried to evaluate SP[p,p] expecting "-1" but instead the output was "p^2". How can I define an explicit FV that works in all other FV-related functions?

Dear feyncalc authors,
The following code works with Mathematica v9 and Feyncalc v 9.1.0 :

(1/2 - DiracGamma[5]/2) . (-((mQf + DiracGamma[Momentum[p + q]])/(-mQf^2 + Pair[Momentum[p + q], Momentum[p + q]]))) .
(1/2 + DiracGamma[5]/2)// DiracSimplify

However with Feyncalc v9.2.0 it throws up the following error and Aborts:

"DiracTrick::failmsg: Error! DiracTrick has encountered a fatal problem and must abort the computation. The problem reads: Incorrect combination of dimensions and g^5 scheme! >>"

• Your Mathematica version

11.2.0 for Microsoft Windows (64-bit) (September 11, 2017)

• Your FeynCalc version

9.3.0 (development) (15238e617d5ee719667ecb01248d3d0b1e535397)

There appears to be a bug in FCCanonicalizeDummyIndices[] when, during the associated expansion of the expression being canonicalized, a (dot-)product of Gamma matrices becomes transformed into a regular product.

This example works: after the expansion the Gamma matrices ordering is correctly kept:

In[1] := FCCanonicalizeDummyIndices@DiracTrace[GS[q].(gS GA[\[Mu]].GA[6]).GS[k + q].(gS GA[\[Mu]].GA[7])]

Out[1] = gS^2*DiracTrace[DiracGamma[Momentum[q]] . DiracGamma[LorentzIndex[FCGV["li241"]]] .
    DiracGamma[6] . DiracGamma[Momentum[k]] . 
    DiracGamma[LorentzIndex[FCGV["li241"]]] . DiracGamma[7]]
 + gS^2*DiracTrace[DiracGamma[Momentum[q]] . DiracGamma[LorentzIndex[FCGV["li241"]]] .
    DiracGamma[6] . DiracGamma[Momentum[q]] .
    DiracGamma[LorentzIndex[FCGV["li241"]]] . DiracGamma[7]]

However, the following example does not work: the sole addition of the SUNT matrices (e.g. part of a fermion-fermion-gluon vertex) breaks the ordering of the Gamma matrices after the expansion (look at the first term for example: GA[7] comes first and is not DOT-multiplied with the term on its right):

In[2] := FCCanonicalizeDummyIndices@DiracTrace[GS[q].(gS SUNT[b] GA[\[Mu]].GA[6]).GS[k + q].(gS SUNT[a] GA[\[Mu]].GA[7])]

Out[2] = gS^2*DiracTrace[DiracGamma[Momentum[k]] . DiracGamma[LorentzIndex[FCGV["li341"]]] .
    DiracGamma[7] * DiracGamma[Momentum[q]] . DiracGamma[LorentzIndex[FCGV["li341"]]] .
    DiracGamma[6]*SUNT[SUNIndex[a]]*SUNT[SUNIndex[b]]]
 + gS^2*DiracTrace[DiracGamma[Momentum[q]] . DiracGamma[LorentzIndex[FCGV["li341"]]] .
    DiracGamma[6] * DiracGamma[Momentum[q]] . DiracGamma[LorentzIndex[FCGV["li341"]]] .
    DiracGamma[7]*SUNT[SUNIndex[a]]*SUNT[SUNIndex[b]]]

I've installed FeynCalc and FeynArt using online installation, in mathematica 10.3.
I opened the file "QEDElectronMuonScatteringTree" from the "example" folder in FeynCalc folder. Howerver, when the code reached to "Generate Feynman diagrams" I got this error:

ln[7]:= topElMuScat = CreateTopologies[0, 2 -> 2];
diagsElMuScat = InsertFields[topElMuScat, {F[2, {1}], F[2, {2}]} ->
{F[2, {1}], F[2, {2}]}, InsertionLevel -> {Classes},
Model -> "SM", ExcludeParticles -> {S[1], S[2], V[2]}];
Paint[diagsElMuScat, ColumnsXRows -> {1, 1}, Numbering -> None,SheetHeader->None,ImageSize->{256,256}];

During evaluation of In[7]:= TagSetDelayed::tagnf: Tag FourVector not found in -Overscript[mom_, ]^mu__. >>

Out[8]= $Aborted

I don't know if it is a problem related to Mathematica or FeynCalc.

Hi,

I'm performing the following computation with FeynCalc 9.0.1

num=Spinor[ps].DiracMatrix[mu].DiracSlash[k].PR.Spinor[pb].Spinor[
  p1].DiracSlash[k].DiracMatrix[mu].PL.Spinor[p2]

num*FeynAmpDenominator[PropagatorDenominator[k, mt], 
 PropagatorDenominator[k, 0], PropagatorDenominator[k, mHp], 
 PropagatorDenominator[k, mW]]

Simplify[OneLoop[k, %] /. D -> 4]

For some strange reason, Feyncalc changes the order of the spinors from (s)(b)(1)(2) to (s)(1)(b)(2) -- which is not manifestly Lorentz invariant. How can I prevent this type of behavior?

Many thanks in advance.
O.

The Short introduction link is broken. It should be FeynCalc/tutorials/Intro instead of FeynCalc/ref/Intro

The subheadings below are confusing and difficult to open because the cell brackets are not visible. Suggest setting the ShowGroupOpener and WholeCellGroupOpener options to True on these specific cells.

Hi,

I used the auto installer script and it looked like FeynArts was patched successfully. When I execute https://github.com/FeynCalc/feyncalc/blob/master/FeynCalc/Examples/EW/EWMuonDecayTree.m with math -script EWMuonDecayTree I get

Computation of the matrix element squared for the decay of a muon into an electron, an electron anitnueutrino and a muon neutrino in Electroweak Theory at tree level.

OptionValue::nodef: Unknown option SMP for FCPrepareFAAmp.
Check with the literature: !!! WRONG !!!

same result in an interactive session. Mathematica version is 10.2.0 for Linux x86 (64-bit) (July 28, 2015). When printing the two results that are compared, I see

(2*EL^4*Pair[Momentum[p], Momentum[p2]]*Pair[Momentum[p1], Momentum[p3]])/(MW^4*SW^4)
64*G_F^2*Pair[Momentum[p], Momentum[p2]]*Pair[Momentum[p1], Momentum[p3]]

which is at least equal when you use the tree-level relations for G_F and so on. So is the example just out of date or is something wrong with my installation? I had HEPMath already installed that also uses FeynArts. I moved HEPMath out of ~/.Mathematica/Applications, deleted the FeynArts folder in FeynCalc, downloaded FeynArts-3.9 freshly and put it in FeynCalc again. At startup of FeynArts he patched again but the problem with the example persisted.

• Your Mathematica version

12.0.0 for Linux x86 (64-bit) (May 19, 2019)

• Your FeynCalc version

9.3.1

• Did you try to reinstall FeynCalc (stable version) using the automatic installer to make sure that you have the latest bugfixes?

Yes

I tried to use FermionSpinSum in WolframScript.
In[2]:= Spinor[p].Spinor[q] Spinor[q].Spinor[p] // FermionSpinSum

However, I just got the following error message, and I cannot get correct result.
FermionSpinSum::spinorsleft: Error! After applying FermionSpinSum to all spinor chains the output still contains spinors.
Out[2]= u[p] . u[q] u[q] . u[p]

Hi,
is there a way to deal with Majorana fermions in Feyncalc?

Cheers
Luca

Not sure if this is normal or not, but got a weird error when running the internet install for the latest Stable release on Mathematica 10:

neither SP[k, Polarization[k, I]] neither Pair[ Momentum[k], Momentum[ Polarization[k, I] ] ] are vanishing in feynCalc 9 (mathematica 9 ).

AntiSymmetrize is no longer found. Also, there is a Symmetrize function in the Mathematica core language now. When I load my old version of feyncalc AntiSymmetrize works.

The in feyncalc, included example of a QEDComptonScatteringTree returns the wrong value.
Mathematica version 11.0.0.0
Mac OS X x86 (32-bit, 64-bit kernel)
Using an out of the box installation of mathematica and feyncalc using
Import["https://raw.githubusercontent.com/FeynCalc/feyncalc/master/install.m"]; InstallFeynCalc[]

I would love to know what is wrong since this makes no sense to me at all.
It might be the setmandelstram?
QEDComptonScatteringTree.pdf