| 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>
|
|---|
