]>
Commit | Line | Data |
---|---|---|
5ad4eb21 | 1 | <chapter name="Particle Properties"> |
2 | ||
3 | <h2>Particle Properties</h2> | |
4 | ||
5 | A <code>Particle</code> corresponds to one entry/slot in the | |
6 | event record. Its properties therefore is a mix of ones belonging | |
7 | to a particle-as-such, like its identity code or four-momentum, | |
8 | and ones related to the event-as-a-whole, like which mother it has. | |
9 | ||
10 | <p/> | |
11 | What is stored for each particle is | |
12 | <ul> | |
13 | <li>the identity code,</li> | |
14 | <li>the status code,</li> | |
15 | <li>two mother indices,</li> | |
16 | <li>two daughter indices,</li> | |
17 | <li>a colour and an anticolour index,</li> | |
18 | <li>the four-momentum and mass,</li> | |
19 | <li>the production vertex and proper lifetime,</li> | |
20 | <li>a pointer to the particle kind in the particle data tables.</li> | |
21 | </ul> | |
22 | From these, a number of further quantities may be derived. | |
23 | ||
24 | <h3>Basic methods</h3> | |
25 | ||
26 | The following member functions can be used to extract the information: | |
27 | ||
28 | <method name="id()"> | |
29 | the identity of a particle, according to the PDG particle codes | |
30 | <ref>Yao06</ref>. | |
31 | </method> | |
32 | ||
33 | <method name="status()"> | |
34 | status code. The status code includes information on how a particle was | |
35 | produced, i.e. where in the program execution it was inserted into the | |
36 | event record, and why. It also tells whether the particle is still present | |
37 | or not. It does not tell how a particle disappeared, whether by a decay, | |
38 | a shower branching, a hadronization process, or whatever, but this is | |
39 | implicit in the status code of its daughter(s). The basic scheme is: | |
40 | <ul> | |
41 | <li>status = +- (10 * i + j)</li> | |
42 | <li> + : still remaining particles</li> | |
43 | <li> - : decayed/branched/fragmented/... and not remaining</li> | |
44 | <li> i = 1 - 9 : stage of event generation inside PYTHIA</li> | |
45 | <li> i = 10 -19 : reserved for future expansion</li> | |
46 | <li> i >= 20 : free for add-on programs</li> | |
47 | <li> j = 1 - 9 : further specification</li> | |
48 | </ul> | |
49 | In detail, the list of used or foreseen status codes is: | |
50 | <ul> | |
51 | <li>11 - 19 : beam particles</li> | |
52 | <ul> | |
53 | <li>11 : the event as a whole</li> | |
54 | <li>12 : incoming beam</li> | |
55 | <li>13 : incoming beam-inside-beam (e.g. <ei>gamma</ei> | |
56 | inside <ei>e</ei>)</li> | |
57 | <li>14 : outgoing elastically scattered</li> | |
58 | <li>15 : outgoing diffractively scattered</li> | |
59 | </ul> | |
60 | <li>21 - 29 : particles of the hardest subprocess</li> | |
61 | <ul> | |
62 | <li>21 : incoming</li> | |
63 | <li>22 : intermediate (intended to have preserved mass)</li> | |
64 | <li>23 : outgoing</li> | |
65 | </ul> | |
66 | <li>31 - 39 : particles of subsequent subprocesses</li> | |
67 | <ul> | |
68 | <li>31 : incoming</li> | |
69 | <li>32 : intermediate (intended to have preserved mass)</li> | |
70 | <li>33 : outgoing</li> | |
71 | </ul> | |
72 | <li>41 - 49 : particles produced by initial-state-showers</li> | |
73 | <ul> | |
74 | <li>41 : incoming on spacelike main branch</li> | |
75 | <li>42 : incoming copy of recoiler</li> | |
76 | <li>43 : outgoing produced in timelike sidebranch of shower</li> | |
77 | <li>44 : outgoing shifted by the branching</li> | |
78 | </ul> | |
79 | <li>51 - 59 : particles produced by final-state-showers</li> | |
80 | <ul> | |
81 | <li>51 : outgoing produced by parton branching</li> | |
82 | <li>52 : outgoing copy of recoiler, with changed momentum</li> | |
83 | <li>53 : copy of recoiler when this is incoming parton, | |
84 | with changed momentum</li> | |
85 | </ul> | |
86 | <li>61 - 69 : particles produced by beam-remnant treatment</li> | |
87 | <ul> | |
88 | <li>61 : incoming subprocess particle with primordial <ei>kT</ei> | |
89 | included</li> | |
90 | <li>62 : outgoing subprocess particle with primordial <ei>kT</ei> | |
91 | included</li> | |
92 | <li>63 : outgoing beam remnant</li> | |
93 | </ul> | |
94 | <li>71 - 79 : partons in preparation of hadronization process</li> | |
95 | <ul> | |
96 | <li>71 : copied partons to collect into contiguous colour singlet</li> | |
97 | <li>72 : copied recoiling singlet when ministring collapses to | |
98 | one hadron and momentum has to be reshuffled</li> | |
99 | <li>73 : combination of very nearby partons into one</li> | |
100 | <li>74 : combination of two junction quarks (+ nearby gluons) | |
101 | to a diquark</li> | |
102 | <li>75 : gluons split to decouple a junction-antijunction pair</li> | |
103 | <li>76 : partons with momentum shuffled to decouple a | |
104 | junction-antijunction pair </li> | |
105 | <li>77 : temporary opposing parton when fragmenting first two | |
106 | strings in to junction (should disappear again)</li> | |
107 | <li>78 : temporary combined diquark end when fragmenting last | |
108 | string in to junction (should disappear again)</li> | |
109 | </ul> | |
110 | <li>81 - 89 : primary hadrons produced by hadronization process</li> | |
111 | <ul> | |
112 | <li>81 : from ministring into one hadron</li> | |
113 | <li>82 : from ministring into two hadrons</li> | |
114 | <li>83, 84 : from normal string (the difference between the two | |
115 | is technical, whether fragmented off from the top of the | |
116 | string system or from the bottom, useful for debug only)</li> | |
117 | <li>85, 86 : primary produced hadrons in junction frogmentation of | |
118 | the first two string legs in to the junction, | |
119 | in order of treatment</li> | |
120 | </ul> | |
121 | <li>91 - 99 : particles produced in decay process, or by Bose-Einstein | |
122 | effects</li> | |
123 | <ul> | |
124 | <li>91 : normal decay products</li> | |
125 | <li>92 : decay products after oscillation <ei>B0 <-> B0bar</ei> or | |
126 | <ei>B_s0 <-> B_s0bar</ei></li> | |
127 | <li>93, 94 : decay handled by external program, normally | |
128 | or with oscillation</li> | |
129 | <li>99 : particles with momenta shifted by Bose-Einstein effects | |
130 | (not a proper decay, but bookkept as an <ei>1 -> 1</ei> such, | |
131 | happening after decays of short-lived resonances but before | |
132 | decays of longer-lived particles)</li> | |
133 | </ul> | |
134 | <li>101 - 199 : reserved for future expansion</li> | |
135 | <li>201 - : free to be used by anybody</li> | |
136 | </ul> | |
137 | </method> | |
138 | ||
139 | <method name="mother1(), mother2()"> | |
140 | the indices in the event record where the first and last mothers are | |
141 | stored, if any. There are five allowed combinations of <code>mother1</code> | |
142 | and <code>mother2</code>: | |
143 | <ol> | |
144 | <li><code>mother1 = mother2 = 0</code>: for lines 0 - 2, where line 0 | |
145 | represents the event as a whole, and 1 and 2 the two incoming | |
146 | beam particles; </li> | |
147 | <li><code>mother1 = mother2 > 0</code>: the particle is a "carbon copy" | |
148 | of its mother, but with changed momentum as a "recoil" effect, | |
149 | e.g. in a shower;</li> | |
150 | <li><code>mother1 > 0, mother2 = 0</code>: the "normal" mother case, where | |
151 | it is meaningful to speak of one single mother to several products, | |
152 | in a shower or decay;</li> | |
153 | <li><code>mother1 < mother2</code>, both > 0, for | |
154 | <code>abs(status) = 81 - 86</code>: primary hadrons produced from the | |
155 | fragmentation of a string spanning the range from <code>mother1</code> | |
156 | to <code>mother2</code>, so that all partons in this range should be | |
157 | considered mothers;</li> | |
158 | <li><code>mother1 < mother2</code>, both > 0, except case 4: particles | |
159 | with two truly different mothers, in particular the particles emerging | |
160 | from a hard <ei>2 -> n</ei> interaction.</li> | |
161 | </ol> | |
162 | <note>Note 1:</note> in backwards evolution of initial-state showers, | |
163 | the mother may well appear below the daughter in the event record. | |
164 | <note>Note 2:</note> the <code>motherList(i)</code> method of the | |
165 | <code>Event</code> class returns a vector of all the mothers, | |
166 | providing a uniform representation for all five cases. | |
167 | </method> | |
168 | ||
169 | <method name="daughter1(), daughter2()"> | |
170 | the indices in the event record where the first and last daughters | |
171 | are stored, if any. There are five allowed combinations of | |
172 | <code>daughter1</code> and <code>daughter2</code>: | |
173 | <ol> | |
174 | <li><code>daughter1 = daughter2 = 0</code>: there are no daughters | |
175 | (so far);</li> | |
176 | <li><code>daughter1 = daughter2 > 0</code>: the particle has a | |
177 | "carbon copy" as its sole daughter, but with changed momentum | |
178 | as a "recoil" effect, e.g. in a shower;</li> | |
179 | <li><code>daughter1 > 0, daughter2 = 0</code>: each of the incoming beams | |
180 | has only (at most) one daughter, namely the initiator parton of the | |
181 | hardest interaction; further, in a <ei>2 -> 1</ei> hard interaction, | |
182 | like <ei>q qbar -> Z^0</ei>, or in a clustering of two nearby partons, | |
183 | the initial partons only have this one daughter;</li> | |
184 | <li><code>daughter1 < daughter2</code>, both > 0: the particle has | |
185 | a range of decay products from <code>daughter1</code> to | |
186 | <code>daughter2</code>;</li> <li><code>daughter2 < daughter1</code>, | |
187 | both > 0: the particle has two separately stored decay products (e.g. | |
188 | in backwards evolution of initial-state showers).</li> | |
189 | </ol> | |
190 | <note>Note 1:</note> in backwards evolution of initial-state showers, the | |
191 | daughters may well appear below the mother in the event record. | |
192 | <note>Note 2:</note> the mother-daughter relation normally is reciprocal, | |
193 | but not always. An example is hadron beams (indices 1 and 2), where each | |
194 | beam remnant and the initiator of each multiple interaction has the | |
195 | respective beam as mother, but the beam itself only has the initiator | |
196 | of the hardest interaction as daughter. | |
197 | <note>Note 3:</note> the <code>daughterList(i)</code> method of the | |
198 | <code>Event</code> class returns a vector of all the daughters, | |
199 | providing a uniform representation for all five cases. With this method, | |
200 | also all the daughters of the beams are caught, with the initiators of | |
201 | the basic process given first, while the rest are in no guaranteed order | |
202 | (since they are found by a scanning of the event record for particles | |
203 | with the beam as mother, with no further information). | |
204 | </method> | |
205 | ||
206 | <method name="col(), acol()"> | |
207 | the colour and anticolour tags, Les Houches Accord <ref>Boo01</ref> | |
208 | style (starting from tag 101 by default, see below). | |
209 | </method> | |
210 | ||
211 | <method name="px(), py(), pz(), e()"> | |
212 | the particle four-momentum components, alternatively extracted as a | |
213 | <code>Vec4 p()</code>. | |
214 | </method> | |
215 | ||
216 | <method name="m()"> | |
217 | the particle mass. | |
218 | </method> | |
219 | ||
220 | <method name="scale()"> | |
221 | the scale at which a parton was produced, which can be used to restrict | |
222 | its radiation to lower scales in subsequent steps of the shower evolution. | |
223 | Note that scale is linear in momenta, not quadratic (i.e. <ei>Q</ei>, | |
224 | not <ei>Q^2</ei>). | |
225 | </method> | |
226 | ||
227 | <method name="xProd(), yProd(), zProd(), tProd()"> | |
228 | the production vertex coordinates, in mm or mm/c, alternatively extracted | |
229 | as a <code>Vec4 vProd()</code>. The initial process is assumed to occur | |
230 | at the origin. | |
231 | <note>Note:</note>the <code>Vec4</code> has components px(), py(), | |
232 | pz() and e(), which of course should be reinterpreted as above. | |
233 | </method> | |
234 | ||
235 | <method name="tau()"> | |
236 | the proper lifetime, in mm/c; is assigned for all hadrons with | |
237 | positive nominal <ei>tau</ei>, <ei>tau_0 > 0</ei>, even if not | |
238 | decayed by PYTHIA (because of one veto or another). | |
239 | </method> | |
240 | ||
241 | <p/> | |
242 | The same method names are overloaded to take an argument, in which case | |
243 | the corresponding property is set accordingly. | |
244 | ||
245 | <h3>Further methods</h3> | |
246 | ||
247 | There are a few alternative methods for input: | |
248 | ||
249 | <method name="statusPos(), statusNeg()"> | |
250 | sets the status sign positive or negative, without changing the absolute value. | |
251 | </method> | |
252 | ||
253 | <method name="statusCode(code)"> | |
254 | changes the absolute value but retains the original sign. | |
255 | </method> | |
256 | ||
257 | <method name="mothers(m1, m2)"> | |
258 | sets both mothers in one go. | |
259 | </method> | |
260 | ||
261 | <method name="daughters(d1, d2)"> | |
262 | sets both daughters in one go. | |
263 | </method> | |
264 | ||
265 | <method name="cols(c, ac)"> | |
266 | sets both colour and anticolour in one go. | |
267 | </method> | |
268 | ||
269 | <method name="p( px, py, pz, e)"> | |
270 | sets the four-momentum in one go; | |
271 | alternative input as a <code>Vec4</code> object. | |
272 | </method> | |
273 | ||
274 | <method name="vProd( xProd, yProd, zProd, tProd)"> | |
275 | sets the production vertex in one go; alternative input as a | |
276 | <code>Vec4</code> | |
277 | object. | |
278 | </method> | |
279 | ||
280 | <p/> | |
281 | In addition, a number of derived quantities can easily be obtained | |
282 | (but cannot be set), such as: | |
283 | ||
284 | <method name="idAbs()"> | |
285 | the absolute value of the particle identity code. | |
286 | </method> | |
287 | ||
288 | <method name="statusAbs()"> | |
289 | the absolute value of the status code. | |
290 | </method> | |
291 | ||
292 | <method name="isFinal()"> | |
293 | true for a remaining particle, i.e. one with positive status code, | |
294 | else false. Thus, after an event has been fully generated, it | |
295 | separates the final-state particles from intermediate-stage ones. | |
296 | (If used earlier in the generation process, a particle then | |
297 | considered final may well decay later.) | |
298 | </method> | |
299 | ||
300 | <method name="m2()"> | |
301 | squared mass. | |
302 | </method> | |
303 | ||
304 | <method name="mCalc(), m2Calc()"> | |
305 | (squared) mass calculated from the four-momentum; should agree | |
306 | with <code>m(), m2()</code> up to roundoff. | |
307 | </method> | |
308 | ||
309 | <method name="eCalc()"> | |
310 | energy calculated from the mass and three-momentum; | |
311 | should agree with <code>e()</code> up to roundoff. | |
312 | </method> | |
313 | ||
314 | <method name="pT(), pT2()"> | |
315 | (squared) transverse momentum. | |
316 | </method> | |
317 | ||
318 | <method name="mT(), mT2()"> | |
319 | (squared) transverse mass. | |
320 | </method> | |
321 | ||
322 | <method name="pAbs(), pAbs2()"> | |
323 | (squared) three-momentum size. | |
324 | </method> | |
325 | ||
326 | <method name="theta(), phi()"> | |
327 | polar and azimuthal angle. | |
328 | </method> | |
329 | ||
330 | <method name="thetaXZ()"> | |
331 | angle in the <ei>(p_x, p_z)</ei> plane, between <ei>-pi</ei> and | |
332 | <ei>+pi</ei>, with 0 along the <ei>+z</ei> axis | |
333 | </method> | |
334 | ||
335 | <method name="pPlus(), pMinus()"> | |
336 | <ei>E +- p_z</ei>. | |
337 | </method> | |
338 | ||
339 | <method name="y(), eta()"> | |
340 | rapidity and pseudorapidity. | |
341 | </method> | |
342 | ||
343 | <method name="xDec(), yDec(), zDec(), tDec()"> | |
344 | the decay vertex coordinates, in mm or mm/c, alternatively extracted as | |
345 | a <code>Vec4 vDec()</code>; this decay vertex is calculated from the | |
346 | production vertex, the proper lifetime and the four-momentum assuming | |
347 | no magnetic field or other detector interference; it can be used to | |
348 | decide whether a decay should be performed or not, and thus is defined | |
349 | also for particles which PYTHIA did not let decay. | |
350 | </method> | |
351 | ||
352 | <p/> | |
353 | Each Particle contains a pointer to the respective | |
354 | <code>ParticleDataEntry</code> object in the | |
355 | <aloc href="ParticleDataScheme">particle data tables</aloc>. | |
356 | This gives access to properties of the particle species as such. It is | |
357 | there mainly for convenience, and should be thrown if an event is | |
358 | written to disk, to avoid any problems of object persistency. Should | |
359 | an event later be read back in, the pointer will be recreated from the | |
360 | <code>id</code> code if the normal input methods are used. (Use the | |
361 | <aloc href="EventRecord"><code>Event::restorePtrs()</code></aloc> method | |
362 | if your persistency scheme bypasses the normal methods.) This pointer is | |
363 | used by the following member functions: | |
364 | ||
365 | <method name="name()"> | |
366 | the name of the particle, as a string. | |
367 | </method> | |
368 | ||
369 | <method name="nameWithStatus()"> | |
370 | as above, but for negative-status particles the name is given in | |
371 | brackets to emphasize that they are intermediaries. | |
372 | </method> | |
373 | ||
374 | <method name="spinType()"> | |
375 | <ei>2 *spin + 1</ei> when defined, else 0. | |
376 | </method> | |
377 | ||
378 | <method name="charge(), chargeType()"> | |
379 | charge, and three times it to make an integer. | |
380 | </method> | |
381 | ||
382 | <method name="isCharged(), isNeutral()"> | |
383 | charge different from or equal to 0. | |
384 | </method> | |
385 | ||
386 | <method name="colType()"> | |
387 | 0 for colour singlets, 1 for triplets, | |
388 | -1 for antitriplets and 2 for octets. | |
389 | </method> | |
390 | ||
391 | <method name="m0()"> | |
392 | the nominal mass of the particle, according to the data tables. | |
393 | </method> | |
394 | ||
395 | <method name="mWidth(), mMin(), mMax()"> | |
396 | the width of the particle, and the minimum and maximum allowed mass value | |
397 | for particles with a width, according to the data tables. | |
398 | </method> | |
399 | ||
400 | <method name="mass()"> | |
401 | the mass of the particle, picked according to a Breit-Wigner | |
402 | distribution for particles with width, and thus different each | |
403 | time called. | |
404 | </method> | |
405 | ||
406 | <method name="constituentMass()"> | |
407 | will give the constituent masses for quarks and diquarks, | |
408 | else the same masses as with <code>m0()</code>. | |
409 | </method> | |
410 | ||
411 | <method name="isResonance()"> | |
412 | particles where the decay is to be treated as part of the hard process, | |
413 | typically with nominal mass above 20 GeV (<ei>W^+-, Z^0, t, ...</ei>). | |
414 | </method> | |
415 | ||
416 | <method name="mayDecay()"> | |
417 | flag whether particle has been declared unstable or not, offering | |
418 | the main user switch to select which particle species to decay. | |
419 | </method> | |
420 | ||
421 | <method name="canDecay()"> | |
422 | flag whether decay modes have been declared for a particle, | |
423 | so that it could be decayed, should that be requested. | |
424 | </method> | |
425 | ||
426 | <method name="doExternalDecay()"> | |
427 | particles that are decayed by an external program. | |
428 | </method> | |
429 | ||
430 | <method name="isVisible()"> | |
431 | particles with strong or electric charge, or composed of ones having it, | |
432 | which thereby should be considered visible in a normal detector. | |
433 | </method> | |
434 | ||
435 | <method name="doForceWidth()"> | |
436 | resonances that have code to recalculate the width in <code>mWidth</ei> | |
437 | from the nominal mass value <code>m0</code>, but where nevertheless the | |
438 | stored <code>mWidth</ei> value is used. | |
439 | </method> | |
440 | ||
441 | <method name="isLepton()"> | |
442 | true for a lepton or an antilepton (including neutrinos). | |
443 | </method> | |
444 | ||
445 | <method name="isQuark()"> | |
446 | true for a quark or an antiquark. | |
447 | </method> | |
448 | ||
449 | <method name="isGluon()"> | |
450 | true for a gluon. | |
451 | </method> | |
452 | ||
453 | <method name="isHadron()"> | |
454 | true for a hadron (made up out of normal quarks and gluons, | |
455 | i.e. not for R-hadrons and other exotic states). | |
456 | </method> | |
457 | ||
458 | <method name="particleData()"> | |
459 | a reference to the ParticleDataEntry. | |
460 | </method> | |
461 | ||
462 | <p/> | |
463 | There are some further methods, inherited from <code>Vec4</code>, | |
464 | to rotate and boost the four-momentum. | |
465 | ||
466 | <p/> | |
467 | Not part of the event class proper, but obviously tightly linked, | |
468 | are the metods <code>m(Particle, Particle)</code> and | |
469 | <code>m2(Particle, Particle)</code> to calculate the (squared) | |
470 | invariant mass of two particles. | |
471 | ||
472 | <p/> | |
473 | The | |
474 | <aloc href="EventRecord"><code>Event</code></aloc> | |
475 | class also contains a few methods defined for individual particles, | |
476 | but these may require some search in the event record and therefore | |
477 | cannot be defined as a <code>Particle</code> method. | |
478 | ||
479 | <p/> | |
480 | Currently there is no information on polarization states. | |
481 | ||
482 | </chapter> | |
483 | ||
484 | <!-- Copyright (C) 2008 Torbjorn Sjostrand --> | |
485 |