Navigation in parallel geometries
- Fast simulation and shower parameterisation
- Geometric importance biasing
- Scoring and tallies (fluxes and doses)
- Readout geometry (?)
- Parallel tracking geometries (support structures) (?)
Parallel navigation is possible for the case of fast-simulation and
importance-biasing. Both allow for tracking in either the tracking
(mass) geometry or parallel (ghost) geometry (superimposed to the
tracking one). Independent navigators are defined and associated to
specialised processes regularly registered to the G4ProcessManager.
In the case of fast-simulation, more than one geometry can in principle
be assigned to the same navigator.
Limitations in the old approach:
The design proposal documented here allows to overcome the limitations above
and provide a generic and universal way for handling navigation in parallel
geometries, where more than one navigator (and geometry) can be invoked
and centrally controlled such that the final evaluation of the step to
take (including eventually integration in field) is made taking into
account the existance [or not] of specialised processes applied [or
not] to parallel geometries.
Fast simulation envelopes
- Could not be applied in presence of magnetic-field (field applied
only to the tracking geometry and main navigation)
- Could not be applied in concurrent manner (problems of mutual
competition and with G4Transportation)
The first step which is sort of independent from the realization of a
parallel navigation scheme, but is required in order to assure the
consistency with some aspects of the existing design, has been to "merge" the
concept of 'envelopes' used in fast-simulation and 'regions' associated
A G4Region could be easily extended to cover also the concept of an
'envelope', the result is mainly an implementation detail which
requires adapting the mechanism for the scanning of the
materials to consider the case of the existance of logical-volumes with
NULL material pointer assigned.
- Material scanning is not performed if the region is attached to a
- The presence or not of an attached G4FastSimulationManager
can help in distinguishing the cases.
Design diagrams & descriptions:
Notes & considerations:
- The class diagram for the
G4TransportationManager foresees a central place where
navigators (included tracking navigator) are registered and
- The class diagram for the
G4PathFinder includes a ''special'' class
G4MultiNavigator which inherits from G4Navigator in
order to be used seamlessly as a navigator object by
G4PropagatorInField and distinguish the cases where only one
tracking navigator is in use (the most common situation) and when
more than one navigator associated to multiple geometries exist.
- Scenario diagram for the user's
initialisation: creation of parallel geometry and
auto-generation of the parallel world.
- Creation of the navigators should not be exposed to the user;
- Navigators are created and registered at the time the parallel
geometry is created and registered;
- Steps for the user are the following:
- Create a parallel geometry;
- Instantiate the process, specifying the name of the parallel
- Assign the process to particles.
- The creation of the world-volumes should be delegated to an utility
which will assure that the created world is consistent with the
mass-geometry's one (same size, same solid, no material assigned,
...). The G4TransportationManager must provide a way to
return a navigator, given a pointer to a registered world, or
given a string indicating the name of the world volume:
- G4TransportationManager::GetNavigator(G4VPhysicalVolume* world)
- G4TransportationManager::GetNavigator(const G4String& worldName)
- A process cannot have more than one navigator.
- Scenario diagram for the system
initialisation from G4TrackingManager and interaction
among the specialised processes.
- G4VProcess has been extended to add a new
signature as virtual method:
The default implementation in G4VProcess will call
- virtual G4VProcess::StartTracking(const G4Track*)
- Scenario diagram of G4SteppingManager
and relevant interaction among the specialised processes.
- Status at the ghost/dual boundary: how to deal with first/last step
in a volume ?
- The presence of a pointer to G4VProcess limiting the
step in G4StepPoint is not enough.
- More than one parallel worlds should be allowed (rarely more than
- One navigator is associated to one active world; more than one
world can be considered by the same navigator and can be
- The G4TransportationManager must own the different navigators:
- Navigators can be collected in a std::vector and can be
associated with an "activation" flag as data-member.
- G4Navigator has been extended adding the
activation flag and accessor/modifier for it.
- The transportation-manager should keep track of the number of times
a navigator has been activated.
- Specialised processes (biasing, fast-parameterisation, ...) are
- Handles are created by the navigator associated to the world they
- The G4[Coupled]Transportation calls all the 'moving'
- The G4PropagatorInField must be aware of the existance of the
- It is responsible in handling the integration in the field taking
into account of their existance;
- G4TransportationManager can be used as helper class and a
"multi-navigator" entity ("G4MultiNavigator") can be
considered for dealing with this.
- The G4PathFinder will be called by each process owning a
touchable-handles, and will compute the curved path and intersections
with each geometry. It will return to each of the processes the value
of the step in that geometry (if limited the step) or an identifiable
value (enum), if didn't limit the step; otherwise, if a process gets
a reasonable distance from the G4PathFinder, this process is
one of the processes limiting the step and therefore it should return
"Forced" flag, so that more than one process will be invoked
if each is limiting the step simultaneously.
- Treatment of parallel geometries at boundaries in the case of optical
processes needs to be understood (zero-step length currently done at
boundary ?!) !
- Optionally an additional status for parallel geometries can be
considered in order to distiguish them from the mass geometry,
where treatment at boundaries is done by optical processes.
- The specialised process for tallies must apply its
DoIt() after all physics processes and must limit the step
(along) after all physics processes. A solution is to give a different
order in 'along' and 'post' step-DoIt().
- G4[Coupled]Transportation should limit the step ONLY for the
mass geometry. It is also responsible for calling InactivateAll()
from G4TransportationManager at the end !
- Processes need to distinguish parallel world and mass geometry such that
they do not interfere with transportation when parallel and mass worlds
are coincident (i.e. use of kShareTransport flag!).
- Processes should be written without change when:
A potential revision when another process and transportation share the
geometry, the path-finder returns kShareTransport for steps
limited by the mass geometry.
- using their own geoemtry
- using the mass geoemtry (shared with transportation)
- using used a geometry shared with some other processes
- The scoring process is strongly forced (even if particle is
killed), therefore it is not a candidate for selection.
- Can a process call G4PathFinder::ComputeStep() in the
PostStepGPIL ? The current known challenge is that the PostStepGPIL
cannot return the Safety; to cope with this, transportation already
returns full Safety for all the geometries.
- Should each process call PrepareNewTrack() ? It has been
decided to revise the process ordering in PrepareNewTrack()
of G4ProcessManager such that transportation will be the
last process to invoke it.
- A new ''helper'' class (G4PathHelper or G4PathGuide...)
is foreseen for easily determining the location of the particles on the
boundary, therefore avoiding code duplication in several areas.
The class will be placed inside the module processes/management;
each process other than transportation dealing with the geometry should
own a pointer to an instance of such class.
- communicate with path-finder to limit the step
- create touchable and retrieve the current volume
- eventually, copy the Step (?)
- should work also in case of a single world
- As in several cases the particle-change is meant to affect NO change,
can we make this quicker and simpler ?
Another case for unchanged particle-change is for processes whose
cross-section is approximated as constant.
- Return an instance of a new class G4DummyParticleChange
which does nothing;
- or, return 0 pointer and have the stepping-manager
checking for this !
- exampleN02 (transportation vs coupled-transportation)
- water-box (RE03)
- exampleN05 (one particle, fast-simulation in mass or parallel geometry
- exampleN07 (scoring)
- exampleB02 (importance biasing)
- New test like N05 to be done with less physics ad use of shared
- New test to be done with simple physics and combining use of scoring,
fast-simulation and biasing (MA)
- G4PathHelper interface ready (JA)
- Additions to G4TransportationManager (GC)
- Modifications to G4ProcessManager (HK)
- Test for G4PathHelper completed (MV)
v.3.0, GC - Friday, 1 February 2008