bugs within the Larin Gamma5 scheme

[ygtw1]

• Your Mathematica version

13.1

• Your FeynCalc version

10.1

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

Yes

• Does your Mathematica initialization file contain statements that might influence the behavior of FeynCalc? Sometimes external packages may modify `init.m` in unusual ways, causing troubles for other codes.

No

• Please provide a minimal working example that illustrates the problem and works on a fresh kernel. The example should be provided either by writing the code (as `InputForm`!) directly in the issue text or by attaching a Mathematica notebook. Please do not post code samples as screenshots, PDF files etc.: Those essentially require us to retype everything by hand, which is annoying and also time consuming. Please explain the difference between the current behavior and the expected behavior.

(*input*)

<< FeynCalc`;
FCSetDiracGammaScheme["Larin"];
f[ex_] := {TR[ex] /. p2 -> p1, 
   DiracSimplify[DiracTrace[ex]] /. p2 -> p1, TR[ex /. p2 -> p1], 
   DiracSimplify[DiracTrace[ex /. p2 -> p1]]} // Contract // 
 FullSimplify;

example1 = 
GSD[p1] . DiracSigma[GAD[bb], GAD[Lor1]] . GA[5] . GSD[p2] . 
 GA[5] . DiracSigma[GAD[bb], GAD[Lor1]];
f@%

example2 = 
FCI[GSD[p1] . GA[5] . GAD[bb] . GA[5] . GSD[p2] . GA[5] . 
   GAD[bb1] . GAD[bb2] . GAD[Lor1] LCD[bb, bb1, bb2, Lor1]];
f@%

example3 = 
FCI[GSD[p1] . GA[5] . GAD[bb] .(*GA[5].*)GSD[p2] .(*GA[5].*)
   GAD[bb1] . GAD[bb2] . GAD[Lor1] LCD[bb, bb1, bb2, Lor1]];
f@%

(*output*)

During evaluation of In[1]:= FeynCalc 10.1.0 (stable version). For help, use the online documentation, visit the forum and have a look at the supplied examples. The PDF-version of the manual can be downloaded here.

During evaluation of In[1]:= If you use FeynCalc in your research, please evaluate FeynCalcHowToCite[] to learn how to cite this software.

During evaluation of In[1]:= Please keep in mind that the proper academic attribution of our work is crucial to ensure the future development of this package!

Out[5]= {-(4/3) (D-4) (D-3) (D-2) (D-1) p1^2,-(4/3) (D-4) (D-3) (D-2) (D-1) p1^2,2/3 (D-5) (D-4) (D-3) (D-2) (D-1) p1^2,2/3 (D-5) (D-4) (D-3) (D-2) (D-1) p1^2}

Out[7]= {-(2/3) I (D-3)^2 (D-2) (D-1) (D ((D-23) D+80)-4) p1^2,-(2/3) I (D-3)^2 (D-2)^2 (D-1) ((D-21) D+74) p1^2,-(2/3) I (D-3)^2 (D-2)^2 (D-1) ((D-21) D+74) p1^2,-(2/3) I (D-3)^2 (D-2)^2 (D-1) ((D-21) D+74) p1^2}

Out[9]= {8 I (D-3) (D-2) (D-1) p1^2,8 I (D-3) (D-2) (D-1) p1^2,-4 I (D-6) (D-3) (D-2) (D-1) p1^2,-4 I (D-6) (D-3) (D-2) (D-1) p1^2}

[vsht]

Many thanks for the bug report. Indeed, the implemented formula was not correct, which resulted in the
described issues.

Please check if it now works for you.

Concerning the example with an external Levi-Civita, this case is kind of tricky, so I added an extra note to the manual
about it:
https://github.com/FeynCalc/feyncalc/blob/master/FeynCalc/Documentation/Markdown/Extra/Gamma5.md

[ygtw1]

With the updated version of FeynCalc, example1 and example3 are working correctly, but it seems example2 still has issues. Here is my test.

(input)

FCSetDiracGammaScheme["Larin"];
f[ex_] := Contract[TR[ex] /. p2 -> p1] - Contract[TR[ex /. p2 -> p1]] // FullSimplify;

GSD[p1] . GA[5] . GAD[bb] . GA[5] . GSD[p2] . GA[5] . GAD[bb1] . GAD[bb2] . GAD[Lor1] // f;
% // FCE // StandardForm
%% LCD[bb, bb1, bb2, Lor1] // Contract // FullSimplify

(output)

-4 I (-3 + D) (5 LCD[bb, bb1, bb2, Lor1] SPD[p1, p1] +
(-9 + D) (FVD[p1, Lor1] LCD[bb, bb1, bb2][p1] - FVD[p1, bb2] LCD[bb, bb1, Lor1][p1] +
FVD[p1, bb1] LCD[bb, bb2, Lor1][p1]) +
5 FVD[p1, bb] LCD[bb1, bb2, Lor1][p1])

32 I (D-4) (D-3)^2 (D-2) (D-1) p1^2

[vsht]

This particular case is special in the sense that here you end up with 4 Levi-Civita tensors in the intermediate
expressions.

Unfortunately, in the Larin scheme it really matters how those tensors are paired with each other, see the discussion
on p.6 of 1506.04517. At this point FeynCalc has no way to know, which $\gamma^5$ or Levi-Civita comes from where.
Furthermore, there's also no generic rule, on how to do it.

It's more like people know that a particular pairing gives a correct result in the given calculation,
but this doesn't mean that doing the same in a different calculation won't return a wrong result.

But it's also true that in such cases FeynCalc shouldn't return arbitrary results without any warnings.

The only fix I can come up with is to disable automatic contractions of Eps tensors for all cases where
the code can detect multiple $g^5$ matrices inside a trace. Then it's up to the user to figure out which
ordering/pairing is the correct one, since this is not something a code can do for you.

Now your example simplifies to zero, but of course it is not being completely evaluated anymore

FCSetDiracGammaScheme["Larin"];
f[ex_] := Contract[TR[ex] /. p2 -> p1] - Contract[TR[ex /. p2 -> p1]];

diff = GSD[p1] . GA[5] . GAD[bb] . GA[5] . GSD[p2] . GA[5] . 
    GAD[bb1] . GAD[bb2] . GAD[Lor1] // f;
diff // FRH // FCCanonicalizeDummyIndices // Simplify

[ygtw1]

Thank you for your reply!
I have learned the following three points:

1. When contracting more than two Eps-tensors, the result depends on the order of contractions.
2. If the Diractrace contains more than two Gamma5​ matrices, thereby requiring the contraction of more than two Eps-tensors, the Larin scheme might not be automated in FeynCalc.
3. For the Diractrace containing two Gamma5​ matrices within the Larin scheme, the result depend on which Gamma5 ​is replaced by GAD[u].GA[5] = 1/6 I GAD[a, b, c] LCD[a, b, c, u]. Therefore, it is the most appropriate to automatically calculate the Diractrace containing only one Gamma5​ matrice within the Larin scheme in FeynCalc.

[ygtw1]

And I find another problem as following.
FCSetDiracGammaScheme["Larin"];

(input)

GAD[Lor1].GA[5].GAD[Lor2].GA[5];
TR[%] // Factor // FCE // StandardForm
Contract[TR[%% /. GAD[Lor1].GA[5] -> 1/6 I GAD[a, b, c] LCD[a, b, c, Lor1]]] // Factor // FCE // StandardForm
GAD[Lor1].GA[5].GA[5].GAD[Lor2];
TR[%] // Factor // FCE // StandardForm
Contract[TR[%% /. GAD[Lor1].GA[5] -> 1/6 I GAD[a, b, c] LCD[a, b, c, Lor1]]] // Factor // FCE // StandardForm

(ouput)
-(2/3) (-3 + D) (-2 + D) (-1 + D) MTD[Lor1, Lor2]
-(2/3) (-3 + D) (-2 + D) (-1 + D) MTD[Lor1, Lor2]
4 MTD[Lor1, Lor2]
2/3 (-3 + D) (-2 + D) (-1 + D) MTD[Lor1, Lor2]

[vsht]

The case with two neighboring $\gamma^5$ is not really covered by Larin's scheme. If you look at
Eq. 9 in 1506.04517, there are always at least two $\gamma^{\mu_i}$ separating two $\gamma^5$, so I don't think that the formula is applicable to $tr(\gamma^\mu \gamma^5 \gamma^5 \gamma^\nu) $.

Furthermore, to my knowledge, the relation $(\gamma^5)^2 = 1$ must be respected in all schemes. Or at least I've never seen a scheme where it's not true. Especially since the Larin scheme is supposed to imitate BMHV where $\gamma^5$
is 4-dimensional.

In FeynCalc all $(\gamma^5)^2$ strings are immediately replaced by unity in all schemes. So it will never happen that
in $tr(\gamma^\mu \gamma^5\gamma^5 \gamma^\nu )$, the combination $\gamma^\mu \gamma^5$ will be relplaced by the Larin prescription.

[ygtw1]

But sometimes two neighboring γ5 can not be detected by FeynCalc until the expression is expanded.
In such cases, FeynCalc may produce inconsistent results.
Here is an example.
(input)
FCSetDiracGammaScheme["Larin"];
test = (mb + GSD[p1]).GAD[Lor1].GA[5].(mc - GSD[p2]). GA[5].GAD[Lor1]
test1 = Expand@DotExpand@test
test2 = test1 /. {GA[5].GA[5] -> 1} /. {GAD[Lor1].GA[5] -> 1/6 I GAD[a, b, c] LCD[a, b, c, Lor1]}
(Contract[DiracSimplify@DiracTrace[#] // FRH] /. {FCI@SPD[p1, p2] -> mb mc} // Factor) & /@ {test, test1, test2}
(output)

[vsht]

Yes, there seem to be too many edge cases, where it's not really clear how one should resolve
the expression according to the Larin-Scheme. Perhaps you should use some other code for the time being...

[vsht]

I actually got in touch with the authors of 1506.04517 regarding these issues.

Their answer was essentially that the prescription described in the paper has been tailored for DIS calculation mentioned there and is not automatically generalizable to any g^5 calculation.

There their guiding principle for dealing with two g^5 in the trace was to reproduce the known correct results. The cases you mentioned do not happen there. They may happen in general, but again, one would then need to work out a way for handling them using the problem at hand.

The upshot is that when a trace contains two g^5, Larin's scheme is not algebraically consistent without additional rules. These rules are fixed depending on the calculation one is doing (e.g. to preserve certain symmetries or reproduce known results) and are not generalizable.