TrackID of Secondaries in a Step (GetSecondaryInCurrentStep)

Hi,

Is it possible to find the track ID of secondary tracks from a current step? It seems the collection returned by GetSecondaryInCurrentStep have not yet been processed by the track manager. I’m curious if there is a simpler method to connect parent track to child tracks (the current connection seems to be child track to parent tracks) than doing a comparison to my unlabelled child tracks in stacking action.

Relatedly, could I rely on the order of tracks in the secondaries vector returned to keep an internal counter that would be synchronized with the track ID?

Thanks,

1 Like

Hi. I am with the same issue. I want to find the energy of the parent particle when it produces my secondary, but I saw that the IDs are just assigned later and so I can not keep them. Waiting for updates in the topic.

I don’t know if this works for you, gdvgarcia, but I think since the track stack is a LIFO, I can keep a count of all secondaries myself in my UserSteppingAction class. I’m not sure if there are any exceptions to this, so I’m thinking about running some tests.

As an alternative, I would like to know if it is possible to access the stack manager from the stepping action. Then you would know the number of tracks in each stack, and could easily infer the IDs of new tracks.

The exception would be for processes which put the track into a Suspended state, so that the newly created secondaries are immediately tracked. This is done to reduce the memory burden of the stacked tracks. For instances, the optical processes which generate optical photons, such as Cherenkov and Scintillation, do this.

I’m having a related issue… I want to keep track of information about the step that created the secondaries. Right now pretty much all information is kept by the RunAction indexed by TrackID.
However,

auto secondaries = currentStep->GetSecondaryInCurrentStep();
    for (auto sec : *secondaries){
        G4cout << sec->GetTrackID() << G4endl; 
    }

will only ever give me 0 for the reasons described by @cowden . So that doesn’t work here.
Have you figured out yet to to get that future track id?