Message: Re: Setting Track Info for secondaries Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

Feedback Re: Setting Track Info for secondaries  

Forum: Event and Track Management
Re: Question Setting Track Info for secondaries (Nigel Hawkes)
Date: 26 Nov, 2013
From: Gumplinger Peter <Gumplinger Peter>

Hello Nigel,

Good points, all! I'll respond to what I can.

> I thought that the recently-added function
> G4Step::GetSecondaryInCurrentStep() would be just what I needed, but
> there are problems.
> This function returns a vector of pointers to const G4Track, so it's not
> easy to add an information object pointer via
> G4Track::SetUserInformation(). I'd be interested to know why the design
> was done this way, as the self-same track pointers are available in
> non-const form via the likes of G4Step::GetSecondary(), if you only knew
> which ones relate to the current step.

The idea was so user can't modify secondary tracks or add/remove tracks but your issue may have been an oversight. I'll confirm that the developer is aware of your posting.

You could use the GetfSecondary() as in:

This also shows you how to extract just the secondaries in the current step.

> So, following a suggestion from Tom Roberts in his reply "Re: Passing
> info to tracks" (12 Sep 2009), I set up a std::map to relate tracks to
> information objects. My first attempt used the track ID as key, but
> unfortunately this didn't work: the IDs in the tracks provided by
> GetSecondaryInCurrentStep() were all zero (when making the call from
> within ProcessHits(), at any rate).


> So in my next attempt I changed the map to use a pointer to const
> G4Track as key instead. This largely worked but with occasional
> surprises. It occurred to me that tracks are deleted during the
> processing of an event, and if an area of memory got re-used for a new
> track, the new track would magically acquire the information object from
> the old one.

As you found out, it is not a good idea to use the pointer to a G4Track as a key for your map.

> I'd be very grateful for your expert thoughts on:
> (1) Do people in fact just cast away const in order to force
> SetUserInformation() to work? (It would save a lot of trouble!)

Yes, you'll find code that uses const_cast even in the G4 examples, but it is not encouraged.

> (2) At what point do the many members of G4Track become valid? It would
> be useful if the ID were one of the early ones.

called from G4EventManager::DoProcessing()

> (3) Is there a way for the user to intervene at the moment a secondary
> is created, in order to (for example) implement routine copying of
> context-dependent information from parent to secondary?

Well, yes - but not exactly 'at the moment a secondary is created' because this happens inside processes.

You can implement ClassifyNewTrack in your StackingAction:


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

1 None: Re: Setting Track Info for secondaries   (Hisaya Kurashige - 26 Nov, 2013)
(_ Ok: Re: Setting Track Info for secondaries   (Nigel Hawkes - 27 Nov, 2013)
(_ Feedback: Re: Setting Track Info for secondaries   (Gumplinger Peter - 27 Nov, 2013)
(_ Feedback: Re: Setting Track Info for secondaries   (Nigel Hawkes - 28 Nov, 2013)
 Add Message Add Message
to: "Re: Setting Track Info for secondaries "

 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 ]