Hi Pedro,
thanks for your mail. Your guess is fully correct. In fact,
many FeynCalc function have an "undocumented" option FCVerbose
that allows one to follow the internal evaluation.
With
$Larin = True;
DiracTrace[GAD[mu].GA[5].GAD[mu].GA[5], DiracTraceEvaluate -> True,
FCVerbose -> 3]
you can see that the gamma^5 between two other matrices gets replaced
by the epsilon tensor with three gamma's after DiracTrick. The latter is
responsible for the simplification of chains of Dirac matrices. Looking
at
DiracTrick[GAD[mu].GA[5].GAD[mu].GA[5], InsideDiracTrace -> True,
FCVerbose -> 3]
provides even more insight.
As to the second part of your question, the issue here is, that,
in general, Larin's scheme doesn't allow one to anticommute gamma^5
matrices in a trace with an even number of gamma^5. I know that this
is what people usually do in QCD calculations and in most cases this
works out as it should, but nevertheless this trick is not guaranteed to
give correct results in all cases.
On the other hand, I'm always in favor of giving people the right to
choose how they do their calculations, as long as they understand the
implications. In my view the only acceptable solution here is to
implement a second Larin's scheme with the property that you request, so
that traces with an even number of g^5 will give the same result as in NDR.
In fact, this is probably also a good point to improve the way how
traces are calculated in Larin's scheme, as the current performance is
apparently very bad. For comparison, with the current development
version (git master branch) I get
$BreitMaison = True;
$Larin = False;
DiracTrace[GAD[i1, i2, i3, i4, i5, i6, i7, i8].GA[5],
DiracTraceEvaluate -> True]; // AbsoluteTiming
{0.322333,Null}
$BreitMaison = False;
$Larin = True;
DiracTrace[GAD[i1, i2, i3, i4, i5, i6, i7, i8].GA[5],
DiracTraceEvaluate -> True]; // AbsoluteTiming
{5.56139,Null}
so Breitenlohner-Maison currently beats Larin hands down.
To my knowledge, the fastest algorithm for Larin's scheme currently
available is Eq. 10 in arXiv:1506.04517. Of course, Mathematica version
will be slower than the FORM implementation, but the speed up as
compared to what we have now should be considerable.
The only issue is that I quite busy at the moment, so it will take me
some time O(2-3 weeks) to take care of that.
Cheers,
Vladyslav
Am 01.02.2017 um 16:02 schrieb Pedro Ruiz-Femenia:
> Hi Vladyslav,
>
> I seem to get a different result for a trace with an even number of gamma5's using Larin's prescription ($Larin = True) as compared to the naive anticommuting scheme: (I am using FeynCalc 9.2.0)
>
> In[1]:= trace:=Tr[GAD[mu].DiracMatrix[5].GAD[mu].DiracMatrix[5]]
>
> In[2]:=
> $Larin = False;
> trace
> Out[2]:= -4D
>
> In[3]:=
> $Larin = True;
> trace
> Out[3]:= -(2/3) (D-3) (D-2) (D-1) D
>
> The results differ for D!=4. The reason may be that with the Larin's prescription implemented in FeynCalc, GAD[mu].DiracMatrix[5] at the end of the trace is first replaced by the LeviCivita tensor with three gamma's, and the resulting trace with the remaining gamma5 gives another LeviCivita. Then the contraction of the two tensors is done treating them as D-dimensional. This gives something different to what you will get putting gamma5's together in the first place.
>
> I can of course avoid the problem by separating traces with odd and even number of gamma5's, and using NDR on the latter. But sometimes (this was my case) one carelessly writes the expression for the full trace, and one expects that terms with even number of gamma5's will be the same no matter which prescription has been set. Is there a way to set Larin's gamma5 scheme in FeynCalc to avoid the issue above?
>
> Thanks for your support of FeynCalc!
>
> Pedro
>
This archive was generated by hypermail 2b29 : 09/04/20-12:55:05 AM Z CEST