Infinite expressions in calculating triangle loops

[helfaham]

Hi, I am trying to calculate the following diagrams using FeynCalc and Package-X

For this, my code is essentially as follows:

FCClearScalarProducts[];
SPD[k1, k1] = 0;
SPD[k2, k2] = 0;
SPD[k1, k2] = s/2;
SPD[p1, p1] = mt^2;
SPD[p2, p2] = mt^2;
SPD[p1, p2] = (s - 2 mt^2)/2;

amp1 = FCFAConvert[
      CreateFeynAmp[
       DiagramExtract[
        diagsLoop, {36, 37, 52, 38, 53, 51, 114, 115, 116}], 
       Truncated -> False], IncomingMomenta -> {k1, k2}, 
      OutgoingMomenta -> {p1, p2}, LoopMomenta -> {l}, 
      ChangeDimension -> D, List -> False, DropSumOver -> True, 
      UndoChiralSplittings -> True, SMP -> True] // Contract // 
    Simplify // FeynAmpDenominatorSimplify;

amp1xx = 
  TID[amp1x, l, ToPaVe -> True] // PaVeReduce // 
    PropagatorDenominatorExplicit[#] & // EchoTiming;

amp1xxFullEv = 
  PaXEvaluate[amp1xx, l, PaXImplicitPrefactor -> 1, 
     PaXC0Expand -> True] // EchoTiming // Normal;

amp1xxFullEvDim4 = 
  amp1xxFullEv // ChangeDimension[#, 4] /. D -> 4 & // Normal;

The issue I am reporting is that when including the diagrams with the loop running in the initial state, I encounter infinite expressions at the level of computing the helicity amplitudes. However, that is different when considering diagrams with the loop running in the final state where this issue is nonexistent.

As a cross-check, I tried computing the same diagrams but with the top quark in the initial state and still ran into the same problem. I don't immediately see why these diagrams can cause these infinities; I would greatly appreciate any help you could give me. Thanks!

Best,
Hesham

[vsht]

Hi,

can you please also provide the code for generating diagsLoop? Otherwise, the example you give is not reproducible.

Cheers,
Vladyslav

[helfaham]

Hi,
Thank you for the reply, here it is:

diagsLoop = 
  InsertFields[
   CreateTopologies[1, 2 -> 2, 
    ExcludeTopologies -> {SelfEnergies, Tadpoles, WFCorrections}], 
   {F[3, {1}], -F[3, {1}]} -> {F[3, {3}], -F[3, {3}]}, 
   Model -> "SMQCD", InsertionLevel -> {Classes}];      
Paint[diagsLoop, ColumnsXRows -> {5, 1}, Numbering -> Simple, 
  SheetHeader -> None, ImageSize -> {800, 120}];

Best,
Hesham

[vsht]

I guess it must come from having SMP["m_t"] and mt which mean the same.

Other than that I don't see any issues.

test2.zip

[helfaham]

Thank you very much; I will try to run it.

I have another couple of questions. I have been reading about the D->4 limit on the forum and got a bit confused. I understand that the limit D->4 should be fine, given that PaX evaluation happened in D dimensions. Is that correct?

My other question is regarding the TID, I checked that my numerical results are very similar when doing partial reduction using PaVeBasis->True compared to when using //PaVeReduce. Is it then safe to obtain analytical expressions with the former since it produces much more compact results?

Thank you in advance for your help.

Best,
Hesham

[vsht]

I have another couple of questions. I have been reading about the D->4 limit on the forum and got a bit confused. I understand that the limit D->4 should be fine, given that PaX evaluation happened in D dimensions. Is that correct?

What you probably read is related to the simplification of the amplitude written in terms of PaVe functions without evaluating them explicitly,
cf.

https://feyncalc.github.io/FeynCalcBookDev/PaVeLimitTo4.html

This can be indeed tricky. Since you use PaXEvaluate to obtain explicit results this doesn't affect you, though. Sec 4.3 of 2001.04407 may be also relevant.

My other question is regarding the TID, I checked that my numerical results are very similar when doing partial reduction using PaVeBasis->True compared to when using //PaVeReduce. Is it then safe to obtain analytical expressions with the former since it produces much more compact results?

The rule of thumb is to use full reduction to scalar functions for analytic results (provided that things can be written in a compact way) and
to stick to the coefficient functions for the numerics. Otherwise, the huge kinematic prefactors (inverse Gram determinants) from the full reduction will generate lots of numerical cancelations between similar numbers and effectively kill the precision of the numerical evaluation.

[helfaham]

Thank you for the detailed answer. I take it with explicit you mean results with kinematic variables and spinors which are then evaluated explicitly for helicity amplitude calculations. My D->4 is immediately after the full PaXEvaluate so now I understand it should be alright.

For the second part, with coefficient functions, you mean partial reduction using PaVeBasis->True, is that correct?

This has already been very helpful; thank you again.

Best,
Hesham

[vsht]

For the second part, with coefficient functions, you mean partial reduction using PaVeBasis->True, is that correct?

Yes.

[helfaham]

Hi again,

I have a follow-up question: to the same computation I had before, I tried adding four box diagrams, namely those "151, 152, 153, 154";

During PaXEvaluate , I get the following error:

I tried looking up this error, but it is not very popular. May you please help with this?

Best,
Hesham

[vsht]

I had a look at the diagram 151 but it didn't give me any such errors. May be you could isolate the parts of the expression that cause the issues
to have a really minimal working example?

Apart from that, the amplitude even for a single diagram is quite large and the evaluation is super slow. This is usually a sign that FeynCalc is not an adequate tool for the task (at least for me). Also keeping k2.p2 and k2.p1 generic costs performance.

[helfaham]

After some checks, I realised it is List->False that causes all errors while setting it to True fixes everything. Is it clear to you why that is the case? And is there a way around this? This eliminates the problem I mentioned above.

Yet, the previous original problem of infinite expressions arising when the up mass is zero (massless loops) is still on.

Best,
Hesham

[vsht]

After some checks, I realised it is List->False that causes all errors while setting it to True fixes everything. Is it clear to you why that is the case? And is there a way around this? This eliminates the problem I mentioned above.

PaXEvaluate is not listable, so you need to give it each amplitude separately, not as a list thereof.

Yet, the previous original problem of infinite expressions arising when the up mass is zero (massless loops) is still on.

Again, I would try to isolate a single term that causes this issue.

[helfaham]

Hi,
I am attaching a minimal notebook that causes the error. The error arises when mu->0 before PaXEvaluate due to logs with explicit 1/mu dependence.
test2_error.nb.zip

Best,
Hesham

[vsht]

Hi,

thanks a lot for narrowing down the issue. So essentially it is a $D_1$ function with a threshold singularity that
Package-X has troubles evaluating:

PaXEvaluate[
 PaVe[1, {0, mt^2 - 2*Pair[Momentum[k2, D], Momentum[p2, D]], mt^2, 
   s, mt^2, 
   s - 2*Pair[Momentum[k2, D], Momentum[p1, D]] - 
    2*Pair[Momentum[k2, D], Momentum[p2, D]]}, {0, 0, mt^2, 0}]]

For some reason if one first reduces is it to scalar functions using PaVeReduce, then the evaluation works

PaVe[1, {0, mt^2 - 2*Pair[Momentum[k2, D], Momentum[p2, D]], mt^2, s, 
   mt^2, s - 2*Pair[Momentum[k2, D], Momentum[p1, D]] - 
    2*Pair[Momentum[k2, D], Momentum[p2, D]]}, {0, 0, mt^2, 
   0}] // PaVeReduce
PaXEvaluate[%, PaXD0Expand -> True, PaXC0Expand -> True]

although the result is still very complicated and probably not particularly useful in this form.

Unfortunately, this is not something I can fix on my side, because the problem comes from Package-X,
not FeynCalc. This is how the problem using only Package-X looks like:

X`PVD[0, 1, 0, 0, 0, mt^2 - 2*k2 . p2, mt^2, s, mt^2, 
 s - 2*k2 . p1 - 2*k2 . p2, 0, 0, mt, 0]
X`LoopRefine[%]

As you might know, Package-X is not being developed anymore and since its code was not made public
even after the development stopped, there is no real way to fix such issues. In its current state
Package-X is more like "take it or leave it".

Cheers,
Vladyslav

[helfaham]

Hi,

Thanks for the detailed answer, I am still a bit confused though. Because still, if I only choose scalar functions after the TID, I get the same error for this diagram (please see the attached nb). So I do not understand how the error can be from D1.

Best,
Hesham
test2_error.nb.zip

[vsht]

Hi,

indeed, in the case of your kinematics there seem to be multiple functions that Package-X fails to evaluate. D0 is affected as well, namely

PaXEvaluate[ D0[0, mt^2, mt^2, 2*mt^2 + s + t + u, mt^2 + t, 2*mt^2 + s, 0, 0,   mt^2, mz^2]]

which stems from

X`LoopRefine[X`PVD[0, 0, 0, 0, 0, mt^2, mt^2, 2 mt^2 + s + t + u, mt^2 + t, 2 mt^2 + s, 0, 0, mt, mz]]

Here I don't really see a simple workaround, so you'd need to supply the analytic result by hand.

Cheers,
Vladyslav