<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
READMEfile 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
DECAYtables 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
SusyLesHouchesclass, while the subsequent calculation of derived quantities of direct application to SUSY processes is done in the
SLHA:allowUserOverride) provide some safety against unintentionally overwriting PYTHIA's Standard-Model information. These parameters can be altered to hand over more or less control to the SLHA interface. In particular, a lot of mass and decay-table information may be included by default in some SLHA files, without it being the explicit intention of the user to overwrite the corresponding PYTHIA information. The default values of the SLHA safety parameters have been chosen so as to eliminate at least the most obvious causes of Garbage In Garbage Out. (E.g., there is usually no reason to modify the masses of well-measured SM particles, like the W and Z bosons, nor to replace their sophisticated internal decay treatments by the simplified isotropic treatment used for SLHA DECAY tables.)
mMaxcutoffs will normally be placed at 5 times the width or the on-shell mass divided by two, whichever is smaller, so that the default gives a decent sampling of the shape without straying too far from the on-shell value. The user is allowed to use the
mMaxparameters to choose a different sampling range if so desired (still subject to the constraint of at least one decay channel remaining open for on-shell decay products).
SLHA:meMode. If the channel is off shell, then an
meModeof 100 is always used. As a further protection against GIGO, if the channel appears to be physically impossible (defined as requiring fluctuations of more than more than 100 times the effective combined widths), it is switched of and a warning message is printed.
default = 1;
minimum = 0;
maximum = 2)
option0 : is not read at all. Useful when SUSY is not simulated and normal particle properties should not be overwritten.
option1 : read in from the
<slha>...</slha>block of a LHEF, if such a file is read during initialization, and else from the
option2 : read in from the
default = void)
voidsignals that no such file has been assigned.
default = 100.0)
default = off)
offto 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
readStringand related methods.
default = on)
DECAYtables 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
DECAYtable for it and then use PYTHIA's internal
id:MayDecayswitch for that particle, or you may include an SLHA
DECAYtable for it, with the width set explicitly to zero.)
default = 100;
minimum = 100;
maximum = 103)
meMode = 100and 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.
default = 1;
minimum = 0;
maximum = 3)
default = off)
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
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
class (i.e., in particular, from any semi-internal process written by
a user), through its SLHA pointer,
slhaPtr, by using the
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
and that it should be interpreted as
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
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.