On the computation of one-loop unrenormalised amplitude in FeynCalc

[helfaham]

Hi,

I am computing one-loop triangle amplitudes exhibiting IR and UV divergences in FeynCalc using Package-X. I aim to numerically match the unrenormalised non-divergent part of the amplitude to MG5 for cross-checking the FeynCalc computation.

I am trying to do this by using PaVe and PaXEvaluate, expanding in D->4-2Epsilon around Epsilon{0,0}, removing the pole using FCSplit and then performing numerical computations. I do see a mismatch between both computations even though I made sure conventions and schemes, etc are equivalent. The mismatch only happens for the 'finite' part of the amplitude while the poles from FeynCalc match MG5 perfectly.

Recently, I noticed that PaVeUV is different from PaXEvaluateUV, in the sense that numerically the latter only computes the UV pole while the former contains an extra contribution to the UV divergent part of the amplitude that PaXEvaluateUV 'misses'.

I then thought that this can be causing the mismatch and that one way to tackle the issue is to calculate the full amplitude and then subtract whatever UV divergence PaVeUV claims. But then I ran into the problem that there is no such way to also subtract the IR divergences of the loop integral since PaXEvaluateIR will only compute the poles, similar to PaXEvaluateUV.

So my first question is, is there a way to properly remove the IR divergent part to obtain the non-divergent un-renormalised one?

And on a more general note, is trying to match the unrenormalised non-divergent amplitude from FeynCalc to its counterpart from MG5 something that is in principle feasible or perhaps it is more subtle than what I naively expected?

Best,
Hesham

[vsht]

Hi,

Recently, I noticed that PaVeUV is different from PaXEvaluateUV, in the sense that numerically the latter only computes the UV pole while the former contains an extra contribution to the UV divergent part of the amplitude that PaXEvaluateUV 'misses'.

What extra contributions are you talking about? The results generated by the two functions should be equivalent, everything else must be a bug in one of them.

So my first question is, is there a way to properly remove the IR divergent part to obtain the non-divergent un-renormalised one?

You could look into sector decomposition, but if you are asking for specific implementations, then I'm not aware of any public tool that gives
you the IR poles upon hitting a button.

And on a more general note, is trying to match the unrenormalised non-divergent amplitude from FeynCalc to its counterpart from MG5 something that is in principle feasible or perhaps it is more subtle than what I naively expected?

I'm not a MadGraph expert, so you should better direct this question to the MG devs.

Cheers,
Vladyslav

[helfaham]

Thanks for your reply.

Yes, using PaVeUV gives 1/e pole which is the same as what PaXEvaluateUV computes but it also adds another non-epsilon part which the latter does not know about.
PaVeUVTS.nb.zip

I added a notebook that shows this.

"..then I'm not aware of any public tool that gives you the IR poles upon hitting a button"
So what does PaXEvaluateIR do?

Best,
Hesham

[vsht]

I added a notebook that shows this.

Apart from the obviously missing normalization prefactor I don't see any difference between the two:

...
amp1xxxUV = (PaXEvaluateUV[#, l, 
       PaXImplicitPrefactor -> 1/(2 Pi)^D] & /@ (amp1xx)) // 
   EchoTiming;
amp1xxxUVT = amp1xxxUV /. EpsilonUV -> Epsilon;

tmp = 1/(2 Pi)^D (PaVeUVPart[#] & /@ (amp1xx)) // EchoTiming;
amp1xxxUVv2 = 
 Series[FCReplaceD[tmp, D -> 4 - 2 Epsilon], {Epsilon, 0, -1}] // 
  Normal

 amp1xxxUVT - amp1xxxUVv2 // Simplify
(*0*)

So what does PaXEvaluateIR do?

It extracts the full pole and subtracts the UV one from it. The remainder is by definition the UV-pole.
However, PaVe integrals are a very special case in that respect and they have been well studied in the past.
You cannot pull the same trick with an arbitrary loop integral, since the involved calculations require much more work.

[helfaham]

I see, you are comparing the 1/e part of both which is the same, I agree.
What I was saying is that the result of PaVeUVPart has a piece with no epsilons in it (which I do not understand). Of course, this piece will only show up when you do {Epsilon, 0, 0}

"It extracts the full pole and subtracts the UV one from it. The remainder is by definition the UV-pole"
You meant the IR-pole, right?

Best,
Hesham

[vsht]

I see, you are comparing the 1/e part of both which is the same, I agree.
What I was saying is that the result of PaVeUVPart has a piece with no epsilons in it (which I do not understand). Of course, this piece will only show up when you do {Epsilon, 0, 0}

Yes of course, because I multiplied the result by $1/(2\pi)^D$ to have the same normalization as in the PaXEvaluateUV case. But the results substituted for the loop integrals are valid only up to $1/\varepsilon$. So it makes mathematically no sense to expand to higher orders in $\varepsilon$, because the finite pieces are meaningless in this context.

You meant the IR-pole, right?
Yes.

[helfaham]

Ok, thanks. It is clear now.

Best,
Hesham