Dear FLUKA experts,
in my simulation I’m interested in using the DETECT card to score both prompt and delayed gammas due to interactions by thermal neutrons.
I read in the Manual that DETECT works only in a completely analogue mode, and it’s recommended to issue a GLOBAL card with
WHAT(2) < 0.0 (see note 2 of DETECT).
In order to simulate the delayed gammas, I would use the RADDECAY card and my doubt is which RADDECAY mode to use. From my understanding, “
Active” mode is non-analogue (see note 4 of DCYSCORE), so it’s not suitable. “
Semi-Analogue” is then my best option. I will need to add a TIME-CUT card to take into account the duration of the experiment.
Would this setup work? Does it create conflicts? Do you have any suggestions?
Thank you in advance
Dear Giacomo, go ahead indeed with “
Semi-Analogue” in the RADDECAY card (and let us know in case of doubtful findings).
thanks for the answer. However I noticed just now that DCYSCORE doesn’t have the option for the DETECT kind.
Can I still perform the simulation using another scoring card? Which one do you suggest?
Thank you in advance,
You do not need DCYSCORE for DETECT, which should collect both prompt and decay contributions together (I did not test it, so your feedback is more than welcome).
I did a couple of simulatios with and without RADDECAY Semi Analogue in order to compare the scoring from DETECT. The results from 400 to 600 keV are the following:
The region of each plot in which the counts are higher corresponds to the prompt 478keV emitted by B-10 neutron capture. Indeed the two seem to differ, but I was expecting also two lines at 487keV, given by the decay subsequent to the activation of the crystal itself, and at 511 keV. These are the scoring from USRTRACK in the scintillator done in the same simulation, without and with decay gammas respectively. In the second one we can see on top of the B-10 contribution the (much higher) lines at 487 and 511.
Is there a reason why the 487 and 511 lines seem not to be present in DETECT?
I attached the .inp file of my simulation, in case it might be helpful.
Thank you in advance,
DETECT + RADDECAY tests.inp (4.0 KB)
Interesting findings! which at first glance look consistent to me.
In fact, one has to keep in mind that DETECT records the energy deposited in the scintillator region as a result of ALL energy deposition contributions (if any) initiated by one primary neutron.
I think that your interpretation of the 478 keV bump is correct: the count excess shall be attributed to events where the energy deposition in the scintillator is exclusively due to an incoming prompt gamma from B-10 neutron capture, through the ionization by a daughter photoelectron.
However, as for the 487 keV gamma from radioactive decay and the 511 keV gamma from positron annihilation, these are generated in the scintillator itself, following the impact of other particles, which deposit energy beforehand. Thereby, their additional contribution cannot be seen at the respective energies, but it’s spread in a higher energy range of the DETECT spectrum.
In this regard, the fact that the ‘no decay’ spectrum surpasses the ‘decay’ spectrum at low energies, makes perfectly sense, since the additional contribution of decay particles reduces the low energy counts and increases the high energy counts.
thank you for your analysis, it was really helpful. To conclude, the spread of the 487 and 511 keV gammas happens also in a real scintilator? Do you have any reference which explains this process?
It depends on their delay and the scintillator time resolution.
Sorry, I presently miss a suitable reference at hand.
In the simulation, in addition to the global TIME-CUT you initially mentioned, one could try to filter the DETECT spectrum as a function of the aforementioned delay between subsequent energy deposition contributions. To this purpose, you may want to take a look at the use of the comscw routine as discussed in this contemporary DETECT thread. In your case, the relevant filter variable (for possible multiple DETECT cards of tailored names) would not be the particle species, rather its age (ATRACK in trackr.inc).
Thank you for your suggestions, I will take a look at the sources you provided.