MadGraph5_aMC@NLO

Incorrect Cross Section After Switching Model

Asked by JINHEUNG KIM

Dear MG5 Team,

I am Jinheung Kim from Konkuk University, Korea.

We have encountered an issue where the calculated cross section differs depending on whether it is calculated directly or after running another model and then switching to the standard model (SM).

Here is the script we used:

For direct:
generate mu+ mu- > vl vl~ t t~
output mm_vlvltt
launch mm_vlvltt
set ebeam1 5000
set ebeam2 5000
This gives a cross section of 0.01707489424847721 fb.

For switching:
import model MSSM_SLHA2
generate mu+ mu- > vl vl~ t t~
launch

import model sm
generate mu+ mu- > vl vl~ t t~
output mm_vlvltt
launch mm_vlvltt
set ebeam1 5000
set ebeam2 5000
This gives a cross section of 0.06229609513247126 fb.

This issue appears in both script and user modes.

Question information

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

Thanks for reporting, I'm reproducing the error and hoping to understand what is going on soon.
Will keep you in touch,

Cheers,

Olivier

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

Hi,

I will have to stop for today and did not yet found the issue. The problem does not seem to be a phase-space related glitch but rather a gitch in the way the matrix-element is computed.
Indeed the two code are mainly identical but the aloha routine are quite different (but so far the only difference that I spot are naming convention for sub-expression).

But when running standalone in both case:
 -----------------------------------------------------------------------------
 n E px py pz m
 1 0.5000000E+03 0.0000000E+00 0.0000000E+00 0.5000000E+03 0.0000000E+00
 2 0.5000000E+03 0.0000000E+00 0.0000000E+00 -0.5000000E+03 0.0000000E+00
 3 0.7768872E+02 -0.1938959E+02 0.3516368E+02 -0.6650636E+02 0.2697398E-05
 4 0.2880532E+03 -0.9111035E+02 -0.2648955E+03 0.6711127E+02 0.4768372E-05
 5 0.2186235E+03 -0.9289251E+02 -0.8572357E+02 0.4347027E+02 0.1730000E+03
 6 0.4156347E+03 0.2033925E+03 0.3154553E+03 -0.4407518E+02 0.1730000E+03
 -----------------------------------------------------------------------------
 Matrix element = 4.8874980891710058E-012 GeV^ -4
 -----------------------------------------------------------------------------

 -----------------------------------------------------------------------------
 n E px py pz m
 1 0.5000000E+03 0.0000000E+00 0.0000000E+00 0.5000000E+03 0.0000000E+00
 2 0.5000000E+03 0.0000000E+00 0.0000000E+00 -0.5000000E+03 0.0000000E+00
 3 0.7768872E+02 -0.1938959E+02 0.3516368E+02 -0.6650636E+02 0.2697398E-05
 4 0.2880532E+03 -0.9111035E+02 -0.2648955E+03 0.6711127E+02 0.4768372E-05
 5 0.2186235E+03 -0.9289251E+02 -0.8572357E+02 0.4347027E+02 0.1730000E+03
 6 0.4156347E+03 0.2033925E+03 0.3154553E+03 -0.4407518E+02 0.1730000E+03
 -----------------------------------------------------------------------------
 Matrix element = 8.3180839763685298E-012 GeV^ -4
 -----------------------------------------------------------------------------

So tommorow, I will investigate more the standalone code and likely try to understand which lorentz structure differs in both code and why...
The solution is likely a reset of the aloha code when loading a new model, but before implementing that easy fix, I want to fully understand what is going on. And see if what I thought is enough or not.

Thanks for such precious report,

Olivier

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

Hi,

So the issue is a python issue where in some cases, the "new" model is keeping part of the definition of the "old" model in some cases.
The reason is that the file within the UFO are the same for all model and the way python works to resolve import (and that UFO model was based on python2 import strategy which was changed by python for python3).

I'm testing now a way to force python to drop such reference and so far I have confusing result so far (the test suite is shouting at me after such changes). But it fixes the issue that you report so far (and also the issue at standalone level)
But the patch is obviously irrelevant, since the cleanest work-around is obviously close MG5aMC after you do an output before changing model.

thanks for reporting,

Olivier

Revision history for this message
JINHEUNG KIM (kjh1216) said : 		#4

Dear Olivier,

Thank you for your prompt and detailed response.
Your explanation about the Python issue clarifies why this problem doesn't always occur.
I hope that my report contributes to the improvement of MadGraph.

Revision history for this message
JINHEUNG KIM (kjh1216) said : 		#5

Thanks Olivier Mattelaer, that solved my question.