RE: [fluka-discuss]: Possibile error in Barium133 isotope decay

From: Eleftherios Skordis <>
Date: Fri, 24 Mar 2017 10:30:49 +0000

Hi Francesco,

and thank you for a very well explained question.

"So, to sum up: it would seem that when generating a primary Barium isotope, FLUKA does not choose one channel decay, but does them all together every time, resulting in a unphysical situation."

To answer to the outcome of your research, what you are saying is partly correct.
Every decay product has a chance of appearing (e.g. What FLUKA is doing (by design) in semi-Analog mode, is to reproduce these results on average after a statistically significant amount of decays. However since it is not fully-Analog the results cannot be used (out of the box) for event by event spectroscopy analysis since the coincidence summing would be unrealistic, and especially dominant if your detector is very close to the source.

Kind regards



Eleftherios Skordis
CH-1211 GENEVA 23

OFFICE: +41-22-7679541<tel:%2B41-22-7675461>
From: [] on behalf of Francesco Collamati []
Sent: 24 March 2017 10:12
Subject: [fluka-discuss]: Possibile error in Barium133 isotope decay

Dear FLUKA experts,
In my simulations I came across something that seems like a bug in the way fluka handles the decay of Barium 133 radioactive isotope.
Starting from the theory, the decay of this isotope into stable Cs is showed in this picture (reference here<>):

So, after the electron capture, a whole range of (independent) gammas can be emitted, but with a total energy release of about ~400keV.
In fact, looking in the literature for some “good spectra” of this isotope we found:


That is to say, nothing exceeds 400keV!
Now, in the simple fluka simulation I attach I generate a source of HIPROPE Z=56 A=133, and activate RADDECAY in semi analog mode, and just score the particles entering a certain volume almost in contact with the source.
If I score the USRBDX (I1 lin lin) of photons and electrons entering the “detector” region the result is the one expected: several lines of gammas and some low energy electron.
The problem seems to arise when I score event-per-event the total amount of particles entering the detector region. For this purpose I wrote a devoted mgdraw and used the BXDRAW routine to store (in a .70 text file) the
 total the number, kind and energy of particles entering the region per each event.
This is the resulting plot for the energy “carried” in the detector (vacuum) region, where red is for electrons and blue for photons.
There is lot of signal well above 400keV (h axis is in MeV)!!

To check that the problem is not with my routines, I used the DETECT card within fluka (temporarily setting the DETECTOR region to BLACKHOLE material), that gives me the histogram of the energy release in the region, giving an almost identical result:
The only reasonable explanation for this strange result seems to suppose that FLUKA knows the correct lines for gammas and electrons, but generates them all for each primary, instead of choosing one decay channel at a time! This would infect explain the spectrum reaching several MeV.. In fact, if we sum up all the photons energies we obtain something around ~1.5MeV, that is exactly the “endpoint” we see..
As a very final check, my routines enable to see the multiplicity of each event, i.e. the number of particles entering the detector region per each event. The plots show that for a given primary Barium even 20 electrons/10 photons can reach the detector!


So, to sum up: it would seem that when generating a primary Barium isotope, FLUKA does not choose one channel decay, but does them all together every time, resulting in a unphysical situation.

Is it possible as a bug in FLUKA, or am I missing something?
Thank you for your attention,
best regards


p.s. This test was performed on last Fluka version (2011.2c.5)

You can manage unsubscription from this mailing list at

(image/png attachment: 133CSgvlvtvjvfveM481.0em0.0r2723.png)

(image/png attachment: url.png)

(image/gif attachment: url.gif)

(image/png attachment: PastedGraphic-15.png)

(image/png attachment: PastedGraphic-16.png)

(image/png attachment: PastedGraphic-17.png)

(image/png attachment: PastedGraphic-18.png)

Received on Fri Mar 24 2017 - 13:11:18 CET

This archive was generated by hypermail 2.3.0 : Fri Mar 24 2017 - 13:11:20 CET