During an event, is it possible to find a G4Track instance by the trackID during that event?
No. Generally speaking, tracks are transient objects. They are created and stacked in a buffer (e.g., when a process creates a secondary), and when the particle is stopped-and-killed, the G4Track object is deleted from memory.
Using find on the entire contents of $G4INCLUDE, there is no interface anywhere which returns a G4Track* based on its assigned ID. The underlying G4TrackStack objects are not accessible to any code. They are private data members of G4StackManager, which means not even a custom subclass can get to them for inspection or query.
So when processing the tracks/steps of secondaries, the primaries might have already been deleted, so it’s impossible to step back through the tracking history? That means I have to pre-emptively cache the parent particles, if I need their information later. OK, thanks.
1 Like
Yes, that’s exactly right.
My own experiment had this issue with wanting to hold onto radioactive decay chains. We use the SteppingAction to identify tracks decayed by RDM, and store the track and its daughters into a HitsCollection with a “track level” G4VHitData container. We write that collection out to our ROOT file, along with the real detector hits, and can correlate the entries by way of the track ID in both TTrees.
I think Mike full explain how to save simulation histories, so this thread may be closed