Get current track in a utility function?

[mkelsey]

I have a data processing class which is only passed the position and energy at the current step, not the full G4Step* or G4Track*. For debugging output, I’d like to report the current event and track IDs, but I wasn’t able to find clear guidance in the documentation for the second one.

I think the right answer is

const G4EventManager* evtMan = G4EventManager::GetEventManager();
const G4TrackingManager* trkMan = evtMan->GetTrackingManager();
G4int trackID = trkMan->GetTrack()->GetTrackID();

Is that correct?

[Munther_Hindi]

It is not clear from your question how or when your data processing class or function gets called. Typically, one assigns a logial volume of interest a sensitive detector (a class derived from G4VSensitiveDetector). At every step the method G4VSensitiveDetector::ProcessHits(G4Step * aStep, G4TouchableHistory *) is called. The track ID can then be obtained from

G4Track * aTrack = aStep->GetTrack()

[mkelsey]

Sorry, I’ll be more explicit. I have class we might call an “electrode”, which is attached to a volume via a SurfaceProperty (not an SD). In a separate Geant4 library (G4CMP), when the BorderSurface to which that SurfaceProperty is attached gets triggered, the value of the energy is extracted from the G4Track and passed into my utility class (G4CMPKaplanQP). At this point, the G4Step and G4Track pointers are no longer available.

For normal simulations, that’s fine. The energy passed in gets processed and the resulting information is returned and handled. But for debugging and diagnostic purposes, I would like to be able to report the TrackID that contributed the energy value to this call to G4CMPKaplanQP.

[Munther_Hindi]

I am not familiar with G4CMP. The point is an event can create multiple tracks, so which track the track manager gives you (trkMan->GetTrack()), depends at what point in the lifetime of the event your utility function gets called. If it is at the end of the event, then there will be no tracks left. If it is, as you say, when the track crosses the surface of the boundary, then probably the approach you outlined will work. You should probably test whether trkMan-GetTrack() is returning a null pointer first, thoguh.

[mkelsey]

Thank you!

@Munther_Hindi

I am not familiar with G4CMP.

No worries! It provides support for semiconductor and other solid-state processes (phonons and charge carriers) at very low energies. We use it with G4 to model the CDMS dark-matter detectors.

@Munther_Hindi

You should probably test whether trkMan-GetTrack() is returning a null pointer first, though.

Yes, Definitely! I wrote the above directly into my post as an example.

@Munther_Hindi

The point is an event can create multiple tracks, so which track the track manager gives you (trkMan->GetTrack()), depends at what point in the lifetime of the event your utility function gets called.

That’s how I understand it as well. Our function (G4CMPKaplanQP) gets called during particle tracking, several layers deep in a BoundaryProcess::PostStepDoIt() (enough layers that the G4Track* is not being passed from one to the next). If G4TrackingManager::GetTrack() is the right interface, then I’m happy. I just wish it were written down more clearly somewhere