1 | <chapter name="Implement New Showers"> |
---|
2 | |
---|
3 | <h2>Implement New Showers</h2> |
---|
4 | |
---|
5 | In case you want to replace the PYTHIA initial- and final-state |
---|
6 | showers by your own, it is possible but not trivial. The point is |
---|
7 | that multiparton interactions (MPI), initial-state radiation (ISR) and |
---|
8 | final-state radiation (FSR) in general appear in one single |
---|
9 | interleaved sequence of decreasing <ei>pT</ei> values. Therefore |
---|
10 | shower replacements would have to be able to play the game by such |
---|
11 | rules, as we will outline further below. Of course, this still |
---|
12 | leaves the field open exactly how to define what to mean by |
---|
13 | <ei>pT</ei>, how to handle recoil effects, how the colour flow is |
---|
14 | affected, and so on, so there is certainly room for alternative |
---|
15 | showers. A first example of a shower implemented within the PYTHIA |
---|
16 | context is <a href="http://home.fnal.gov/~skands/vincia/">VINCIA</a>, |
---|
17 | which however so far only handles FSR. |
---|
18 | |
---|
19 | <p/> |
---|
20 | For the moment we assume you want to keep the MPI part of the story |
---|
21 | unchanged, and make use of the existing beam-remnants (BR) machinery. |
---|
22 | If you want to replace both MPI, ISR, FSR and BR then you had better |
---|
23 | replace the whole <code>PartonLevel</code> module of the code. |
---|
24 | If, in addition, you want to produce your own hard processes, |
---|
25 | then you only need the |
---|
26 | <aloc href="HadronLevelStandalone">hadron-level standalone</aloc> |
---|
27 | part of the machinery. |
---|
28 | |
---|
29 | <p/> |
---|
30 | In order to write replacement codes for ISR and/or FSR it is useful |
---|
31 | to be aware of which information has to be shared between the |
---|
32 | different components, and which input/output structure is required |
---|
33 | of the relevant methods. For details, nothing beats studying the |
---|
34 | existing code. However, here we provide an overview, that should |
---|
35 | serve as a useful introduction. |
---|
36 | |
---|
37 | <p/> |
---|
38 | It should be noted that we here primarily address the problem in |
---|
39 | its full generality, with interleaved MPI, ISR and FSR. There exists |
---|
40 | an option <code>TimeShower:interleave = off</code> where only |
---|
41 | MPI and ISR would be interleaved and FSR be considered after these |
---|
42 | two, but still before BR. Most of the aspects described here would |
---|
43 | apply also for that case. By contrast, resonance decays are only |
---|
44 | considered after all the four above components, and timelike |
---|
45 | showers in those decays would never be interleaved with anything |
---|
46 | else, so are much simpler to administrate. |
---|
47 | |
---|
48 | <p/> |
---|
49 | Therefore the <code><aloc href="ProgramFlow"> |
---|
50 | pythia.setShowerPtr( timesDecPtr, timesPtr, spacePtr)</aloc></code> |
---|
51 | method allows two separate pointers to be set to instances of |
---|
52 | derived <code>TimeShower</code> classes. The first is only required |
---|
53 | to handle decays, say of <ei>Z^0</ei> or <ei>Upsilon</ei>, with no |
---|
54 | dependence on beam remnants or ISR. The second, as well as |
---|
55 | <code>spacePtr</code>, has to handle the interleaved evolution of MPI, |
---|
56 | ISR and FSR. Therefore you are free to implement only the first, and |
---|
57 | let the PYTHIA default showers take care of the latter two. But, if |
---|
58 | you wanted to, you could also set <code>timesDecPtr = 0</code> and |
---|
59 | only provide a <code>timesPtr</code>, or only a <code>spacePtr</code>. |
---|
60 | If your timelike shower does both cases, the first two pointers |
---|
61 | can agree. The only tiny point to take into account then is that |
---|
62 | <code>init( beamAPtr, beamBPtr)</code> is called twice, a first time |
---|
63 | to <code>timesDecPtr</code> with beam pointers 0, and a second time |
---|
64 | to <code>timesPtr</code> with nonvanishing beam pointers. |
---|
65 | |
---|
66 | <h3>The event record and associated information</h3> |
---|
67 | |
---|
68 | Obviously the main place for sharing information is the event |
---|
69 | record, specifically the <code>Event event</code> member of |
---|
70 | <code>Pythia</code>, passed around as a reference. It is |
---|
71 | assumed you already studied how it works, so here we only draw |
---|
72 | attention to a few aspects of special relevance. |
---|
73 | |
---|
74 | <p/> |
---|
75 | One basic principle is that existing partons should not be |
---|
76 | overwritten. Instead new partons should be created, even when a |
---|
77 | parton only receives a slightly shifted momentum and for the rest |
---|
78 | stays the same. Such "carbon copies" by final-state branchings |
---|
79 | should be denoted by both daughter indices of the original parton |
---|
80 | pointing to the copy, and both mother indices of the copy to the |
---|
81 | original. If the copy instead is intended to represent an earlier |
---|
82 | step, e.g. in ISR backwards evolution, the role of mothers and |
---|
83 | daughters is interchanged. The |
---|
84 | <code>event.copy( iCopy, newStatus)</code> |
---|
85 | routine can take care of this tedious task; the sign of |
---|
86 | <code>newStatus</code> tells the program which case to assume. |
---|
87 | |
---|
88 | <p/> |
---|
89 | To make the event record legible it is essential that the |
---|
90 | <aloc href="ParticleProperties">status codes</aloc> |
---|
91 | are selected appropriately to represent the reason why each new |
---|
92 | parton is added to the record. Also remember to change the |
---|
93 | status of a parton to be negative whenever an existing parton |
---|
94 | is replaced by a set of new daughter partons. |
---|
95 | |
---|
96 | <p/> |
---|
97 | Another important parton property is <code>scale()</code>, |
---|
98 | which does not appear in the normal event listing, but only |
---|
99 | if you use the extended |
---|
100 | <code>Event:listScaleAndVertex = on</code> option. |
---|
101 | This property is supposed to represent the production scale |
---|
102 | (in GeV) of a parton. In the current FSR and ISR algorithms |
---|
103 | it is used to restrict from above the allowed <ei>pT</ei> |
---|
104 | values for branchings of this particular parton. |
---|
105 | Beam remnants and other partons that should not radiate are |
---|
106 | assigned scale 0. |
---|
107 | |
---|
108 | <p/> |
---|
109 | Auxiliary to the event record proper is the |
---|
110 | <code><aloc href="AdvancedUsage">PartonSystems</aloc></code> |
---|
111 | class, that keep track of which partons belong together in the |
---|
112 | same scattering subsystem. This information must be kept up-to-date |
---|
113 | during the shower evolution. |
---|
114 | |
---|
115 | <p/> |
---|
116 | For initial-state showers it is also necessary to keep track of |
---|
117 | the partonic content extracted from the beams. This information |
---|
118 | is stored in the |
---|
119 | <code><aloc href="AdvancedUsage">BeamParticle</aloc></code> |
---|
120 | class. |
---|
121 | |
---|
122 | <h3>The TimeShower interface</h3> |
---|
123 | |
---|
124 | If you want to replace the <code>TimeShower</code> class this would |
---|
125 | involve replacing the virtual methods among the following ones. |
---|
126 | |
---|
127 | <method name="TimeShower::TimeShower()"> |
---|
128 | The constructor does not need to do anything. |
---|
129 | </method> |
---|
130 | |
---|
131 | <method name="virtual TimeShower::~TimeShower()"> |
---|
132 | The destructor does not need to do anything. |
---|
133 | </method> |
---|
134 | |
---|
135 | <method name="void TimeShower::initPtr(Info* infoPtr, Settings* settingsPtr, |
---|
136 | ParticleData* particleDataPtr, Rndm* rndmPtr, CoupSM* coupSMPtr, |
---|
137 | PartonSystems* partonSystemsPtr, UserHooks* userHooksPtr)"> |
---|
138 | This method only imports pointers to standard facilities, |
---|
139 | and is not virtual. |
---|
140 | </method> |
---|
141 | |
---|
142 | <method name="virtual void TimeShower::init( BeamParticle* beamAPtrIn = 0, |
---|
143 | BeamParticle* beamBPtrIn = 0)"> |
---|
144 | You have to store your local copy of the pointers to these objects, |
---|
145 | since they have to be used during the generation, as explained above. |
---|
146 | The pointers could be zero; e.g. a local copy of <code>TimeShower</code> |
---|
147 | is created to handle showers in decays such as <ei>Upsilon -> q qbar</ei> |
---|
148 | from inside the <code>ParticleDecays class</code>. This is also the |
---|
149 | place to do initialization of whatever parameters you plan to use, |
---|
150 | e.g. by reading in them from a user-accessible database like the |
---|
151 | <code>Settings</code> one. |
---|
152 | </method> |
---|
153 | |
---|
154 | <method name="virtual bool TimeShower::limitPTmax( Event& event, |
---|
155 | double Q2Fac = 0., double Q2Ren = 0.)"> |
---|
156 | The question is whether the FSR should be allowed to occur at larger |
---|
157 | scales than the hard process it surrounds. This is process-dependent, |
---|
158 | as illustrated below for the the analogous |
---|
159 | <code>SpaeShower::limitPTmax(...)</code> method, although the two |
---|
160 | kinds of radiation need not have to be modelled identically. |
---|
161 | The <code>TimeShower:pTmaxMatch</code> switch allows you to force the |
---|
162 | behaviour among three options, but you may replace by your own logic. |
---|
163 | <br/>The internal PYTHIA implementation also allows intermediate options, |
---|
164 | where emissions can go up to the kinematical limit but be dampened above |
---|
165 | the factorization or renormalization scale. Therefore the (square of the) |
---|
166 | latter two are provided as optional input parameters. |
---|
167 | </method> |
---|
168 | |
---|
169 | <method name="double TimeShower::enhancePTmax()"> |
---|
170 | Relative to the default <ei>pT_max</ei> evolution scale of the process, |
---|
171 | it may still be convenient to vary the matching slightly for the hardest |
---|
172 | interaction in an event, to probe the sensitivity to such details. The |
---|
173 | base-class implementation returns the value of the |
---|
174 | <code>TimeShower:pTmaxFudge</code> parameter. |
---|
175 | </method> |
---|
176 | |
---|
177 | <method name="virtual int TimeShower::shower( int iBeg, int iEnd, |
---|
178 | Event& event, double pTmax, int nBranchMax = 0)"> |
---|
179 | This is an all-in-one call for shower evolution, and as such cannot be |
---|
180 | used for the normal interleaved evolution, where only the routines below |
---|
181 | are used. It also cannot be used in resonance decays that form part of |
---|
182 | the hard process, since there the |
---|
183 | <aloc href="UserHooks">user hooks</aloc> insert a potential |
---|
184 | veto step. Currently this routine is therefore only used in the |
---|
185 | hadron-level decays, e.g. <ei>Upsilon -> g g g</ei>. |
---|
186 | <br/><code>iBeg</code> and <code>iEnd</code> is the position of the |
---|
187 | first and last parton of a separate system, typically produced by a |
---|
188 | resonance decay. Such a system only evolves in isolation, and in |
---|
189 | particular does not relate to the beams. |
---|
190 | <br/>The <code>pTmax</code> value sets the maximum scale for evolution, |
---|
191 | but normally you would restrict that further for each individual |
---|
192 | parton based on its respective scale value. |
---|
193 | <br/>The <code>nBranchMax</code> value, if positive, gives the maximum |
---|
194 | number of allowed branchings in the call, as useful for matching studies. |
---|
195 | <br/>The routine is expected to return the number of FSR branchings that |
---|
196 | were generated, but only for non-critical statistics purposes. |
---|
197 | <br/>Since the real action typically is delegated to the routines |
---|
198 | below, it may well be that the existing code need not be replaced. |
---|
199 | </method> |
---|
200 | |
---|
201 | <method name="double TimeShower::pTLastInShower()"> |
---|
202 | Can be used to return the <ei>pT</ei> evolution scale of the last |
---|
203 | branching in the cascade generated with the above |
---|
204 | <code>shower(...)</code> method. Is to be set in the internal |
---|
205 | <code>pTLastInShower</code> variable, and should be 0 if there |
---|
206 | were no branchings. Can be useful for matching studies. |
---|
207 | </method> |
---|
208 | |
---|
209 | <method name="virtual void TimeShower::prepare( int iSys, Event& event)"> |
---|
210 | This method is called immediately after a new interaction (or the |
---|
211 | products of a resonance decay) has been added, and should then be used |
---|
212 | to prepare the subsystem of partons for subsequent evolution. In |
---|
213 | the current code this involves identifying all colour and charge |
---|
214 | dipole ends: the position of radiating and recoiling partons, maximum |
---|
215 | <ei>pT</ei> scales, possible higher-order matrix elements matchings |
---|
216 | to apply, and so on. |
---|
217 | <br/>The <code>iSys</code> parameter specifies which parton system |
---|
218 | is to be prepared. It is used to extract the set of partons to be |
---|
219 | treated, with rules as described in the above section on subsystems. |
---|
220 | Specifically, the first two partons represent the incoming state, |
---|
221 | or are 0 for resonance decays unrelated to the beams, while the |
---|
222 | rest are not required to be in any particular order. |
---|
223 | </method> |
---|
224 | |
---|
225 | <method name="virtual void TimeShower::rescatterUpdate( int iSys, |
---|
226 | Event& event)"> |
---|
227 | This method is called immediately after rescattering in the description |
---|
228 | of multiparton interactions. Thus the information on one or several |
---|
229 | systems is out-of-date, while that of the others is unchanged. |
---|
230 | We do not provide the details here, since we presume few implementors |
---|
231 | of new showers will want to touch the technicalities involved |
---|
232 | in obtaining a description of rescattering. |
---|
233 | </method> |
---|
234 | |
---|
235 | <method name="virtual void TimeShower::update( int iSys, Event& event)"> |
---|
236 | This method is called immediately after a spacelike branching in the |
---|
237 | <code>iSys</code>'th subsystem. Thus the information for that system is |
---|
238 | out-of-date, while that of the others is unchanged. If you want, you are |
---|
239 | free to throw away all information for the affected subsystem and call |
---|
240 | <code>prepare( iSys, event)</code> to create new one. Alternatively |
---|
241 | you may choose only to update the information that has changed. |
---|
242 | </method> |
---|
243 | |
---|
244 | <method name="virtual double TimeShower::pTnext( Event& event, |
---|
245 | double pTbegAll, double pTendAll)"> |
---|
246 | This is the main driver routine for the downwards evolution. A new |
---|
247 | <ei>pT</ei> is to be selected based on the current information set up |
---|
248 | by the routines above, and along with that a branching parton or dipole. |
---|
249 | The <code>pTbegAll</code> scale is the maximum scale allowed, from which |
---|
250 | the downwards evolution should be begun (usually respecting the maximum |
---|
251 | scale of each individual parton). If no emission is found above |
---|
252 | <code>pTendAll</code> (and above the respective shower cutoff scales) |
---|
253 | then <code>0.</code> should be returned and no emissions will be allowed. |
---|
254 | Both scales can vary from one event to the next: if a scale has |
---|
255 | already been selected for MPI or ISR it makes no sense to look for |
---|
256 | a scale smaller than that from FSR, since it would not be able to |
---|
257 | compete, so <code>pTendAll</code> is set correspondingly. As it happens, |
---|
258 | FSR is tried before ISR and MPI in the interleaved evolution, |
---|
259 | but this is an implementational detail that could well change. |
---|
260 | <br/>Typically the implementation of this routine would be to set |
---|
261 | up a loop over all possible radiating objects (dipoles, dipole ends, ...), |
---|
262 | for each pick its possible branching scale and then pick the one |
---|
263 | with largest scale as possible winner. At this stage no branching should |
---|
264 | actually be carried out, since MPI, ISR and FSR still have to be compared |
---|
265 | to assign the winner. |
---|
266 | </method> |
---|
267 | |
---|
268 | <method name="virtual bool TimeShower::branch( Event& event, |
---|
269 | bool isInterleaved = false)"> |
---|
270 | This method will be called once FSR has won the competition with |
---|
271 | MPI and ISR to do the next branching. The candidate branching found |
---|
272 | in the previous step should here be carried out in full. The |
---|
273 | pre-branching partons should get a negative status code and new |
---|
274 | replacement ones added to the end of the event record. Also the |
---|
275 | subsystem information should be updated, and possibly also the |
---|
276 | beams. |
---|
277 | <br/>Should some problem be encountered in this procedure, e.g. if |
---|
278 | some not-previously-considered kinematics requirement fails, it is |
---|
279 | allowed to return <code>false</code> to indicate that no branching |
---|
280 | could be carried out. |
---|
281 | <br/>Normally the optional <code>isInterleaved</code> argument would |
---|
282 | not be of interest. It can be used to separate resonance decays, false, |
---|
283 | from the interleaved evolution together with MPI and ISR, true. |
---|
284 | More precisely, it separates calls to the <code>timesDecPtr</code> |
---|
285 | and the <code>timesPtr</code> instances. |
---|
286 | </method> |
---|
287 | |
---|
288 | <method name="virtual bool TimeShower::rescatterPropogateRecoil( |
---|
289 | Event& event, Vec4& pNew)"> |
---|
290 | This method is only called if rescattering is switched on in the |
---|
291 | description of multiparton interactions. It then propagates a recoil |
---|
292 | from a timelike branching to internal lines that connect systems. |
---|
293 | As for <code>rescatterUpdate</code> above, this is not likely to be |
---|
294 | of interest to most implementors of new showers. |
---|
295 | </method> |
---|
296 | |
---|
297 | <method name="int TimeShower::system()"> |
---|
298 | This method is not virtual. If a branching is constructed by the |
---|
299 | previous routine this tiny method should be able to return the number |
---|
300 | of the selected subsystem <code>iSysSel</code> where it occured, |
---|
301 | so that the spacelike shower can be told which system to update, |
---|
302 | if necessary. Therefore <code>iSysSel</code> must be set in |
---|
303 | <code>branch</code> (or already in <code>pTnext</code>). |
---|
304 | </method> |
---|
305 | |
---|
306 | <method name="virtual void TimeShower::list( ostream& os = cout)"> |
---|
307 | This method is not at all required. In the current implementation it |
---|
308 | outputs a list of all the dipole ends, with information on the |
---|
309 | respective dipole. The routine is not called anywhere in the public |
---|
310 | code, but has been inserted at various places during the |
---|
311 | development/debug phase. |
---|
312 | </method> |
---|
313 | |
---|
314 | <h3>The SpaceShower interface</h3> |
---|
315 | |
---|
316 | If you want to replace the <code>SpaceShower</code> class this would |
---|
317 | involve replacing the virtual methods in the following. You will find |
---|
318 | that much of the story reminds of <code>TimeShower</code> above, and |
---|
319 | actually some cut-and-paste of text is involved. In some respects the |
---|
320 | description is simpler, since there are no special cases for resonance |
---|
321 | decays and non-interleaved evolution. Thus there is no correspondence |
---|
322 | to the <code>TimeShower::shower(...)</code> routine. |
---|
323 | |
---|
324 | <method name="SpaceShower::SpaceShower()"> |
---|
325 | The constructor does not need to do anything. |
---|
326 | </method> |
---|
327 | |
---|
328 | <method name="virtual SpaceShower::~SpaceShower()"> |
---|
329 | Also the destructor does not need to do anything. |
---|
330 | </method> |
---|
331 | |
---|
332 | <method name="void SpaceShower::initPtr(Info* infoPtr, |
---|
333 | Settings* settingsPtr, ParticleData* particleDataPtr, Rndm* rndmPtr, |
---|
334 | PartonSystems* partonSystemsPtr, UserHooks* userHooksPtr)"> |
---|
335 | This method only imports pointers to standard facilities, |
---|
336 | and is not virtual. |
---|
337 | </method> |
---|
338 | |
---|
339 | <method name="virtual void SpaceShower::init( BeamParticle* beamAPtrIn, |
---|
340 | BeamParticle* beamBPtrIn)"> |
---|
341 | You have to store your local copy of the pointers to these objects, |
---|
342 | since they have to be used during the generation, as explained above. |
---|
343 | This is also the place to do initialization of whatever parameters |
---|
344 | you plan to use, e.g. by reading in them from a user-accessible |
---|
345 | database like the <code>Settings</code> one. |
---|
346 | </method> |
---|
347 | |
---|
348 | <method name="virtual bool SpaceShower::limitPTmax( Event& event, |
---|
349 | double Q2Fac = 0., double Q2Ren = 0.)"> |
---|
350 | The question is whether the ISR should be allowed to occur at larger |
---|
351 | scales than the hard process it surrounds. This is process-dependent. |
---|
352 | For instance, if the hard process is <ei>Z^0</ei> production we know |
---|
353 | that ISR should be allowed to go right up to the kinematical limit. |
---|
354 | If it is a <ei>2 -> 2</ei> QCD process the ISR should not exceed |
---|
355 | the scale of the hard process, since if so one would doublecount. |
---|
356 | The <code>SpaceShower:pTmaxMatch</code> switch allows you to force the |
---|
357 | behaviour, or else to program your own logic. The current default |
---|
358 | implementation limits <ei>pT</ei> whenever the final state contains |
---|
359 | a quark (except top), gluon or photon, since then the danger of |
---|
360 | doublecounting is there. You may replace by your own logic, or leave as is. |
---|
361 | <br/>The internal PYTHIA implementation also allows intermediate options, |
---|
362 | where emissions can go up to the kinematical limit but be dampened above |
---|
363 | the factorization or renormalization scale. Therefore the (square of the) |
---|
364 | latter two are provided as optional input parameters. |
---|
365 | </method> |
---|
366 | |
---|
367 | <method name="virtual double SpaceShower::enhancePTmax()"> |
---|
368 | When the above method limits <ei>pT_max</ei> to the scale of the process, |
---|
369 | it may still be convenient to vary the matching slightly for the hardest |
---|
370 | interaction in an event, to probe the sensitivity to such details. The |
---|
371 | base-class implementation returns the value of the |
---|
372 | <code>SpaceShower:pTmaxFudge</code> parameter. |
---|
373 | </method> |
---|
374 | |
---|
375 | <method name="virtual void SpaceShower::prepare( int iSys, Event& event, |
---|
376 | bool limitPTmax = true)"> |
---|
377 | This method is called immediately after a new interaction has been |
---|
378 | added, and should then be used to prepare the subsystem of partons |
---|
379 | for subsequent evolution. In the current code this involves identifying |
---|
380 | the colour and charge dipole ends: the position of radiating and recoiling |
---|
381 | partons, maximum <ei>pT</ei> scales, and possible higher-order matrix |
---|
382 | elements matchings to apply. Depending on what you have in mind you may |
---|
383 | choose to store slightly different quantities. You have to use the |
---|
384 | subsystem information described above to find the positions of the two |
---|
385 | incoming partons (and the outgoing ones) of the system, and from there |
---|
386 | the scales at which they were produced. |
---|
387 | <br/> The <code>limitPTmax</code> input agrees with the output of the |
---|
388 | previous method for the hardest process, and is always true for |
---|
389 | subsequent MPI, since there an unlimited <ei>pT</ei> for sure |
---|
390 | would lead to doublecounting. |
---|
391 | </method> |
---|
392 | |
---|
393 | <method name="virtual void SpaceShower::update( int iSys, Event& event)"> |
---|
394 | This method is called immediately after a timelike branching in the |
---|
395 | <code>iSys</code>'th subsystem. Thus the information for that system may |
---|
396 | be out-of-date, and to be updated. For the standard PYTHIA showers |
---|
397 | this routine does not need to do anything, but that may be different |
---|
398 | in another implementation. |
---|
399 | </method> |
---|
400 | |
---|
401 | <method name="virtual double SpaceShower::pTnext( Event& event, |
---|
402 | double pTbegAll, double pTendAll, int nRadIn = -1)"> |
---|
403 | This is the main driver routine for the downwards evolution. A new |
---|
404 | <ei>pT</ei> is to be selected based on the current information set up |
---|
405 | by the routines above, and along with that a branching parton or dipole. |
---|
406 | The <code>pTbegAll</code> scale is the maximum scale allowed, from which |
---|
407 | the downwards evolution should be begun (usually respecting the maximum |
---|
408 | scale of each individual parton). If no emission is found above |
---|
409 | <code>pTendAll</code> (and above the respective shower cutoff scales) |
---|
410 | then <code>0.</code> should be returned and no emissions will be allowed. |
---|
411 | Both scales can vary from one event to the next: if a scale has |
---|
412 | already been selected for MPI or ISR it makes no sense to look for |
---|
413 | a scale smaller than that from FSR, since it would not be able to |
---|
414 | compete, so <code>pTendAll</code> is set correspondingly. As it happens, |
---|
415 | FSR is tried before ISR and MPI in the interleaved evolution, |
---|
416 | but this is an implementational detail that could well change. |
---|
417 | <br/>Typically the implementation of this routine would be to set |
---|
418 | up a loop over all possible radiating objects (dipoles, dipole ends, ...), |
---|
419 | for each pick its possible branching scale and then pick the one |
---|
420 | with largest scale as possible winner. At this stage no branching should |
---|
421 | actually be carried out, since MPI, ISR and FSR still have to be compared |
---|
422 | to assign the winner. |
---|
423 | <br/>The final input <code>nRadIn</code> provides the total number of |
---|
424 | ISR and FSR emissions already generated in the event, and so allows a |
---|
425 | special treatment for the very first emission, if desired. |
---|
426 | </method> |
---|
427 | |
---|
428 | <method name="virtual bool SpaceShower::branch( Event& event)"> |
---|
429 | This method will be called once FSR has won the competition with |
---|
430 | MPI and ISR to do the next branching. The candidate branching found |
---|
431 | in the previous step should here be carried out in full. The |
---|
432 | pre-branching partons should get a negative status code and new |
---|
433 | replacement ones added to the end of the event record. Also the |
---|
434 | subsystem information should be updated, and possibly also the |
---|
435 | beams. |
---|
436 | <br/>Should some problem be encountered in this procedure, e.g. if |
---|
437 | some not-previously-considered kinematics requirement fails, it is |
---|
438 | allowed to return <code>false</code> to indicate that no branching |
---|
439 | could be carried out. Also a complete restart of the parton-level |
---|
440 | description may be necessary, see <code>doRestart()</code> below. |
---|
441 | </method> |
---|
442 | |
---|
443 | <method name="int SpaceShower::system()"> |
---|
444 | This method is not virtual. If a branching is constructed by the |
---|
445 | previous routine this tiny method should be able to return the number |
---|
446 | of the selected subsystem <code>iSysSel</code> where it occured, |
---|
447 | so that the spacelike shower can be told which system to update, |
---|
448 | if necessary. Therefore <code>iSysSel</code> must be set in |
---|
449 | <code>branch</code> (or already in <code>pTnext</code>). |
---|
450 | </method> |
---|
451 | |
---|
452 | <method name="bool SpaceShower::doRestart()"> |
---|
453 | This method is not virtual. If <code>branch(...)</code> above fails |
---|
454 | to construct a branching, and the conditions are such that the whole |
---|
455 | parton-level description should be restarted, then it should return |
---|
456 | true, else not. Currently only the rescattering description can give |
---|
457 | thi kind of failures, and so the internal <code>rescatterFail</code> |
---|
458 | boolean must be set true when this should happen, and else false. |
---|
459 | </method> |
---|
460 | |
---|
461 | <method name="virtual void SpaceShower::list( ostream& os = cout)"> |
---|
462 | This method is not at all required. In the current implementation it |
---|
463 | outputs a list of all the dipole ends, with information on the |
---|
464 | respective dipole. The routine is not called anywhere in the public |
---|
465 | code, but has been inserted at various places during the |
---|
466 | development/debug phase. |
---|
467 | </method> |
---|
468 | |
---|
469 | </chapter> |
---|
470 | |
---|
471 | <!-- Copyright (C) 2012 Torbjorn Sjostrand --> |
---|