Error running MadGraph 2.5.5 with long-lived particles

[Rebecca Carney]

Hi,

I have found what may not be a bug, per se, but is certainly problematic for specific MadGraph users. The problem concerns simulating SUSY particles with long lifetimes/small decay widths.
I recently switched from generating an event with MadGraph version 2.4.3 to a more recent release, 2.5.5, when I noticed the program crashing with the following errors:

ERROR: The width of particle 1000022 is too small for an s-channel resonance (6.58211928e-16). If you have this particle in an s-channel, this is likely to create numerical instabilities .

I have attached the full logfile, and the param and run cards.

Since such a detailed error message exists, this is clearly not a mistake. The ability for users in ATLAS to simulate particles with long lifetimes is necessary for many analyses, so it seems necessary that this restriction be removed. Looking forward to hearing from you,

Thanks,
Rebecca

[Olivier Mattelaer (olivier-mattelaer)]

Dear Rebecca,

Do you really have a crash?
In principle what can happen is three things:
1) The code finishes but takes a very long time and do not reach the requested number of events.
2) The code finishes but the cross-section is not production times branching ratio.
3) The code finishes correctly.

Note that nothing was changed on support of long-lived particle from 2.4.3 to 2.5.5 on that topic.
The only difference is the printing of such message in order to warn the user that the width is so small that you should expect numerical inaccuracy if that particle is in a s-channel resonances (i.e. it is produced and decayed inside MadGraph).

If your Feynman diagram does not contain such case, you should be fine to ignore that message.

If you face such numerical problem, you have to use a workaround:
1) use MadSpin (potentially with "onshell" mode)
2) increase the value of the width to 1e-8 times the mass of that particle (and change the cross-section and/or the coupling accordingly)

Cheers,

Olivier

> On 27 Aug 2017, at 07:50, Rebecca Carney <email address hidden> wrote:
>
> Public bug reported:
>
> Hi,
>
> I have found what may not be a bug, per se, but is certainly problematic for specific MadGraph users. The problem concerns simulating SUSY particles with long lifetimes/small decay widths.
> I recently switched from generating an event with MadGraph version 2.4.3 to a more recent release, 2.5.5, when I noticed the program crashing with the following errors:
>
> ERROR: The width of particle 1000022 is too small for an s-channel
> resonance (6.58211928e-16). If you have this particle in an s-channel,
> this is likely to create numerical instabilities .
>
> I have attached the full logfile, and the param and run cards.
>
> Since such a detailed error message exists, this is clearly not a
> mistake. The ability for users in ATLAS to simulate particles with long
> lifetimes is necessary for many analyses, so it seems necessary that
> this restriction be removed. Looking forward to hearing from you,
>
> Thanks,
> Rebecca
>
> ** Affects: mg5amcnlo
> Importance: Undecided
> Status: New
>
>
> ** Tags: 2.5.5 llp long-lived particle
>
> ** Attachment added: "Tar containing run log, param card, and run card."
> https://bugs.launchpad.net/bugs/1713298/+attachment/4939554/+files/errorInfo.tar.gz
>
> --
> You received this bug notification because you are subscribed to
> MadGraph5_aMC@NLO.
> https://bugs.launchpad.net/bugs/1713298
>
> Title:
> Error running MadGraph 2.5.5 with long-lived particles
>
> Status in MadGraph5_aMC@NLO:
> New
>
> Bug description:
> Hi,
>
> I have found what may not be a bug, per se, but is certainly problematic for specific MadGraph users. The problem concerns simulating SUSY particles with long lifetimes/small decay widths.
> I recently switched from generating an event with MadGraph version 2.4.3 to a more recent release, 2.5.5, when I noticed the program crashing with the following errors:
>
> ERROR: The width of particle 1000022 is too small for an s-channel
> resonance (6.58211928e-16). If you have this particle in an s-channel,
> this is likely to create numerical inst...

[Rebecca Carney (rcarney)]

Hi Olivier,

As you can see from the log, the program exits with an error and doesn't produce an LHE. Since the only error quoted in the logfile is the error I mentioned in my original post, and since the only thing that changed in between runs is the version, the only conclusion I can draw is that the long-lifetime causes the LHE not to be built.

If, for some reason the message is actually just a warning as you say, it still begs the question why the LHE is no longer built from simply changing the version.

Thanks,
Rebecca

[Olivier Mattelaer (olivier-mattelaer)]

Dear Rebecca,

Looks like that you are using the mssm_v4 model.
Is it on purpose? or is it because the model mssm does not exists anymore on 2.5.0 version of the code?

In 2.5.0, the model mssm has been replaced by MSSM_SLHA2.

The difference between the two model is ONLY the input format of the param_card.
As the name is explicit for the new name, this new model expect SLHA2 input.
The mssm model was actually coded to have SLHA2 input as well, but due to PY6 problem to handle such type of input, the user was suppose to pass a SLHA1 input, and we were translated it internally to SLHA2 such that we were able to pass the parameter to the model.

Long story, short: the mssm model and the MSSM_SLHA2 are 100% identical, the only difference is the way MG5aMC was supporting the model internally and therefore the user expected from the user.

Since
1) PY6 interface (pythia-pgs) is not supported anymore in MG5aMC (since 2.5.0)
2) PY8 inteface is now supported in MG5aC (since 2.5.0)
3) that PY8 handles SLHA2 format
4) that such automatic translation was creating many bugs (especially for code like MadSpin, re-weighting,....)
We decided to drop the automatic SLHA1->SLHA2 automatic translation.

Now:
1) if the user type "import model mssm" the code will fail to load the mssm model (since it does not exists by default anymore) but will then try (automatically) the following command "import model_v4 mssm". Which will go trough.
This model is
a) not an UFO model
b) a model inhereted from MG4 (we will fully remove those in 3.0)
c) not compatible with all the functionalities of MG5aMC
d) more restrictive than the mssm model
My guess is that your benchmark point is not supported by this very old model.

2) in order to help to the transition, we have provide user access to the SLHA1->SLHA2 translator.
At the time of the edition of the card, you can type, the following two line:
PATH/TO/PARAM_CARD/IN/SLHA1/FORMAT
update to_slha2
in order to load and convert to slha2 format your slha1 format card.

So my suggestion, would be
1) switch to MSSM_SLHA2 model
2) use the "update to_slha2" command to have the exact same behavior as in 2.4.x

Cheers,

Olivier

[Rebecca Carney (rcarney)]

Hi Olivier,

Just to update you, we changed all references of 'import model mssm' to 'import model MSSM_SLHA2' and, as you predicted, the job now runs successfully.
This change has been tagged in our software and will be added to the next release, so hopefully no one will bring this up again from our end.

Thanks for your detailed answer and suggestions.
Rebecca

[Zachary Marshall (zach-marshall)]

Hi,

I just want to add that the default behavior of MG5_aMC is to fall back to a _v4 model when one is available. That means all the people who previously imported the mssm model will not see an error, but will see the _v4 model suddenly being used in their jobs. I think this is really undesirable behavior, and you should pull the mssm_v4 model if it's not something that people should be using in a serious way. That, or you could add a depreciation warning if mssm is used as the model for importing.

Best,
Zach