Tracking

In Geant4 the term ‘tracking’ means propagating a particle through a geometrical structure. There are two class categories closely related each other to describe the particle propagation:

• tracking category: manages the contribution of the physics processes to the evolution of a track’s state and provides information in sensitive volumes for hits and digitisation.

• track category: represents physical information of a particle to be propagated.

Design Philosophy

The tracking in Geant4 is based on step-wise propagation of the particle through a given geometry. The overall performance of the Geant4 simulation depends critically on the CPU time spent to move the particle by one step. Therefore the most important consideration in the object design of the tracking and track categories is maintaining high execution speed of step-wise propagation of the particle while utilising the power of the object-oriented approach.

During the design stage of tracking two possible approaches were investigated: ‘single-class’ versus ‘structured-classes’. The ‘single-class’ approach is based on a class design of mimicking a particle in the real world. This approach looks object-oriented because a particle in the real world propagates by itself while interacting with the material surrounding it. The design would be to integrate all functionalities required for the propagation of a particle into a single class, for example the ‘particle class’. Combining all the necessary functionalities into this single class exposes all the data attributes to a large number of methods in the class. This is against the strategy of ‘data hiding’, which is one of the most important ingredients in the object-oriented approach.

The simulation of a particle passing through matter is a complex task involving particles, detector geometry, physics interactions and hits in the detector. In the ‘structured-classes’ approach the class design is based on the idea of managing the complexity of the tracking task by separating it into structured multiple classes. Object-oriented techniques, such as inheritance and aggregation, play the essential roles in this design. In this approach it is also possible to categorise the classes into multiple categories. This approach enables each class category to be designed independently to others.

The ‘structured-classes’ approach was employed for the tracking design because it provides more flexibility in the designing and implementing stages.

In order to maintain high-performance tracking, use of the inheritance (‘is-a’ relation) hierarchy in the tracking and categories was avoided as much as possible. For example, track and particle classes might have been designed so that a track ‘is a’ particle. In this scheme, however, whenever a track object is used, time is spent copying the data from the particle object into the track object. Adopting the aggregation (‘has-a’ relation) hierarchy requires only pointers to be copied, thus providing a performance advantage.

Class Design

Track Category

The class diagram shown in Fig. 4 describes the static structure of classes in the ‘track’ category and their relation to closely coupled classes. The design is characterised by the hierarchic structure of three major classes, i.e. G4Track, G4Step and G4StepPoint. Main features of these classes are explained below.

• G4Track represents a particle which is pushed by G4SteppingManager. It holds information required for stepping a particle, for example, the current position, the time since the start of stepping, the identification of the geometrical volume which contains the particle, etc.

  Dynamic information, such as particle momentum and energy, is held in the class through a pointer to the G4DynamicParticle class. Static information, such as the particle mass and charge is stored in the G4DynamicParticle class through the pointer to the G4ParticleDefinition class. Here the aggregation hierarchical design is extensively employed to maintain high tracking performance.

  G4Track has information of the most recent step pushed by G4SteppingManager as a G4Step object. For G4Step see the explanation below.

• G4Step keeps information of a step pushed by G4SteppingManager. It holds information, for example, the step length and the deposited energy during a step. Information related to the begin/end points of a step are kept in the aggregated objects of G4StepPoint, which is described below.

• G4StepPoint keeps information of either the beginning or the end points of a step. This includes the geometry position, the volume to which the step point belongs, the global time when a step point is created, the physics process which occurred at a step point, etc.

  Two objects of G4StepPoint (PreStepPoint and PostStepPoint) are aggregated by a step.

Fig. 4 Tracking design.

Tracking Category

As mentioned already the tracking in Geant4 is based on step-wise propagation of the particle. The propagation is steered by two major classes in the ‘tracking’ category - G4TrackingManager and G4SteppingManager. G4TrackingManager propagates a particle from its start point to end. G4SteppingManager steers a single step in the particle propagation.

The class diagram shown in Fig. 4 describes the static structure of classes in the tracking category and their relation to closely coupled classes. The design is characterised by the hierarchic structure of two major classes, i.e. G4TrackingManager and G4SteppingManager. Main features of these classes and their closely related ones are explained below.

G4TrackingManager

is responsible for processing one track passed from the event manager G4EventManager. G4EventManager belongs to the event class category and is the hierarchically upper manager class to G4TrackingManager - see the previous section Event for details. Receiving one track G4TrackingManager propagates it step-by-step. Steering each step is delegated to the stepping manager G4SteppingManager, which is the the hierarchically lower manager class to G4TrackingManager.

G4TrackingManager aggregates the pointers to closely related classes:

• G4SteppingManager (composite aggregation)

• G4Trajectory (composite aggregation)

• G4UserTrackingAction (composite aggregation)

• G4Track (shared aggregation)

G4SteppingManager

