|
Celeritas 0.7.0-dev.264+develop.12c52268
|
Offload to Celeritas via the per-particle Geant4 "tracking manager". More...
#include <TrackingManager.hh>
Public Member Functions | |
| TrackingManager (SharedParams const *params, LocalTransporter *local) | |
| Construct a tracking manager with data needed to offload to Celeritas. | |
| void | PreparePhysicsTable (G4ParticleDefinition const &) final |
| Prepare physics tables for this particle. | |
| void | BuildPhysicsTable (G4ParticleDefinition const &) final |
| Build physics tables for this particle. | |
| void | HandOverOneTrack (G4Track *aTrack) final |
| Offload the incoming track to Celeritas. | |
| void | FlushEvent () final |
| Complete processing of any buffered tracks. | |
| SharedParams const * | shared_params () const |
| Get the shared params associated with this TM. | |
| LocalTransporter * | local_transporter () const |
| Get the thread-local transporter. | |
Offload to Celeritas via the per-particle Geant4 "tracking manager".
Tracking managers are created by G4VUserPhysicsList::Construct during G4RunManager::Initialize on each thread. The tracking manager pointer is a thread-local part of the split-class data for a global G4Particle. This thread-local manager points to a corresponding thread-local transporter.
Because physics initialization also happens on the master MT thread, where no events are processed, a custom tracking manager also exists for that thread. In that case, the local transporter should be null.
SharedParams and LocalTransporter must have lifetimes that span multiple runs (which is the case for using global/thread-local). | celeritas::TrackingManager::TrackingManager | ( | SharedParams const * | params, |
| LocalTransporter * | local | ||
| ) |
Construct a tracking manager with data needed to offload to Celeritas.
|
final |
Build physics tables for this particle.
Messaged by the G4ParticleDefinition who stores us whenever cross-section tables have to be rebuilt (i.e. if new materials have been defined). An override is needed for Celeritas as it uses the particle's process manager and tables to initialize its own physics data for the particle, and this is disabled when a custom tracking manager is used. Note that this also means we could have filters in HandOverOneTrack to hand back the track to the general G4TrackingManager if matching a predicate(s).
The implementation follows that in G4VUserPhysicsList::BuildPhysicsTable , see also Geant4 Extended Example runAndEvent/RE07.
|
final |
Complete processing of any buffered tracks.
Note that this is called in G4EventManager::DoProcessing(G4Event*) after the after the main tracking loop has completed.
That is done to allow for models that may add "onload" particles back to Geant4.
Offload the incoming track to Celeritas.
This will not be called in the master thread of an MT run.
|
final |
Prepare physics tables for this particle.
Messaged by the G4ParticleDefinition who stores us whenever cross-section tables have to be rebuilt (i.e. if new materials have been defined). As with BuildPhysicsTable, we override this to ensure all Geant4 process/cross-section data is available for Celeritas to use.
The implementation follows that in G4VUserPhysicsList::PreparePhysicsTable , see also Geant4 Extended Example runAndEvent/RE07.