Tracking
The tracking category manages the contribution of the processes to the
evolution of a track's state and provides information in sensitive volumes
for hits and digitization.
Design Philosophy
It is well known that the overall performance of a detector
simulation depends critically on the CPU time spent
propagating the particle through one step. The most
important consideration in the object design of the tracking
category is maintaining high execution speed in the Geant4
simulation while utilizing the power of the object-oriented
approach.
An extreme approach to the particle tracking design would be
to integrate all functionalities required for the propagation
of a particle into a single class. This design approach looks
object-oriented because a particle in the real world
propagates by itself while interacting with the material
surrounding it. However, in terms of data hiding, which is
one of the most important ingredients in the object-oriented
approach, the design can be improved.
Combining all the necessary functionalities into a single
class exposes all the data attributes to a large number of
methods in the class. This is basically equivalent to using
a common block in Fortran.
Instead of the 'big-class' approach, a hierarchical design
was employed by Geant4. The hierarchical approach, which
includes inheritance and aggregation, enables large, complex
software systems to be designed in a structured way. The
simulation of a particle passing through matter is
a complex task involving particles, detector geometry, physics
interactions and hits in the detector. It is well-suited to
the hierarchical approach. The hierarchical design manages the
complexity of the tracking category by separating the system
into layers. Each layer may then be designed independently of
the others.
In order to maintain high-performance tracking, use of the
inheritance ('is-a' relation) hierarchy in the tracking category
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
shows a general overview of the
tracking design in Unified Modelling Language Notation.
G4TrackingManager is an interface
between the event and track categories and the tracking category.
It handles the message passing between the upper hierarchical object,
which is the event manager (G4EventManagerz),
and lower hierarchical objects in the tracking category.
G4TrackingManager is responsible for processing
one track which it receives from the event manager.
G4TrackingManager aggregates the pointers to
G4SteppingManager, G4Trajectory
and G4UserTrackingAction. It also has a 'use'
relation to G4Track.
G4SteppingManager plays an essential
role in particle tracking. It performs message passing to objects
in all categories related to particle transport, such as
geometry and physics processes. Its public method
Stepping() steers the stepping of the particle.
The algorithm employed in this method is basically the same as that
in Geant3. The Geant4 implementation, however, relies on the inheritance
hierarchy of the physics interactions. The hierarchical
design of the physics interactions enables the stepping
manager to handle them as abstract objects. Hence, the manager
is not concerned with concrete interaction objects such as
bremsstrahlung or pair creation. 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 also aggregates
the pointers to G4Navigator from the geometry
category, to the current G4Track, and
the list of secondaries from the current track
(through a G4TrackVector) to
G4UserSteppingAction and to
G4VSteppingVerbose.
It also has a 'use' relation to G4ProcessManager
and G4ParticleChange in the physics processes
class category.
G4Track - the class
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.
G4TrajectoryPoint and G4Trajectory -
the class G4TrajectoryPoint holds the state 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.
G4UserTrackingAction and G4UserSteppingAction -
G4UserTrackingAction is a base class from which user actions
at the beginning or end of tracking may be derived. Similarly,
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" from 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 processes.
The "TrackingManager" object delegates management of each of the
steps to the "SteppingManager" object. This object keeps all
information related to a particular step.
The public method ProcessOneTrack() in
G4TrackingManager
is the key to managing the tracking, while the public method
Stepping() is the key to managing one step. The algorithms
used in these methods are explained below.
ProcessOneTrack() in G4TrackingManager
Actions before tracking the particle: Clear secondary particle vector
Pre tracking user intervention process.
Construct a trajectory if it is requested
Give SteppingManager the pointer to the track which will be tracked
Inform beginning of tracking to physics processes
Track the particle Step-by-Step while it is alive
Call Stepping method of G4SteppingManager
Append a trajectory point to the trajectory object if it is requested
Post tracking user intervention process.
Destroy the trajectory if it was created
Stepping() in G4SteppingManager
Initialize current step
If particle is stopped, get the minimum life time from all the at rest
processes and invoke InvokeAtRestDoItProcs for the selected AtRest
processes
If particle is not stopped:
Invoke DefinePhysicalStepLength, that finds the minimum
step length demanded by the active processes
Invoke InvokeAlongStepDoItProcs
Update current track properties by taking into account all
changes by AlongStepDoIt
Update the safety
Invoke PostStepDoIt 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 ways. First each process can limit the step length
through one of its three GetPhysicalInteractionLength()
methods, AtRest, AlongStep, or PostStep. Second, for the selected processes
the DoIt (AtRest, AlongStep or PostStep) methods are invoked.
All this interaction is managed by the Stepping method of
G4SteppingManager. To calculate the step length, the
DefinePhysicalStepLength() method is called. The flow of
this method is the following:
Obtain maximum allowed Step in the volume define by the user
through G4UserLimits.
The PostStepGetPhysicalInteractionLength of all active processes
is called. Each process returns a step length and the minimum
one is chosen. This method also returns a G4ForceCondition flag,
to indicate if the process is forced 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.
All other DoIt including AlongStepDoIts are ignored.
The AlongStepGetPhysicalInteractionLength method of all active
processes is called. Each process returns a step length and the
minimum of these and the
This method also returns a fGPILSelection flag, to indicate if
the process is the selected one can be is forced or not:
= CandidateForSelection: this process can be the winner. If
its step length is the smallest, it will be the process
defining the step (the process
= 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 method G4SteppingManager::InvokeAlongStepDoIts()
is in charge of calling the AlongStepDoIt methods of the different
processes:
If the current step is defined by a 'ExclusivelyForced'
PostStepGetPhysicalInteractionLength, no AlongStepDoIt method will be invoked
Else, all the active continuous processes will be invoked, and they return
the ParticleChange. After it for each process the following is executed:
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
Then for each secondary:
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. 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 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
The track status is set according to what the process defined
The method G4SteppingManager::InvokePostStepDoIts is on
charge of calling the PostStepDoIt methods of the different processes.
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.
After it for each process the following is executed:
Update PostStepPoint of Step according to ParticleChange
Update G4Track according to ParticleChange after each PostStepDoIt
Update safety after each invocation of PostStepDoIts
The secondaries from ParticleChange are stored to SecondaryList
Then for each secondary:
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. 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 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
The track status is set according to what the process defined
The method G4SteppingManager::InvokeAtRestDoIts is called
instead of the three above methods in case the track status is
fStopAndALive. It is on charge of selecting
the rest process which has the shortest time before and then invoke it:
To select the process with shortest tiem, the AtRestGPIL method of all
active processes is called.
Each process returns an lifetime and the minimum one is chosen.
This method returm also a 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 0.
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.
After it for each process the following is executed:
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
Then for each secondary:
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.
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 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
The track is updated and its status is set according to what the process
defined
Ordering of Methods of Physics Processes
The ProcessManager of a particle is responsible for providing the
correct ordering of process invocations. G4SteppingManager
invokes the processes at each phase just following the order given
by the ProcessManager of the corresponding particle.
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:
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.
Ordering of DoIts
There is only some special cases. For example, the Cherenkov
process needs the energy loss information of the current step
for its DoIt invocation. Therefore, the EnergyLoss process has
to be invoked before the Cherenkov process. This ordering is
provided by the process manager. Energy loss information
necessary for the Cherenkov 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).
Any other?
[Status of this chapter]
Nov. 1998 created by K. Amako
10.06.02 partially re-written by D.H. Wright
14.11.02 updated and partially re-written by P. Arce
Dec. 2006 Converted from latex to Docbook by K. Amako