# How to get step/interaction time when using RDM?

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.

Thanks!

1 Like

does this post help?

@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?

1 Like

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

1 Like

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?

Thanks!