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

From: Eleftherios Skordis <eleftherios.skordis_at_cern.ch>
Date: Mon, 27 Mar 2017 12:32:46 +0000

Hi Francesco,

"Just to be sure I understood correctly: you are telling me that FLUKA cannot be used to simulate the interaction of single decay products in a material, because of the “inclusive” approach?"

You can use FLUKA to simulate the interaction of single decay products in a material... on average. For example you can simulate the average energy deposition/decay on your target.
FLUKA cannot be used (out of the box ) for event by event analysis of correlated decay products since " the radiation spectra are inclusive (i.e. no correlated $\gamma$ cascade is reproduced, etc.) "

"This allows for event-by-event analysis, with the time structure recorded in the particles age variable"
If such correlations are not an issue (e.g. for a study where your geometry does not allow for the detection of correlated decay products or there are none in your radioactive isotope etc.) then you can use FLUKA for event by event analysis either "as is" or by filtering (throught specialised routines) the products according to their time structure recorded in the particles age variable.

"Do the so generated particles in the decay carry a sort of “statistical weight” in some common I could use, or are they all equally important?"
No they do not carry a different "statistical weight" in terms of event by event analysis.

I hope this clears things up.

Kind regards

Lefteris




-----------------------

Eleftherios Skordis
Dep. EN/STI, CERN
CH-1211 GENEVA 23
SWITZERLAND

OFFICE: +41-22-7679541<tel:%2B41-22-7675461>
________________________________
From: Francesco Collamati [francesco.collamati_at_roma1.infn.it]
Sent: 27 March 2017 12:59
To: Eleftherios Skordis
Cc: fluka-discuss_at_fluka.org
Subject: Re: [fluka-discuss]: Possibile error in Barium133 isotope decay

Dear Lefteris
thank you for your reply.
Just to be sure I understood correctly: you are telling me that fluka cannot be used to simulate the interaction of single decay products in a material, because of the “inclusive” approach?
Because in the FLUKA manual, in the RADDECAY page, I read what follows:

  * FLUKA allows for two different ways of simulating radioactive decay. In the semi-analogue mode, (WHAT(1) >
  * 1) each single radioactive nucleus is treated in a Monte Carlo way like all other unstable particles: a random decay time, random daughters, random radiation are selected and tracked. This allows for event-by-event analysis, with the time structure recorded in the particles age variable. It is called semi-analogue because the radiation spectra are inclusive (i.e. no correlated $\gamma$ cascade is reproduced, etc.)

It would suggest that a “Monte Carlo way” was possible, but probably I’ve misunderstood, since in the next phrase it cites the “inclusive” approach.

Do the so generated particles in the decay carry a sort of “statistical weight” in some common I could use, or are they all equally important?
Thanks again

Francesco
############################
Francesco Collamati Ph.D.
Istituto Nazionale di Fisica Nucleare
Laboratori Nazionali di Frascati
Divisione Acceleratori, Ed.2, stanza 111,
tel. 2340
francesco.collamati_at_lnf.infn.it<mailto:francesco.collamati_at_lnf.infn.it>
###########################





Il giorno 24 mar 2017, alle ore 11:30, Eleftherios Skordis <eleftherios.skordis_at_cern.ch<mailto:eleftherios.skordis_at_cern.ch>> ha scritto:

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. http://nucleardata.nuclear.lu.se/toi/nuclide.asp?iZA=560133). 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

Lefteris


-----------------------

Eleftherios Skordis
Dep. EN/STI, CERN
CH-1211 GENEVA 23
SWITZERLAND

OFFICE: +41-22-7679541<tel:%2B41-22-7675461>
________________________________
From: owner-fluka-discuss_at_mi.infn.it<mailto:owner-fluka-discuss_at_mi.infn.it> [owner-fluka-discuss_at_mi.infn.it<mailto:owner-fluka-discuss_at_mi.infn.it>] on behalf of Francesco Collamati [francesco.collamati_at_roma1.infn.it<mailto:francesco.collamati_at_roma1.infn.it>]
Sent: 24 March 2017 10:12
To: fluka-discuss_at_fluka.org<mailto:fluka-discuss_at_fluka.org>
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<http://www.nndc.bnl.gov/nudat2/decaysearchdirect.jsp?nuc=133BA&unc=nds>):

<133CSgvlvtvjvfveM481.0em0.0r2723.png>
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:

<url.png>

<url.gif>
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.
<PastedGraphic-15.png>
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)!!

<PastedGraphic-16.png>
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:
<PastedGraphic-17.png>
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!


<PastedGraphic-18.png>

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

Francesco

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



__________________________________________________________________________
You can manage unsubscription from this mailing list at https://www.fluka.org/fluka.php?id=acc_info
Received on Mon Mar 27 2017 - 16:38:24 CEST

This archive was generated by hypermail 2.3.0 : Mon Mar 27 2017 - 16:38:26 CEST