1 | <!-- ******************************************************** --> |
---|
2 | <!-- Docbook Version: For Toolkit Developers Guide --> |
---|
3 | <!-- ******************************************************** --> |
---|
4 | |
---|
5 | <!-- ******************** Top of Section ******************** --> |
---|
6 | <sect1 id="sect.DsgnFuncTracking"> |
---|
7 | <title> |
---|
8 | Tracking |
---|
9 | </title> |
---|
10 | |
---|
11 | <para> |
---|
12 | The tracking category manages the contribution of the processes to the |
---|
13 | evolution of a track's state and provides information in sensitive volumes |
---|
14 | for hits and digitization. |
---|
15 | </para> |
---|
16 | |
---|
17 | <!-- ******************* Section (Level#2) ****************** --> |
---|
18 | <sect2 id="sect.DsgnFuncTracking.DsgPhlsp"> |
---|
19 | <title> |
---|
20 | Design Philosophy |
---|
21 | </title> |
---|
22 | |
---|
23 | <para> |
---|
24 | It is well known that the overall performance of a detector |
---|
25 | simulation depends critically on the CPU time spent |
---|
26 | propagating the particle through one step. The most |
---|
27 | important consideration in the object design of the tracking |
---|
28 | category is maintaining high execution speed in the Geant4 |
---|
29 | simulation while utilizing the power of the object-oriented |
---|
30 | approach. |
---|
31 | </para> |
---|
32 | |
---|
33 | <para> |
---|
34 | An extreme approach to the particle tracking design would be |
---|
35 | to integrate all functionalities required for the propagation |
---|
36 | of a particle into a single class. This design approach looks |
---|
37 | object-oriented because a particle in the real world |
---|
38 | propagates by itself while interacting with the material |
---|
39 | surrounding it. However, in terms of data hiding, which is |
---|
40 | one of the most important ingredients in the object-oriented |
---|
41 | approach, the design can be improved. |
---|
42 | </para> |
---|
43 | |
---|
44 | <para> |
---|
45 | Combining all the necessary functionalities into a single |
---|
46 | class exposes all the data attributes to a large number of |
---|
47 | methods in the class. This is basically equivalent to using |
---|
48 | a common block in Fortran. |
---|
49 | </para> |
---|
50 | |
---|
51 | <para> |
---|
52 | Instead of the 'big-class' approach, a hierarchical design |
---|
53 | was employed by Geant4. The hierarchical approach, which |
---|
54 | includes inheritance and aggregation, enables large, complex |
---|
55 | software systems to be designed in a structured way. The |
---|
56 | simulation of a particle passing through matter is |
---|
57 | a complex task involving particles, detector geometry, physics |
---|
58 | interactions and hits in the detector. It is well-suited to |
---|
59 | the hierarchical approach. The hierarchical design manages the |
---|
60 | complexity of the tracking category by separating the system |
---|
61 | into layers. Each layer may then be designed independently of |
---|
62 | the others. |
---|
63 | </para> |
---|
64 | |
---|
65 | <para> |
---|
66 | In order to maintain high-performance tracking, use of the |
---|
67 | inheritance ('is-a' relation) hierarchy in the tracking category |
---|
68 | was avoided as much as possible. For example, <literal>track</literal> |
---|
69 | and <literal>particle</literal> classes might have been designed so that a |
---|
70 | <literal>track</literal> 'is a' <literal>particle</literal>. In this |
---|
71 | scheme, however, whenever a <literal>track</literal> object is used, |
---|
72 | time is spent copying the data from the <literal>particle</literal> object |
---|
73 | into the <literal>track</literal> |
---|
74 | object. Adopting the aggregation ('has-a' relation) hierarchy |
---|
75 | requires only pointers to be copied, thus providing a |
---|
76 | performance advantage. |
---|
77 | </para> |
---|
78 | |
---|
79 | </sect2> |
---|
80 | |
---|
81 | <!-- ******************* Section (Level#2) ****************** --> |
---|
82 | <sect2 id="sect.DsgnFuncTracking.DsgClass"> |
---|
83 | <title> |
---|
84 | Class Design |
---|
85 | </title> |
---|
86 | |
---|
87 | <para> |
---|
88 | <xref linkend="fig.DsgnFuncTracking_1" /> shows a general overview of the |
---|
89 | tracking design in Unified Modelling Language Notation. |
---|
90 | |
---|
91 | <figure id="fig.DsgnFuncTracking_1"> |
---|
92 | <title> |
---|
93 | Tracking design |
---|
94 | </title> |
---|
95 | <mediaobject> |
---|
96 | <imageobject role="fo"> |
---|
97 | <imagedata fileref="./AllResources/OOAnalysisDesign/Tracking/classDgmTracking.jpg" |
---|
98 | format="JPG" contentwidth="10.0cm" align="center" /> |
---|
99 | </imageobject> |
---|
100 | <imageobject role="html"> |
---|
101 | <imagedata fileref="./AllResources/OOAnalysisDesign/Tracking/classDgmTracking.jpg" |
---|
102 | format="JPG" contentwidth="120%" align="center" /> |
---|
103 | </imageobject> |
---|
104 | </mediaobject> |
---|
105 | </figure> |
---|
106 | |
---|
107 | |
---|
108 | <itemizedlist spacing="compact"> |
---|
109 | <listitem><para> |
---|
110 | <emphasis role="bold">G4TrackingManager</emphasis> is an interface |
---|
111 | between the event and track categories and the tracking category. |
---|
112 | It handles the message passing between the upper hierarchical object, |
---|
113 | which is the event manager (<literal>G4EventManagerz</literal>), |
---|
114 | and lower hierarchical objects in the tracking category. |
---|
115 | <literal>G4TrackingManager</literal> is responsible for processing |
---|
116 | one track which it receives from the event manager. |
---|
117 | </para> |
---|
118 | <para> |
---|
119 | <literal>G4TrackingManager</literal> aggregates the pointers to |
---|
120 | <literal>G4SteppingManager</literal>, <literal>G4Trajectory</literal> |
---|
121 | and <literal>G4UserTrackingAction</literal>. It also has a 'use' |
---|
122 | relation to <literal>G4Track</literal>. |
---|
123 | </para></listitem> |
---|
124 | <listitem><para> |
---|
125 | <emphasis role="bold">G4SteppingManager</emphasis> plays an essential |
---|
126 | role in particle tracking. It performs message passing to objects |
---|
127 | in all categories related to particle transport, such as |
---|
128 | geometry and physics processes. Its public method |
---|
129 | <literal>Stepping()</literal> steers the stepping of the particle. |
---|
130 | The algorithm employed in this method is basically the same as that |
---|
131 | in Geant3. The Geant4 implementation, however, relies on the inheritance |
---|
132 | hierarchy of the physics interactions. The hierarchical |
---|
133 | design of the physics interactions enables the stepping |
---|
134 | manager to handle them as abstract objects. Hence, the manager |
---|
135 | is not concerned with concrete interaction objects such as |
---|
136 | bremsstrahlung or pair creation. The actual invocations of |
---|
137 | various interactions during the stepping are done through a |
---|
138 | dynamic binding mechanism. This mechanism shields the |
---|
139 | tracking category from any change in the design of the physics |
---|
140 | process classes, including the addition or subtraction of new |
---|
141 | processes. |
---|
142 | </para> |
---|
143 | <para> |
---|
144 | <literal>G4SteppingManager</literal> also aggregates |
---|
145 | <itemizedlist spacing="compact"> |
---|
146 | <listitem><para> |
---|
147 | the pointers to <literal>G4Navigator</literal> from the geometry |
---|
148 | category, to the current <literal>G4Track</literal>, and |
---|
149 | </para></listitem> |
---|
150 | <listitem><para> |
---|
151 | the list of secondaries from the current track |
---|
152 | (through a <literal>G4TrackVector</literal>) to |
---|
153 | <literal>G4UserSteppingAction</literal> and to |
---|
154 | <literal>G4VSteppingVerbose</literal>. |
---|
155 | </para></listitem> |
---|
156 | </itemizedlist> |
---|
157 | It also has a 'use' relation to <literal>G4ProcessManager</literal> |
---|
158 | and <literal>G4ParticleChange</literal> in the physics processes |
---|
159 | class category. |
---|
160 | </para></listitem> |
---|
161 | <listitem><para> |
---|
162 | <emphasis role="bold">G4Track</emphasis> - the class |
---|
163 | <literal>G4Track</literal> represents a particle |
---|
164 | which is pushed by <literal>G4SteppingManager</literal>. It holds |
---|
165 | information required for stepping a particle, for example, the |
---|
166 | current position, the time since the start of stepping, the |
---|
167 | identification of the geometrical volume which contains the particle, |
---|
168 | etc. Dynamic information, such as particle momentum and energy, |
---|
169 | is held in the class through a pointer to the |
---|
170 | <literal>G4DynamicParticle</literal> class. Static |
---|
171 | information, such as the particle mass and charge is stored in the |
---|
172 | <literal>G4DynamicParticle</literal> class through the pointer to the |
---|
173 | <literal>G4ParticleDefinition</literal> class. Here the aggregation |
---|
174 | hierarchical design is extensively employed to maintain high tracking |
---|
175 | performance. |
---|
176 | </para></listitem> |
---|
177 | <listitem><para> |
---|
178 | <emphasis role="bold">G4TrajectoryPoint and G4Trajectory</emphasis> - |
---|
179 | the class <literal>G4TrajectoryPoint</literal> holds the state of |
---|
180 | the particle after propagating one step. Among other things, it |
---|
181 | includes information on space-time, energy-momentum and geometrical |
---|
182 | volumes. |
---|
183 | </para> |
---|
184 | <para> |
---|
185 | <literal>G4Trajectory</literal> aggregates all |
---|
186 | <literal>G4TrajectoryPoint</literal> objects which belong to the |
---|
187 | particle being propagated. |
---|
188 | <literal>G4TrackingManager</literal> takes care of adding the |
---|
189 | <literal>G4TrajectoryPoint</literal> to a <literal>G4Trajectory</literal> |
---|
190 | object if the user requested it (see |
---|
191 | <ulink url="http://geant4.web.cern.ch/geant4/UserDocumentation/UsersGuides/ForApplicationDeveloper/html/index.html"> |
---|
192 | Geant4 User's Guide - For Application Developers</ulink>. |
---|
193 | The life of a <literal>G4Trajectory</literal> object spans an event, contrary to |
---|
194 | <literal>G4Track</literal> objects, which are deleted from memory after being |
---|
195 | processed. |
---|
196 | </para></listitem> |
---|
197 | <listitem><para> |
---|
198 | <emphasis role="bold">G4UserTrackingAction and G4UserSteppingAction</emphasis> - |
---|
199 | <literal>G4UserTrackingAction</literal> is a base class from which user actions |
---|
200 | at the beginning or end of tracking may be derived. Similarly, |
---|
201 | <literal>G4UserSteppingAction</literal> is a base class from which user actions |
---|
202 | at the beginning or end of each step may be derived. |
---|
203 | </para></listitem> |
---|
204 | </itemizedlist> |
---|
205 | </para> |
---|
206 | |
---|
207 | </sect2> |
---|
208 | |
---|
209 | <!-- ******************* Section (Level#2) ****************** --> |
---|
210 | <sect2 id="sect.DsgnFuncTracking.TrkAlgo"> |
---|
211 | <title> |
---|
212 | Tracking Algorithm |
---|
213 | </title> |
---|
214 | |
---|
215 | <para> |
---|
216 | The key classes for tracking in Geant4 are |
---|
217 | <literal>G4TrackingManager</literal> and <literal>G4SteppingManager</literal>. |
---|
218 | The singleton object "TrackingManager" from <literal>G4TrackingManager</literal> |
---|
219 | keeps all information related to a particular track, and it |
---|
220 | also manages all actions necessary to complete the tracking. The |
---|
221 | tracking proceeds by pushing a particle by a step, the length |
---|
222 | of which is defined by one of the active processes. |
---|
223 | The "TrackingManager" object delegates management of each of the |
---|
224 | steps to the "SteppingManager" object. This object keeps all |
---|
225 | information related to a particular step. |
---|
226 | </para> |
---|
227 | |
---|
228 | <para> |
---|
229 | The public method <literal>ProcessOneTrack()</literal> in |
---|
230 | <literal>G4TrackingManager</literal> |
---|
231 | is the key to managing the tracking, while the public method |
---|
232 | <literal>Stepping()</literal> is the key to managing one step. The algorithms |
---|
233 | used in these methods are explained below. |
---|
234 | </para> |
---|
235 | |
---|
236 | <para> |
---|
237 | <emphasis role="bold">ProcessOneTrack() in G4TrackingManager</emphasis> |
---|
238 | |
---|
239 | <orderedlist spacing="compact"> |
---|
240 | <listitem><para> |
---|
241 | Actions before tracking the particle: Clear secondary particle vector |
---|
242 | </para></listitem> |
---|
243 | <listitem><para> |
---|
244 | Pre tracking user intervention process. |
---|
245 | </para></listitem> |
---|
246 | <listitem><para> |
---|
247 | Construct a trajectory if it is requested |
---|
248 | </para></listitem> |
---|
249 | <listitem><para> |
---|
250 | Give SteppingManager the pointer to the track which will be tracked |
---|
251 | </para></listitem> |
---|
252 | <listitem><para> |
---|
253 | Inform beginning of tracking to physics processes |
---|
254 | </para></listitem> |
---|
255 | <listitem><para> |
---|
256 | Track the particle Step-by-Step while it is alive |
---|
257 | <itemizedlist spacing="compact"> |
---|
258 | <listitem><para> |
---|
259 | Call Stepping method of G4SteppingManager |
---|
260 | </para></listitem> |
---|
261 | <listitem><para> |
---|
262 | Append a trajectory point to the trajectory object if it is requested |
---|
263 | </para></listitem> |
---|
264 | </itemizedlist> |
---|
265 | </para></listitem> |
---|
266 | <listitem><para> |
---|
267 | Post tracking user intervention process. |
---|
268 | </para></listitem> |
---|
269 | <listitem><para> |
---|
270 | Destroy the trajectory if it was created |
---|
271 | </para></listitem> |
---|
272 | </orderedlist> |
---|
273 | </para> |
---|
274 | |
---|
275 | <para> |
---|
276 | <emphasis role="bold">Stepping() in G4SteppingManager</emphasis> |
---|
277 | |
---|
278 | <orderedlist spacing="compact"> |
---|
279 | <listitem><para> |
---|
280 | Initialize current step |
---|
281 | </para></listitem> |
---|
282 | <listitem><para> |
---|
283 | If particle is stopped, get the minimum life time from all the at rest |
---|
284 | processes and invoke InvokeAtRestDoItProcs for the selected AtRest |
---|
285 | processes |
---|
286 | </para></listitem> |
---|
287 | <listitem><para> |
---|
288 | If particle is not stopped: |
---|
289 | <itemizedlist spacing="compact"> |
---|
290 | <listitem><para> |
---|
291 | Invoke DefinePhysicalStepLength, that finds the minimum |
---|
292 | step length demanded by the active processes |
---|
293 | </para></listitem> |
---|
294 | <listitem><para> |
---|
295 | Invoke InvokeAlongStepDoItProcs |
---|
296 | </para></listitem> |
---|
297 | <listitem><para> |
---|
298 | Update current track properties by taking into account all |
---|
299 | changes by AlongStepDoIt |
---|
300 | </para></listitem> |
---|
301 | <listitem><para> |
---|
302 | Update the <emphasis role="bold">safety</emphasis> |
---|
303 | </para></listitem> |
---|
304 | <listitem><para> |
---|
305 | Invoke PostStepDoIt of the active discrete process. |
---|
306 | </para></listitem> |
---|
307 | <listitem><para> |
---|
308 | Update the track length |
---|
309 | </para></listitem> |
---|
310 | <listitem><para> |
---|
311 | Send G4Step information to Hit/Dig if the volume is sensitive |
---|
312 | </para></listitem> |
---|
313 | <listitem><para> |
---|
314 | Invoke the user intervention process. |
---|
315 | </para></listitem> |
---|
316 | <listitem><para> |
---|
317 | Return the value of the StepStatus. |
---|
318 | </para></listitem> |
---|
319 | </itemizedlist> |
---|
320 | </para></listitem> |
---|
321 | </orderedlist> |
---|
322 | </para> |
---|
323 | |
---|
324 | </sect2> |
---|
325 | |
---|
326 | <!-- ******************* Section (Level#2) ****************** --> |
---|
327 | <sect2 id="sect.DsgnFuncTracking.IntPhysProc"> |
---|
328 | <title> |
---|
329 | Interaction with Physics Processes |
---|
330 | </title> |
---|
331 | |
---|
332 | <para> |
---|
333 | The interaction of the tracking category with the physics processes |
---|
334 | is done in two ways. First each process can limit the step length |
---|
335 | through one of its three <literal>GetPhysicalInteractionLength()</literal> |
---|
336 | methods, AtRest, AlongStep, or PostStep. Second, for the selected processes |
---|
337 | the DoIt (AtRest, AlongStep or PostStep) methods are invoked. |
---|
338 | All this interaction is managed by the Stepping method of |
---|
339 | <literal>G4SteppingManager</literal>. To calculate the step length, the |
---|
340 | <literal>DefinePhysicalStepLength()</literal> method is called. The flow of |
---|
341 | this method is the following: |
---|
342 | |
---|
343 | <itemizedlist spacing="compact"> |
---|
344 | <listitem><para> |
---|
345 | Obtain maximum allowed Step in the volume define by the user |
---|
346 | through G4UserLimits. |
---|
347 | </para></listitem> |
---|
348 | <listitem><para> |
---|
349 | The PostStepGetPhysicalInteractionLength of all active processes |
---|
350 | is called. Each process returns a step length and the minimum |
---|
351 | one is chosen. This method also returns a G4ForceCondition flag, |
---|
352 | to indicate if the process is forced or not: |
---|
353 | = Forced : Corresponding PostStepDoIt is forced. |
---|
354 | = NotForced : Corresponding PostStepDoIt is not forced |
---|
355 | unless this process limits the step. |
---|
356 | = Conditionally : Only when AlongStepDoIt limits the |
---|
357 | step, corresponding PoststepDoIt is invoked. |
---|
358 | = ExclusivelyForced : Corresponding PostStepDoIt is exclusively |
---|
359 | forced. |
---|
360 | All other DoIt including AlongStepDoIts are ignored. |
---|
361 | </para></listitem> |
---|
362 | <listitem><para> |
---|
363 | The AlongStepGetPhysicalInteractionLength method of all active |
---|
364 | processes is called. Each process returns a step length and the |
---|
365 | minimum of these and the |
---|
366 | This method also returns a fGPILSelection flag, to indicate if |
---|
367 | the process is the selected one can be is forced or not: |
---|
368 | = CandidateForSelection: this process can be the winner. If |
---|
369 | its step length is the smallest, it will be the process |
---|
370 | defining the step (the process |
---|
371 | = NotCandidateForSelection: this process cannot be the winner. |
---|
372 | Even if its step length is taken as the smallest, it will not |
---|
373 | be the process defining the step |
---|
374 | </para></listitem> |
---|
375 | </itemizedlist> |
---|
376 | </para> |
---|
377 | |
---|
378 | <para> |
---|
379 | The method <literal>G4SteppingManager::InvokeAlongStepDoIts()</literal> |
---|
380 | is in charge of calling the AlongStepDoIt methods of the different |
---|
381 | processes: |
---|
382 | |
---|
383 | <itemizedlist spacing="compact"> |
---|
384 | <listitem><para> |
---|
385 | If the current step is defined by a 'ExclusivelyForced' |
---|
386 | PostStepGetPhysicalInteractionLength, no AlongStepDoIt method will be invoked |
---|
387 | </para></listitem> |
---|
388 | <listitem><para> |
---|
389 | Else, all the active continuous processes will be invoked, and they return |
---|
390 | the ParticleChange. After it for each process the following is executed: |
---|
391 | <itemizedlist spacing="compact"> |
---|
392 | <listitem><para> |
---|
393 | Update the G4Step information by using final state information of the |
---|
394 | track given by a physics process. This is done through the |
---|
395 | UpdateStepForAlongStep method of the ParticleChange |
---|
396 | </para></listitem> |
---|
397 | <listitem><para> |
---|
398 | Then for each secondary: |
---|
399 | <itemizedlist spacing="compact"> |
---|
400 | <listitem><para> |
---|
401 | It is checked if its kinetic energy is smaller than the energy |
---|
402 | threshold for the material. In this case the particle is assigned a 0. |
---|
403 | kinetic energy and its energy is added as deposited energy of the |
---|
404 | parent track. This check is only done if the flag ApplyCutFlag is set |
---|
405 | for the particle (by default it is set to 'false' for all particles, |
---|
406 | user may change it in its G4VUserPhysicsList). |
---|
407 | If the track has the flag IsGoodForTracking 'true' this check will |
---|
408 | have no effect (used mainly to track particles below threshold) |
---|
409 | </para></listitem> |
---|
410 | <listitem><para> |
---|
411 | The parentID and the process pointer which created this track are set |
---|
412 | </para></listitem> |
---|
413 | <listitem><para> |
---|
414 | The secondary track is added to the list of secondaries. If it has 0. |
---|
415 | kinetic energy, it is only added if it it invokes a rest process at |
---|
416 | the beginning of the tracking |
---|
417 | </para></listitem> |
---|
418 | </itemizedlist> |
---|
419 | </para></listitem> |
---|
420 | <listitem><para> |
---|
421 | The track status is set according to what the process defined |
---|
422 | </para></listitem> |
---|
423 | </itemizedlist> |
---|
424 | </para></listitem> |
---|
425 | </itemizedlist> |
---|
426 | </para> |
---|
427 | |
---|
428 | <para> |
---|
429 | The method <literal>G4SteppingManager::InvokePostStepDoIts</literal> is on |
---|
430 | charge of calling the PostStepDoIt methods of the different processes. |
---|
431 | |
---|
432 | <itemizedlist spacing="compact"> |
---|
433 | <listitem><para> |
---|
434 | Invoke the PostStepDoIt methods of the specified discrete process |
---|
435 | (the one selected by the PostStepGetPhysicalInteractionLength, and they |
---|
436 | return the ParticleChange. The order of invocation of processes is |
---|
437 | inverse to the order used for the GPIL methods. |
---|
438 | After it for each process the following is executed: |
---|
439 | <itemizedlist spacing="compact"> |
---|
440 | <listitem><para> |
---|
441 | Update PostStepPoint of Step according to ParticleChange |
---|
442 | </para></listitem> |
---|
443 | <listitem><para> |
---|
444 | Update G4Track according to ParticleChange after each PostStepDoIt |
---|
445 | </para></listitem> |
---|
446 | <listitem><para> |
---|
447 | Update safety after each invocation of PostStepDoIts |
---|
448 | </para></listitem> |
---|
449 | <listitem><para> |
---|
450 | The secondaries from ParticleChange are stored to SecondaryList |
---|
451 | </para></listitem> |
---|
452 | <listitem><para> |
---|
453 | Then for each secondary: |
---|
454 | <itemizedlist spacing="compact"> |
---|
455 | <listitem><para> |
---|
456 | It is checked if its kinetic energy is smaller than the energy |
---|
457 | threshold for the material. In this case the particle is assigned a 0. |
---|
458 | kinetic energy and its energy is added as deposited energy of the |
---|
459 | parent track. This check is only done if the flag ApplyCutFlag is set |
---|
460 | for the particle (by default it is set to 'false' for all particles, |
---|
461 | user may change it in its G4VUserPhysicsList). |
---|
462 | If the track has the flag IsGoodForTracking 'true' this check will |
---|
463 | have no effect (used mainly to track particles below threshold) |
---|
464 | </para></listitem> |
---|
465 | <listitem><para> |
---|
466 | The parentID and the process pointer which created this track are set |
---|
467 | </para></listitem> |
---|
468 | <listitem><para> |
---|
469 | The secondary track is added to the list of secondaries. If it has 0. |
---|
470 | kinetic energy, it is only added if it it invokes a rest process at |
---|
471 | the beginning of the tracking |
---|
472 | </para></listitem> |
---|
473 | </itemizedlist> |
---|
474 | </para></listitem> |
---|
475 | <listitem><para> |
---|
476 | The track status is set according to what the process defined |
---|
477 | </para></listitem> |
---|
478 | </itemizedlist> |
---|
479 | </para></listitem> |
---|
480 | </itemizedlist> |
---|
481 | </para> |
---|
482 | |
---|
483 | <para> |
---|
484 | The method <literal>G4SteppingManager::InvokeAtRestDoIts</literal> is called |
---|
485 | instead of the three above methods in case the track status is |
---|
486 | <emphasis role="bold">fStopAndALive</emphasis>. It is on charge of selecting |
---|
487 | the rest process which has the shortest time before and then invoke it: |
---|
488 | |
---|
489 | <itemizedlist spacing="compact"> |
---|
490 | <listitem><para> |
---|
491 | To select the process with shortest tiem, the AtRestGPIL method of all |
---|
492 | active processes is called. |
---|
493 | Each process returns an lifetime and the minimum one is chosen. |
---|
494 | This method returm also a G4ForceCondition flag, to indicate if the process |
---|
495 | is forced or not: |
---|
496 | = Forced : Corresponding AtRestDoIt is forced. |
---|
497 | = NotForced : Corresponding AtRestDoIt is not forced |
---|
498 | unless this process limits the step. |
---|
499 | </para></listitem> |
---|
500 | <listitem><para> |
---|
501 | Set the step length of current track and step to 0. |
---|
502 | </para></listitem> |
---|
503 | <listitem><para> |
---|
504 | Invoke the AtRestDoIt methods of the specified at rest process, and they |
---|
505 | return the ParticleChange. The order of invocation of processes is |
---|
506 | inverse to the order used for the GPIL methods. |
---|
507 | </para> |
---|
508 | <para> |
---|
509 | After it for each process the following is executed: |
---|
510 | <itemizedlist spacing="compact"> |
---|
511 | <listitem><para> |
---|
512 | Set the current process as a process which defined this Step length. |
---|
513 | </para></listitem> |
---|
514 | <listitem><para> |
---|
515 | Update the G4Step information by using final state information of the |
---|
516 | track given by a physics process. This is done through the |
---|
517 | UpdateStepForAtRest method of the ParticleChange. |
---|
518 | </para></listitem> |
---|
519 | <listitem><para> |
---|
520 | The secondaries from ParticleChange are stored to SecondaryList |
---|
521 | </para></listitem> |
---|
522 | <listitem><para> |
---|
523 | Then for each secondary: |
---|
524 | <itemizedlist spacing="compact"> |
---|
525 | <listitem><para> |
---|
526 | It is checked if its kinetic energy is smaller than the energy |
---|
527 | threshold for the material. In this case the particle is assigned a 0. |
---|
528 | kinetic energy and its energy is added as deposited energy of the |
---|
529 | parent track. |
---|
530 | This check is only done if the flag ApplyCutFlag is set for the |
---|
531 | particle (by default it is set to 'false' for all particles, user may |
---|
532 | change it in its G4VUserPhysicsList). |
---|
533 | If the track has the flag IsGoodForTracking 'true' this check will |
---|
534 | have no effect (used mainly to track particles below threshold) |
---|
535 | </para></listitem> |
---|
536 | <listitem><para> |
---|
537 | The parentID and the process pointer which created this track are set |
---|
538 | </para></listitem> |
---|
539 | <listitem><para> |
---|
540 | The secondary track is added to the list of secondaries. If it has 0. |
---|
541 | kinetic energy, it is only added if it it invokes a rest process at |
---|
542 | the beginning of the tracking |
---|
543 | </para></listitem> |
---|
544 | </itemizedlist> |
---|
545 | </para></listitem> |
---|
546 | <listitem><para> |
---|
547 | The track is updated and its status is set according to what the process |
---|
548 | defined |
---|
549 | </para></listitem> |
---|
550 | </itemizedlist> |
---|
551 | </para></listitem> |
---|
552 | </itemizedlist> |
---|
553 | </para> |
---|
554 | |
---|
555 | </sect2> |
---|
556 | |
---|
557 | <!-- ******************* Section (Level#2) ****************** --> |
---|
558 | <sect2 id="sect.DsgnFuncTracking.OrderPhysProc"> |
---|
559 | <title> |
---|
560 | Ordering of Methods of Physics Processes |
---|
561 | </title> |
---|
562 | |
---|
563 | <para> |
---|
564 | The ProcessManager of a particle is responsible for providing the |
---|
565 | correct ordering of process invocations. <literal>G4SteppingManager</literal> |
---|
566 | invokes the processes at each phase just following the order given |
---|
567 | by the ProcessManager of the corresponding particle. |
---|
568 | </para> |
---|
569 | |
---|
570 | <para> |
---|
571 | For some processes the order is important. |
---|
572 | Geant4 provides by default the right ordering. |
---|
573 | It is always possible for the user to choose the order of process |
---|
574 | invocations at the initial set up phase of Geant4. |
---|
575 | This default ordering is the following: |
---|
576 | |
---|
577 | <orderedlist spacing="compact"> |
---|
578 | <listitem><para> |
---|
579 | Ordering of GetPhysicalInteractionLength |
---|
580 | <itemizedlist spacing="compact"> |
---|
581 | <listitem><para> |
---|
582 | In the loop of GetPhysicalInteractionLength of AlongStepDoIt, |
---|
583 | the Transportation process has to be invoked at the end. |
---|
584 | </para></listitem> |
---|
585 | <listitem><para> |
---|
586 | In the loop of GetPhysicalInteractionLength of AlongStepDoIt, |
---|
587 | the Multiple Scattering process has to be invoked just before |
---|
588 | the Transportation process. |
---|
589 | </para></listitem> |
---|
590 | </itemizedlist> |
---|
591 | </para></listitem> |
---|
592 | <listitem><para> |
---|
593 | Ordering of DoIts |
---|
594 | <itemizedlist spacing="compact"> |
---|
595 | <listitem><para> |
---|
596 | There is only some special cases. For example, the Cherenkov |
---|
597 | process needs the energy loss information of the current step |
---|
598 | for its DoIt invocation. Therefore, the EnergyLoss process has |
---|
599 | to be invoked before the Cherenkov process. This ordering is |
---|
600 | provided by the process manager. Energy loss information |
---|
601 | necessary for the Cherenkov process is passed using G4Step |
---|
602 | (or the static dE/dX table is used together with the step length |
---|
603 | information in G4Step to obtain the energy loss information). |
---|
604 | Any other? |
---|
605 | </para></listitem> |
---|
606 | </itemizedlist> |
---|
607 | </para></listitem> |
---|
608 | </orderedlist> |
---|
609 | </para> |
---|
610 | |
---|
611 | |
---|
612 | <!-- ******* Bridgehead ******* --> |
---|
613 | <bridgehead role="revisionHistory" renderas='sect4'> |
---|
614 | [Status of this chapter] |
---|
615 | </bridgehead> |
---|
616 | |
---|
617 | <para> |
---|
618 | <simplelist type="var"> |
---|
619 | <member> |
---|
620 | Nov. 1998 created by K. Amako |
---|
621 | </member> |
---|
622 | <member> |
---|
623 | 10.06.02 partially re-written by D.H. Wright |
---|
624 | </member> |
---|
625 | <member> |
---|
626 | 14.11.02 updated and partially re-written by P. Arce |
---|
627 | </member> |
---|
628 | <member> |
---|
629 | Dec. 2006 Converted from latex to Docbook by K. Amako |
---|
630 | </member> |
---|
631 | </simplelist> |
---|
632 | </para> |
---|
633 | |
---|
634 | </sect2> |
---|
635 | </sect1> |
---|