SUSY Les Houches Accord

  1. Sanity Checks
  2. SLHA Switches and Parameters
  3. SLHA DECAY Tables
  4. Internal SLHA Variables
  5. Using SLHA for generic BSM Models
The PYTHIA 8 program does not contain an internal spectrum calculator (a.k.a. RGE package) to provide supersymmetric couplings, mixing angles, masses and branching ratios. Thus the SUSY Les Houches Accord (SLHA) [Ska04][All08] is the only way of inputting SUSY models, and SUSY processes (see the SUSYProcesses page) cannot be run unless such an input has taken place.

The SLHA input format can also be extended for use with more general BSM models, beyond SUSY. Information specific to how to use the SLHA interface for generic BSM models is collected below, under Using SLHA for generic BSM Models, with more elaborate explanations and examples in [Des11].

Most of the SUSY implementation in PYTHIA 8 is compatible with both the SLHA1 [Ska04] and SLHA2 [All08] conventions (with some limitations for the NMSSM in the latter case). Internally, PYTHIA 8 uses the SLHA2 conventions and translates SLHA1 input to these when necessary. See the section on SUSY Processes and [Des11] for more information. Note that PYTHIA assumes that a spectrum is either fully SHLA1 or fully SLHA2 compliant. Mixing of the two standards is discouraged, as this can lead to ambiguities and inconsistencies.

When reading LHEF files, Pythia automatically looks for SLHA information between <slha>...</slha> tags in the header of such files. When running Pythia without LHEF input (or if reading an LHEF file that does not contain SLHA information in the header), a separate file containing SLHA information may be specified using SLHA:file (see below).

Normally the LHEF would be in uncompressed format, and thus human-readable if opened in a text editor. A possibility to read gzipped files has been added, based on the Boost and zlib libraries, which therefore have to be linked appropriately in order for this option to work. See the README file in the main directory for details on how to do this.

Finally, the SLHA input capability can of course also be used to input SLHA-formatted MASS and DECAY tables for other particles, such as the Higgs boson, furnishing a less sophisticated but more universal complement to the standard PYTHIA 8-specific methods for inputting such information (for the latter, see the section on Particle Data and the scheme to modify it). This may at times not be desirable, so a few options can be used to curb the right of SLHA to overwrite particle data. Conversely, it is sometimes useful to allow the user to modify eg a mass parameter relative to its value in the SLHA spectrum. This is normally not permitted (the SLHA spectrum is normally self-consistent and should not be modified), but an option for allowing it is provided.

The reading-in of information from SLHA or LHEF files is handled by the SusyLesHouches class, while the subsequent calculation of derived quantities of direct application to SUSY processes is done in the CoupSUSY, SigmaSUSY, and SUSYResonanceWidths classes.

Sanity Checks

As an aid for basic validation, some checks and ranges are imposed on SLHA input during initialization, as follows: Note that these sanity checks will not catch all possible cases of Garbage In Garbage Out, so human verification of the input files is always a good idea, as is taking a look at any warnings or error messages printed by the SLHA interface during initialization. It is ultimately up to the user to ensure that sensible input is being given.

SLHA Switches and Parameters

mode  SLHA:readFrom   (default = 1; minimum = 0; maximum = 2)
Controls from where SLHA information is read.
option 0 : is not read at all. Useful when SUSY is not simulated and normal particle properties should not be overwritten.
option 1 : read in from the <slha>...</slha> block of a LHEF, if such a file is read during initialization, and else from the SLHA:file below.
option 2 : read in from the SLHA:file below.

word  SLHA:file   (default = void)
Name of an SLHA (or LHEF) file containing the SUSY/BSM model definition, spectra, and (optionally) decay tables. Default void signals that no such file has been assigned.

parm  SLHA:minMassSM   (default = 100.0)
This parameter provides an alternative possibility to ignore SLHA input for all particles with identity codes below 1,000,000 (which mainly means SM particle, but also includes e.g. the Higgs bosons in two-Higgs-doublet scenarios) whose default masses in PYTHIA lie below some threshold value, given by this parameter. The default value of 100.0 allows SLHA input to modify the top quark, but not, e.g., the Z^0 and W^+- bosons.

flag  SLHA:allowUserOverride   (default = off)
Flag to set whether the user is allowed to modify the parameters read from an SLHA spectrum. Is normally kept off to preserve the internal self-consistency of SLHA spectra. If this flag is switched on, the mass values read from the SLHA block MASS are allowed to be modified by the user, using PYTHIA's standard readString and related methods.


In addition to SUSY spectra, the SLHA also defines a set of conventions for decay tables. These are not restricted to SUSY models, but can be used for arbitrary particles, either in combination with or independently of the SUSY parts of the Accord. The settings in this section control whether and how PYTHIA will make use of such tables. See also the comments under sanity checks above.
Note: the PYTHIA SLHA interface is limited to at most 1→8 decays.

