I tried to do a simulation of Rn222 decay chain (stopped at Pb210) and I notice an issue with which tracks are assigned to which subevent after each decay.
For instance, when an alpha decay occurs, the daughter nuclear recoil and the alpha emitted tracks are not inside the same subevent. The nuclear recoil is in the subevent of its decay instead of the decay where it is generated.
See for example:

the difference in time between the trackID 2 (3.12 ks) and trackID 751 (3.14ks) is afterwards problematic when passing to raw signal stages where it triggers the first and the former ends up outside the signal time window (thus is lost).
I have tried several approaches to fix this in
|
if (particle->GetParticleType() == "nucleus" && !particle->GetPDGStable()) { |
|
// unstable nucleus |
|
if (particle->GetPDGLifeTime() > fMaxAllowedLifetime) { |
|
G4String energy = G4BestUnit(track->GetKineticEnergy(), "Energy"); |
|
G4String lifeTime = G4BestUnit(particle->GetPDGLifeTime(), "Time"); |
|
return decayClassification; |
|
} |
|
} |
but they didnt fully worked as I intended...
I tried to do a simulation of Rn222 decay chain (stopped at Pb210) and I notice an issue with which tracks are assigned to which subevent after each decay.
For instance, when an alpha decay occurs, the daughter nuclear recoil and the alpha emitted tracks are not inside the same subevent. The nuclear recoil is in the subevent of its decay instead of the decay where it is generated.
See for example:

the difference in time between the trackID 2 (3.12 ks) and trackID 751 (3.14ks) is afterwards problematic when passing to raw signal stages where it triggers the first and the former ends up outside the signal time window (thus is lost).
I have tried several approaches to fix this in
restG4/src/StackingAction.cxx
Lines 55 to 62 in 505707f
but they didnt fully worked as I intended...