**Next message:**Peter Meinzinger: "StandardMatrixElements"**Previous message:**Pedro Ruiz-Femenia: "Larin scheme for gamma5"**In reply to:**Pedro Ruiz-Femenia: "Larin scheme for gamma5"**Next in thread:**Pedro Ruiz-Femenia: "Larin scheme for gamma5"**Messages sorted by:**[ date ] [ thread ] [ subject ] [ author ]**Mail actions:**[ respond to this message ] [ mail a new topic ]

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
*

*>
*

**Next message:**Peter Meinzinger: "StandardMatrixElements"**Previous message:**Pedro Ruiz-Femenia: "Larin scheme for gamma5"**In reply to:**Pedro Ruiz-Femenia: "Larin scheme for gamma5"**Next in thread:**Pedro Ruiz-Femenia: "Larin scheme for gamma5"**Messages sorted by:**[ date ] [ thread ] [ subject ] [ author ]**Mail actions:**[ respond to this message ] [ mail a new topic ]

*
This archive was generated by hypermail 2b29
: 08/19/17-02:00:02 AM Z CEST
*