FCCanonicalizeDummyIndices[] bug?

[HBelusca]

• Your Mathematica version

11.2.0 for Microsoft Windows (64-bit) (September 11, 2017)

• Your FeynCalc version

9.3.0 (development) (15238e617d5ee719667ecb01248d3d0b1e535397)

---

There appears to be a bug in FCCanonicalizeDummyIndices[] when, during the associated expansion of the expression being canonicalized, a (dot-)product of Gamma matrices becomes transformed into a regular product.

This example works: after the expansion the Gamma matrices ordering is correctly kept:

In[1] := FCCanonicalizeDummyIndices@DiracTrace[GS[q].(gS GA[\[Mu]].GA[6]).GS[k + q].(gS GA[\[Mu]].GA[7])]

Out[1] = gS^2*DiracTrace[DiracGamma[Momentum[q]] . DiracGamma[LorentzIndex[FCGV["li241"]]] .
    DiracGamma[6] . DiracGamma[Momentum[k]] . 
    DiracGamma[LorentzIndex[FCGV["li241"]]] . DiracGamma[7]]
 + gS^2*DiracTrace[DiracGamma[Momentum[q]] . DiracGamma[LorentzIndex[FCGV["li241"]]] .
    DiracGamma[6] . DiracGamma[Momentum[q]] .
    DiracGamma[LorentzIndex[FCGV["li241"]]] . DiracGamma[7]]

However, the following example does not work: the sole addition of the SUNT matrices (e.g. part of a fermion-fermion-gluon vertex) breaks the ordering of the Gamma matrices after the expansion (look at the first term for example: GA[7] comes first and is not DOT-multiplied with the term on its right):

In[2] := FCCanonicalizeDummyIndices@DiracTrace[GS[q].(gS SUNT[b] GA[\[Mu]].GA[6]).GS[k + q].(gS SUNT[a] GA[\[Mu]].GA[7])]

Out[2] = gS^2*DiracTrace[DiracGamma[Momentum[k]] . DiracGamma[LorentzIndex[FCGV["li341"]]] .
    DiracGamma[7] * DiracGamma[Momentum[q]] . DiracGamma[LorentzIndex[FCGV["li341"]]] .
    DiracGamma[6]*SUNT[SUNIndex[a]]*SUNT[SUNIndex[b]]]
 + gS^2*DiracTrace[DiracGamma[Momentum[q]] . DiracGamma[LorentzIndex[FCGV["li341"]]] .
    DiracGamma[6] * DiracGamma[Momentum[q]] . DiracGamma[LorentzIndex[FCGV["li341"]]] .
    DiracGamma[7]*SUNT[SUNIndex[a]]*SUNT[SUNIndex[b]]]

[vsht]

Well, if you want to add the SUNT matrices you should use the non-commutative multiplication (i.e. Dot) instead of Times. This works fine

DotSimplify[
 DiracGamma[
   Momentum[
    q]].(DiracGamma[LorentzIndex[\[Mu]]].DiracGamma[
      6] c1).(DiracGamma[Momentum[k]] + 
    DiracGamma[
     Momentum[q]]).(DiracGamma[LorentzIndex[\[Mu]]].DiracGamma[7] c2)]

While this gets messed up

DotSimplify[
 DiracGamma[
   Momentum[
    q]].(DiracGamma[LorentzIndex[\[Mu]]].DiracGamma[6] SUNT[
     SUNIndex[b]]).(DiracGamma[Momentum[k]] + 
    DiracGamma[
     Momentum[q]]).(DiracGamma[LorentzIndex[\[Mu]]].DiracGamma[
      7] SUNT[SUNIndex[a]])]

Even though SUNT and DiracGamma commute, you need DOTs to fix the ordering of the SUNT matrices when they are pulled out of the Dirac structures. Alternatively, you may uses SUNTFs, which are commutative and hence can be just Times multiplied.

Clearly FeynCalc can try to guess what was meant by the user, although this might also give unexpected results. In your example it is more or less clear, but what about

 DiracTrace[DiracGamma[
   Momentum[
    q]].(DiracGamma[LorentzIndex[mu]].DiracGamma[6] DiracGamma[
     Momentum[z1]]).(DiracGamma[Momentum[k]] + 
    DiracGamma[
     Momentum[q]]).(DiracGamma[LorentzIndex[mu]].DiracGamma[
      7] DiracGamma[Momentum[z2]])]

Here there is no way to make sense of the expression and therefore it should trigger an error. But catching syntax errors (except perhaps for the most obvious ones) is not something I would like to do in the code to avoid performance penalties.

I added some workaround for now, but this is not something I'm entirely happy with. Let us see how this will work.

[HBelusca]

Thank you for your explanation! Yes of course I assumed that SUNT commute with DiracGamma and thought that e.g. DotSimplify would thread DOT over the SUNTs while keeping regular multiplication between the product of SUNTs and that of DiracGammas. It seems that the best way would be indeed to "indicate" to FeynCalc that these two different objects do commute together, but adding such support would probably be more complicated than what's needed.

[vsht]

Actually I think that with the fix that I added earlier it should work also without the extra DOTs. You can check it on your codes and see if there are still remaining issues.

[HBelusca]

About catching the syntax errors, you have this "FCCheckSyntax" option that is used for some other Dirac-related functions (e.g. DiracSimplify, but not used by DotSimplify), and which may be set to False when those functions are called internally by other ones, and be set to True (default value?) when they are called manually by the user.

[vsht]

The main issue with this approach is that the performance penalties are too large: FCCheckSyntax must effectively expand all commutative and noncommutative products before it can start looking for syntax errors like multiple dummy indices or commutative products of matrices. Still, it is not guaranteed that the expression that passes this check is 100% correct. So my idea was that FCCheckSyntax should be used only in special cases (new FeynCalc users or potentially faulty expressions), but not automatically.