1 | % $Id: tracking.tex,v 1.10 2005/12/11 02:16:01 dennis Exp $ |
---|
2 | \chapter{Tracking} |
---|
3 | |
---|
4 | The tracking category manages the contribution of the processes to the |
---|
5 | evolution of a track's state and provides information in sensitive volumes |
---|
6 | for hits and digitization. |
---|
7 | |
---|
8 | \section{Design Philosophy} |
---|
9 | |
---|
10 | It is well known that the overall performance of a detector |
---|
11 | simulation depends critically on the CPU time spent |
---|
12 | propagating the particle through one step. The most |
---|
13 | important consideration in the object design of the tracking |
---|
14 | category is maintaining high execution speed in the {\sc Geant4} |
---|
15 | simulation while utilizing the power of the object-oriented |
---|
16 | approach. |
---|
17 | |
---|
18 | An extreme approach to the particle tracking design would be |
---|
19 | to integrate all functionalities required for the propagation |
---|
20 | of a particle into a single class. This design approach looks |
---|
21 | object-oriented because a particle in the real world |
---|
22 | propagates by itself while interacting with the material |
---|
23 | surrounding it. However, in terms of data hiding, which is |
---|
24 | one of the most important ingredients in the object-oriented |
---|
25 | approach, the design can be improved. |
---|
26 | |
---|
27 | Combining all the necessary functionalities into a single |
---|
28 | class exposes all the data attributes to a large number of |
---|
29 | methods in the class. This is basically equivalent to using |
---|
30 | a common block in Fortran. |
---|
31 | |
---|
32 | Instead of the 'big-class' approach, a hierarchical design |
---|
33 | was employed by {\sc Geant4}. The hierarchical approach, which |
---|
34 | includes inheritance and aggregation, enables large, complex |
---|
35 | software systems to be designed in a structured way. The |
---|
36 | simulation of a particle passing through matter is |
---|
37 | a complex task involving particles, detector geometry, physics |
---|
38 | interactions and hits in the detector. It is well-suited to |
---|
39 | the hierarchical approach. The hierarchical design manages the |
---|
40 | complexity of the tracking category by separating the system |
---|
41 | into layers. Each layer may then be designed independently of |
---|
42 | the others. |
---|
43 | |
---|
44 | In order to maintain high-performance tracking, use of the |
---|
45 | inheritance ('is-a' relation) hierarchy in the tracking category |
---|
46 | was avoided as much as possible. For example, {\it track} and |
---|
47 | {\it particle} classes might have been designed so that a |
---|
48 | {\it track} 'is a' {\it particle}. In this scheme, however, |
---|
49 | whenever a {\it track} object is used, time is spent copying |
---|
50 | the data from the {\it particle} object into the {\it track} |
---|
51 | object. Adopting the aggregation ('has-a' relation) hierarchy |
---|
52 | requires only pointers to be copied, thus providing a |
---|
53 | performance advantage. |
---|
54 | |
---|
55 | \section{Class Design} |
---|
56 | |
---|
57 | Fig. (not yet available) |
---|
58 | % \ref{figure:tracking-1} |
---|
59 | shows a general overview of the tracking |
---|
60 | design in Unified Modelling Language Notation. |
---|
61 | |
---|
62 | % \begin{figure} |
---|
63 | % \begin{center} |
---|
64 | % \includegraphics[angle=0,scale=0.4]{OOAnalysisDesign/Tracking/classDgmTracking.ps} |
---|
65 | % \vspace{10pt} |
---|
66 | % \caption{Tracking} |
---|
67 | % \label{figure:tracking-1} |
---|
68 | % \end{center} |
---|
69 | % \end{figure} |
---|
70 | |
---|
71 | \begin{itemize} |
---|
72 | \item {\em G4TrackingManager} is an interface between the event |
---|
73 | and track categories and the tracking category. It handles the |
---|
74 | message passing between the upper hierarchical object, which is |
---|
75 | the event manager ({\tt G4EventManager}), and lower hierarchical |
---|
76 | objects in the tracking category. {\tt G4TrackingManager} is |
---|
77 | responsible for processing one track which it receives from the |
---|
78 | event manager. |
---|
79 | |
---|
80 | {\tt G4TrackingManager} aggregates the pointers to |
---|
81 | {\tt G4SteppingManager}, {\tt G4Trajectory} and |
---|
82 | {\tt G4UserTrackingAction}. It also has a 'use' |
---|
83 | relation to {\tt G4Track}. |
---|
84 | |
---|
85 | \item {\em G4SteppingManager} plays an essential role in |
---|
86 | particle tracking. It performs message passing to objects |
---|
87 | in all categories related to particle transport, such as |
---|
88 | geometry and physics processes. Its public method {\tt Stepping()} |
---|
89 | steers the stepping of the particle. The algorithm employed in |
---|
90 | this method is basically the same as that in Geant3. The |
---|
91 | {\sc Geant4} implementation, however, relies on the inheritance |
---|
92 | hierarchy of the physics interactions. The hierarchical |
---|
93 | design of the physics interactions enables the stepping |
---|
94 | manager to handle them as abstract objects. Hence, the manager |
---|
95 | is not concerned with concrete interaction objects such as |
---|
96 | bremsstrahlung or pair creation. The actual invocations of |
---|
97 | various interactions during the stepping are done through a |
---|
98 | dynamic binding mechanism. This mechanism shields the |
---|
99 | tracking category from any change in the design of the physics |
---|
100 | process classes, including the addition or subtraction of new |
---|
101 | processes. |
---|
102 | |
---|
103 | {\tt G4SteppingManager} also aggregates |
---|
104 | \begin{itemize} |
---|
105 | \item{the pointers to {\tt G4Navigator} from the geometry category, |
---|
106 | to the current {\tt G4Track}, and} |
---|
107 | |
---|
108 | \item{the list of secondaries from the current track |
---|
109 | (through a {\tt G4TrackVector}) to {\tt G4UserSteppingAction} |
---|
110 | and to {\tt G4VSteppingVerbose}.} |
---|
111 | \end{itemize} |
---|
112 | |
---|
113 | It also has a 'use' relation to {\tt G4ProcessManager} and |
---|
114 | {\tt G4ParticleChange} in the physics processes class category. |
---|
115 | |
---|
116 | \item |
---|
117 | {\em G4Track} - the class {\tt G4Track} represents a particle |
---|
118 | which is pushed by {\tt G4SteppingManager}. It holds information |
---|
119 | required for stepping a particle, for example, the current position, |
---|
120 | the time since the start of stepping, the identification of the |
---|
121 | geometrical volume which contains the particle, etc. Dynamic |
---|
122 | information, such as particle momentum and energy, is held in the |
---|
123 | class through a pointer to the {\tt G4DynamicParticle} class. Static |
---|
124 | information, such as the particle mass and charge is stored in the |
---|
125 | {\tt G4DynamicParticle} class through the pointer to the |
---|
126 | {\tt G4ParticleDefinition} class. Here the aggregation hierarchical |
---|
127 | design is extensively employed to maintain high tracking performance. |
---|
128 | |
---|
129 | \item |
---|
130 | {\em G4TrajectoryPoint} and {\em G4Trajectory} - the class |
---|
131 | {\tt G4TrajectoryPoint} holds the state of the particle after |
---|
132 | propagating one step. Among other things, it includes information |
---|
133 | on space-time, energy-momentum and geometrical volumes. |
---|
134 | |
---|
135 | {\tt G4Trajectory} aggregates all {\tt G4TrajectoryPoint} objects |
---|
136 | which belong to the particle being propagated. |
---|
137 | {\tt G4TrackingManager} takes care of adding the |
---|
138 | {\tt G4TrajectoryPoint} to a {\tt G4Trajectory} object if the user |
---|
139 | requested it (see \cite{applGuide}). |
---|
140 | The life of a {\tt G4Trajectory} object spans an event, contrary to |
---|
141 | {\tt G4Track} objects, which are deleted from memory after being |
---|
142 | processed. |
---|
143 | |
---|
144 | \item |
---|
145 | {\b G4UserTrackingAction and G4UserSteppingAction} - |
---|
146 | {\tt G4UserTrackingAction} is a base class from which user actions |
---|
147 | at the beginning or end of tracking may be derived. Similarly, |
---|
148 | {\tt G4UserSteppingAction} is a base class from which user actions |
---|
149 | at the beginning or end of each step may be derived. |
---|
150 | |
---|
151 | \end{itemize} |
---|
152 | |
---|
153 | \section{Tracking Algorithm} |
---|
154 | The key classes for tracking in {\sc Geant4} are |
---|
155 | {\tt G4TrackingManager} and {\tt G4SteppingManager}. The |
---|
156 | singleton object "TrackingManager" from {\tt G4TrackingManager} |
---|
157 | keeps all information related to a particular track, and it |
---|
158 | also manages all actions necessary to complete the tracking. The |
---|
159 | tracking proceeds by pushing a particle by a step, the length |
---|
160 | of which is defined by one of the active processes. |
---|
161 | The "TrackingManager" object delegates management of each of the |
---|
162 | steps to the "SteppingManager" object. This object keeps all |
---|
163 | information related to a particular step. |
---|
164 | |
---|
165 | The public method {\tt ProcessOneTrack()} in {\tt G4TrackingManager} |
---|
166 | is the key to managing the tracking, while the public method |
---|
167 | {\tt Stepping()} is the key to managing one step. The algorithms |
---|
168 | used in these methods are explained below.\newline |
---|
169 | |
---|
170 | \mbox{} |
---|
171 | {\bf ProcessOneTrack() in G4TrackingManager} |
---|
172 | \begin{enumerate} |
---|
173 | \item Actions before tracking the particle:\newline |
---|
174 | Clear secondary particle vector |
---|
175 | \item Pre tracking user intervention process. |
---|
176 | \item Construct a trajectory if it is requested |
---|
177 | \item Give SteppingManager the pointer to the track which will |
---|
178 | be tracked |
---|
179 | \item Inform beginning of tracking to physics processes |
---|
180 | \item Track the particle Step-by-Step while it is alive |
---|
181 | \begin{itemize} |
---|
182 | \item Call Stepping method of G4SteppingManager |
---|
183 | \item Append a trajectory point to the trajectory object if it |
---|
184 | is requested |
---|
185 | \end{itemize} |
---|
186 | \item Post tracking user intervention process. |
---|
187 | \item Destroy the trajectory if it was created |
---|
188 | \end{enumerate} |
---|
189 | |
---|
190 | \mbox{} |
---|
191 | {\bf Stepping() in G4SteppingManager } |
---|
192 | \begin{enumerate} |
---|
193 | \item Initialize current step |
---|
194 | \item If particle is stopped, get the minimum life time from all |
---|
195 | the at rest processes and invoke InvokeAtRestDoItProcs for |
---|
196 | the selected AtRest processes |
---|
197 | \item If particle is not stopped: |
---|
198 | \begin{itemize} |
---|
199 | \item Invoke DefinePhysicalStepLength, that finds the minimum |
---|
200 | step length demanded by the active processes |
---|
201 | \item Invoke InvokeAlongStepDoItProcs |
---|
202 | \item Update current track properties by taking into account all |
---|
203 | changes by AlongStepDoIt |
---|
204 | \item Update the {\em safety} |
---|
205 | \item Invoke PostStepDoIt of the active discrete process. |
---|
206 | \item Update the track length |
---|
207 | \item Send G4Step information to Hit/Dig if the volume is sensitive |
---|
208 | \item Invoke the user intervention process. |
---|
209 | \item Return the value of the StepStatus. |
---|
210 | \end{itemize} |
---|
211 | \end{enumerate} |
---|
212 | |
---|
213 | \section{Interaction with Physics Processes} |
---|
214 | |
---|
215 | The interaction of the tracking category with the physics processes |
---|
216 | is done in two ways. First each process can limit the step length |
---|
217 | through one of its three {\tt GetPhysicalInteractionLength()} methods, |
---|
218 | AtRest, AlongStep, or PostStep. Second, for the selected processes |
---|
219 | the DoIt (AtRest, AlongStep or PostStep) methods are invoked. |
---|
220 | All this interaction is managed by the Stepping method of |
---|
221 | {\tt G4SteppingManager}. To calculate the step length, the |
---|
222 | {\tt DefinePhysicalStepLength()} method is called. The flow of this |
---|
223 | method is the following: |
---|
224 | |
---|
225 | \begin{itemize} |
---|
226 | \item Obtain maximum allowed Step in the volume define by the user |
---|
227 | through G4UserLimits. |
---|
228 | \item The PostStepGetPhysicalInteractionLength of all active processes |
---|
229 | is called. Each process returns a step length and the minimum |
---|
230 | one is chosen. This method also returns a G4ForceCondition flag, |
---|
231 | to indicate if the process is forced or not: |
---|
232 | = Forced : Corresponding PostStepDoIt is forced. |
---|
233 | = NotForced : Corresponding PostStepDoIt is not forced |
---|
234 | unless this process limits the step. |
---|
235 | = Conditionally : Only when AlongStepDoIt limits the |
---|
236 | step, corresponding PoststepDoIt is invoked. |
---|
237 | = ExclusivelyForced : Corresponding PostStepDoIt is exclusively |
---|
238 | forced. |
---|
239 | All other DoIt including AlongStepDoIts are ignored. |
---|
240 | \item The AlongStepGetPhysicalInteractionLength method of all active |
---|
241 | processes is called. Each process returns a step length and the |
---|
242 | minimum of these and the |
---|
243 | This method also returns a fGPILSelection flag, to indicate if |
---|
244 | the process is the selected one can be is forced or not: |
---|
245 | = CandidateForSelection: this process can be the winner. If |
---|
246 | its step length is the smallest, it will be the process |
---|
247 | defining the step (the process |
---|
248 | = NotCandidateForSelection: this process cannot be the winner. |
---|
249 | Even if its step length is taken as the smallest, it will not |
---|
250 | be the process defining the step |
---|
251 | \end{itemize} |
---|
252 | |
---|
253 | The method {\tt G4SteppingManager::InvokeAlongStepDoIts()} is in charge |
---|
254 | of calling the AlongStepDoIt methods of the different processes: |
---|
255 | \begin{itemize} |
---|
256 | \item If the current step is defined by a 'ExclusivelyForced' |
---|
257 | PostStepGetPhysicalInteractionLength, no AlongStepDoIt method will be invoked |
---|
258 | \item Else, all the active continuous processes will be invoked, and they return the ParticleChange. |
---|
259 | After it for each process the following is executed: |
---|
260 | \begin{itemize} |
---|
261 | \item Update the G4Step information by using final state information of the track given by a physics process. This is done through the UpdateStepForAlongStep method of the ParticleChange |
---|
262 | \item Then for each secondary: |
---|
263 | \begin{itemize} |
---|
264 | \item It is checked if its kinetic energy is smaller than the energy threshold for the material. In this case the particle is assigned a 0. kinetic energy and its energy is added as deposited energy of the parent track. |
---|
265 | This check is only done if the flag ApplyCutFlag is set for the particle (by default it is set to 'false' for all particles, user may change it in its G4VUserPhysicsList). |
---|
266 | If the track has the flag IsGoodForTracking 'true' this check will have no effect (used mainly to track particles below threshold) |
---|
267 | \item The parentID and the process pointer which created this track are set \item The secondary track is added to the list of secondaries. If it has 0. kinetic energy, it is only added if it it invokes a rest process at the beginning of the tracking |
---|
268 | \end{itemize} |
---|
269 | \item The track status is set according to what the process defined |
---|
270 | \end{itemize} |
---|
271 | \end{itemize} |
---|
272 | |
---|
273 | The method G4SteppingManager::InvokePostStepDoIts is on charge of calling the PostStepDoIt methods of the different processes. |
---|
274 | \begin{itemize} |
---|
275 | \item Invoke the PostStepDoIt methods of the specified discrete process (the one selected by the PostStepGetPhysicalInteractionLength, and they return the ParticleChange. The order of invocation of processes is inverse to the order used for the GPIL methods. |
---|
276 | After it for each process the following is executed: |
---|
277 | \begin{itemize} |
---|
278 | \item Update PostStepPoint of Step according to ParticleChange |
---|
279 | \item Update G4Track according to ParticleChange after each PostStepDoIt |
---|
280 | \item Update safety\footnote{} after each invocation of PostStepDoIts |
---|
281 | \item The secondaries from ParticleChange are stored to SecondaryList |
---|
282 | \item Then for each secondary: |
---|
283 | \begin{itemize} |
---|
284 | \item It is checked if its kinetic energy is smaller than the energy threshold for the material. In this case the particle is assigned a 0. kinetic energy and its energy is added as deposited energy of the parent track. |
---|
285 | This check is only done if the flag ApplyCutFlag is set for the particle (by default it is set to 'false' for all particles, user may change it in its G4VUserPhysicsList). |
---|
286 | If the track has the flag IsGoodForTracking 'true' this check will have no effect (used mainly to track particles below threshold) |
---|
287 | \item The parentID and the process pointer which created this track are set \item The secondary track is added to the list of secondaries. If it has 0. kinetic energy, it is only added if it it invokes a rest process at the beginning of the tracking |
---|
288 | \end{itemize} |
---|
289 | \item The track status is set according to what the process defined |
---|
290 | \end{itemize} |
---|
291 | \end{itemize} |
---|
292 | |
---|
293 | The method G4SteppingManager::InvokeAtRestDoIts is called instead of the three above methods in case the track status is {\em fStopAndALive}. It is on charge of selecting the rest process which has the shortest time before and then invoke it: |
---|
294 | \begin{itemize} |
---|
295 | \item To select the process with shortest tiem, the AtRestGPIL method of all active processes is called. |
---|
296 | Each process returns an lifetime and the minimum one is chosen. |
---|
297 | This method returm also a G4ForceCondition flag, to indicate if the process is forced or not: |
---|
298 | = Forced : Corresponding AtRestDoIt is forced. |
---|
299 | = NotForced : Corresponding AtRestDoIt is not forced |
---|
300 | unless this process limits the step. |
---|
301 | \item Set the step length of current track and step to 0. |
---|
302 | \item Invoke the AtRestDoIt methods of the specified at rest process, and they return the ParticleChange. The order of invocation of processes is inverse to the order used for the GPIL methods. |
---|
303 | |
---|
304 | After it for each process the following is executed: |
---|
305 | \begin{itemize} |
---|
306 | \item Set the current process as a process which defined this Step length. |
---|
307 | \item Update the G4Step information by using final state information of the track given by a physics process. This is done through the UpdateStepForAtRest method of the ParticleChange. |
---|
308 | \item The secondaries from ParticleChange are stored to SecondaryList |
---|
309 | \item Then for each secondary: |
---|
310 | \begin{itemize} |
---|
311 | \item It is checked if its kinetic energy is smaller than the energy threshold for the material. In this case the particle is assigned a 0. kinetic energy and its energy is added as deposited energy of the parent track. |
---|
312 | This check is only done if the flag ApplyCutFlag is set for the particle (by default it is set to 'false' for all particles, user may change it in its G4VUserPhysicsList). |
---|
313 | If the track has the flag IsGoodForTracking 'true' this check will have no effect (used mainly to track particles below threshold) |
---|
314 | \item The parentID and the process pointer which created this track are set \item The secondary track is added to the list of secondaries. If it has 0. kinetic energy, it is only added if it it invokes a rest process at the beginning of the tracking |
---|
315 | \end{itemize} |
---|
316 | \item The track is updated and its status is set according to what the process defined |
---|
317 | \end{itemize} |
---|
318 | \end{itemize} |
---|
319 | |
---|
320 | |
---|
321 | \section{Ordering of Methods of Physics Processes} |
---|
322 | The ProcessManager of a particle is responsible for providing the |
---|
323 | correct ordering of process invocations. {\tt G4SteppingManager} |
---|
324 | invokes the processes at each phase just following the order given |
---|
325 | by the ProcessManager of the corresponding particle. |
---|
326 | |
---|
327 | For some processes the order is important. |
---|
328 | {\sc Geant4} provides by default the right ordering. |
---|
329 | It is always possible for the user to choose the order of process |
---|
330 | invocations at the initial set up phase of {\sc Geant4}. |
---|
331 | This default ordering is the following: |
---|
332 | |
---|
333 | \begin{enumerate} |
---|
334 | \item Ordering of GetPhysicalInteractionLength |
---|
335 | \begin{itemize} |
---|
336 | \item In the loop of GetPhysicalInteractionLength of |
---|
337 | AlongStepDoIt, the Transportation process has to be invoked |
---|
338 | at the end. |
---|
339 | \item In the loop of GetPhysicalInteractionLength of |
---|
340 | AlongStepDoIt, the Multiple Scattering process |
---|
341 | has to be invoked just before the Transportation process. |
---|
342 | \end{itemize} |
---|
343 | \item Ordering of DoIts |
---|
344 | \begin{itemize} |
---|
345 | \item There is only some special cases. |
---|
346 | For example, the Cherenkov process needs the energy |
---|
347 | loss information of the current step for its DoIt |
---|
348 | invocation. Therefore, the EnergyLoss process has to |
---|
349 | be invoked before the Cherenkov process. This |
---|
350 | ordering is provided by the process manager. Energy |
---|
351 | loss information necessary for the Cherenkov process |
---|
352 | is passed using G4Step (or the static dE/dX table is |
---|
353 | used together with the step length information in |
---|
354 | G4Step to obtain the energy loss information). |
---|
355 | Any other? |
---|
356 | \end{itemize} |
---|
357 | \end{enumerate} |
---|
358 | |
---|
359 | \section{Status of this chapter} |
---|
360 | |
---|
361 | created by ? \\ |
---|
362 | 10.06.02 partially re-written by D.H. Wright \\ |
---|
363 | 14.11.02 updated and partially re-written by P. Arce \\ |
---|
364 | |
---|
365 | \begin{latexonly} |
---|
366 | |
---|
367 | \begin{thebibliography}{999} |
---|
368 | \bibitem{applGuide} Geant4 Users' Guide for Application Developers. |
---|
369 | \end{thebibliography} |
---|
370 | |
---|
371 | \end{latexonly} |
---|
372 | |
---|
373 | \begin{htmlonly} |
---|
374 | |
---|
375 | \section{Bibliography} |
---|
376 | |
---|
377 | \begin{enumerate} |
---|
378 | \item Geant4 Users' Guide for Application Developers. |
---|
379 | \end{enumerate} |
---|
380 | |
---|
381 | \end{htmlonly} |
---|