MCTrack
Just to make sure I don't get bored!
Description
It might be useful to introduce the concept of a MCTrack. MCTracks should carry the information a G4Track has when it is created and when it terminates. I.e.
- at which spatial position
- in which G4PhysicalVolume (creation)
- what was the G4CreatorProcess - name & type
- energy
- custom track ID
- link to parent
- (link to children)
Proposal
The proposed featured build atop of !125 (merged). I have a dirty implementation which merely exploits static functions of AllpixG4TrackInfo
- which I know is bad design for now. I would propose we take it as a starting point to see if this feature is wanted and useful, try to estimate the impact, etc. I will open a merge request soon. Let me try to describe how it works:
- Introduced the
MCTrack
class - The
AllpixG4TrackInfo
is expanded to also carry aunique_ptr<MCTrack>
- The
UserHookSetUniqueTrackID::PreUserTrackingAction
will set the corresponding fields for the initial state - If any
SensitiveDetectorActionG4::ProcessHits
sees the track, it will be registered (via a static function) to be stored - The
UserHookSetUniqueTrackID::PostUserTrackingAction
will set the corresponding fields for the final state, it will also trigger the ownership transfer of theMCTrack
object - aAllpixG4TrackInfo
global object will hold ownership if the track was set to be stored, and discard it if not - When the
AllpixG4TrackInfo::reset()
is called, all the soredMCTrack
s are dispatched via the Messenger
If you approve of the idea, my suggestion would be to introduce something like a track manager class to actually take over the tasks which are now hacked into it by static functions. The track manager would be owned by the DepositionGeant4Module
,
every SensitiveDetectorActionG4
would know it so it can register tracks to be stored. The track manager itself would take ownership of the MCTrack
s once they are terminated and would hold a ptr to the Messenger
of the DepositionGeant4Module
so it can dispatch the track messages.
Links / references
Will update...
Use cases
- secondary vertices
- energy (loss) of tracked particle
- creation process
E.g. secondary tracks can be easily seperated from delta tracks without any ambiguity, the full hierarchy can be made available
Feature checklist
Make sure these are completed before closing the issue, with a link to the relevant commit.
-
Is the feature wanted? -
Agree on implementation -
MCTrack implementation -
Track manager class -
Test performance impact -
Validate