Problem 968 - Wrong G4ContinuumGammaDeexcitation::CanDoTransition() for some radioactive nuclei
Summary: Wrong G4ContinuumGammaDeexcitation::CanDoTransition() for some radioactive nu...
Status: RESOLVED FIXED
Alias: None
Product: Geant4
Classification: Unclassified
Component: processes/hadronic/models/de_excitation/photon_evaporation (show other problems)
Version: other
Hardware: All All
: P3 trivial
Assignee: aatos.heikkinen
URL:
Depends on:
Blocks:
 
Reported: 2007-09-20 10:04 CEST by Luciano Pandola
Modified: 2008-01-31 16:06 CET (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this problem.
Description Luciano Pandola 2007-09-20 10:04:37 CEST
The problem occurs when a nucleus is produced (e.g. by radioactive decay) in the highest of the excited levels contained in the G4LEVELGAMMADATA database. 

For instance, Pb-212 can decay to the 415,272-keV level of Bi-212, which is the highest one reported in the G4LEVELGAMMADATA database.
 
Although the level energy is exactly the same in the two databases, the difference (excitation-maxLevelEnergy) calculated in G4ContinuumGammaDeexcitation::CanDoTransition() is positive (5.1459947e-12) probably because of rounding errors. The condition   
if (excitation <= _levelManager->MaxLevelEnergy()) at line 133 
is NOT met, causing CanDoTransition() to return "true", instead of "false". Therefore, a ContinuumGammaDeexcitation takes place instead of a DiscreteGammaDeexcitation and gamma rays are produced with the wrong branching ratios (e.g. the 176.7-keV line is produced at 1.76% instead of 0.05%).

Possible solutions:
1) hack the database $G4RADIOACTIVEDECAYDATA, so that the excitation energy is slighly lower than the level energy reported in $G4LEVELGAMMADATA. This is necessary only if the highest excited level is populated.

2) add a tolerance in the "if" block of G4ContinuumGammaDeexcitation::CanDoTransition(), line 133, e.g.
if (excitation <= (_levelManager->MaxLevelEnergy()+1*eV))
Comment 1 Luciano Pandola 2008-01-31 16:06:29 CET
The bug has been fixed (see patch described above) in version 9.1.