search

FeynCalc / feyncalc

Mathematica package for algebraic calculations in elementary particle physics.
https://feyncalc.github.io
GNU General Public License v3.0
309 stars 87 forks source link

Momentum normalization in fermion spin sums #76

Closed cverhaaren closed 3 years ago

cverhaaren commented 3 years ago

No

The issue seems to be with the normalization of momenta in fermion spin sums. When one of the momentum is scaled by a factor this factor is put with the mass, rather than with the momentum, leading to numerical mismatches down the line:

In[1]:= FermionSpinSum[ SpinorVBar[p1, m].SpinorU[p2, m]SpinorUBar[p2, m].SpinorV[p1, m]] FermionSpinSum[ SpinorVBar[2 p1, m].SpinorU[p2, m]SpinorUBar[p2, m].SpinorV[2 p1, m]]

Out[1]= DiracTrace[(-m + DiracGamma[Momentum[p1]]).(m + DiracGamma[Momentum[p2]])]

Out[2]= DiracTrace[(-2 m + DiracGamma[Momentum[p1]]).(m + DiracGamma[Momentum[p2]])]

The second output should instead be

Out[2]= DiracTrace[(-m + 2*DiracGamma[Momentum[p1]]).(m + DiracGamma[Momentum[p2]])]

vsht commented 3 years ago

This particular bug can be fixed, but there remains a fundamental issue that the momenta inside spinors are very sensitive objects.

Essentially, the sign of the momentum decides whether the spinor is of u- or v-type, cf. https://github.com/FeynCalc/feyncalc/wiki/FAQ#spinors or the manual of FeynArts

This is also the reason why rewritings of external momenta should be done via FCReplaceMomentum and not direct rules. The former will make sure that the momenta inside spinors (and polarization vectors) are not altered, while the latter might mess things up considerably.

Therefore, I would actually recommend to abstain from rescaling the momenta inside spinors. If the rescaling at some point introduces a sign change, the Dirac chain will be messed up and the result will be incorrect.

Is there a real need for such rescaling that cannot be achieved otherwise (i.e. by renaming the momenta)? Notice that other spinor related function such as DiracEquation might also not work properly with rescaled spinors.

cverhaaren commented 3 years ago

It is likely that one can always define the momentum so that this issue is avoided. I spent a day trying to track it down because it was convenient for the problem I was working on to define the spinor momenta as p1=p/2+k and p2=p/2-k, as the sum p and difference 2k of the momenta were more useful in understanding the results. This type of decomposition is sometimes used when dealing with bound states, for instance. The code seems to deal with p+k and p-k without trouble, but the factors of 2 threw things off considerably.

So, whether or not the code needs to be adapted I don't know, but anyone using the spinors should be aware of the issue so that they can make sure they do not run into it. Perhaps it is already in the documentation and I missed it.

vsht commented 3 years ago

If you are dealing with bound states, I suppose that you are using some kind of projectors applied to your spinor chains in order to extract particular quantum numbers? In this case the projectors can be applied to the original chains and after that (when there are no spinors left) one switches to the more suitable 2-body kinematics.

At least this is how I deal with quarkonium calculations in NRQCD.

So, whether or not the code needs to be adapted I don't know, but anyone using the spinors should be aware of the issue so that they can make sure they do not run into it. Perhaps it is already in the documentation and I missed it.

This is why I'm actually more inclined to put a check on such scaled momenta in FermionSpinSum and DiracEquation and abort the evaluation if the prefactors and not +/-1. But I need to think about that more. Certainly, something should be done about this.

vsht commented 3 years ago

Should be now fixed. The relevant functions were equipped with internal checks to detect illegal Spinor-syntax and abort the evaluation accordingly.

cverhaaren commented 3 years ago

Sounds good.

Thanks!

On Thu, Nov 26, 2020 at 10:10 AM Vladyslav Shtabovenko < notifications@github.com> wrote:

Should be now fixed. The relevant functions were equipped with internal checks to detect illegal Spinor-syntax and abort the evaluation accordingly.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/FeynCalc/feyncalc/issues/76#issuecomment-734430742, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJPQGMA7KLJI3FSSQ6SXTULSR2KWTANCNFSM4SB5W4YQ .