Finetuning transport in decay radiation

Hey Fluka experts,

I’m trying to get some elucidation on the inner workings of the transport cutoffs using the EMFCUT and RADDECAY cards.

As I understand it, there are two ways to set up transport parameters in a residual radiation calculation:

  1. Use the RADDECAY card with prompt/decay cuts. This is applied globally to all EMFCUT cards of the ‘transport’ type.
  2. Use the RADDECAY card, leave the prompt decay cuts to default (0), but specify EMFCUT cards of both the PROMPT and DELAYED type.

The usual way I’ve been setting up residual dose calculations is using the first method, but would like a more explicit method of setting up the transport.

To the first method I still have a lingering question namely:

  • Is the RADDECAY’s card prompt/decay cut multiplier always applied to either the total or kinetic energy, or is this dependent on the chosen value for total/kinetic in the EMFCUT transport card?

To the second method i have the following questions:

  • What is the correct way to apply the EMFCUT card with PROMPT and DELAYED for its type(SDUM). Is there a priority system in place when specifying a DELAYED type EMFCUT card for a specific region later in the input file? (e.g. does a DELAYED type card overwrite the region properties of a previously set ‘transport’ type card?)
  • Is there a way to see applied /final/ cuts for both prompt and decay? In my testing the .out file did not show any different values in the media parameters section when applying both PROMPT and DELAYED types.

Thanks in advance!

Chris

Hi Chris,

Excellent questions on which the documentation does not directly offer conclusive answers. I did a couple of test runs with the following answers to your questions:

  • According to the output file, the multiplier factors in the RADDECAY card are applied to the total energy. I.e., if you specify in the EMFCUT card a threshold for electrons/positrons at 1 MeV and in the RADDECAY card a multiplier factor of 2x, the cut will be 2x(1 MeV + 511 keV) = 3.022 MeV.
  • In principle the cards are indeed overwritten when specifying a new EMFCUT for either PROMPT or DELAYED, however
  • I see the same as you that not in all of my test cases the media parameters are updated. However in the region description echo of the output file this should be specified in the proper way. The only way to be completely sure is to make some scoring tests to see if the cutoffs are applied in the proper way, have you already tried this? For example scoring if you get any electrons/positrons by setting EMFCUT cards separately and alternatively for PROMPT and DELAYED?

I will try some more test runs from my side as well.
Cheers,

Andreas

1 Like

Hi Andreas,

Thanks for the help. I’ve also finally gotten around to a small toy-model which tries to confirm these thresholds.

One thing I’ve found which is counterintuitive to me (or at least undocumented, at worst a bug?) is that the smallest possible multiplier is 1x: i.e. specifying a decay cut in the card of 1.0, does not result in a multiplier of 0.1x. This is reflected in the output (“EM transport threshold multipliers”) but that took me a while to find out. Also I was unable to glean from the manual that the multiplier applies to the prod-cut as well (next to the transport cut ofcourse).

With regards to multipliers applying to total energy vs. kinetic: I’m seeing some conflicting data.
E.g. in one of my cases i put total or kinetic energy to some value (let’s say 100 keV kinetic, 611 keV total). For prompt and decay I have a multiplier of 2x, and 1x respectively…
The output in the ‘media parameters’ section notes (for both kinetic and total defitinion, as expected) that Ecut is at 1.222 MeV for the prompt case, and 611 keV for the decay case. Given this, I would expect the spectra to be cut-off at (1.222 MeV - 511 keV=)689 keV for the prompt case and 100 keV for the decay case.
The decay case cuts off at 100 keV. However the prompt case shows a cutoff at 200 keV, which would imply the Ecut is somehow corrected internally?

With regards to the PROMPT/DELAYED card: I’m not seeing any effect of these in the spectra in my scoring. (USRBDX)

Cheers,

Chris

Hi Chris, thanks for these checks, it is indeed a delicate problem. Doing some tests on my side has also resulted in conflicting statements in the output files in particular so it would be useful to compare. Could you share your toy model input file? This way I can reproduce your results and try to figure out if your settings are indeed somehow overwritten or there are some conflicts in the use of several of these cards.

Cheers,

Andreas

1 Like

Here are the input files. This has a simple prod/decay cut at 1.0x and 2.0x, you’ll also find the relevant plots.

main.flair (8.4 KB)
main.inp (5.3 KB)

Hello Chris,

My apologies for taking this time but it was necessary to flesh out this problem in detail and thanks a lot for bringing it to our attention!

To reply to your questions:

  • The multipliers need to be larger than or equal to 1.0, this is however clearly noted in the manual.
  • The thresholds set by RADDECAY (and EMFCUT with SDUM=PROMPT, DELAYED) indeed only apply to transport, not production.
  • Concerning the multipliers, as noted above the output file states that the factor is applied to the total energy, not the kinetic energy. However in the code the multiplier is applied to the kinetic energy, therefore showing the discrepancies in the simulations. What is reflected in the output file in terms of threshold needs to be corrected.
  • For the EMFCUT using PROMPT/DELAYED as SDUM and hence setting the transport threshold to different values in the same region is not dealt with in an appropriate way in the code. However we identified the issue and are now working on the solution.

So in summary: knowing that the multipliers in RADDECAY are applied to the kinetic energy, is it possible for you to do your studies without setting thresholds using EMFCUT with SDUM=PROMPT/DELAYED on a region basis for the time being?

Hope this helps and again apologies for the long waiting time,

Andreas

Hey Andreas,

Long lead-times are fine :slight_smile: Thanks for the in-depth detective work. Given the now-clear constraints, it should definitely be workable. Thanks, and good luck with the bugfixing! :wink:

Chris

1 Like