Name: Vladyslav Shtabovenko (email_not_shown)
Date: 04/08/14-03:24:59 PM Z

Dear all,

during my further investigations of FeynCalc 8.2 I encountered a problem
related to the models from FeynArts.

In the current state (even after applying my patches), to use the
FeynArts models like SMQCD etc. you need to use

SetOptions[FourVector, FeynCalcInternal -> False];

as described here


If I understand it correctly, the problem comes from the tag assigment

FourVector/: -FourVector[ mom_, mu_ ] := FourVector[Expand[-mom], mu]
FourVector[ 0, _ ] = 0

that is used Dirac.gen, DiracU.gen, Lorentz.gen, Lorentzbgf.gen and
QED.gen. While in FeynArts, FourVector is just an ordinary function, in
FeynCalc it is defined in a more complicated way. In particular, the
standard behavior (FeynCalcInternal=True) is

In[1]: FourVector[a, mu] // FullForm
Out[1]: Pair[LorentzIndex[mu],Momentum[a]]

Then, with

In[2]: SetOptions[FourVector, FeynCalcInternal -> False]
         FourVector[a, mu] // FullForm
we get
Out [2]: FourVector[a,mu]

In the first case, the TagSetDelayed command from FeynArts from
obviously doesn't work, while in the latter case it seems to work fine.

Now I was thinking that to make the FeynArts models work out-of-the-box
we could just comment out

FourVector/: -FourVector[ mom_, mu_ ] := FourVector[Expand[-mom], mu]
FourVector[ 0, _ ] = 0

in the corresponding gen-files of FeynArts. The second rule is redundant
anyhow, since in FeynCalc, FourVector[0, mu] already gives you zero. The
second rule which absorbs the minus sign into the brackets is actually
useless, since

In[12]:= FourVector[-a, mu] // FullForm

Out[12]//FullForm= Times[-1,Pair[LorentzIndex[mu],Momentum[a]]]

which means that FeynCalc will throw all the absorbed minus signs out of
the brackets anyhow.

Now I know that for some strange reason Phi works properly only with
SetOptions[FourVector, FeynCalcInternal -> False] (see the comment in
PhiStart.m regarding QEDRadiativeCorrections.nb). However, when Phi is
loaded, it sets this option automatically and it uses its own gen-files.

So currently I don't see a problem in applying this change in the
gen-files of FeynArts. Rolf and Frederic are of course free to correct
me if I'm missing a point here.

This way you can generate FeynArts diagrams from FeynArts models but
there are still difficulties evaluating them in FeynCalc, since they use
different conventions and functions. Things get better after you apply
ConvertToFC1, but even after that certain replacements are still necessary.

There is a FAToFC function in Phi, but since Phi is not working as of
now (at least for me), I cannot test it much, such that currently I'm
doing the replacements by hand.

For the momenta you can always do something like

{FourMomentum[Incoming, 1]->p1,
FourMomentum[Incoming, 2]->p2,
FourMomentum[Outgoing, 1] ->p3,
FourMomentum[Outgoing, 2] -> p4}

Other replacements that seem to be ok in most cases are

{IndexDelta[Index[a_, b_], Index[c_, d_]] -> 1,
SumOver[___] -> 1,
Conjugate[PolarizationVector][_, x_, y_]
->Conjugate[PolarizationVector[x, y]],
PolarizationVector[_, x_, y_] -> PolarizationVector[x, y]}

Please find the corresponding patch attached. The patch should be
applied on top of FeynArts-3.7 that has already been patched for FeynCalc


On 05/04/14 21:40, Vladyslav Shtabovenko wrote:
> Dear all,
> I would like to report two bugs I encountered in Feyncalc 8.2 (latest
> version). I'm using Mathematica 9, but the bugs are not really related
> to that.
> First of all, in Models/FCQCDLorentz.gen there should be a
> "$FermionLines = True" statement, since otherwise FeynArts generates
> diagrams without Dirac traces and FeynCalc subsequently fails to compute
> the color trace. This is fixed in Phi, but not in FeynCalc itself.
> Then, in general/Collect3.m, there is a regression bug related to the
> MonomialList function. In FC8.1 there was a condition to use the
> FeynCalc's version of MonomialList for Mathematica below version 6. For
> some reason this condition was removed in FC8.2. The problem is, that
> Mathematica's built-in MonomialList doesn't have the Option
> "CoefficientDomain -> RationalFunctions", which makes all functions that
> rely on Collect3 fail.
> You can easily reproduce the bugs by trying to run
> fcexamples/qcdghostse2loopnew2.nb.
> Because of the missing Dirac traces and the broken MonomialList, the
> computation fails on FC8.2.
> Please find the patch that fixes this problems attached.
> Just in case, I also attach a patch for the FeynArts 3.7, since
> automatic patching doesn't seem to work with Mathematica 9. The patch is
> just what happens to FA 3.7 after you run
> << "HighEnergyPhysics`Phi`Extras`FAPatch`"
> $FeynArtsDirectory =
> "/home/YOUR_USERNAME/.Mathematica/Applications/HighEnergyPhysics/FeynArts-3.7/"
> HighEnergyPhysics`Phi`FAPatch`FAPatch[]
> -------------------------------------------------------------------------
> If you need to use FeynCalc 8.2 now and you absolutely cannot wait until
> developers release the new version, here's a quick fix guide on Linux:
> 1) Install fresh Feyncalc via
> Import[""]
> 2) Copy the attached patches to
> ~/.Mathematica/Applications/HighEnergyPhysics
> 3) In the console run
> cd ~/.Mathematica/Applications/HighEnergyPhysics
> patch -p0 < feynarts.patch
> patch -p0 < fc82.patch
> 4) Restart Mathematica, run fcexamples/qcdghostse2loopnew2.nb. and check
> that you get the same results as in the notebook
> -----------------------------------------------------------------------
> P.S. Correct me if I'm wrong but it looks like in the CVS we still have
> FC8.1, not FC8.2. Also, with the instructions on
> it is impossible to check
> out the repository :(
> Cheers,
> Vladyslav

This archive was generated by hypermail 2b29 : 02/22/19-05:20:01 AM Z CET