just to avoid the confusion: Aliaksandr is right regarding the
calculation of Pedro. My previous e-mail only concerned the muon
decay example in FeynCalc 9.2 that gave incorrect amplitude squared.
Apart from that, the mistake of forgetting to rename dummy indices
when squaring an expression is unfortunately quite common among
As I have already mentioned it several times on this
mailing list, for performance reasons FeynCalc usually does not check
if an expression contains dummy indices that violate Einstein's
convention. BTW, with FORM it is the same, you can write something
L res= exp1*exp2;
and FORM will not complain about it. Having said that, the development
version of FeynCalc does contain some improvements to mitigate such issues
1) ComplexConjugate now automatically applies FCRenameDummyIndices. This
is why the above mentioned muon decay calculation that I "backported"
from the development version did not work properly in FeynCalc 9.2.
2) There is a new function called FCCheckSyntax
FCCheckSyntax[expr] attempts to detect mistakes and inconsistencies in
the user input. The function returns the original expression but will
abort the evaluation if it thinks that the input is incorrect.
Notice that false positives are possible and it is not guaranteed that
the input which passes FCCheckSyntax is indeed fully correct.
FCCheckSyntax is also an option for several FeynCalc routines. If set to
True, those functions will try to check the syntax of the input
expressions to detect possible inconsistencies. However, on large
expressions such checks may cost a lot of performance, which is why this
option is set to False by default.
which can prevent the given problem
j\[Mu] = Gf/Sqrt*Spinor[p3, 0].GA[a].(1 - GA).Spinor[p1, m\[Mu]];
je = Gf/Sqrt Spinor[p4, me].GA[b].(1 - GA).Spinor[-p2, 0];
M = (j\[Mu] MT[a, b] je // Contract);
FermionSpinSum[M*ComplexConjugate[M]] // FCCheckSyntax
FCCheckSyntax::failmsg: Error! FCCheckSyntax has found an inconsistency
in your input expression and must abort the evaluation. The problem
reads: More than two repeating indices in <<2030>>
Am 28.02.2018 um 06:49 schrieb Aliaksandr Dubrouski:
> Btw. do not forget to rename Lorentz indices in the conjugated matrix
> element after contraction from a to b.
> 2018-02-27 22:29 GMT+03:00 Pedro <email@example.com
> Dear all,
> I am calculating a simple diagram and the program is returning the
> wrong answer.
> I have looked up my code thousand times and I don't think it has an
> error (plus I run the EWMuonDecayTree example and it gave me the
> same wrong answer....)
> Is this a bug or am I missing something very trivial?
> The proble is the following:
> I am calculating the muon decay matrix element, using the following
> (* Beging of the code *)
> (*This is Gf/SqrtOverscript[u,
> _](p3)\[Gamma]^a(1-\[Gamma]^5)u(p1) (muon curent) *)
> j\[Mu] = Gf/Sqrt*Spinor[p3, 0].GA[a].(1 - GA).Spinor[p1, m\[Mu]];
> (*This is Gf/SqrtOverscript[u,
> _](p4)\[Gamma]^a(1-\[Gamma]^5)v(p2) (electron curent) *)
> je = Gf/Sqrt Spinor[p4, me].GA[b].(1 - GA).Spinor[-p2, 0];
> (*This is to contract the \[Gamma] matrices*)
> M = (j\[Mu] MT[a, b] je // Contract);
> (* Matrix element <|M|^2>. Should be 64 Gf^2 (p1.p2)(p3.p4), see
> e.g. Griffths *)
> FermionSpinSum[M*ComplexConjugate[M]] /. DiracTrace -> TR
> (*End of the code *)
> The result it is giving is: 64 Gf^2 (p1.p3)(p2.p4) and not the well
> known 64 Gf^2 (p1.p2)(p3.p4).
> Now, if I run the EWMuonDecayTree example, it will show in the last line
> Check with the Okun, Chapter 3.2:CORRECT.
> But only because it is checking the final total decay rate and not
> the intermediate step (by lucky, it gave the correct result). If
> you run the EWMuonDecayTree, in the third output, after the Feynman
> Diagram, you will find the equivalent expression. Notice that the
> program gives ~(k.q1)(p.q2) which should be ~(k.q2)(p.q1)
> I am currently using version 9.2.0 and I also tested it on 8.2.0 and
> it gave the same results.
> Is there something wrong with my code and the example?
> Aliaksandr Dubrouski
This archive was generated by hypermail 2b29 : 01/19/19-03:40:01 PM Z CET