plays an essential role in transporting a particle. Its public method Stepping() steers propagation of the particle by one step. In this method messages are passed to objects in the categories which are related to particle propagation, such as geometry and physics processes. In designing the message passing scheme between G4SteppingManager and physics processes, the key feature is the abstraction of physics processes utilising the inheritance hierarchy. The hierarchical design of the physics interactions enables the stepping manager to handle them as abstract objects. Hence, the manager need not interact directly with concrete physics process objects such as bremsstrahlung, pair creation, etc. The actual invocations of various interactions during the stepping are done through a dynamic binding mechanism. This mechanism shields the tracking category from any change in the design of the physics process classes, including the addition or subtraction of new processes.

G4SteppingManager aggregates pointers to closely related classes:

• G4Navigator (geometry category)

• G4Track under the current tracking (track category)

• G4TrackVector for the list of secondaries created during the current tracking (track category)

• G4UserSteppingAction

• G4ProcessManager (physics processes category)

• G4ParticleChange (physics processes category)

G4TrajectoryPoint

holds information of the particle after propagating one step. Among other things, it includes information on space-time, energy-momentum and geometrical volumes.

G4Trajectory

aggregates all G4TrajectoryPoint objects which belong to the particle being propagated. G4TrackingManager takes care of adding the G4TrajectoryPoint to a G4Trajectory object if the user requested it (see Geant4 User’s Guide For Application Developers). The life of a G4Trajectory object spans an event, contrary to G4Track objects, which are deleted from memory after being processed. G4RichTrajectory and G4SmoothTrajectory are derived classes from G4Trajectory. These classes are used for elaborate drawing of a trajectory on a graphic device.

G4UserTrackingAction

is a base class from which user actions at the beginning or end of tracking may be derived.

G4UserSteppingAction

is a base class from which user actions at the beginning or end of each step may be derived.

Tracking Algorithm

The key classes for tracking in Geant4 are G4TrackingManager and G4SteppingManager. The singleton object ‘TrackingManager’ created from the class G4TrackingManager keeps all information related to a particular track, and it also manages all actions necessary to complete the tracking. The tracking proceeds by pushing a particle by a step, the length of which is defined by one of the active physics processes. The ‘TrackingManager’ object delegates the management of each step to the object ‘SteppingManager’ created from the class G4SteppingManager . This object keeps all information related to a single step.

The public method ProcessOneTrack() in G4TrackingManager is the key of managing the tracking, while the public method Stepping() in G4SteppingManager is the key of managing one step. The basic algorithms used in these methods are described below.

ProcessOneTrack() in G4TrackingManager:

1. Clear the secondary particle vector before starting to track the particle.

2. Invoke pre-tracking user intervention process.

3. Construct a trajectory if it is requested.

4. Give SteppingManager the pointer to the track which will be tracked.

5. Inform ‘beginning of tracking’ to all the active physics processes.

6. Track the particle step-by-step while it is alive:

   • Call the method ‘Stepping’ of G4SteppingManager.

   • Append a trajectory point to the trajectory object if it is requested.

7. Invoke post-tracking user intervention process.

8. Delete the trajectory if it was created.

Stepping() in G4SteppingManager:

1. Initialise current step.

2. If the given particle has ‘zero’ kinetic energy, get the minimum life time from all the at rest processes and invoke InvokeAtRestDoItProcs of the selected AtRest processes.

3. If particle has ‘non-zero’ kinetic energy:

   • Invoke the method ‘DefinePhysicalStepLength’, that finds the minimum step length demanded by the active processes.

   • Invoke the method ‘InvokeAlongStepDoItProcs’.

   • Update current track properties by taking into account all changes by ‘AlongStepDoIt’ methods of the processes .

   • Update the value ‘safety’.

   • Invoke Invoke the method ‘PostStepDoItPrcs’ of the active discrete process.

   • Update the track length.

   • Send G4Step information to Hit/Dig if the volume is sensitive.

   • Invoke the user intervention process.

   • Return the value of the StepStatus.

Interaction with Physics Processes

The interaction of the tracking category with the physics processes is done in two stages by G4SteppingManager. The first stage is to find minimum step length demanded by active discrete and continues physics processes. Also to find the processes which will be invoked in the step. The second stage is to execute the selected processes by calling their DoIt methods. More details of the interaction are explained below.

The first stage of the interaction with the physics processes is to execute the private method DefinePhysicalStepLength() of G4SteppingManager. The general flow in this method is as follows:

• Obtain ‘maximum allowed step’ in the volume define by the user through G4UserLimits.

• The PostStepGetPhysicalInteractionLength methods of all active processes are called. Each process returns a step length and the process which proposed the minimum value is identified - sometimes this race of selection is called the GPIL (Get Physical Interaction Length) selection. The method also returns the G4ForceCondition flag which indicate if the process is forced for execution or not:

  • Forced : Corresponding PostStepDoIt is forced.

  • NotForced : Corresponding PostStepDoIt is not forced unless this process limits the step.

  • Conditionally : Only when AlongStepDoIt limits the step, corresponding PostStepDoIt is invoked.

  • ExclusivelyForced : Corresponding PostStepDoIt is exclusively forced.

