[1] | 1 | <html> |
---|
| 2 | <head> |
---|
| 3 | <title>Hadron-Level Standalone</title> |
---|
| 4 | <link rel="stylesheet" type="text/css" href="pythia.css"/> |
---|
| 5 | <link rel="shortcut icon" href="pythia32.gif"/> |
---|
| 6 | </head> |
---|
| 7 | <body> |
---|
| 8 | |
---|
| 9 | <h2>Hadron-Level Standalone</h2> |
---|
| 10 | |
---|
| 11 | The Les Houches Accord allows external process-level configurations |
---|
| 12 | to be fed in, for subsequent parton-level and hadron-level generation |
---|
| 13 | to be handled internally by PYTHIA. There is no correspondingly |
---|
| 14 | standardized interface if you have external events that have also |
---|
| 15 | been generated through the parton-level stage, so that only the |
---|
| 16 | hadron-level remains to be handled. A non-standard way to achieve this |
---|
| 17 | exists, however, and can be useful both for real applications and |
---|
| 18 | for various tests of the hadronization model on its own. |
---|
| 19 | |
---|
| 20 | <p/> |
---|
| 21 | The key trick is to set the flag <code>ProcessLevel:all = off</code>. |
---|
| 22 | When <code>pythia.next()</code> is called it then does not try to |
---|
| 23 | generate a hard process. Since there are no beams, it is also not |
---|
| 24 | possible to perform the normal <code>PartonLevel</code> step. |
---|
| 25 | (It is still possible to generate final-state radiation, but this |
---|
| 26 | is not automatic. It would have to be done by hand, using the |
---|
| 27 | <code>pythia.forceTimeShower(...)</code> method, before |
---|
| 28 | <code>pythia.next()</code> is called.) |
---|
| 29 | Thus only the <code>HadronLevel</code> methods are |
---|
| 30 | called, to take the current content of the event record stored in |
---|
| 31 | <code>pythia.event</code> as a starting point for any hadronization |
---|
| 32 | and decays that are allowed by the normal parameters of this step. |
---|
| 33 | Often the input would consist solely of partons grouped into colour |
---|
| 34 | singlets, but also (colour-singlet) particles are allowed. |
---|
| 35 | |
---|
| 36 | <p/> |
---|
| 37 | To set up all the parameters, a <code>pythia.init()</code> call has |
---|
| 38 | to be used, without any arguments. In brief, the structure of the |
---|
| 39 | main program therefore should be something like |
---|
| 40 | <pre> |
---|
| 41 | Pythia pythia; // Declare generator. |
---|
| 42 | Event& event = pythia.event // Convenient shorthand. |
---|
| 43 | pythia.readString("ProcessLevel:all = off"); // The trick! |
---|
| 44 | pythia.init(); // Initialization. |
---|
| 45 | for (int iEvent = 0; iEvent < nEvent; ++iEvent) { |
---|
| 46 | // Insert filling of event here! |
---|
| 47 | pythia.next(); // Do the hadron level. |
---|
| 48 | } |
---|
| 49 | </pre> |
---|
| 50 | Of course this should be supplemented by analysis of events, error checks, |
---|
| 51 | and so on, as for a normal PYTHIA run. The unique aspect is how to fill |
---|
| 52 | the <code>event</code> inside the loop, before <code>pythia.next()</code> |
---|
| 53 | is called. |
---|
| 54 | |
---|
| 55 | <h3>Input configuration</h3> |
---|
| 56 | |
---|
| 57 | To set up a new configuration the first step is to throw away the current |
---|
| 58 | one, with <code>event.reset()</code>. This routine will also reserve |
---|
| 59 | the zeroth entry in the even record to represent the event as a whole. |
---|
| 60 | |
---|
| 61 | <p/> |
---|
| 62 | With the <code>event.append(...)</code> methods a new entry is added at the |
---|
| 63 | bottom of the current record, i.e. the first time it is called entry |
---|
| 64 | number 1 is filled, and so on. The <code>append</code> method basically |
---|
| 65 | exists in four variants, either without or with history information, |
---|
| 66 | and with four-momentum provided either as a <code>Vec4</code> four-vector |
---|
| 67 | or as four individual components: |
---|
| 68 | <pre> |
---|
| 69 | append( id, status, col, acol, p, m) |
---|
| 70 | append( id, status, col, acol, px, py, pz, e, m) |
---|
| 71 | append( id, status, mother1, mother2, daughter1, daughter2, col, acol, p, m) |
---|
| 72 | append( id, status, mother1, mother2, daughter1, daughter2, col, acol, px, py, pz, e, m) |
---|
| 73 | </pre> |
---|
| 74 | The methods return the index at which the entry has been stored, |
---|
| 75 | but normally you would not use this feature. |
---|
| 76 | |
---|
| 77 | <p/> |
---|
| 78 | You can find descriptions of the input variables |
---|
| 79 | <a href="ParticleProperties.html" target="page">here</a>. |
---|
| 80 | The PDG particle code <code>id</code> and the Les Houches Accord colour |
---|
| 81 | <code>col</code> and anticolour <code>acol</code> tags must be set |
---|
| 82 | correctly. The four-momentum and mass have to be provided in units of GeV; |
---|
| 83 | if you omit the mass it defaults to 0. |
---|
| 84 | |
---|
| 85 | <p/> |
---|
| 86 | Outgoing particles that should hadronize should be given status code 23. |
---|
| 87 | Often this is the only status code you need. You could e.g. also fill in |
---|
| 88 | incoming partons with -21 and intermediate ones with -22, if you so wish. |
---|
| 89 | Usually the choice of status codes is not crucial, so long as you recall |
---|
| 90 | that positive numbers correspond to particles that are still around, while |
---|
| 91 | negative numbers denote ones that already hadronized or decayed. However, |
---|
| 92 | so as not to run into contradictions with the internal PYTHIA checks |
---|
| 93 | (when <code>Check:event = on</code>), or with external formats such as |
---|
| 94 | HepMC, we do recommend the above codes. When <code>pythia.next()</code> |
---|
| 95 | is called the positive-status particles that hadronize/decay get the sign |
---|
| 96 | of the status code flipped to negative but the absolute value is retained. |
---|
| 97 | The new particles are added with normal PYTHIA status codes. |
---|
| 98 | |
---|
| 99 | <p/> |
---|
| 100 | For normal hadronization/decays in <code>pythia.next()</code> the |
---|
| 101 | history encoded in the mother and daughter indices is not used. |
---|
| 102 | Therefore the first two <code>append</code> methods, which set all these |
---|
| 103 | indices vanishing, should suffice. The subsequent hadronization/decays |
---|
| 104 | will still be properly documented. |
---|
| 105 | |
---|
| 106 | <p/> |
---|
| 107 | The exception is when you want to include junctions in your string |
---|
| 108 | topology, i.e. have three string pieces meet. Then you must insert in |
---|
| 109 | your event record the (decayed) particle that is the reason for the |
---|
| 110 | presence of a junction, e.g. a baryon beam remnant from which several |
---|
| 111 | valence quarks have been kicked out, or a neutralino that underwent a |
---|
| 112 | baryon-number-violating decay. This particle must have as daughters |
---|
| 113 | the three partons that together carry the baryon number. |
---|
| 114 | |
---|
| 115 | <p/> |
---|
| 116 | The sample program in <code>main21.cc</code> illustrates how you can work |
---|
| 117 | with this facility, both for simple parton configurations and for more |
---|
| 118 | complicated ones with junctions. |
---|
| 119 | |
---|
| 120 | <p/> |
---|
| 121 | As an alternative to setting up a topology with the methods above, |
---|
| 122 | a <a href="LesHouchesAccord.html" target="page">Les Houches Event File</a> (LHEF) |
---|
| 123 | can also provide the configurations. Since no beams or processes are |
---|
| 124 | defined, only the <code><event>....</event></code> blocks |
---|
| 125 | need to be present, one for each event, so strictly it is not a true |
---|
| 126 | LHEF. You need to select <code>Beams:frameType = 4</code>, provide |
---|
| 127 | the file name in <code>Beams:LHEF</code> and, as above, set |
---|
| 128 | <code>ProcessLevel:all = off</code>. Needless to say, an externally |
---|
| 129 | linked <code>LHAup</code> class works as well as an LHEF, |
---|
| 130 | with <code>Beams:frameType = 5</code>. |
---|
| 131 | |
---|
| 132 | <p/> |
---|
| 133 | The event information to store in the LHEF, or provide by the |
---|
| 134 | <code>LHAup</code>, is essentially the same as above. The only |
---|
| 135 | difference is in status codes: outgoing particles should have 1 |
---|
| 136 | instead of 23, and intermediate resonances 2 instead of -22. |
---|
| 137 | Incoming partons, if any, are -1 instead of -21. |
---|
| 138 | |
---|
| 139 | <h3>Extensions to resonance decays</h3> |
---|
| 140 | |
---|
| 141 | With the above scheme, <code>pythia.next()</code> will generate |
---|
| 142 | hadronization, i.e. string fragmentation and subsequent decays of |
---|
| 143 | normal unstable particles. It will not decay |
---|
| 144 | <a href="ResonanceDecays.html" target="page">resonances</a>, i.e. |
---|
| 145 | <i>W, Z</i>, top, Higgs, SUSY and other massive particles. |
---|
| 146 | |
---|
| 147 | <p/> |
---|
| 148 | If the decay products are already provided, of course those |
---|
| 149 | products will be hadronized, but without any of the showers |
---|
| 150 | that one would expect in <i>Z^0 -> q qbar</i>, say. That is, the |
---|
| 151 | presence of a decayed resonance in the event record can be nice |
---|
| 152 | for documentation purposes, but otherwise it plays no role. |
---|
| 153 | It is possible to change this behaviour with the following flag. |
---|
| 154 | |
---|
| 155 | <p/><code>flag </code><strong> Standalone:allowResDec </strong> |
---|
| 156 | (<code>default = <strong>off</strong></code>)<br/> |
---|
| 157 | If off, then resonances are stable if final-state particles, |
---|
| 158 | and irrelevant if intermediate particles. If on, then |
---|
| 159 | resonances are decayed, sequentially if necessary. After each |
---|
| 160 | decay step a parton shower is applied, and subsequent decay |
---|
| 161 | kinematics is shifted by the recoil of such branchings. |
---|
| 162 | If the decay chain and kinematics of the resonance is provided |
---|
| 163 | at input, this information is used, otherwise it is generated |
---|
| 164 | internally according to built-in branching ratios etc. |
---|
| 165 | |
---|
| 166 | |
---|
| 167 | <p/> |
---|
| 168 | The input configuration has to follow the rules described above, |
---|
| 169 | with <code>ProcessLevel:all = off</code>. (Terminology not quite |
---|
| 170 | consistent, since resonance decays normally is part of the |
---|
| 171 | process-level step.) It is possible to combine several resonances, |
---|
| 172 | and other coloured or uncoloured particles into the same event. |
---|
| 173 | |
---|
| 174 | <p/> |
---|
| 175 | Final-state radiation is applied to each step of the decay |
---|
| 176 | sequence by default, but can be switched off with |
---|
| 177 | <code>PartonLevel:FSR = off</code> or |
---|
| 178 | <code>PartonLevel:FSRinResonances</code>. |
---|
| 179 | |
---|
| 180 | <h3>Repeated hadronization or decay</h3> |
---|
| 181 | |
---|
| 182 | An alternative approach is possible with the |
---|
| 183 | <code>pythia.forceHadronLevel()</code> routine. This method does |
---|
| 184 | a call to the <code>HadronLevel</code> methods, irrespective of the |
---|
| 185 | value of the <code>HadronLevel:all</code> flag. If you hadronize |
---|
| 186 | externally generated events it is equivalent to a |
---|
| 187 | <code>pythia.next()</code> call with |
---|
| 188 | <code>ProcessLevel:all = off</code>. |
---|
| 189 | |
---|
| 190 | <p/> |
---|
| 191 | This method truly sticks to the hadron level, and thus cannot handle |
---|
| 192 | resonance decays. You therefore <b>must not</b> mix it with the |
---|
| 193 | <code>Standalone:allowResDec = on</code> framework. |
---|
| 194 | |
---|
| 195 | <p/> |
---|
| 196 | The similarity of names indicates that |
---|
| 197 | <code>pythia.forceTimeShower( int iBeg, int iEnd, double pTmax, |
---|
| 198 | int nBranchMax = 0)</code> is intended to belong to the same set of |
---|
| 199 | work-by-hand methods. Here <code>iBeg</code> and <code>iEnd</code> |
---|
| 200 | give the range of partons that should be allowed to shower, |
---|
| 201 | <code>pTmax</code> the maximum <i>pT</i> scale of emissions, |
---|
| 202 | and a nonzero <code>nBranchMax</code> a maximum number of allowed |
---|
| 203 | branchings. Additionally, a <code>scale</code> has to be set for each |
---|
| 204 | parton that should shower, which requires an additional final argument |
---|
| 205 | to the <code>append</code> methods above. This scale limits the maximum |
---|
| 206 | <i>pT</i> allowed for each parton, in addition to the global |
---|
| 207 | <code>pTmax</code>. When not set the scale defaults to 0, meaning no |
---|
| 208 | radiation for that parton. |
---|
| 209 | |
---|
| 210 | <p/> |
---|
| 211 | The real application instead is for repeated hadronization of the same |
---|
| 212 | PYTHIA process- and parton-level event. This may for some studies |
---|
| 213 | help to save time, given that these two first step are more |
---|
| 214 | time-consuming than the hadronization one. |
---|
| 215 | |
---|
| 216 | <p/> |
---|
| 217 | For repeated hadronization you should first generate an event as usual, |
---|
| 218 | but with <code>HadronLevel:all = off</code>. This event you can save |
---|
| 219 | in a temporary copy, e.g. <code>Event savedEvent = pythia.event</code>. |
---|
| 220 | Inside a loop you copy back with <code>pythia.event = savedEvent</code>, |
---|
| 221 | and call <code>pythia.forceHadronLevel()</code> to obtain a new |
---|
| 222 | hadronization history. |
---|
| 223 | |
---|
| 224 | <p/> |
---|
| 225 | A more limited form of repetition is if you want to decay a given kind |
---|
| 226 | of particle repeatedly, without having to generate the rest of the event |
---|
| 227 | anew. This could be the case e.g. in <i>B</i> physics applications. |
---|
| 228 | Then you can use the <code>pythia.moreDecays()</code> method, which |
---|
| 229 | decays all particles in the event record that have not been decayed |
---|
| 230 | but should have been done so. The |
---|
| 231 | <code>pythia.particleData.mayDecay( id, false/true)</code> method |
---|
| 232 | may be used to switch off/on the decays of a particle species |
---|
| 233 | <code>id</code>, so that it is not decayed in the |
---|
| 234 | <code>pythia.next()</code> call but only inside a loop over a number of |
---|
| 235 | tries. |
---|
| 236 | |
---|
| 237 | <p/> |
---|
| 238 | Between each loop the newly produced decay products must be |
---|
| 239 | removed and the decayed particle status restored to undecayed. |
---|
| 240 | The former is simple, since the new products are appended to the |
---|
| 241 | end of the event record: <code>event.saveSize()</code> saves the |
---|
| 242 | initial size of the event record, and <code>event.restoreSize()</code> |
---|
| 243 | can later be used repeatedly to restore this original size, which means |
---|
| 244 | that the new particles at the end are thrown away. The latter is more |
---|
| 245 | complicated, and requires the user to identify the positions of all |
---|
| 246 | particles of the species and restore a positive status code with |
---|
| 247 | <code>event[i].statusPos()</code>. |
---|
| 248 | |
---|
| 249 | <p/> |
---|
| 250 | The <code>main15.cc</code> program illustrates both these methods, |
---|
| 251 | i.e. either repeated hadronization or repeated decay of PYTHIA |
---|
| 252 | events. |
---|
| 253 | |
---|
| 254 | </body> |
---|
| 255 | </html> |
---|
| 256 | |
---|
| 257 | <!-- Copyright (C) 2012 Torbjorn Sjostrand --> |
---|