I am trying to validate a Fluka input file with many regions. They are not needed yet but as the material will change densities in later simulations, I would like to have everything set up already.
Unfortunately, some of the runs result in runtime errors.
If so, in the output files it says:
Error: “/opt/fluka4-1.1/bin/fluka” executable returned RC=2
In the pertinent error files of the cycle before the crash it reads:
Unknown control code: ASSI , ignored ***
I checked if I have an incomplete ASSIGNMA card but I couldn’t find any.
I also encountered two Geofar errors that both origin from the border between void and target at the beginning of the target. I couldn’t figure out why, though.
Could you help me understand what is happening? Also, is there a list decrypting the error codes? I searched for it but didn’t find it anywhere (yet).
As you probably know, your input file takes quite some time to run. Could you please share the random seed that causes the crash?
Also, I have an extra comment about the speed. I don’t know exactly what you’re aiming at, but I wonder if it is really necessary for your goal to use such low energies for the transport thresholds. Increasing the energies would reduce the runtime.
Last thing about the Geofar error. I wasn’t able to replicate it, nevertheless, it seems to me that the geometry is correct and I’m inclined to believe that those errors could be ascribed to precision that are recovered by Fluka.
One should look at .err and .log file content. In particular, it would be interesting to know if the aborting cycle left behind a fluka_# directory with the aforementioned files (the .err file of a previous cycle successfully completed is not really of help). There you should find also the ran* file @amario referred to in order to try to reproduce the abort, which is important to figure out if the latter is due to a real bug.
The seed for run 16 was 757. There were others that crashed, too but the error messages were all alike. Unfortunately, for run 16 there is no ran* nor .err file. In any case, I attached the .log file.
For better understanding: If I find a ran* file, does it mean the run failed? Would it then make sense to share another one from a different run? (It is a little difficult for me to reconstruct which are the other ones that failed since I aborted the simulation after noticing it’s not working properly.)
I checked the relevant *echo.inp files in the meantime and noticed that some input-files were not properly cloned when it came to the ASSIGNMA cards. So the error message makes sense to me now - I just wonder how this happend? I cloned all of them from the same initial file (which didn’t cause any problems). Some of them worked just fine, some didn’t.
Regarding the speed: Yes, we discussed that. But since the density is expected to decrease drastically (down to 0.02 g/cm^3) we were recommended not to adjust the energy cutoff.
Regarding the geofar: that’s good to know, thank you!
Not at all, the ran* files are used for the random seed initialization and are regularly written as the code runs. On the other hand, if a fluka_# temporary directory is left after the run end, then something did not go well and its content is important for debug purposes. In this case, the .log file you usefully provided indicates that there was a problem with your input reading, most likely related to the cloning issues you actually witnessed.
No. Anyway, as mentioned above, the failure is clearly related to the irregular input content, whose origin is not obvious to assess. Just check that the submitted input files are as expected.
Do not pay too much attention to the system messages such as
Error: “/opt/fluka4-1.1/bin/fluka” executable returned RC=2
What matters to identify the issue is the .log and .err content.
Just to clarify. “757” is the seed that you put in the RANDOMIZ card. The random number that is actually necessary to debug is the one in the ran* file.
Let us know if you manage to solve your problem or it persists.
I see. But where in the run file do I find the seed? Is it one of the numbers in the first two lines? The rest seems to be hex-code to me. Unfortunately, when I put it in a hex to ascii converter, the result is not intelegible at all. How am I supposed to read this file?
Now I am worried. So far, the directories always remained after my simulations. I thought that was normal. Just to be clear: If everything goes right, all the temporary fluka_# directories from the run get deleted? Or just the ones from the previous cycles?
Ok. That is good to know. Do you always check them - even after successful runs?
This is an example of ran* file: rantest_01001.txt (1.6 KB)
I had to add the .txt extension in order to upload onto the forum, otherwise, without extension, it wouldn’t have been accepted.
It looks like a bit alphanumeric, but it is ok. There is no need for you to actually read the file with your own eyes. The program has to read it.
Just to avoid misunderstanding: my explanation about the ran* file, is to be intended in general and for future reference.
While the ran* file is necessary to reproduce crashes, in this specific case it is not necessary to upload, as the problem has been already identified.
yes, this is normally the case (after the actual end of the run). Now, if by chance they are left but contain only the .inp file, then there is no real issue either.
Indeed, after a successful run, it’s mostly instructive to look at the .out content, and the .err too, being aware that normally the latter is anyway not empty and contains certain innocent messages.