Message: Re: Relation between physical particles and G4Tracks Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

Warning Re: Relation between physical particles and G4Tracks 

Forum: Event and Track Management
Re: None Relation between physical particles and G4Tracks (Erik Dietz-Laursonn)
Re: Question Re: Relation between physical particles and G4Tracks (Marcus O'Flaherty)
Date: 02 Dec, 2015
From: Marcus O'Flaherty <Marcus O'Flaherty>

Hi Peter, thanks for your input. I do have a G4VTrajectory class derived as in your example, and as you say it is my own code that defines the typedef for points container and creates new points containers as appropriate in the constructors. It also uses the push_back mechanism in AppendStep(), which I have to admit wouldn't appear to tie up with my theory. However, I don't see how this alone could cause my observed behaviour: the constructor does indeed create new points containers, but when a track is found to have user information in the PreUserTrackingAction, no constructor is called - the pointer to the previous trajectory is merely passed on. push_back is then the only function that accesses the points container, and should only ever append to it (which is not the behaviour I'm seeing).

However! Your second link though is very interesting. It looks like the Event Manager is doing some fiddling in the background, presumably to implement the normal step accumulation behaviour in Tracks (as previously discussed in this thread).

From what I can tell, the ProcessOneEvent() method of the G4EventManager:

1) retrieves a pointer to the trajectory for the previously processed track (lines 171-173) (I assume this excludes optical photons)

2) processes the track, calling PreUserTrackingAction and then PostUserTrackingAction in the ProcessOneTrack() method (line 185)

3) Retrieves a pointer to the trajectory used by the Tracking Manager for the processing of the track (line 200) and merges it with the previous trajectory! This would amount to merging with itself if the pointer is passed forward?! (line 204) I'm also not sure how this distinguishes unique tracks, as they would not want to be merged...

4) Deletes the trajectory used by the Tracking Manager! In my case there is only one Trajectory, so this would delete it!

5) Moves the pointer given to the Tracking Manager to point at the previous trajectory (now merged, so in theory containing the new points). In my case, the Trajectory given to the Tracking Manager is the same, so this would just move it to itself (although this has now been deleted in 4... )

So it looks like the event manager is doing a whole lot with trajectories outside of what's visible within my own classes & methods. I'm still not sure this makes sense with my observations, as it would appear to delete the trajectory! This would cause ALL points (and any other information) to vanish at the end of tracking, but that doesn't seem to be the case.

It would also suggest that my implementation in this case may not even be necessary - trajectories are automatically merged for new tracks. But again, this doesn't seem to be the behaviour I observe, and I'm also aware that for some inelastic collisions the Track is NOT preserved, even when I want it to be. So manual pass-over of trajectories would still be necessary.

All in all, very informative, but raises about as many questions as it answers!

Inline Depth:
 1 1
 All All
Outline Depth:
 1 1
 2 2
 All All
Add message: (add)

1 Ok: Re: Relation between physical particles and G4Tracks   (Marcus O'Flaherty - 04 Dec, 2015)
2 Ok: Re: Relation between physical particles and G4Tracks   (Marcus O'Flaherty - 04 Dec, 2015)
 Add Message Add Message
to: "Re: Relation between physical particles and G4Tracks"

 Subscribe Subscribe

This site runs SLAC HyperNews version 1.11-slac-98, derived from the original HyperNews


[ Geant 4 Home | Geant 4 HyperNews | Search | Request New Forum | Feedback ]