My name is David and I have the following issue:
My plan is to use the USRYIELD built-in score card to score photons from isotope primaries, i.e. radionuclide sources using the RADDECAY (semi-analogue mode) in combination with the DCYSCORE card.
My test input file (USRYIELD_rad_test.inp) using a Cs-137 source gives me the following error in the output file:
Error: "/usr/local/fluka/bin/fluka" executable returned RC=144
No error file was created.
USRYIELD_rad_test.flair (6.1 KB)
USRYIELD_rad_test.inp (5.2 KB)
rad.out (687 Bytes)
rad001.out (42.4 KB)
In addition to the test input file with the isotope source, I’ve created another input file with a mono-energetic photon point source (only using the BEAM card without semi-analogue decay mode). In this case, the simulation ran through without any problems.
USRYIELD_beam_test.flair (5.8 KB)
USRYIELD_beam_test.inp (4.8 KB)
beam.out (872 Bytes)
beam001.err (22.4 KB)
beam001.out (94.7 KB)
beam001_fort.txt (78.9 KB)
What is the reason for the errors in the first input file (USRYIELD_rad_test.inp) and why does the second input file (USRYIELD_beam_test.inp) doesn’t give the same errors?
I performed all simulations with the FLUKA CERN version 4-3.3 together with the FLAIR interface version 3.2-4.5 on Ubuntu 18.04 LTS WSL. In addition, I tested both input files with a FLUKA CERN version 4-3.2. Unfortunately, I obtained the same results.
Thank you very much for your support
you get a bit more information in the rad001.log file, where you can guess from the abort backtrace that the problem is with USRYIELD itself. In fact, you ask it to score as a function of the photon angle, which is defined with respect to the beam direction. However, there is no beam in your first case, which requires an additional USRYIELD card with SDUM=BEAMDEF to set the reference beam direction. Fill the direction cosine fields accordingly (and input a fake momentum).
Also, note that assigning the same name (Yield) to different detectors is not a good idea. Actually, your DCYSCORE card will apply only to the first.
You are of course correct. I was not aware of the requirement for an additional SDUM=BEAMDEF card in semi-analoge simulations. To test this option, I’ve created an updated input file (“USRYIELD_rad_test2.inp”):
USRYIELD_rad_test2.flair (6.5 KB)
USRYIELD_rad_test2.inp (5.3 KB)
With this, I managed to succesfully run the test problem. However, I still have some questions:
- I’ve tested two beam directions with cosz=1 (positive z-axis beam) and cosz=-1 (negative z-axis beam) in the USRYIELD card (SDUM=BEAMDEF) . For both cases, I got exactly the same results. I would have expected mucher lower bin values for the latter (if I’m not wrong, this would be only backscatter contribution) as well as some statistical deviations for rare event bins. Did I miss something here?
radpos001_fort.txt (78.9 KB)
USRYIELD_radpos_test2.flair (6.8 KB)
USRYIELD_rad_test2.inp (5.3 KB)
radneg001_fort.txt (78.9 KB)
USRYIELD_radneg_test2.flair (6.8 KB)
USRYIELD_radneg_test2.inp (5.3 KB)
Do the other entries (momentum, projectile and target) for SDUM=BEAMDEF in the USRYIELD card have an influence on my simulations? Which values should I use?
I think a read in the manual or a previous post that for some scoring options, we can also use the beamaxes to define an artificial beam direction in case of scoring problems with radioactive decay simulations. I tested this for USRYIELD. This doesn’t seem to work. Do you know anything about that option?
Thanks for your support. I really appreciate your help.
Namely for USRYIELD angle-related scoring in the ISOTOPE case, as no beam direction is set.
From a radioactive source at rest, you shall expect exactly an isotropic distribution, independent of the reference direction (that has to be set, though).
You just need a momentum different from zero, the rest is relevant for the reaction cross section normalization available with USRYIELD, which cannot apply here (and in general should be used with care, and limited to thin target calculations).
The BEAMAXES card is not specific to scoring and actually alters the beam reference frame such as to allow for the definition of the beam size (by means of the respective BEAM card parameters) in a transverse plane different from xy (since the BEAM card assumes the beam direction along z, despite any modification in BEAMPOS).
As for USRYIELD, the BEAMDEF SDUM option is there to freely redefine the reference axis for scoring purposes. In the ISOTOPE case, as a matter of fact, there is no beam axis (neither by default nor modified), which is what USRYIELD takes by default as reference axis for scoring purposes. Therefore, you need to define the latter (which will not become the beam axis, though, since there is no beam).
Thanks again for your detailed reply. I think I got it now. My problem was the following remark in the FLUKA manual for the USRYIELD card:
1. While option USRBDX calculates angular distributions with respect to the normal to the boundary at the point of crossing, USRYIELD distributions are calculated with respect to a fixed direction (the beam direction, or a different direction specified by the user with SDUM = `BEAMDEF`).
Based on this remark, I expected that the artificial beam direction defined in the additional USRYIELD card with SDUM =
BEAMDEF will become the reference direction to compute the polar angle in my scoring quantity (ixa = 6). Therefore, a flip of the beam axis as described above should definitly affect the scoring values for the given source-detector configuration in my input file.
What I was not aware is the fact that the above remark, at least as I understand, doesn’t apply to my scoring quantity (ixa = 6) as described in the manual as well:
ixa = 6: Double differential fluence yield where x_1 and x_2 are the first and second quantity, and theta is the angle between the particle direction and the normal to the crossed surface.
So, this is all a bit confusing. I have now the following understanding:
- For isotope beam source (with RADDECAY) in combination with USRYIELD scoring cards, we are required to add an additional USRYIELD scoring card with SDUM =
BEAMDEF and a non-negative momentum value.
- If we use the ixa = 6 scoring quantity, the beam direction (true or artifical) doesn’t affect the reference vector to compute the polar angler in degrees.
- If we use instead an isotropic beam source (without RADDECAY), we are not required to add the additional USRYIELD scoring cards with SDUM =
So what got me confused is the fact that for both beam options (isotope and isotropic beam), we have no “fixed” beam direction. But only for one case (isotope), we need to add an additional USRYIELD card to provide an artificial beam direction, which in the end for ixa = 6 has no impact what so ever. Did I miss again something here?
we are dealing with two different angles. The first is the polar angle with respect to the USRYIELD reference direction. Although it does depend on the latter, the scored quantity does not, due to your isotropic source. The second is the angle between the particle direction and the normal to the crossed surface (as for USRBDX), which is invoked to calculate fluence (by 1/cos(theta)) .
- … and a positive momentum value (zero does not work).
- It doesn’t for the second angle, but it does for the first.
- Correct, because in this case a reference beam direction is anyway set (thanks to the non-null momentum), albeit overruled by the isotropic choice.
In case of isotropic source, you may avoid to score as a function of the angle, unless you wish to verify the assumed isotropy or you expect that the presence of material alters it.
Thanks again for your detailed reply. You wrote:
- It doesn’t for the second angle, but it does for the first.
But why is the double differential fluence with respect to the selected scoring plane (VOID010i->VOIDtopi) for two different reference beam directions, i.e. cosz=1 and cosz=-1, exactly the same (see radpos001_fort.txt and radneg001_fort.txt)? If the first angle (x_2=polar angle in the lab frame in degrees) would truely depend on the USRYIELD reference direction, the differential fluence should change for a change in cosz (given the selected scoring plane), shouldn’t it? Note that we score the fluence not at the source position but in about 10 m distance.
my apologies and thanks for your insistence. I see now that you score on a circular boundary that corresponds to a polar angle interval from 0 to about 25 deg with respect to the source position and the z-axis. Therefore, your expectation of a dependence on the inversion of the reference axis (changed into -z) is fully legitimate. In fact, you can observe it when scoring double differential yield (ixa=3): for cosz=1, you see most of the yield between 0 and 30 deg, something at larger angles (due to photon scattering in air at closer distances from the boundary), and obviously nothing above 90 deg; for cosz=-1, the result is not identical, but symmetric (i.e., nothing below 90 deg and most of the yield between 150 and 180 deg). So far so good.
Now, when scoring double differential fluence (ixa=6), the only considered angle becomes the one between the particle direction and the normal to the crossed surface, which is necessary for the fluence calculation by the 1/cos(theta) factor. In this regard, my former statement about the simultaneous relevance of the two different angles was wrong, and I modified my preceding post accordingly, to avoid misleading messages. That’s why the change of the USRYIELD reference axis has no effect (what matters is only the normal to the surface). This was already pointed out in your third post, together with the equally legitimate remark about the illogical necessity of the USRYIELD reference axis definition (via SDUM=BEAMDEF) in this (ixa=6) case. Also, exclusively for the latter (and ixa=16,26), (backscattered) photons that cross the boundary in the opposite direction, i.e. at angles larger than 90 deg wrt the normal, are taken into account.
Actions are on us to clarify the matter in the manual and prevent the pointless BEAMDEF obligation.
Thanks again for your detailed reply and sorry that I didn’t clarify the scoring surface location earlier. With your last post, I think we have resolved my question. I’m looking forward to an update on the BEAMDEF handling for the special cases with ixa=6,16,26 and isotope sources using RADDECAY semi-analogue settings.