I simulate Al-26 ions in my geometry, and have warnings from G4AtomicTransitionManager. It reports about shells with indices more than number of shells for this ion: G4AtomicTransitionManager::Shell - Z = 12, shellIndex = 5 not found; number of shells = 5 It happens approximately once in 1000 events, after the warning the program continues working. In version 4.9.3(no patch) I got shellIndex from 5 to 8, in 4.9.4 only 5 and 6. This is the mail from my colleague with possible explanation: "In the Al-26 --> Mg-26, following a M-capture decay, the RadioactiveDecay samples a shellIndex between 4 and 8, while the total number of shells is 5. If a shellIndex > 4 is given, the G4AtomicTransitionManager will issue the warning, but it will perform the decay with the last valid shell, e.g. id=4. Therefore, you will get the correct physics. In some cases, there could be some discrepancies due to the different binding energies of the shells." Is it a bug? Does it affect results? Thanks, Alex.
reassigned
The warning message is "right", since Mg has a total of 5 possible electronic shells producing fluorescence/auger in Geant4. the shellIndex (being an Index) starts at 0, so an index of 5 is not to be found. The problem is however real and a correction is to be made. Thank you very much, alf
I had a closer look at the problem and I can comment a bit more. The bug comes from the G4RadioactiveDecay following electron capture decays. The decay then invokes the G4AtomicTransitionManager with an unphysical shellID. The problem is observed for partially-filled shells. In the case of Al-26, a M-shell electron is captured. The shellID vacancy is sampled uniformly among the M1-M3 shells, but for Mg-26, M2 and M3 are not populated. That's where the error message is issued. In my impression, physics is ok since the G4AtomicTransitionManager uses the highest valid shell, after having issued the warning message. A fix to suppress the error message is easy (the RadDecay should verify that the shell is valid), while the consistent treatment of EC decays for non-full shells could be more delicate. Luciano
I can confirm all what Luciano did write! The problem occurs when selecting M shells in line 412 of G4NuclearDecayChannel : eShell = G4int(G4UniformRand()*3)+4; This random sampling gives equal probability of getting M1,M2 and M3, while for Al26 only M1 should be allowed. I will add a check for this sampling by using G4AtomicTransitionManager::NumberOfShells(Z). But as Luciano said, G4AtomicTransitionManager will return the highest shell if eshell >=G4AtomicTransitionManager::NumberOfShells(Z) so you will anyway get M1 for the Al26 case. Best regards Laurent Desorgher
The bug has been resolved while ago according to Luciano comments.