flag  SLHA:useDecayTable   (default = on)
Switch to choose whether to read in SLHA DECAY tables or not. If this switch is set to off, PYTHIA will ignore any decay tables found in the SLHA file, and all decay widths will be calculated internally by PYTHIA. If switched on, SLHA decay tables will be read in, and will then supersede PYTHIA's internal calculations, with PYTHIA only computing the decays for particles for which no SLHA decay table is found. (To set a particle stable, you may either omit an SLHA DECAY table for it and then use PYTHIA's internal id:MayDecay switch for that particle, or you may include an SLHA DECAY table for it, with the width set explicitly to zero.)

flag  SLHA:allowOnlyOffShell   (default = off)
Switch to allow a decay table with only off-shell decays. By default, internal checks require particles to have at least one on-shell decay mode.

mode  SLHA:meMode   (default = 100; minimum = 100; maximum = 103)
This value specifies how threshold, off-shell, and phase-space weighting effects for SLHA decay channels should be treated, using the same numbering scheme as for resonances. The default (100) is to use the branching fraction given in the SLHA DECAY tables without any modifications. The corresponding partial widths remain unchanged when the resonance fluctuates in mass. Specifically there are no threshold corrections. That is, if the resonance fluctuates down in mass, to below the nominal threshold for some decay mode, it is assumed that one of the daughters could also fluctuate down to keep the channel open. (If not, there may be problems later on.) Alternative options (with values 101+) documented under resonances allow for some flexibility to apply threshold factors expressing the closing of the on-shell phase space when the daughter masses approach or exceed the parent one. Note that modes that are extremely far off shell (defined as needing a fluctuation of more than 100 times the root-sum-square of the widths of the mother and daughter particles) will always be assigned meMode = 100 and should be switched off by hand if so desired. It is up to the user to ensure that the final behaviour is consistent with what is desired (and/or to apply suitable post facto reweightings). Plotting the generator-level resonance and decay-product mass distributions (and e.g., mass differences), effective branching fractions, etc, may be of assistance to validate the behaviour of the program.

Internal SLHA Variables

mode  SLHA:verbose   (default = 1; minimum = 0; maximum = 3)
Controls amount of text output written by the SLHA interface, with a value of 0 corresponding to the most quiet mode. The following variables are used internally by PYTHIA as local copies of SLHA information. User changes will generally have no effect, since these variables will be reset by the SLHA reader during initialization.

flag  SLHA:NMSSM   (default = off)
Corresponds to SLHA block MODSEL entry 3.

Using SLHA for generic BSM Models

Using the QNUMBERS extension [Alw07], the SLHA can also be used to define new particles, with arbitrary quantum numbers. This already serves as a useful way to introduce new particles and can be combined with MASS and DECAY tables in the usual way, to generate isotropically distributed decays or even chains of such decays. (If you want something better than isotropic, sorry, you'll have to do some actual work ...)

A more advanced further option is to make use of the possibility in the SLHA to include user-defined blocks with arbitrary names and contents. Obviously, standalone PYTHIA 8 does not know what to do with such information. However, it does not throw it away either, but instead stores the contents of user blocks as strings, which can be read back later, with the user having full control over the format used to read the individual entries.

The contents of both standard and user-defined SLHA blocks can be accessed in any class inheriting from PYTHIA 8's SigmaProcess class (i.e., in particular, from any semi-internal process written by a user), through its SLHA pointer, slhaPtr, by using the following methods:

bool slhaPtr->getEntry(string blockName, double& val); 
bool slhaPtr->getEntry(string blockName, int indx, double& val); 
bool slhaPtr->getEntry(string blockName, int indx, int jndx, double& val); 
bool slhaPtr->getEntry(string blockName, int indx, int jndx, int kndx, double& val); 

This particular example assumes that the user wants to read the entries (without index, indexed, matrix-indexed, or 3-tensor-indexed, respectively) in the user-defined block blockName, and that it should be interpreted as a double. The last argument is templated, and hence if anything other than a double is desired to be read, the user has only to give the last argument a different type. If anything went wrong (i.e., the block doesn't exist, or it doesn't have an entry with that index, or that entry can't be read as a double), the method returns false; true otherwise. This effectively allows to input completely arbitrary parameters using the SLHA machinery, with the user having full control over names and conventions. Of course, it is then the user's responsibility to ensure complete consistency between the names and conventions used in the SLHA input, and those assumed in any user-written semi-internal process code.

Note that PYTHIA 8 always initializes at least the SLHA blocks MASS and SMINPUTS, starting from its internal SM parameters and particle data table values (updated to take into account user modifications). These blocks can therefore be accessed using the slhaPtr->getEntry() methods even in the absence of SLHA input. Note: in the SMINPUTS block, PYTHIA outputs physically correct (i.e., measured) values of GF, m_Z, and alpha_EM(m_Z). However, if one attempts to compute, e.g., the W mass, at one loop from these quantities, a value of 79 GeV results, with a corresponding value for the weak mixing angle. We advise to instead take the physically measured W mass from block MASS, and recompute the EW parameters as best suited for the application at hand.