Add reconstructed hit/track/step properties required by ATLAS SDs

[sethrj]

Besides the serious continuity issue of https://github.com/celeritas-project/celeritas/issues/1503, there are several things the ATLAS tallies query from the tracks. We also need to determine what capabilities are needed for production runs.

SimulationEnergies::classify, used by [...?]:

• step->GetPostStepPoint()->GetProcessDefinedStep() selects EM vs non-EM process; we could fake this
• track->GetTrackStatus() for classifying energy loss
• Low-level hack to get the secondaries and loop through them
• track->GetNextVolume() to tell whether the particle has escaped

BLMSensorSD::ProcessHits

• Logical volume of the secondary's "vertex" (where it was emitted from a primary)

Additional Geant4 data requirements used by non-SD parts (TODO: move to separate issue)

• Russian roulette for photons needs the LV where a track was created
• Trajectory for MC truth: we could try to postprocess but I think it'd be much better to hook into the user code at a lower level since the G4 trajectory code is ... suspect
• There's also a custom process that only applies in one region, and is applied at every step (easy for us, hard for adept/g4hepem!)

Required by #1144

[esseivaju]

Reported by @mnovak42 in the internal ATLAS jira ticket:

I have recently integrated the HepEmTrackingManager in Athena such that it can be used so simulate e-/e+ and gamma in the entire ATLAS detector (and producing very nice full physics validation results). There were a set of issues that I had to handle to provide all functionalities and information that are required by an Athena simulation. As AdePT/celeritas will also face these problems I thought it might be good to share them:

1. Some are related to information that SD codes require (beyond what we already give): LogicalVolumeAtVertex information required by the BCM/BLMSensor SD codes (see e.g. https://gitlab.cern.ch/atlas/athena/-/blob/main/InnerDetector/InDetG4/BLM_G4_SD/src/BLMSensorSD.cxx#L96) (implemented in HepEm https://github.com/mnovak42/g4hepem/commit/b3dc506679424e0814c67b75612863bd25e44aba) OriginTouchableHandle need to be set as required by the AthenaTrackingAction to check if the gamma is from the lAr when playing RR (see https://gitlab.cern.ch/atlas/athena/-/blob/main/Simulation/G4Utilities/G4UserActions/src/AthenaStackingAction.cxx#L96) (implemented in HepEm https://github.com/mnovak42/g4hepem/commit/80340477d82b82fda678edf67c7081e5c7ba88f3#diff-a23364e1174bae24096eeb9dded4634bbdbe34820194019d04da91a4cd869af0R167)

These are relatively easy to provide, if stored during the device side stepping, before calling the SD codes. However, some like playing RR with photons needs to be done on the device as no much sense to do after the tracking is already completed anyway on the device (or should be probably better not to do at all on the device).

2. Some will be more complicated with AdePT/Celeritas that requires to store trajectory from the PreUserTrackingAction like the AthenaTrackingAction/MCTruthUserAction. (see e.g. https://gitlab.cern.ch/atlas/athena/-/blob/main/Simulation/ISF/ISF_Geant4/ISF_Geant4Tools/src/MCTruthUserAction.cxx#L60) To do this in general will be more complicated as: you need to know (in general) before start tracking a track if that condition is true it might happen not only inside sensitive volumes (probably) assumes time ordered information

(was of course easy to add this to HepEm https://github.com/mnovak42/g4hepem/commit/d3a6a008c1bf2be0be5b9591144195ce792bcb7a)

All actions and SD codes that assume sequential, continues and time order stepping might cause problem.

3. There are some special processes for e-/e+ and gamma that needs to be considered beyond that standard EM: Geant4 fastSimulation process is attached to them inside Athena (used in the FCal) an Atlas specific transition radiation process (available only inside Athena TRTTransitionRadiation) is attached to e-/e+ used in some volumes of the TRT

While implementing these into the HepEm stepping loop was relatively easy, these will be complicated for AdePT/celeritas This because for a general implementation the triggering conditions should be checked before each simulation steps for fast simulation while the XTR process should be invoked after each e-/e+ steps inside the TRT (when the step is done in some radiator volumes). So the best solution would probably not to use AdePT/Celeritas in the TRT and FCal. I will also give some suggestions, possible improvements inside Athena regarding the TRTTransitionRadiation process

and TRT SD code (that should not change the simulation output but making it more robust and efficient).

[sethrj]

Thanks @esseivaju for the forward (and thanks @mnovak42 for the difficult footwork!) It looks like there's only one SD requirement there, the LV from the vertex; the other requirements can be addressed later. It would be worthwhile to try to partner with ATLAS to refactor their TRT radiation code so that we could try to reuse it on GPU.