[904] | 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"> |
---|
[921] | 97 | <imagedata fileref="./AllResources/OOAnalysisDesign/Tracking/classDgmTracking.jpg" |
---|
| 98 | format="JPG" contentwidth="10.0cm" align="center" /> |
---|
[904] | 99 | </imageobject> |
---|
| 100 | <imageobject role="html"> |
---|
[921] | 101 | <imagedata fileref="./AllResources/OOAnalysisDesign/Tracking/classDgmTracking.jpg" |
---|
[1208] | 102 | format="JPG" contentwidth="120%" align="center" /> |
---|
[904] | 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> |
---|