Dear Geant4, I have discovered that the track local time looses precision for short-lived daughters in the U/Th decay chains. The result of this is that one cannot accurately reproduce the time correlation for decays that have less than 1 second half life. For example, when simulating the full chain of Th232, the local times of the short-lived decays, Po216 and Po212, are always reported as 0. However, if one simulates the decays starting from a shorter lived daughter of Th232 (e.g. Rn220), the precision of Po216 and Po212 local times is properly kept. The problem arises in G4ParticleChangeForDecay::UpdateStepForAtRest where the local time is computed by subtracting the global time of the previous step from the global time of the current step. Because parents in the chain have half lives of order billions of years, the global time has ~10 billion years worth of seconds in it. For such large numbers, the number of digits required to keep track of second-level differences or shorter is greater than what is available in a typical double-precision variable. One way to fix this is to hack the radioactive decay data files so that long-lived isotopes in these chains have their half-lives set to an arbitrarily short time. This is undesirable in that it requires keeping a set of data files that have incorrect values. After inspecting the code, it appears that the problem can be easily circumvented by constructing the local time change from the previous local times and not the global times. Because the local time of the track is not currently available in G4ParticleChangeForDecay, one must also implement a function to store it. Such a function already exists for the global time so it seems natural to follow the same format. I have implemented a patch following this procedure, in my own local version of G4, and attached the files below for example. It would be convenient to rotate this change into the next patch so that collaborators on my experiment as well as other dark matter and low-energy neutrino experiments can benefit from this fix. **** Summary of changes made in the attached files to fix the timing issue: G4RadioactiveDecay.cc - modified to store the local time as well as the global time through G4ParticleChangeForDecay G4ParticleChangeForDecay.cc & hh - added function ProposeLocalTime and data member theLocalTimeChange (paralleling existing functions ProposeGlobalTime and member theGlobalTimeChange). In G4ParticleChangeForDecay.cc, changed in UpdateStepForAtRest to calculate the local time change from local times rather than global times and thus preserve precision for short lived decays in a long decay chain.
Created attachment 122 [details] tar file with suggested patch contains a tar file with example code for suggested patch, but may need some cleanup to remove my comments before being widely circulated.
Dear Lauren, Thank you for reporting the problem. As you pointed out, the local time of decay products from a parent with long life time remains zero because of lack of precision in updating the local time. And I agree that we should modify ParticleChange to handle local time rather than global time. This problem affects not only radioactive decay but also transportation and usual decay processes to describe local time of all decay products correctly. I've submitted fixes for future releases ( or patches ) Regards, Hisaya
