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.
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.
The restrictions on the allowed final states of a process is directly reflected in the cross section of it. That is, if some final states are excluded then the cross section is reduced accordingly. Such restrictions are built up recursively in cases of sequential decay chains. The restrictions are also reflected in the compositions of those events that actually do get to be generated. For instance, the relative rates of H^0 → W^+ W^- and H^0 → Z^0 Z^0 are shifted when the allowed sets of W^+- and Z^0 decay channels are changed.
We remind that only those particles that Pythia treat as resonances enjoy this property, and only those that are considered as part of the hard process and its associated resonance decays.
There is one key restriction on resonances:
parm
ResonanceWidths:minWidth
(default = 1.97e-19
; minimum = 1e-30
)
Minimal allowed width of a resonance, in GeV. If the width falls below
this number the resonance is considered stable and will not be allowed
to decay. This is mainly intended as a technical parameter, to avoid
disasters in cases where no open decay channels exists at all. It could
be used for real-life decisions as well, however. The default value
corresponds to an average lifetime c * tau of 1 km, meaning
such a particle would only rarely decay inside a typical detector.
Special caution would be needed if coloured resonance particles were
made stable, since the program would not necessarily know how to
hadronize them, and therefore fail at that stage (see further the
R-hadrons description).
In spite of this technical parameter choice, it is possible to set a lifetime for a resonance, and thereby to obtain displaced vertices. If a resonance is allowed to decay it will do so, irrespective of the location of the decay vertex. This is unlike normal particle decays, where it is possible to define some region around the primary vertex within which all decays should happen, with particles leaving that region considered stable. The logic is that resonances as a rule are too short-lived for secondary vertices, so if you pick a scenario with a long-lived but unstable resonance it is because you want to study secondary vertices. How to interface those decays to a detector simulation program then is another story, to be solved separately. Do note that a special treatment is needed for coloured long-lived resonances, that form R-hadrons, and where charge and flavour may change between the production and decay vertices.
ParticleData::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")
.
Resonances come in two kinds.
ResonanceWidths
base class. The formulae are used, e.g., to calculate all the partial
widths as a function of the resonance masses you choose, and at
initialization the existing total width values are overwritten.
This is especially convenient for hypothetical states, like a Z',
where the mass is not known and therefore routinely changed. Often the
partial widths are associated with parameters that can be changed by the
user, e.g. for MSSM Higgs states.
id:mWidth
can be changed right away, but for the first
kind any change will be overwritten at initialization. To circumvent
this problem, the id:doForceWidth
flag can be changed from
the default off
to on
. Then the width stored
in id:mWidth
is strictly used to describe the Breit-Wigner
of the resonance. Partial widths are still recalculated to set the
mass-dependent branching ratios, but then uniformly rescaled to the
requested total width. The width can also run across the lineshape,
so that it deviates from the nominal one in the wings of the
Breit-Wigner.
For processes that contain interference terms between resonances,
notably gamma^*/Z^0 or gamma^*/Z^0/Z'^0, it is not
obvious how these contributions should be modified consistently.
Therefore it is necessary to set WeakZ0:gmZmode = 2
or Zprime:gmZmode = 3
, to have a pure Z^0 or
Z'^0, respectively, for width forcing to be allowed in
these cases.
A warning is that the different processes have cross sections
that rescale in different ways when the resonance width is varied.
This depends on them not having been implemented in a guaranteed
uniform way. To illustrate the point, consider the case of an
s-channel resonance, where the cross section dependence
on the width can be written as
sigmaHat(sHat) = constant * Gamma_in * Gamma_out
/ ((sHat - m^2)^2 + m^2 * Gamma^2)
Here the doForceWidth = on
option ensures that the
Gamma in the denominator is rescaled by some factor
k relative to the natural width, but does not guarantee
that Gamma_in and Gamma_out are rescaled as well.
If all three are rescaled by the same factor k, as they
should, then the integrated cross section also scales like k,
assuming that the peak is reasonably narrow, so that the variation
of PDF's across the Breit-Wigner can be neglected. This is the case
for some processes. But in others either or both of the production
and decay vertices can have been hardcoded, based on the coupling
structure, and thus not scale with k. If only
Gamma_out scales with k, say, the cross section
remains (approximately) constant, and if neither scales the cross
section will even go like 1/k. Such obvious normalization
imperfections have to be corrected by hand.
Mainly for internal usage, the
ParticleData
contain
some special methods that are only meaningful for resonances:
resInit(...)
to initialize a resonance, possibly
including a recalculation of the nominal width to match the nominal
mass;resWidth(...)
to calculate the partial and total widths
at the currently selected mass;resWidthOpen(...)
to calculate the partial and total
widths of those channels left open by user switches, at the currently
selected mass;resWidthStore(...)
to calculate the partial and total
widths of those channels left open by user switches, at the currently
selected mass, and store those as input for a subsequent selection of
decay channel;resOpenFrac(...)
to return the fraction of the total
width that is open by the decay channel selection made by users (based on
the choice of onMode
for the various decay channels, recursively calculated for sequential
decays);resWidthRescaleFactor(...)
returns the factor by which
the internally calculated PYTHIA width has to be rescaled to give the
user-enforced width;resWidthChan(...)
to return the width for one particular
channel (currently only used for Higgs decays, to obtain instate coupling
from outstate width).ResonanceWidths
base class, to describe various
resonances.
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 rules are especially useful when new channels are added to an
existing particle, or a completely new resonance added.
minThreshold
(see below) on the value of the on-shell
threshold factor is imposed. (In cases where a big rescaling is
intentional, code 102 would be more appropriate.) parm
ResonanceWidths:minThreshold
(default = 0.1
; minimum = 0.01
)
Used uniquely for meMode = 103
to set the minimal value
assumed for the threshold factor,
sqrt( (1 - m_1^2/m_2 - m_2^2/m^2)^2 - 4 m_1^2 m_2^2/m^4)
for two-body decays and sqrt(1 - Sum_i m_i / m) for multibody
ones. Thus the inverse of this number sets an upper limit for how
much the partial width of a channel can increase from the on-shell
value to the value for asymptotically large resonance masses. Is mainly
intended as a safety measure, to avoid unintentionally large rescalings.
All of these meMode
's may coexist for the same resonance.
This would be the case e.g. if you want to add a few new channels to an
already existing resonance, where the old partial widths come hardcoded
while the new ones are read in from an external file. The typical example
would be an MSSM Higgs sector, where partial widths to SM particles are
already encoded, meMode = 0
, while decay rates to sparticles
are read in from some external calculation and maybe would be best
approximated by using meMode = 103
. Indeed the default
particle table in PYTHIA uses 103 for all channels that are expected
to be provided by external input.
Some further clarification may be useful. At initialization the existing
total width and on-shell branching ratios will be updated. For channels
with meMode < 100
the originally stored branching ratios
are irrelevant, since the existing code will anyway be used to calculate
the partial widths from scratch. For channels with meMode = 100
or bigger, instead the stored branching ratio is used together with the
originally stored total width to define the correct on-shell partial width.
The sum of partial widths then gives the new total width, and from there
new branching ratios are defined.
In these operations the original sum of branching ratios need not be normalized to unity. For instance, you may at input have a stored total width of 1 GeV and a sum of branching ratios of 2. After initialization the width will then have been changed to 2 GeV and the sum of branching ratios rescaled to unity. This might happen e.g. if you add a few channels to an existing resonance, without changing the branching ratios of the existing channels or the total width of the resonance.
In order to simulate the Breit-Wigner shape correctly, it is important that all channels that contribute to the total width are included in the above operations. This must be kept separate from the issue of which channels you want to have switched on for a particular study, to be considered next.
In the event-generation process, when an off-shell resonance mass has been
selected, the width and branching ratios are re-evaluated for this new mass.
At this stage also the effects of restrictions on allowed decay modes are
taken into account, as set by the onMode
switch for each
separate decay channel. Thus a channel may be on or off, with different
choices of open channels between the particle and its antiparticle.
In addition, even when a channel is on, the decay may be into another
resonance with its selection of allowed channels. It is these kinds of
restrictions that lead to the Gamma_out possibly being
smaller than Gamma_tot. As a reminder, the Breit-Wigner for
decays behaves like Gamma_out / ((s - m^2)^2 + s * Gamma_tot^2),
where the width in the numerator is only to those channels being studied,
but the one in the denominator to all channels of the particle. These
ever-changing numbers are not directly visible to the user, but are only
stored in a work area.
UserHooks
code ResonanceDecayFilterHooks
available in include/Pythia8Plugins
provides a convenient
way to select a specific final state from resonance decays. For
example, this could be applied to provide events from top pair
production that include leptons + jets. The example
main248.cc
demonstrates how to use this user hook. Further
documentation on the available settings can by found in the
ResonanceDecayFilterHooks.h
header file.
Note, by default, particle types are treated individually.
Different flags below allow for similar treatment for similar types.
flag
ResonanceDecayFilter:filter
(default = off
)
By default, the filter is not activate.
Activate filter if true/on.
flag
ResonanceDecayFilter:exclusive
(default = off
)
If true/on, demand exactly the particles requested by the filter.
flag
ResonanceDecayFilter:eMuAsEquivalent
(default = off
)
If true/on, treat the particle id for electron and muon as the same.
flag
ResonanceDecayFilter:eMuTauAsEquivalent
(default = off
)
As above, but include tau leptons if true/on.
flag
ResonanceDecayFilter:allNuAsEquivalent
(default = off
)
If true/on, treat the particle id for different neutrinos as the same.
flag
ResonanceDecayFilter:udscAsEquivalent
(default = off
)
If true/on, treat the particle id for all up, down, strange, and charm
quarks as the same.
flag
ResonanceDecayFilter:udscbAsEquivalent
(default = off
)
As above, but include bottom quarks.
flag
ResonanceDecayFilter:wzAsEquivalent
(default = off
)
If true/on, treat the particle id for W and Z bosons as the same.
mvec
ResonanceDecayFilter:mothers
(default = {0}
)
By default, all resonance decay products are considered.
If provided, only the set of provided mothers will be filtered.
mvec
ResonanceDecayFilter:daughters
(default = {0}
)
A list of particle ids for resonance decay products that
will pass the filter. If empty, all particles will pass the
filter. Caution:: an infinite loop arises if any daughter never
appears in resonance decays.
UserHooks
code SetLHEDecayProductHook
in
include/PythiaPlugins
provides a way to modify the decay
products of resonances from imported LHE events. The current use case
changes an LHE file with two resonances decaying to leptons into a
process where one resonance decays leptonically, the other
hadronically.
flag
SetLHEDecayProduct:filter
(default = off
)
Add documentation.