I’ve been working on a somewhat complicated .inp file for a sample array we will be irradiating at the HiRadMat facility. It makes use of a lot of #define statements to switch beam parameters, and only record nuclide inventories when the sample is actually irradiated (good to save computing resources!).
There are 15 cases total, and 14 out of the 15 are fine. The only problem is the first case (which corresponds to enabling #define frac1 and leaving all other cases disabled (frac2 - row4, keep intens and pulset enabled!)). The run completes mostly normally (I have seen the log file pick up a couple comments, but I am not sure that they are severe—they don’t halt the run).
For this case, a nuclide inventory is supposed to be written to logical unit 71 as a binary. I see the fort_71 output files at the completion of the run, but when I attempt to postprocess the results (in the flair interface) it suddenly complains that the .rnc file can’t be written to since it doesn’t exist, which is surprising since usually flair creates that file the first time a postprocess is attempted.
I’ve checked the cards for the first case over and over—moved them in and out of the conditional statements too. Increased statistics. Checked the input echo. Made a new flair project and loaded the .inp. I really can’t determine the issue here, and so I figured this means it’s time to ask for help!
I’ve attached the .inp file; any insight or guidance is much appreciated. This is not “mission critical”, per se, but if it could be fixed before we run all the cases, I figure that is preferrable.
Just a typo: DCYSCORE 6 A11t1 RESNUCLE
should read DCYSCORE 6 A11t6 RESNUCLE
Also, remove PHYSICS 0 0.005 0.15 2 2 3IONSPLIT
which is useless,
as well as the LOW-MAT card (irrelevant with the default point-wise treatment for low-energy neutrons).
Ah, that must be it… gosh, all those cards and I missed just one. That’s awesome that you caught that.
Also thank you for the notes on the physics cards—I copied the IONSPLIT and LOW-MAT cards from another person’s decay setup, and I was wondering how important they were since I usually don’t use them, so good to know they are not necessary. I’ll read up on the details to make sure I understand going forward.
Thanks for your time and help as always Francesco!
To dig into the typo effect, the fatal post-processing outcome it triggered is not related to the unintended double cooling time assignment to the A11t1 detector (since the second should supersede the first), rather to the fact that the A11t6 detector gets no cooling time association and so it returns isotope production yields instead of activities. The problem is that the two different types of quantities cannot coexist inside the same scoring unit (here fort_71).
As for PHYSICS/IONSPLIT, since the first parameter is zero, it does nothing. Previously, with the first parameter set to 1.0 (or any positive integer), it was intended to split low-energy deuterons at interaction (into proton and neutron), in the absence of a dedicated interaction model. However, starting from FLUKA 4-2.0, we embedded the latter, making the (active) presence of that card harmful, since it would perform the former rough deuteron splitting instead of relying on the new physics model.
Ah, I see… I was initially wondering how a double assignment could lead to trouble but that explains it. This was a valuable experience then, since I had never made the mistake of trying to record incompatible quantities to the same binary file, and now know what will indicate that error.
And for the IONSPLIT, the .inp I borrowed from predates FLUKA 4-2.0, and so the new (improved) default behavior was not yet implemented.