3 <title>Resonance Decays</title>
4 <link rel="stylesheet" type="text/css" href="pythia.css"/>
5 <link rel="shortcut icon" href="pythia32.gif"/>
9 <h2>Resonance Decays</h2>
11 The <code>ResonanceDecays</code> class performs the sequential decays of
12 all resonances formed in the hard process. Note the important distinction
13 between "resonances" and other "particles" made in PYTHIA.
16 The list of resonances contains <i>gamma^*/Z^0</i>, <i>W^+-</i>, top,
17 the Higgs, and essentially all new particles of Beyond-the-Standard-Model
18 physics: further Higgses, sfermions, gauginos, techniparticles, and so on.
19 The partial widths to different decay channels are perturbatively
20 calculable, given the parameters of the respective model, and branching
21 ratios may be allowed to vary across a (reasonably broad) resonance peak.
22 Usually resonances are short-lived, and therefore it makes sense to consider
23 their decays immediately after the primary hard process has been set up.
24 Furthermore, in several cases the decay angular distributions are encoded
25 as part of the specific process, e.g. the <i>W</i> decays differently in
26 <i>f fbar -> W^+-</i>, <i>f fbar -> W^+ W^-</i> and
27 <i>h^0 -> W^+ W^- </i>. All of these particles are (in PYTHIA) only
28 produced as part of the hard process itself, i.e. they are not produced
29 in showers or hadronization processes. Therefore the restriction to
30 specific decay channels can be consistently taken into account as a
31 corresponding reduction in the cross section of a process. Finally, note
32 that all of these resonances have an on-shell mass above 20 GeV, with the
33 exception of some hypothetical weakly interacting and stable particles
34 such as the gravitino.
37 The other particles include normal hadrons and the Standard-Model leptons,
38 including the <i>tau^+-</i>. These can be produced in the normal
39 hadronization and decay description, which involve unknown nonperturbative
40 parameters and multistep chains that cannot be predicted beforehand:
41 a hard process like <i>g g -> g g</i> can develop a shower with a
42 <i>g -> b bbar</i> branching, where the <i>b</i> hadronizes to a
43 <i>B^0bar</i> that oscillates to a <i>B^0</i> that decays to a
44 <i>tau^+</i>. Therefore any change of branching ratios - most of which
45 are determined from data rather than from first principles anyway -
46 will not be taken into account in the cross section of a process.
47 Exceptions exist, but most particles in this class are made to decay
48 isotropically. Finally, note that all of these particles have a mass
53 There is one ambiguous case in this classification, namely the photon.
54 The <i>gamma^*/Z^0</i> combination contains a low-mass peak when
55 produced in a hard process. On the other hand, photons can participate
56 in shower evolution, and therefore a photon originally assumed
57 massless can be assigned an arbitrarily high mass when it is allowed
58 to branch into a fermion pair. In some cases this could lead to
59 doublecounting, e.g. between processes such as
60 <i>f fbar -> (gamma^*/Z^0) (gamma^*/Z^0)</i>,
61 <i>f fbar -> (gamma^*/Z^0) gamma</i> and
62 <i>f fbar -> gamma gamma</i>. Here it make sense to limit the
63 lower mass allowed for the <i>gamma^*/Z^0</i> combination,
64 in <code>23:mMin</code>, to be the same as the upper limit allowed
65 for an off-shell photon in the shower evolution, in
66 <code>TimeShower:mMaxGamma</code>. By default this matching is done
70 In spite of the above-mentioned differences, the resonances and the
71 other particles are all stored in one common
72 <a href="ParticleData.html" target="page">particle data table</a>, so as to offer a
73 uniform interface to <a href="ParticleDataScheme.html" target="page">setting and
74 getting</a> properties such as name, mass, charge and decay modes,
75 also for the <a href="ParticleProperties.html" target="page">particle properties</a>
76 in the event record. Some methods are specific to resonances, however,
77 in particular for the calculation of partial widths and thereby of
78 branching ratio. For resonances these can be calculated dynamically,
79 set up at initialization for the nominal mass and then updated to the
80 current mass when these are picked according to a Breit-Wigner resonance
83 <h3>Resonance Decays and Cross Sections</h3>
85 As already hinted above, you have the possibility to set the allowed
86 decay channels of resonances, see
87 <a href="ParticleDataScheme.html" target="page">Particle Data Scheme</a> description.
88 For instance, if you study the process <i>q qbar -> H^0 Z^0</i>
89 you could specify that the <i>Z^0</i> should decay only to
90 lepton pairs, the <i>H^0</i> only to <i>W^+ W^-</i>, the
91 <i>W^+</i> only to a muon and a neutrino, while the <i>W^-</i>
92 can decay to anything. Unfortunately there are limits to the
93 flexibility: you cannot set a resonance to have different properties
94 in different places of a process, e.g. if instead
95 <i>H^0 -> Z^0 Z^0</i> in the above process then the three
96 <i>Z^0</i>'s would all obey the same rules.
99 The restrictions on the allowed final states of a process is directly
100 reflected in the cross section of it. That is, if some final states
101 are excluded then the cross section is reduced accordingly. Such
102 restrictions are built up recursively in cases of sequential decay
103 chains. The restrictions are also reflected in the compositions of
104 those events that actually do get to be generated. For instance,
105 the relative rates of <i>H^0 -> W^+ W^-</i> and
106 <i>H^0 -> Z^0 Z^0</i> are shifted when the allowed sets of
107 <i>W^+-</i> and <i>Z^0</i> decay channels are changed.
110 We remind that only those particles that Pythia treat as resonances
111 enjoy this property, and only those that are considered as part of the
112 hard process and its assocaited resonance decays.
115 There is one key restriction on resonances:
116 <p/><code>parm </code><strong> ResonanceWidths:minWidth </strong>
117 (<code>default = <strong>1e-20</strong></code>; <code>minimum = 1e-30</code>)<br/>
118 Minimal allowed width of a resonance, in GeV. If the width falls below
119 this number the resonance is considered stable and will not be allowed
120 to decay. This is mainly intended as a technical parameter, to avoid
121 disasters in cases where no open decay channels exists at all. It could
122 be used for real-life decisions as well, however, but then typically
123 would have to be much bigger than the default value. Special caution
124 would be needed if coloured resonance particles were made stable, since
125 the program would not necessarily know how to hadronize them, and
126 therefore fail at that stage.
129 <h3>Special properties and methods for resonances</h3>
131 The method <code>ParticleData::isResonance(id)</code> allows you to
132 query whether a given particle species is considered a resonance or not.
133 You can also change the default value of this flag in the normal way,
134 e.g. <code>pythia.readString("id:isResonance = true")</code>.
137 An option with a forced width can be set with the
138 <code>id:doForceWidth</code> flag as above, and queried with
139 <code>ParticleData::doForceWidth(id)</code>. It is by default
140 <code>off</code>, and should normally so remain. If switched
141 <code>on</code> then the width stored in <code>id:mWidth</code> is
142 strictly used to describe the Breit-Wigner of the resonance. This is
143 unlike the normal behaviour of standard resonances such as the
144 <i>Z^0</i>, <i>W^+-</i>, <i>t</i> or <i>h^0</i>, which have
145 explicit decay-widths formulae encoded, in classes derived from the
146 <code><a href="SemiInternalResonances.html" target="page">ResonanceWidths</a></code>
147 base class. These formulae are used, e.g., to derive all the Higgs partial
148 widths as a function of the Higgs mass you choose, and at initialization
149 overwrites the existing total width value. The reason for forcing the
150 width to another value specified by you would normally more have to do
151 with experimental issues than with physics ones, e.g. how sensitive your
152 detector would be to changes in the Higgs width by a factor of two.
153 A warning is that such a rescaling could modify the cross section of
154 a process correspondingly for some processes, while leaving it
155 (essentially) unchanged for others (as would seem most logical),
156 depending on how these were encoded. A further warning is that,
157 if you use this facility for <i>Z^0</i> or <i>Z'^0</i> with
158 <i>gamma^*/Z^0</i> or <i>gamma^*/Z^0/Z'^0</i> interference on,
159 then also the handling of this interference is questionable.
160 So, if you need to use the width-rescaling option, be extremely cautios.
163 If a resonance does not have a class of its own, with hardcoded equations
164 for all relevant partial widths, then a simpler object will be created
165 at initialization. This object will take the total width and branching
166 ratios as is (with the optional variations explained in the next section),
167 and thus the rescaling approach brings no further freedom.
170 Mainly for internal usage, the
171 <code><a href="ParticleDataScheme.html" target="page">ParticleData</a></code> contain
172 some special methods that are only meaningful for resonances:
174 <li><code>resInit(...)</code> to initialize a resonance, possibly
175 including a recalculation of the nominal width to match the nominal
177 <li><code>resWidth(...)</code> to calculate the partial and total widths
178 at the currently selected mass;</li>
179 <li><code>resWidthOpen(...)</code> to calculate the partial and total
180 widths of those channels left open by user switches, at the currently
182 <li><code>resWidthStore(...)</code> to calculate the partial and total
183 widths of those channels left open by user switches, at the currently
184 selected mass, and store those as input for a subsequent selection of
186 <li><code>resOpenFrac(...)</code> to return the fraction of the total
187 width that is open by the decay channel selection made by users (based on
188 the choice of <code><a href="ParticleDataScheme.html" target="page">onMode</a></code>
189 for the various decay channels, recursively calculated for sequential
191 <li><code>resWidthRescaleFactor(...)</code> returns the factor by which
192 the internally calculated PYTHIA width has to be rescaled to give the
193 user-enforced width;</li>
194 <li><code>resWidthChan(...)</code> to return the width for one particular
195 channel (currently only used for Higgs decays, to obtain instate coupling
196 from outstate width).</li>
198 These methods actually provide an interface to the classes derived from
199 the <code>ResonanceWidths</code> base class, to describe various
202 <h3>Modes for Matrix Element Processing</h3>
204 The <code>meMode()</code> value for a decay mode is used to specify
205 <a href="ParticleDecays.html" target="page">nonisotropic decays or the conversion of
206 a parton list into a set of hadrons</a> in some channels of normal
207 particles. For resonances it can also take a third function, namely
208 to describe how the branching ratios and widths of a resonance should
209 be rescaled as a function of the current mass of the decaying resonance.
210 The rules are especially useful when new channels are added to an
211 existing particle, or a completely new resonance added.
214 <li>0 : channels for which hardcoded partial-width expressions are
215 expected to exist in the derived class of the respective resonance.
216 Should no such code exist then the partial width defaults to zero.
218 <li>1 - 99 : same as 0, but normally not used for resonances.</li>
219 <li>100 : calculate the partial width of the channel from its stored
220 branching ratio times the stored total width. This value remains unchanged
221 when the resonance fluctuates in mass. Specifically there are no
222 threshold corrections. That is, if the resonance fluctuates down in
223 mass, to below the nominal threshold, it is assumed that one of the
224 daughters could also fluctuate down to keep the channel open. (If not,
225 there may be problems later on.)
227 <li>101 : calculate the partial width of the channel from its stored
228 branching ratio times the stored total width. Multiply by a step threshold,
229 i.e. the channel is switched off when the sum of the daughter on-shell
230 masses is above the current mother mass.</li>
231 <li>102 : calculate the partial width of the channel from its stored
232 branching ratio times the stored total width. Multiply by a smooth
234 <i>beta = sqrt( (1 - m_1^2/m_2 - m_2^2/m^2)^2 - 4 m_1^2 m_2^2/m^4)</i>
235 for two-body decays and <i>sqrt(1 - Sum_i m_i / m)</i> for multibody
236 ones. The former correctly encodes the size of the phase space but
237 misses out on any nontrivial matrix-element behaviour, while the latter
238 obviously is a very crude simplification of the correct phase-space
239 expression. Specifically, it is thereby assumed that the stored branching
240 ratio and total width did not take into account such a factor.</li>
241 <li>103 : use the same kind of behaviour and threshold factor as for
242 102 above, but assume that such a threshold factor has been used when
243 the default branching ratio and total width were calculated, so that one
244 should additionally divide by the on-shell threshold factor. Specifically,
245 this will give back the stored branching ratios for on-shell mass,
246 unlike the 102 option. To avoid division by zero, or in general
247 unreasonably big rescaling factors, a lower limit
248 <code>minThreshold</code> (see below) on the value of the on-shell
249 threshold factor is imposed. (In cases where a big rescaling is
250 intentional, code 102 would be more appropriate.) </li>
253 <p/><code>parm </code><strong> ResonanceWidths:minThreshold </strong>
254 (<code>default = <strong>0.1</strong></code>; <code>minimum = 0.01</code>)<br/>
255 Used uniquely for <code>meMode = 103</code> to set the minimal value
256 assumed for the threshold factor,
257 <i>sqrt( (1 - m_1^2/m_2 - m_2^2/m^2)^2 - 4 m_1^2 m_2^2/m^4)</i>
258 for two-body decays and <i>sqrt(1 - Sum_i m_i / m)</i> for multibody
259 ones. Thus the inverse of this number sets an upper limit for how
260 much the partial width of a channel can increase from the on-shell
261 value to the value for asymptotically large resonance masses. Is mainly
262 intended as a safety measure, to avoid unintentionally large rescalings.
266 All of these <code>meMode</code>'s may coexist for the same resonance.
267 This would be the case e.g. if you want to add a few new channels to an
268 already existing resonance, where the old partial widths come hardcoded
269 while the new ones are read in from an external file. The typical example
270 would be an MSSM Higgs sector, where partial widths to SM particles are
271 already encoded, <code>meMode = 0</code>, while decay rates to sparticles
272 are read in from some external calculation and maybe would be best
273 approximated by using <code>meMode = 103</code>. Indeed the default
274 particle table in PYTHIA uses 103 for all channels that are expected
275 to be provided by external input.
278 Some further clarification may be useful. At initialization the existing
279 total width and on-shell branching ratios will be updated. For channels
280 with <code>meMode < 100</code> the originally stored branching ratios
281 are irrelevant, since the existing code will anyway be used to calculate
282 the partial widths from scratch. For channels with <code>meMode = 100</code>
283 or bigger, instead the stored branching ratio is used together with the
284 originally stored total width to define the correct on-shell partial width.
285 The sum of partial widths then gives the new total width, and from there
286 new branching ratios are defined.
289 In these operations the original sum of branching ratios need not be
290 normalized to unity. For instance, you may at input have a stored total
291 width of 1 GeV and a sum of branching ratios of 2. After initialization
292 the width will then have been changed to 2 GeV and the sum of branching
293 ratios rescaled to unity. This might happen e.g. if you add a few channels
294 to an existing resonance, without changing the branching ratios of the
295 existing channels or the total width of the resonance.
298 In order to simulate the Breit-Wigner shape correctly, it is important
299 that all channels that contribute to the total width are included in the
300 above operations. This must be kept separate from the issue of which
301 channels you want to have switched on for a particular study, to be
306 In the event-generation process, when an off-shell resonance mass has been
307 selected, the width and branching ratios are re-evaluated for this new mass.
308 At this stage also the effects of restrictions on allowed decay modes are
309 taken into account, as set by the <code>onMode</code> switch for each
310 separate decay channel. Thus a channel may be on or off, with different
311 choices of open channels between the particle and its antiparticle.
312 In addition, even when a channel is on, the decay may be into another
313 resonance with its selection of allowed channels. It is these kinds of
314 restrictions that lead to the <i>Gamma_out</i> possibly being
315 smaller than <i>Gamma_tot</i>. As a reminder, the Breit-Wigner for
316 decays behaves like <i>Gamma_out / ((s - m^2)^2 + s * Gamma_tot^2)</i>,
317 where the width in the numerator is only to those channels being studied,
318 but the one in the denominator to all channels of the particle. These
319 ever-changing numbers are not directly visible to the user, but are only
320 stored in a work area.
325 <!-- Copyright (C) 2010 Torbjorn Sjostrand -->