First of all I found some code of mine started generating HAD_RDM_011 exceptions, after upgrading from geant4-10-00 [MT] to geant4-10-00-patch-01 [MT]. I can reproduce this using examples/extended/radioactivedecay/rdecay02, so I will refer to that in all that follows. Using the macro one-iso.mac, uncommenting the /gps/ion 11 24 0 472 line and running it with patch-01, I get: ********************************************************************************************************* * G4Track Information: Particle = Mg24[4122.889], Track ID = 4, Parent ID = 2 ********************************************************************************************************* Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName 0 0 0 1.1e-06 2.15e-05 0 0 0 Target initStep G4RadioactiveDecay::GetMeanFreePath() KineticEnergy: 2.149895954062231e-08 GeV, Mass: 22.33991948765821 GeV, tau: -1001 ns -------- WWWW ------- G4Exception-START -------- WWWW ------- *** G4Exception : HAD_RDM_011 issued by : G4RadioactiveDecay::GetMeanFreePath() Ion has negative lifetime -1001 but is not stable. Setting mean free path to DBL_MAX *** This is just a warning message. *** -------- WWWW -------- G4Exception-END --------- WWWW ------- mean free path: 1.797693134862316e+305 m Note the spurious mean free path, which looks suspiciously like DBL_MAX*mm. Without patch-01, I get: mean free path: 4.174466240182061e-10 m and tau: 3.173929916742047e-05 ns, which is agrees with the half-life given by ENSDF of 22(2) fs. This bit of code in GetMeanFreePath seems not to have changed between the two versions, so the difference must be due to GetPDGLifeTime returning -1001, which seems to be some sort of error code. According to G4IonTable.hh it means that it is not listed in G4NuclideTable. How do the states get listed in G4NuclideTable in the first place? Using strace I can see that both versions open the same data files, in particular PhotonEvaporation3.0/z12.a24 which has the correct half-life of 2.20e-14 s. Both also try to open the non-existant file RadioactiveDecay4.0/z12.a24, so perhaps the behaviour when a radioactive decay file doesn't exist has changed? By doing G4NuclearLevelStore::GetInstance()->GetManager(12, 24)->PrintAll(); I can see that the data is really being read from PhotonEvaporation3.0/z12.a24 and it has the correct half-life. i.e. if I alter the lifetime for that state in the file, I see it is really changing in the PrintAll. Note that this problem is not restricted to 24Na, that was just an example I could easily reproduce with rdecay02. I first noticed it with 152Eu and have since had it for several other isotopes commonly used as calibration sources.
Thanks for the report and the analysis. Yes, we have had similar reports for other isotopes and I will start working on this soon.
The immediate problem of the G4Exception with HAD_RDM_011 has now been fixed and will be available in a future patch. The changes that caused it in the first place occurred in the particle category, well upstream of the radioactive decay module. Basically, a tau value of -1001 means that the lifetime of the nuclide is very short, that is, unmeasured and listed as zero in the tables, or that it was not found in G4NuclideTable. The fix simply assigns a DBL_MIN path length to such nuclides, causing them to decay immediately. An additional, but optional, wrinkle is the need to set an environment variable, G4ENSDFSTATEDATA, to point to the new database G4ENSDFSTATE1.0. It contains all known isomeric states with lifetimes between 0 and about 1 microsecond. These were separated from the longer-lived entries in G4NuclideTable in order to reduce the multi-threading overhead. One consequence of not setting the environment variable is that some of the shorter-lived nuclides will decay immediately. The other consequence is that your code will run a bit faster.