• Then the AlongStepGetPhysicalInteractionLength methods of all active processes are called. Each process returns a step length and the process which proposed the minimum value is identified. This method also returns a fGPILSelection flag, to indicate if the process can join the race of selection:

  • CandidateForSelection: this process can be the winner. If its step length is the smallest, it will be the process defining the step

  • NotCandidateForSelection: this process cannot be the winner. Even if its step length is taken as the smallest, it will not be the process defining the step

The second stage of the interaction mentioned above is divided in three actions.

The first action is to invoke the AlongStepDoIt method of all processes by calling the private method InvokeAlongStepDoIts() of G4SteppingManager. The general flow in this method is as follows:

• If the current step is defined by a process which returned ‘ExclusivelyForced’, no AlongStepDoIt method will be invoked.

• Else, all the active continuous processes will be invoked, and they return the ParticleChange. Then the following actions are taken:

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

  • Apply the production cut to all created secondaries by invoking the private method ApplyProductionCut() of G4SteppingManager . Actions taken in this method are as follows:

    • Check if the kinetic energy of a secondary is smaller than the production threshold of the particle set in the material. If it is smaller, the kinetic energy is added to the total energy deposit of the parent track. Then the energy of the particle is assigned ‘zero’. 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). If the track has the flag IsGoodForTracking ‘true’, this check will have no effect (used mainly to track particles below threshold).

    • The parentID and the process pointer which created this track are set.

    • The secondary particle is added to the list of secondaries. If the particle has ‘zero’ kinetic energy, it is added only if it has a rest process to be invoked at the beginning of its tracking.

  • The track status is set according to what the process defined

The second action in the second stage is to invoke the method G4SteppingManager::InvokePostStepDoIts, which is in charge of calling the PostStepDoIt methods of all processes.

• Invoke the PostStepDoIt methods of the specified discrete processes (the ones selected by the PostStepGetPhysicalInteractionLength, and they return the ParticleChange. The order of invocation of processes is inverse to the order used for the GPIL selection. After the execution of all PostStepDoIt methods the following actions are taken:

  • Update PostStepPoint of the step according to ParticleChange.

  • Update G4Track according to ParticleChange after each PostStepDoIt.

  • Update safety after each invocation of PostStepDoIt.

  • The secondaries from ParticleChange are stored to SecondaryList.

  • Apply the production cut to all created secondaries by invoking the private method ApplyProductionCut() of G4SteppingManager . The details of this method is described in the previous paragraph of InvokeAlongStepDoIts() .

  • The track status is set according to what the process defined

The third action in the second stage is to invoke the method G4SteppingManager::InvokeAtRestDoIts. This invocation is done only if the track passed from the event manager has the status ‘fStopAndALive’. If this the case the two methods (InvokeAlongStepDoIts and InvokePostStepDoIts) mentioned above will not be executed. In the method ‘InvokeAtRestDoIts’ the selection is executed to find the rest process which has the shortest lifetime. After this selection, the corresponding rest process will be invoked:

• To select the process which has the shortest lifetime, the AtRestGPIL method of all active rest processes is called. Each process returns an lifetime and the minimum one is chosen. This method return also the G4ForceCondition flag, to indicate if the process is forced or not:

  • Forced : Corresponding AtRestDoIt is forced.

  • NotForced : Corresponding AtRestDoIt is not forced unless this process limits the step.

• Set the step length of current track and step to ‘zero’.

• Invoke the AtRestDoIt methods of rest processes selected in the above step. Each invocation returns the ParticleChange. The order of invocation of processes is inverse to the one used for the GPIL methods.

  Completing the previous step, the following actions are taken:

  • Set the current process as a process which defined this step length.

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

  • The secondaries from ParticleChange are stored to SecondaryList.

  • Apply the production cut to all created secondaries by invoking the private method ApplyProductionCut() of G4SteppingManager. The details of this method is described in the previous paragraph of InvokeAlongStepDoIts().

  • The track is updated and its status is set according to what the process defined

Ordering of Methods of Physics Processes

As shown in Fig. 4, ‘G4Track’ has ‘G4ParticleDefinition’ through ‘G4DynamicParticle’. The class ‘G4ParticleDefinition’ aggregates an object of ‘G4ProcessManager’ which has information of ordering of physics processes the particle undertakes. G4SteppingManager invokes the processes at each phase just following the process ordering given by the ProcessManager.

For some processes the order is important. Geant4 provides by default the right ordering. It is always possible for the user to choose the order of process invocations at the initial set up phase of Geant4. This default ordering is the following:

1. Ordering of GetPhysicalInteractionLength

   • In the loop of GetPhysicalInteractionLength of AlongStepDoIt, the transportation process has to be invoked at the end.

   • In the loop of GetPhysicalInteractionLength of AlongStepDoIt, the multiple scattering process has to be invoked just before the Transportation process.

2. Ordering of DoIts

   • Most cases ordering does not matter, though there are some exceptions. For example, the Cerenkov process needs the energy loss information of the current step for its DoIt invocation. Therefore, the EnergyLoss process has to be invoked before the Cerenkov process. This ordering is provided by the process manager. Energy loss information necessary for the Cerenkov process is passed using G4Step (or the static dE/dX table is used together with the step length information in G4Step to obtain the energy loss information).