Resonance Decays

The ResonanceDecays class performs the sequential decays of all resonances formed in the hard process. Note the important distinction between "resonances" and other "particles" made in PYTHIA. There is one ambiguous case in this classification, namely the photon. The gamma^*/Z^0 combination contains a low-mass peak when produced in a hard process. On the other hand, photons can participate in shower evolution, and therefore a photon originally assumed massless can be assigned an arbitrarily high mass when it is allowed to branch into a fermion pair. In some cases this could lead to doublecounting, e.g. between processes such as f fbar -> (gamma^*/Z^0) (gamma^*/Z^0), f fbar -> (gamma^*/Z^0) gamma and f fbar -> gamma gamma. Here it make sense to limit the lower mass allowed for the gamma^*/Z^0 combination, in 23:mMin to be the same as the upper limit allowed for an off-shell photon in the shower evolution, in TimeShower:mMaxGamma. By default this matching is done at 10 GeV.

In spite of the above-mentioned differences, the resonances and the other particles are all stored in one common particle data table, so as to offer a uniform interface to setting and getting properties such as name, mass, charge and decay modes, also for the particle properties in the event record. Some methods are specific to resonances, however, in particular for the calculation of partial widths and thereby of branching ratio. For resonances these can be calculated dynamically, set up at initialization for the nominal mass and then updated to the current mass when these are picked according to a Breit-Wigner resonance shape.

Special properties and methods for resonances

The method ParticleDataTable::isResonance(id) allows you to query whether a given particle species is considered a resonance or not. You can also change the default value of this flag in the normal way, e.g. pythia.readString("id:isResonance = true").

An option with a a forced width can be set with the id:doForceWidth flag as above, and queried with ParticleDataTable::doForceWidth(id). It is by default off, and should normally so remain. If switched on then the width stored in id:mWidth is strictly used to describe the Breit-Wigner of the resonance. This is unlike the normal behaviour of standard resonances such as the Z^0, W^+-, t or h^0, which have explicit decay-widths formulae encoded, in classes derived from the ResonanceWidths base class. These formulae are used, e.g., to derive all the Higgs partial widths as a function of the Higgs mass you choose, and at initialization overwrites the existing total width value. The reason for forcing the width to another value specified by you would normally more have to do with experimental issues than with physics ones, e.g. how sensitive your detector would be to changes in the Higgs width by a factor of two. A warning is that such a rescaling could modify the cross section of a process correspondingly for some processes, while leaving it (essentially) unchanged for others (as would seem most logical), depending on how these were encoded.

If a resonance does not have a class of its own, with hardcoded equations for all relevant partial widths, then a simpler object will be created at initialization. This object will take the total width and branching ratios as is (with the optional variations explained in the next section), and thus the rescaling approach makes no sense.

Mainly for internal usage, the ParticleDataTable contain some special methods that are only meaningful for resonances:

These methods actually provide an interface to the classes derived from the ResonanceWidths base class, to describe various resonances.

Modes for Matrix Element Processing

The meMode() value for a decay mode is used to specify nonisotropic decays or the conversion of a parton list into a set of hadrons in some channels of normal particles. For resonances it can also take a third function, namely to describe how the branching ratios and widths of a resonance should be rescaled as a function of the current mass of the decaying resonance. The codes are not intended for channels where the ResonanceWidths class already contains the correct formulae for the various partial widths, but rather for when the only information available is the on-shell branching ratios and the total width, typically read in from an external program. If no code is set, i.e. if one defaults to 0, then no special threshold behaviour is imposed. If the mother fluctuates down in mass, to below the nominal threshold, 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.)