Getting time of decay

Hi all,

I have a simple test geometry of neutrons trapped within a box and want to record the time at which they decay. Currently, I’m going about it by checking in the stepping action whether a particle is a neutron or not, killing the track if not and recording that time as the decay time.

This result agrees reasonably well with the expected neutron lifetime, but I’m wondering if there’s a less ad-hoc way to get the time at which a decay occurs? Particularly since checking every step if a particle is a neutron is probably running up the computation time.

Thank you!

Checking at each step is fine. Geant4 doesn’t do a “time based” simulation – it works in “trajectory space”, computing interaction lengths for moving particles, and using the particle’s velocity and distance to set a timestamp for each step.

In your case, I guess you’ve placed your neutrons in the box at rest? In that case, Geant4 should decay them automatically, based on the lifetime that is set in the G4Neutron constructor.

What you can do in your stepping action, or in an SD attached to the box, is test the G4Step to see whether (a) the track is a neutron, and (b) does it have secondaries?

You can do (a) very fast if you test the pointer rather than the name string:

    static const G4ParticleDefinition* neutron = G4Neutron::Definition();
    if (aStep->GetTrack()->GetParticleDefiniton() != neutron) return;

You can do (b) very fast by asking if the secondaries vector is empty:

   if (!aStep->GetSecondary() || aStep->GetSecondary().empty()) return;

After these, you can tell G4 to kill the secondaries and then you don’t have to worry about tracking them:

   aStep->GetTrack()->SetTrackStatus(fKillTrackAndSecondaries);

and then get the lifetime from aStep->GetPostStepPoint()->GetLocalTime(); (the time since the track was created).

2 Likes

Thank you for the reply!

I’ve been checking for neutrons like so already, but that method for killing secondaries is quite handy!

The neutrons actually have some small (~100 neV) kinetic energy and I have a Fermi potential for the material defined, so they can bounce around within the volume. My hope was to use the times to record how long neutrons remain in the volume before being lost to decay vs absorption vs etc, which I think is quite doable now.

A follow-up question I have, though, is whether it’s possible to output which process “ended” a particle’s track: in this case due to it decaying or instead its absorption. My thought was to implement a tracking action and fiddle with that–can that sort of thing be done with PostUserTrackingAction?

Thanks a bunch!

1 Like

You should be able to use aStep->GetPostStepPoint()->GetProcessDefinedStep() right in your SD or SteppingAction to find out which DiscreteProcess caused the step to be ended. I’m not 100% certain that it will show G4Decay for neutron decays at rest (just because I’ve never tried), but it should. Once you get that pointer, make sure it’s not null and then you can do things like GetProcessName() and store it into your n-tuple.

2 Likes

You are right. The best place to do this kind of things is PostUserTrackingAction.
You may have a look in examples/extended/radioactivedecay/rdecay01

1 Like

Thank you both! Using this in either the stepping action or tracking action works perfectly, and does indeed display ‘Decay’ as the process for neutrons lost to decay.

Hi, Everyone,
I hope this message finds you well.

I am currently working on an optical simulation using Geant4 (version 4.11). In my setup, I am irradiating a LYSO scintillation crystal with 511 keV gamma photons, which generates optical photons. These optical photons are subsequently detected by a silicon-based SiPM. During the simulation, I am tracking several parameters, including energy deposit, wavelength, global time, and local time.

My focus is on analyzing the global time to extract both the decay and rise times by applying a bi-exponential fit. However, I am encountering some challenges with the fitting process. Specifically, the chi-squared value of the fit is excessively large, and the second rise time appears to be shorter than the first.

I am attaching reference images that illustrate the expected data, as well as my current output for your review. Any advice or suggestions on resolving these issues would be greatly appreciated.

Thank you in advance, and I look forward to your responses.
Screenshot from 2024-10-24 11-04-34
Output image below.

Please do not revive old threads, especially when it has nothing to do with the original topic - new threads are more than welcome!