On the counterterms contributions in mg5 loops

Asked by Hesham El Faham

Hi,

I am doing the loop computation uu~>g>tt~ with an h or Z closing the loop with the two out-state tops. I am trying to match standalone mg5 with my analytical computation, for all possible helicities. I have two questions on that matter:

1) To keep the analytical calculation as simple as possible and still compare against mg5, I commented out the following line in loop_diagram_generation.py: ``self.set_LoopCT_vertices()`` and added some loop filtering to make sure I have the only one loop I am interested in. Now, the single pole contributions match perfectly with mg5 but not the finite part. I am wondering if there are more counterterms contributing (perhaps from wavefunction renormalisation?) regardless of which loops I am filtering out, and whether these contributions can be turned off so as to compare with my computation, at least as a proof of principle.

2) For uu~>g>tt~ with Z in the loop, some helicity configurations, particularly ones with very small contributions (~10^-6), do not match my computation, while other configurations match perfectly using exactly the same computation. Is it possible that mg5 could be running into precision issues here?

I am using loop_qcd_qed_sm in the latest stable mg5 version.

Thank you in advance for you help.

Best,
Hesham

Question information

Language:
English Edit question
Status:
Answered
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said :
#1

Hi,

1) Do you keep the R2 term? I would not be surprised that you have removed the R2 term?
Since we often call them R2 counterterm (even if this is not technically a counter-term), so I would not be surprised if the handling of those contribution being done by self.set_LoopCT_vertices

2) I guess that numerical precision are possible even if the loop stability flag should catch it.

Cheers,

Olivier

Revision history for this message
Hesham El Faham (helfaham) said :
#2

Hi,

No, I don’t keep the R2 terms. This is why I am thinking the additional contributions might be arising from some not obvious terms, maybe wave function normalisation?

For the second point, you mean that the issue might be due numerical precision of mg5?

Best,
Hesham

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said :
#3

> No, I don’t keep the R2 terms. This is why I am thinking the additional
> contributions might be arising from some not obvious terms, maybe wave
> function normalisation?

But you have to keep them, otherwise this breaks gauge and lorentz invariance and this can not be compare to any analytical computation.

Cheers,

Olivier

> On 12 Jan 2023, at 09:45, Hesham El Faham <email address hidden> wrote:
>
> Question #704288 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/704288
>
> Status: Answered => Open
>
> Hesham El Faham is still having a problem:
> Hi,
>
> No, I don’t keep the R2 terms. This is why I am thinking the additional
> contributions might be arising from some not obvious terms, maybe wave
> function normalisation?
>
> For the second point, you mean that the issue might be due numerical
> precision of mg5?
>
> Best,
> Hesham
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
Hesham El Faham (helfaham) said :
#4

Ok, the issue is that I don’t add the counterterms in my calculation and so I wanted to remove them from mg5 too, is there a way to keep the R2 terms but not the UV loops?

Best,
Hesham

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said :
#5

Certainly possible, but I do not know how to do it.
I guess you need to dig into
set_LoopCT_vertices()
and check for each of them with type of contribution it is and if you need to keep them or not.

You can also try to do the filtering at the UFO level by removing the counter-term that you do not want to have at the UFO level.
Or do that work within the Fortran output. No clue which approach will be the simpler one to implement.

Cheers,

Olivier

Can you help with this problem?

Provide an answer of your own, or ask Hesham El Faham for more information if necessary.

To post a message you must log in.