Use Cases

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

• 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 to logical-volumes.
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.

Solution:

• Material scanning is not performed if the region is attached to a parallel world;
• The presence or not of an attached G4FastSimulationManager can help in distinguishing the cases.

Design diagrams & descriptions:

• The class diagram for the G4TransportationManager foresees a central place where navigators (included tracking navigator) are registered and retrieved.
• 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:
    1. Create a parallel geometry;
    2. Instantiate the process, specifying the name of the parallel world;
    3. 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:
    • virtual G4VProcess::StartTracking(const G4Track*)
    The default implementation in G4VProcess will call StartTracking().
• 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 three...).
  • One navigator is associated to one active world; more than one world can be considered by the same navigator and can be activated/deactivated.
• 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 owning touchable-handles.
  • Handles are created by the navigator associated to the world they refer to.
  • The G4[Coupled]Transportation calls all the 'moving' processes.
• The G4PropagatorInField must be aware of the existance of the multiple navigators:
  • 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:
  • using their own geoemtry
  • using the mass geoemtry (shared with transportation)
  • using used a geometry shared with some other processes
  A potential revision when another process and transportation share the geometry, the path-finder returns kShareTransport for steps limited by the mass geometry.
• 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.
  Responsibilities:
  • 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 ?
  • Return an instance of a new class G4DummyParticleChange which does nothing;
  • or, return 0 pointer and have the stepping-manager checking for this !
  Another case for unchanged particle-change is for processes whose cross-section is approximated as constant.

• 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 surfaces (MV)
• New test to be done with simple physics and combining use of scoring, fast-simulation and biasing (MA)

1. G4PathHelper interface ready (JA)
   • by February 28^th, 2008
2. Additions to G4TransportationManager (GC)
   • by February 28^th, 2008
3. Modifications to G4ProcessManager (HK)
   • by February 28^th, 2008
4. Test for G4PathHelper completed (MV)
   • by March 15^th, 2008