celeritas::TrackingManagerOffload Class Reference

Offload tracks to Celeritas via the per-particle G4VTrackingManager interface. More...

#include <TrackingManagerOffload.hh>

Inheritance diagram for celeritas::TrackingManagerOffload:

Public Member Functions
	TrackingManagerOffload (SharedParams const *params, LocalTransporter *local)
	Construct a tracking manager with data needed to offload to Celeritas. More...
void	PreparePhysicsTable (G4ParticleDefinition const &) final
	Prepare physics tables for this particle. More...
void	BuildPhysicsTable (G4ParticleDefinition const &) final
	Build physics tables for this particle. More...
void	HandOverOneTrack (G4Track *aTrack) final
	Offload the incoming track to Celeritas.
void	FlushEvent () final
	Complete processing of any buffered tracks. More...

Detailed Description

Offload tracks to Celeritas via the per-particle G4VTrackingManager interface.

Constructor & Destructor Documentation

TrackingManagerOffload()

celeritas::TrackingManagerOffload::TrackingManagerOffload	(	SharedParams const *	params,
		LocalTransporter *	local
	)

Construct a tracking manager with data needed to offload to Celeritas.

TODO: Clarify thread-locality. Construction/addition to G4ParticleDefinition appears to take place on the master thread, typically in the ConstructProcess method, but the tracking manager pointer is part of the split-class data for the particle. It's observed that different threads have distinct pointers to a LocalTransporter instance, and that these match those of the global thread-local instances in test problems.

Member Function Documentation

BuildPhysicsTable()

void celeritas::TrackingManagerOffload::BuildPhysicsTable ( G4ParticleDefinition const &  part )

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.

FlushEvent()

void celeritas::TrackingManagerOffload::FlushEvent ( )

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.

PreparePhysicsTable()

void celeritas::TrackingManagerOffload::PreparePhysicsTable ( G4ParticleDefinition const &  part )

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.

---

The documentation for this class was generated from the following files:

• TrackingManagerOffload.hh
• TrackingManagerOffload.cc