However, there is one exception and this is for the Cd-109 source. In this case, the FLUKA simulation results are consistently overestimating the experimental results by a factor of about 2. Therefore, I’ve checked the nuclear data files (ENDF/B-VIII.0 and JEFF-3.3) using the Nucleonica website. Both sources predict an emission probability of the 88 keV gamma line of about 3.66%. In contrast, when I checked the emission in FLUKA, the emission probability of the 88 keV gamma line seems to be 7.388%, i.e. about a factor 2 bigger than suggested by the cited nuclear data files. This difference would explain the observed deviation from my measurement data. Therefore my question: Which nuclear data file were adopted for the photon emission probabilities of Cd-109 in FLUKA? Can you maybe confirm that the implemented emission probability of the 88 keV gamma line in the Cd-109 source is 3.66% or explain why it should be 7.388%?
For your convenience, I’m attaching the FLUKA & FLAIR scripts as well as the resulting emission line plots, which I’ve adopted to test the emission probabilities in FLUKA (for photons and electrons).
Thank you very much for your support
Cheers
David
P. S. I’ve used the newest CERN version FLUKA4.2.1 for the test simulations together with the FLAIR software version 3.1-15.1.
We rely on the ENSDF database for the rates of de-excitation through gamma emission/Internal conversion (and for nuclear structure in general).
The value stored in FLUKA for the rate of gamma deexcitation of Ag-109 (88 → 0 keV) is 3.7% .
As 100% of Cd-109 nuclei decay to the 88keV level of Ag-109, we expect 0.037 88 keV-gammas for each Cd-109 decay. You say that the emission probability of the 88 keV-gamma line seems to be 7.388% in FLUKA. May I ask where do you find such a figure ? I’d be happy to verify that we are using the correct value indeed.
Thank you so much for your reply. I really appreciate your support.
Regarding your question from where I have the figure 7.388%, please have a look to the plot " CPS_net_gamma.pdf" from the previous post. I have scored (and normalized per decay, i.e. #primaries) the emitted photons from the Cd-109 source implemented in FLUKA (using the HI-PRPOPE and RADDECAY card in semi-analoge mode). At 88 keV, I expect to see 3.7% emission probability but the value is much higher, i.e. about 7.388%. The FLUKA input and flair scripts to obtain these results are attached as well in the previous post.
To test, if really something is wrong with my scripts or with the FLUKA code, I’ve created a custom source user routine and implemented the emission probability data from ENDF/B-VIII.0. The results are as expected, i.e. now I obtain the expected 3.7% emission probability at 88 keV (cf. figure CPS_net_gamma.pdf in this post). These results could imply, that indeed something weird is going on in the FLUKA code. I’m attaching the new flair and FLUKA input scripts together with the source user routine as well as the resulting figures to this post.
What do you think? Have I made an error somewhere in the input files or in the postprocessing or could it be FLUKA? Do you get the same results, when running my scripts?
Thank you for your patience ! We have identified the bug leading to the doubling of the gammas in the case of the Cd109 decay. The underlying reason is that FLUKA treats a decay in multiple steps, stopping at intermediate points in the decay chain, emitting products for each step at a time. In this case, the isomeric state 109Ag* is sufficiently long-lived to be considered a stopping point. The decay is thus performed as such in FLUKA
109Cd → 109Ag* (EC) then
109Ag* → 109Ag (IT)
However, our decay radiation database comes from ENSDF. In ENSDF, 109Cd → 109 Ag is considered one decay which contains both decay products from the EC and the IT. When performing the two steps indicated above, we produce gammas (and CE) corresponding to the deexcitation of Ag twice
We have implemented a patch to the decay database removing 109Ag* decay products from the 109Cd, which will be live in the next minor release.
Thank you so much for your support. I’m glad that you have found the reason for this bug and could correct it. I’m looking forward to the next minor release.
