|Message: Re: Trying to reset global time||Not Logged In (login)|
Click on the Forum title, e.g. on the "Forums by Category" page, to read a sequence of postings to the Forum and its threads all in one page. If you are only interested in one thread or the thread following a specific posting, click the thread or the posting, which takes you to a smaller page, which contains only the part you are interested in and may be easier to navigate.
Messages are "chained" if there are only replies at the first level, i.e. 1/1.html, 1/1/1.html etc. In case of "chained" messages the message number is replaced by the icon and there is no indentation.
Inline: Display the subject line only or also the text of the posting(s); for the choice "All" the "Outline" choices are switched off.
|1||0||1||no text / full text of posting|
|2||1||All||text for level 1 only / text for All postings|
Outline: Choose the depth of the posting thread, successive toggle controls provide increasing detail.
|1||2||1||2 levels / 1 level (original posting)|
|2||3||2||3 levels / 2 levels|
|3||3||All||3 levels / all levels (all postings)|
Yours is a real interesting problem. I don't understand why you want to set the time to zero at some point during the simulation when a radioactive decay happens in order to find coincident pulses. Still, I found it once very useful to reset the simulation time because I wanted to simulate the same TDC time-stamp as in the experiment. In my case, the simulation time started with a beam particle. In the experiment, time only started when there was a trigger. Of course, one solution is to keep the trigger time and later calculate all pulses' times relative to that trigger time. I thought it was "easier" to just reset the simulation time. My experience was in Geant3. I have never done this in Geant4.
It doesn't look to be 'easy' (and I hope an expert will correct me).
> From ProcessHits in my Tracker, I'm > using this to do the reset: > > G4double reset = 0.0*second; > aStep->GetTrack()->SetGlobalTime(reset); > > This only works the one individual track though. Why do tracks that > follow this still have the original track time?
Exactly, these other tracks already are on the stack when you set the time for the current track. Any secondaries this current track will produce after your SetGlobalTime will have times relative to your reset. Not so, secondary tracks that have already been created by this track and are sitting on the stack. You need to set their time also. And that's what is 'difficult'.
> When I call the reset > after the first gamma ray interaction in my detector, all the electrons > generated by the interaction retain the reset track time. Why the > difference?
These gammas are produced after your SetGlobalTime, see above.
Now, how can we reset the time for tracks on the stack. The only solution I came up with is via a remodeled ClassifyNewTrack method of G4UserStackingAction. First, you have to send the time at which you reset to your G4UserStackingAction:
G4double trigger = aStep->GetTrack()->GetGlobalTime();
(you add a private member 'G4double trigger' to your G4UserSteppingAction and the corresponding SetTrigger method). You also have to set this private trigger back to zero in PrepareNewEvent().
You then code (in ProcessHits):
G4double reset = 0.0*second; aStep->GetTrack()->SetGlobalTime(reset);
ReClassify will now in turn call your ClassifyNewTracks method for each track on the stack. In your ClassifyNewTrack method you code:
aTrack->SetGlobalTime(aTrack->GetGlobalTime() - trigger);
This won't work right away because:
ClassifyNewTrack(const G4Track* aTrack)
so you have to strip the constness first.
As an alternative, you can write code that duplicates the ReClassify method (in your ProcessHits) for the most part - and you'll have to get a handle on the urgent stack.
It just occurred to me that you can also employ: PreUserTrackingAction. This is called for every track about to be tracked. Again, you have to communicate the trigger time and reset at the beginning of an event. But it also needs a const_cast.
There is still the issue that your earlier hits will have times that are not synchronized with 'reset'. I hope you don't have any earlier hits in your event because resetting times in hits already in the hits-collection is yet another can of worms.
|Inline Depth:||Outline Depth:||Add message:|