]>
Commit | Line | Data |
---|---|---|
5ad4eb21 | 1 | <chapter name="Hadron-Level Standalone"> |
2 | ||
3 | <h2>Hadron-Level Standalone</h2> | |
4 | ||
5 | The Les Houches Accord allows external process-level configurations | |
6 | to be fed in, for subsequent parton-level and hadron-level generation | |
7 | to be handled internally by PYTHIA. There is no correspondingly | |
8 | standardized interface if you have external events that have also | |
9 | been generated through the parton-level stage, so that only the | |
10 | hadron-level remains to be handled. A non-standard way to achieve this | |
11 | exists, however, and can be useful both for real applications and | |
12 | for various tests of the hadronization model on its own. | |
13 | ||
14 | <p/> | |
15 | The key trick is to set the flag <code>ProcessLevel:all = off</code>. | |
16 | When <code>pythia.next()</code> is called it then does not try to | |
17 | generate a hard process, and therefore also cannot do anything on the | |
18 | parton level. Instead only the <code>HadronLevel</code> methods are | |
19 | called, to take the current content of the event record stored in | |
20 | <code>pythia.event</code> as a starting point for any hadronization | |
21 | and decays that are allowed by the normal parameters of this step. | |
22 | Often the input would consist solely of partons grouped into colour | |
23 | singlets, but also (colour-singlet) particles are allowed. | |
24 | ||
25 | <p/> | |
26 | To set up all the parameters, a <code>pythia.init()</code> call has | |
27 | to be used, without any arguments. In brief, the structure of the | |
28 | main program therefore should be something like | |
29 | <pre> | |
30 | Pythia pythia; // Declare generator. | |
31 | Event& event = pythia.event // Convenient shorthand. | |
32 | pythia.readString("ProcessLevel:all = off"); // The trick! | |
33 | pythia.init(); // Initialization. | |
34 | for (int iEvent = 0; iEvent < nEvent; ++iEvent) { | |
35 | // Insert filling of event here! | |
36 | pythia.next(); // Do the hadron level. | |
37 | } | |
38 | </pre> | |
39 | Of course this should be supplemented by analysis of events, error checks, | |
40 | and so on, as for a normal PYTHIA run. The unique aspect is how to fill | |
41 | the <code>event</code> inside the loop, before <code>pythia.next()</code> | |
42 | is called. | |
43 | ||
44 | <h3>Input configuration</h3> | |
45 | ||
46 | To set up a new configuration the first step is to throw away the current | |
47 | one, with <code>event.reset()</code>. This routine will also reserve | |
48 | the zeroth entry in the even record to represent the event as a whole. | |
49 | ||
50 | <p/> | |
51 | With the <code>event.append(...)</code> methods a new entry is added at the | |
52 | bottom of the current record, i.e. the first time it is called entry | |
53 | number 1 is filled, and so on. The <code>append</code> method basically | |
54 | exists in four variants, either without or with history information, | |
55 | and with four-momentum provided either as a <code>Vec4</code> four-vector | |
56 | or as four individual components: | |
57 | <pre> | |
58 | append( id, status, col, acol, p, m) | |
59 | append( id, status, col, acol, px, py, pz, e, m) | |
60 | append( id, status, mother1, mother2, daughter1, daughter2, col, acol, p, m) | |
61 | append( id, status, mother1, mother2, daughter1, daughter2, col, acol, px, py, pz, e, m) | |
62 | </pre> | |
63 | The methods return the index at which the entry has been stored, | |
64 | but normally you would not use this feature. | |
65 | ||
66 | <p/> | |
67 | You can find descriptions of the input variables | |
68 | <aloc href="ParticleProperties">here</aloc>. | |
69 | The PDG particle code <code>id</code> and the Les Houches Accord colour | |
70 | <code>col</code> and anticolour <code>acol</code> tags must be set | |
71 | correctly. The four-momentum and mass have to be provided in units of GeV; | |
72 | if you omit the mass it defaults to 0. | |
73 | ||
74 | <p/> | |
75 | The status code can normally be simplified, however; you only need to recall | |
76 | that positive numbers correspond to particles that are still around, while | |
77 | negative numbers denote ones that already hadronized or decayed, so usually | |
78 | <ei>+-1</ei> is good enough. When <code>pythia.next()</code> is called | |
79 | those positive-status particles that hadronize/decay get the sign of the | |
80 | status code flipped to negative but the absolute value is retained. The | |
81 | new particles are added with normal PYTHIA status codes. | |
82 | ||
83 | <p/> | |
84 | For normal hadronization/decays in <code>pythia.next()</code> the | |
85 | history encoded in the mother and daughter indices is not used. | |
86 | Therefore the first two <code>append</code> methods, which set all these | |
87 | indices vanishing, should suffice. The subsequent hadronization/decays | |
88 | will still be properly documented. | |
89 | ||
90 | <p/> | |
91 | The exception is when you want to include junctions in your string | |
92 | topology, i.e. have three string pieces meet. Then you must insert in | |
93 | your event record the (decayed) particle that is the reason for the | |
94 | presence of a junction, e.g. a baryon beam remnant from which several | |
95 | valence quarks have been kicked out, or a neutralino that underwent a | |
96 | baryon-number-violating decay. This particle must have as daughters | |
97 | the three partons that together carry the baryon number. | |
98 | ||
99 | <p/> | |
100 | The sample program in <code>main21.cc</code> illustrates how you can work | |
101 | with this facility, both for simple parton configurations and for more | |
102 | complicated ones with junctions. | |
103 | ||
104 | <h3>Repeated hadronization or decay</h3> | |
105 | ||
106 | An alternative approach is possible with the | |
107 | <code>pythia.forceHadronLevel()</code> routine. This method does | |
108 | a call to the <code>HadronLevel</code> methods, irrespective of the | |
109 | value of the <code>HadronLevel:all</code> flag. If you hadronize | |
110 | externally generated events it is equivalent to a | |
111 | <code>pythia.next()</code> call with | |
112 | <code>ProcessLevel:all = off</code>. | |
113 | ||
114 | <p/> | |
115 | The real application instead is for repeated hadronization of the same | |
116 | PYTHIA process- and parton-level event. This may for some studies | |
117 | help to save time, given that these two first step are more | |
118 | time-consuming than the hadronization one. | |
119 | ||
120 | <p/> | |
121 | For repeated hadronization you should first generate an event as usual, | |
122 | but with <code>HadronLevel:all = off</code>. This event you can save | |
123 | in a temporary copy, e.g. <code>Event savedEvent = pythia.event</code>. | |
124 | Inside a loop you copy back with <code>pythia.event = savedEvent</code>, | |
125 | and call <code>pythia.forceHadronLevel()</code> to obtain a new | |
126 | hadronization history. | |
127 | ||
128 | <p/> | |
129 | A more limited form of repetition is if you want to decay a given kind | |
130 | of particle repeatedly, without having to generate the rest of the event | |
131 | anew. This could be the case e.g. in <ei>B</ei> physics applications. | |
132 | Then you can use the <code>pythia.moreDecays()</code> method, which | |
133 | decays all particles in the event record that have not been decayed | |
134 | but should have been done so. The | |
135 | <code>ParticleDataTable::mayDecay( id, false/true)</code> method | |
136 | may be used to switch off/on the decays of a particle species | |
137 | <code>id</code>, so that it is not decayed in the | |
138 | <code>pythia.next()</code> call but only inside a loop over a number of | |
139 | tries. | |
140 | ||
141 | <p/> | |
142 | Between each loop the newly produced decay products must be | |
143 | removed and the decayed particle status restored to undecayed. | |
144 | The former is simple, since the new products are appended to the | |
145 | end of the event record: <code>event.saveSize()</code> saves the | |
146 | initial size of the event record, and <code>event.restoreSize()</code> | |
147 | can later be used repeatedly to restore this original size, which means | |
148 | that the new particles at the end are thrown away. The latter is more | |
149 | complicated, and requires the user to identify the positions of all | |
150 | particles of the species and restore a positive status code with | |
151 | <code>event[i].statusPos()</code>. | |
152 | ||
153 | <p/> | |
154 | The <code>main15.cc</code> program illustrates both these methods, | |
155 | i.e. either repeated hadronization or repeated decay of PYTHIA | |
156 | events. | |
157 | ||
158 | </chapter> | |
159 | ||
160 | <!-- Copyright (C) 2008 Torbjorn Sjostrand --> |