Confusion regarding USRBDX

Dear FLUKA experts,

I am having some issue understanding how to tackle the following problem. I am using USRBDX to try to generate a neutron spectrum so I would compare it to the input source spectrum as a sanity check. The figure below shows the input neutron spectrum.


After picking the FLOOD option in BEAMPOS, I set up a USRBDX card with log bins scoring one-way neutron current that going into the target region from vacuum. I was expecting to see a plot with the exactly same shape as the input spectrum. However, I am getting the figure below with DX*Y option, which in my understanding would give me the correct normalization since the flux were given in (Part/GeV/cmq/pr) and the bin width must be cancelled out for log binning.

With the default Y option, the figure seemingly agree with each other as follows. Yet, the normalization on the y axis is not very helpful for further analysis.

Can someone help me lift my confusion and what I did wrong?

Thanks in advance.

Martin

Hi @KillMartin
this is indeed a fundamental question deserving proper understanding.
A spectrum plot drawn with the DX*Y option [to be avoided] is intrinsically misleading, since its shape and height will depend on the energy binning (as your second figure demonstrates), while the latter comes from an arbitrary choice that has no vocation to alter a physical quantity representation. Therefore, any histogram plotted as a function of a continuous variable X should always embed the (DX)^-1 term, removing the linear dependence on the bin width.
The linear vs logarithmic alternative for the DE energy binning does not affect the dimension of the resulting quantity, which is always dN/dE. On the other hand, when you plot as a function of logE (on a horizontal logarithmic scale, even independently of the linear/logarithmic choice for DE), you should plot dN/dlogE (Part/cmq/pr) that is [as recalled many times on this forum] E dN/dE (GeV Part/GeV/cmq/pr) = <X> * Y (and not DX * Y !). If you do so, also the spectrum you compare with should of course be plotted on a log E scale as dN/dlogE = E dN/dE (independently of its binning).
As for the integral (sum of dN/dE dE), this is already calculated by FLUKA and printed in the (USRBDX) sum.lis file [this is another piece of information advertised on a regular basis on this forum, we should find the way to do it more effectively].

1 Like

Dear @ceruttif ,

Thanks for your detailed explanation. I did read through a lot of relevant posts before post my own as my confusion just increases as I read through. It took me some time, but I think I finally understand what you are saying. I shall do a quick sanity check calculation to make sure I understand it correctly.

Thanks again.

Martin

Dear @ceruttif ,

Thanks again for the clarification on this matter. I just have a quick question to be certain I understand this correctly. Should I use dN/dE or dN/dE dE for the external input source spectrum? Is the latter one associated with the probability?

Martin

Yes, it’s the latter one ( dN/dE dE ) that is proportional to the bin probability, which does depend on the dE bin size.

Hi Martin!

in addition to Francesco’s answer, it may depend on how the user routine has been written.

For example the source_newgen.f user routine requires dN/dE values, so it can use previous FLUKA results without manually calculating the probabilities.

Cheers,
David

1 Like

Thanks for your help. @horvathd @ceruttif

I’m just using the CERN-FLUKA-spectra-sampling by Chris Theis from this address: Sampling from energy spectra. Which I think requires the calculation of probability values.

Martin

Dear Martin!

According to the README.TXT file, this user routine by default uses:

3rd column = spectral value (e.g. differential fluence dF/dE in the unit 1/(cm2 * GeV) )

This behavior can be changed with the keyword TotalFluenceToDiff or Total-Fluence-To-Diff to assume that the total fluence within the bin has been given which is converted to differential fluence. See the readme for more options.

Cheers,
David

Cheers,
David

Dear @horvathd ,

Thank you so much for point it out.

Martin