I am interested in determining time of interactions relative to event’s start. I used GetGlobalTime in SteppingAction, but the reported times are too large to be believed (in micro seconds, attached). For instance, I am interested in knowing when electron has deposited energy relative to start. Am I doing something wrong? How can I obtain this right for each step for example?
This is what I use exactly in my Stepping Action: myRunAction->SetTime(aStep->GetPreStepPoint()->GetGlobalTime()/CLHEP::microsecond);
Note: I do understand that a histogram of GetGlobalTime for large number of events give me an exponential decay with half-life for that ion.
@weller: Thanks, so I see that’s relative to start of each track! Can I also compare the absolute time difference between two steps belonging to different tracks? I just tried a simple case exporting GetLocalTime() at each step as you suggested:
For example, for the attached case, imagine that I would like to determine the time difference of steps where 0.51354 and 0.03301 keV is deposited, which belong to separate tracks.
I can deduce that trk-14,stp-2,EDep-0.3301 happens at (3.68306E-6 + 3.9905E-6) us since the start of trk-14. Similarly, trk-15,stp-2,EDep-0.51354 happens at (1.21324E-6 + 1.93752E-6) us since the start of trk-15. But how do I know the relative start of trk-14 w.r.t trk-15 to get the absolute difference of 0.51354 and 0.3301 steps?
i don’t think you would add up the localTime, the numbers look already steadily increasing to me, plus it is supposed to be the elapsed time since start of that track.
careful with pinpointing the deposition to discrete timeslots, as a) multiple coulomb scattering events are simulated as one single step, and b) geometry boundary crossings will always terminate a step.
both track 14 and 15 in your example have parentID = 1. if they are created simultaneously, the local time should be synchronized. if not, you might want to compare global times of those two steps with stepID = 1, the difference would be the relative offset.
edit: why do you consider the global time suspiciously large in your opening post? the event starts with the ion waiting to decay, and this happens on the timescale of the half life as you point out yourself. the subsequent localtimes of the decay products tracks are much shorter apparently
When I use the global time, I get a number based on the half life which is 11.8 days for Xe-131m example above. In this case it is 2.32379E11 (see top row of the picture above). So, with GetGlobalTime I see the same number (2.32379E11) for every step/entry; likely because the step/interaction time is so small/insignificant compared to 2.32379E11. Can this be mitigated somehow?
Is it possible to reset the time at the start of each event, such that every entry spits out time relative to that (zero) start of the event, which is independent of whether it is a new track?
