Name: V. Shtabovenko (email_not_shown)
Date: 08/14/19-05:17:41 PM Z


Hi,

in general, contracting two eps tensors yields

e^{i1 i2 i3 i4} e_{i1 i2 i3 i4} = 24 e^{0123} e_{0123}

Now the point is that you have some freedom in choosing what
eps^{0123} should be. Notice that that whatever choice you make,
the result for eps_{0123} will be the opposite of that value, since
the signature of the Minkowski spacetime is either (1,-1,-1,-1) or
(-1,1,1,1).

Notice that in the Euclidean spacetime the signature is (1,...,1) so
there you always have

e^{i1 ... in} e_{i1 ... in} = e^{i1 ... in}^2 = n!

The "standard" choice (e.g. what is used in Peskin and Schroeder, cf.
their Notations and Conventions chapter) is

e^{0123} = 1 => e_{0123} = - 1

so that e^{i1 i2 i3 i4} e_{i1 i2 i3 i4} = - 24.

Bjorken and Drell, on the contrary, use

e_{0123} = 1 => e^{0123} = - 1

but the result is still -24.

Now FORM uses e^{0123} = I (sic!), so that the result of the
corresponding contraction should actually be 24 even in the
Minkowski spacetime. However, since (in my understanding)
FORM treats the eps tensors in a "Euclidean fashion",
the contraction sort of corresponds to calculating

e^{i1 i2 i3 i4} e^{i1 i2 i3 i4} = 24 e^{0123}^2 = - 24

There is more on it in the chapter 15 of the FORM manual.

FeynCalc like FORM doesn't distinguish between upper and lower indices,
but we account for e^{0123} = - e_{0123} in the eps^2 contractions, so
that setting e^{0123} = I would give you 24 as expected.

This is controlled by the global variable $LeviCivitaSign which specifies
the value of e_{0123} and can be set to +/- 1 or +/- I.

The default value -1 follows the Peskin convention. With

$LeviCivitaSign = -I;

evaluating

LC[a, b, c, d]^2 // Contract

returns 24.

However, an important point is that the choice of e^{0123} should not modify
the value of the matrix element squared. After all, you don't want a
positive |M|^2
become negative only because you use a different convention.

So even when you set e^{0123}=I you have to account for that when taking the
complex conjugate of the matrix element. If eps is purely imaginary,
then of course
(e^{mu nu rho si})^* = - e^{mu nu rho si}, e.g.

$LeviCivitaSign = -1
LC[a, b, c, d] M*ComplexConjugate[LC[a, b, c, d] M]
% // Contract

and

$LeviCivitaSign = -I
LC[a, b, c, d] M*ComplexConjugate[LC[a, b, c, d] M]
% // Contract

which yields the same (as it should). So I don't know which conventions
MadGraph
is using, but your discrepancy must be coming from elsewhere.

PS Changing the values of e^{0123} also changes the values of the Dirac
matrix
traces with one gamma^5. The FORM choice eliminates an overall I in the
trace
formula, which of course has its advantages in large calculations.

Cheers,
Vladyslav

Am 14.08.19 um 16:07 schrieb Karl:
> Hi,
>
> i am calculating the tree level process e+ e- -> t t~ only with an Z
> exchange, so no photon is involved. After the calculation i took this
> squared element and wanted to check whether it fits numerically for a
> specific phase space point by comparing it for example with MadGraph.
> It turns out that both values differ, so i calculated this process by
> hand and i see that i obtain a different result than FeynCalc does
> and my result fits with
>
> the result from MadGraph. The difference can be traced back to the
> contraction of the Levi Civita tensors occurring due to the gamma5 in
> the vertices. Your implementation seems to use the opposite sign in
> comparison to the usual definitions and this sign difference causes
>
> the result to be wrong. You can see it for example in the help menu
> when you enter "Levi Civita" in the search field. There you find the
> following example:
>
> In[7]:= t1 = LeviCivita[\[Alpha], \[Beta], \[Gamma],
> \[Rho]].LeviCivita[\[Alpha], \ \[Beta], \[Gamma], \[Rho]]
>
> In[8]:= Contract[t1]
>
> Out[8]= -D^4+6 D^3-11 D^2+6 D
>
> Setting D->4 in the result leads to -24, contrary to the usual
> definition of 24. In the calculation one obtains:
>
> In[150]:= LeviCivita[\[Mu], \[Mu]C, \[Nu], \[Rho]]* LeviCivita[\[Mu],
> \[Mu]C, \[Alpha], \[Beta]] // Contract
>
> Out[150]= 2 Overscript[g, _]^(\[Alpha]\[Rho]) Overscript[g,
> _]^(\[Beta]\[Nu])-2 Overscript[g, _]^(\[Alpha]\[Nu]) Overscript[g,
> _]^(\[Beta]\[Rho])
>
> where the sign is again different to the usual definition. Is it
> possible to cure this different sign such that i obtain a correct
> result? Ultimately, i would like to calculate processes like e+ e- ->
> t t~ g or with another gluon in the final state. By the way your
> result is the same as in FORM.
>
> Thank you for your help.
>



This archive was generated by hypermail 2b29 : 09/04/20-12:55:05 AM Z CEST