Hi Nikita,
thanks for your example. I think that this way it is indeed much simpler
to nail down the problem.
The case where A and B both represent just one Dirac matrix is
of course a bit trivial, since here one gets traces over an odd number
of gamma matrices which automatically vanish. Thus one gets zero on both
sides.
The non-trivial case with 3 matrices is of course more interesting. I
agree with you that FORM (see the code attached) can't show this
equality out of the box.
With FeynCalc only (i.e. without FORM)
<< FeynCalc`
$West = False;
r1 = DiracTrace[
GA[y1, y2, y3].GA[a].GS[k].GA[b].(1 - GA[5])].DiracTrace[
GA[z1, z2, z3].GA[b].GS[p].GA[a].(1 - GA[5])]
r2 = (r1 /. DiracTrace -> Tr) // Contract;
r3 = 4*Tr[GA[y1, y2, y3].GS[p].(1 - GA[5])]*
Tr[GA[z1, z2, z3].GS[k].(1 - GA[5])] // Contract;
(r2 - r3)//Schouten//Simplify
I can simplify the difference to
32 I (-LC[y3, z1, z2, z3] MT[y1, y2] SP[k, p] +
LC[y2, z1, z2, z3] MT[y1, y3] SP[k, p] -
FV[p, z3] MT[y1, y3] LC[y2, z1, z2][k] +
FV[p, z2] MT[y1, y3] LC[y2, z1, z3][k] -
FV[p, z1] MT[y1, y3] LC[y2, z2, z3][k] +
FV[p, z3] MT[y1, y2] LC[y3, z1, z2][k] -
FV[p, z2] MT[y1, y2] LC[y3, z1, z3][k] +
FV[p, z1] MT[y1, y2] LC[y3, z2, z3][
k] + (-FV[p, y3] MT[y1, y2] + FV[p, y2] MT[y1, y3]) LC[z1, z2,
z3][k])
This is, however, still non-vanishing.
The only thing one can see is that the difference is antisymmetric in y2
and y3, so that contracting it with a tensor that is symmetric in these
two indices would make the whole thing vanish.
Contract[((r2 - r3) // Schouten // Simplify) MT[y2, y3]] // Schouten
I think that before contacting FORM developers one should first try to
understand what is so tricky about this relation.
Could you may be provide me a reference for the occurence of your
formula (obviously I'm not familiar with it)? I want to understand how
the general proof goes and what are the steps that might cause problems
with computer codes.
Does this relation hold only in 4 or also in D-dimensions (if yes, in
what scheme, naive or t'Hooft Veltman?). If it is a purely 4D equality
then I suppose that the proof might involve SPVAT
(scalar,pseudoscalar,vector,axial vector, tensor) decomposition of A and
B. This might be a good starting point to investigate things.
Cheers,
Vladyslav
Am 08.08.2015 um 02:25 schrieb Nikita Belyaev:
> Dear Vladyslav,
>
> Sorry for such a late reply, we've been investigating the problem in much more details.
>
> Looks like it is some kind of a general problem.
>
> The most illustrating example is the following.
> To calculate the multiplication of traces of gamma matrices we can use one useful formula. Let's write it in the following way:
>
> Tr[A.GA[a].GS[k].GA[b].(1-GA[5])].Tr[B.GA[b].GS[p].GA[a].(1-GA[5])]=4*Tr[A.GS[p].(1-GA[5])]*Tr[B.GS[k].(1-GA[5])],
>
> where A and B are any possible combinations of gamma matrices, p and k - Feynman slashed 4-vectors.
> The proof of the general case can be founded in special literature, but we've proved this formula for the cases when both A and B are sets of three and one gamma matrices (for example, A=GA[a].GA[b].GA[c] and A=GA[a] respectively).
>
> We've checked this formula in FeynCalc and calculated the difference between left and right part of this equation and we got zero answer for the case when A and B contains only one gamma matrix.
> Then we've checked the same for the case when A and B are sets of three gamma matrices. In this case we got the imaginary answer which looks the same as the imaginary part in our previous trace calculation. Real part was zero.
>
> According to our calculation of u^3 terms we also have done some checks. Our initial general calculation, as you know, contains the imaginary terms proportional to u^3.
> But when we simplified the related expressions by hand and reduced the amount of gamma matrices by using few mathematical tricks the result no longer contains the imaginary part.
> We can provide you a working example of that if you are going to re-check this.
>
> So the problem should be hidden somewhere here, calculation of long chain of gamma matrices causes this bug.
>
> Should we contact the FORM developers or you have some better ideas?
>
> Best Regards,
> Nikita Belyaev
>
This archive was generated by hypermail 2b29 : 09/04/20-12:55:05 AM Z CEST