Skip to content

MadGraphControl, SUSY: check model imports for RPV processes

Giordon Holtsberg Stark requested to merge gstark/athena:21.6 into 21.6

./cc @zmarshal @jmontejo

This should impact:

A longer discussion can be found in ATLMCPROD-8518 of which the following conclusions have been made:

  • RPVMSSM_UFO or another model should be explicitly imported as part of the process specification
  • The team/request should understand whether they want to decay via MadGraph/MadSpin (likely important to use the right model) or if they want it handled by Pythia (it's ok to use MSSM_SLHA2 as long as the decays happen in Pythia, e.g. no consistency warning from MadGraph in log.generate)
  • When using input (pre-made) LHEs, the team should check that OTF generation provides identical results (for reproducible physics of course!). The model will not be updated when using pre-made LHEs, but this should be ok for most situations.

Note: how can you determine when RPVMSSM_UFO or MSSM_SLHA2 is needed? There are two different scales for decay widths:

  • large decay widths might lead to error messages like generate 17:21:53 WARNING: For consistency, the width of particle 1000022 (n1) is changed to 0.0. which means Pythia will not decay the particle (thus no RPV). You likely will need RPVMSSM_UFO.
  • small decay widths will usually be ignored by MadGraph and written directly to output for Pythia to pick up ( You likely will not need RPVMSSM_UFO

Merge request reports