| 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 --> |
|---|
![(please configure the [header_logo] section in trac.ini)](/HiSusy/chrome/site/your_project_logo.png){kind=logo}
