Dear FLUKA experts,
I received an error message states “Error: “/mnt/f/CERN-FLUKA-spectra-sampling/src/flukahp-spec” executable returned RC=142” in the .out file. What went wrong?
In addition, is there a place I could find information on error codes for future reference? I couldn’t find it in the manual.
Thanks in advance.
Martin
The attached are all my files.
BNTN.out (654 Bytes) BNTN.inp (1.7 KB) BNTN001.out (58.4 KB) BNTN001.log (571 Bytes) BNTN001.err (753 Bytes)
Dear Martin,
the error codes in this error message are the standard linux error codes, which in case should be 142 - 128 = 14: EFAULT Bad address, which is quite unusual.
Could you post your spectrum file as well, to be able to reproduce the error?
Cheers,
David
Dear Martin,
I tried to run your input, but initially I got the error code 136. Afterwards I changed the primary particle from NEUTRON to PROTON, then the simulation was running.
Unfortunately I’m not familiar with the internal working of the sampling code, so we need to wait until @ctheis can take a look.
Cheers,
David
Hello,
I just had a quick look but if the code runs with protons but not with neutrons then the actual problem seems not to be directly related to the sampling part. At a first glance I can see that the lowest energy bin starts with 0.0 GeV. As energies are taken from [Emin, Emax) it might be that a neutron with 0,0 energy is started and this could pose a problem for FLUKA.
Martin, can you try to set this to a small energy like 1e-14 GeV, which is the lowest neutron energy that FLUKA can handle.
Cheers
Chris
Dear @ctheis,
Thank you for your advice. Unfortunately, the input still produces the exact same error with RC = 142 on my machine after I change the lowest energy from 0 to 1e-14 GeV.
Martin
Dear @horvathd,
Thank you for your help. I tried to reproduce what you did on my machine and it works as well for proton. However, my error code is always 142 instead of 136.
Martin
Dear Martin,
it seems to me, that you are using FLUKA with WSL on Windows, so I checked there as well, and I got the error code 142 this time.
Cheers,
David
Dear @horvathd,
Yes that’s right, I am using FLUKA w/ WSL and the latest version of FLUKA and flair.
Martin
Hi @KillMartin,
The return code is a bit strange as 142 should be SIGALRM (you can check it in a shell with the command „kill -l 142“). That code is usually triggered by a timeout and I cannot reproduce it right away.
Can you try one thing please: use the example input file that comes with the spectra sampling routines and verify that this one runs correctly on your system. After that use the example input and simply replace the input spectrum of the example with your own and run the input again.
It would also be interesting to know which compiler version you have.
Cheers
Chris
Dear @ctheis,
I tested the example input file in your addon package along with the example spectra file and it runs with no problem. After this test, I replace the spectra file with my spectra file attached in this topic and it also runs successfully…
I’m using Ubuntu 18.04 LTS with a list of compilers install as stated below if this is what you want to know. I think I installed FLUKA with the correct release, which is the “gfortran 7 .deb” one.
List of compilers:
ii g++ 4:7.4.0-1ubuntu2.3 amd64 GNU C++ compiler
ii g+±7 7.5.0-3ubuntu1~18.04 amd64 GNU C++ compiler
ii gcc 4:7.4.0-1ubuntu2.3 amd64 GNU C compiler
ii gcc-7 7.5.0-3ubuntu1~18.04 amd64 GNU C compiler
ii gfortran 4:7.4.0-1ubuntu2.3 amd64 GNU Fortran 95 compiler
ii gfortran-7 7.5.0-3ubuntu1~18.04 amd64 GNU Fortran compiler
ii libllvm10:amd64 1:10.0.0-4ubuntu1~18.04.2 amd64 Modular compiler and toolchain technologies, runtime library
ii libllvm9:amd64 1:9-2~ubuntu18.04.2 amd64 Modular compiler and toolchain technologies, runtime library
ii libxkbcommon0:amd64 0.8.2-1~ubuntu18.04.1 amd64 library interface to the XKB compiler - shared library
Martin
Hi Chris,
I found a bug report for WSL with the error code 142. It seems the actual error code is 136 (what I got on my Linux desktop) - Floating-point exception
See: https://github.com/microsoft/WSL/issues/3657
With WSL2 I also get the error code 136
Cheers,
David
Hi @KillMartin and @horvathd,
This is very strange. If the original add on package runs and the new input spectrum runs with the example input then the problem should not be related to the sampling but must be related to an option in the martin’s input file.
Unfortunately I don’t have a platform to reproduce it. @KillMartin The best might be to try to produce a core file by running “ulimit -c unlimited” in the shell and then trying again. Once a core is produced you can load it in the gnu debugger with the shell command “gdb nameofmyflukaexecutable coredumpfilename”
In the debugger simply type “bt” and you will see where the code crashed.
Cheers
Chris
Dear @ctheis,
I try to follow your instructions yet I don’t have enough knowledge working with Linux to get what are you telling me to do. So I ran “ulimit -c unlimited” in the shell and then successfully (“Finished with ERROR”) ran the flair project. After that, I closed flair and then try to run “gdb flukahp-spec coredumpfilename”. However, I do not know the filename for the core dump file. Where could I find it? Do I need to change my directory to the working folder for all of these steps?
Thanks again for the time.
Martin
Dear @KillMartin and @ctheis,
I managed to narrow down the problem to the USRYIELD scoring. It seems to me that the Particle LET option doesn’t play well with 4-HELIUM particle and NEUTRON primaries.
Also for some reason the core file generated in the crash is empty, but the trace back is available in the .log file.
Cheers,
David
Hi @horvathd,
I managed to create a core file and have a backtrace. The problem has nothing to do with the spectrum sampling routines but it is due to errors in the input.
Martin, please check your material assignments. There is one where you assign a material to a material (h-BN and Ar). In addition, there might be something fishy with your definition of h-BN. If I replace that one with Ar (assigning Argon to the region Paint) your input works.
Cheers
Chris
P.S.: @KillMartin: the core file is created in the fluka_XXXXX directory and usually has a name core.XXXXX (where the XXXX is a number). If you carry out the steps I’ve described you will see:
#0 0x00007fc79b4cd353 in log () from /lib64/libm.so.6
#1 0x000000000063918e in master.0.dpdxio (__entry=__entry@entry=0, tdmax=<error reading variable: Cannot access memory at address 0x0>, ldedx=.TRUE.,
jmat=3, epo=0.0011759015688124989, ij=-6) at dedx/dpdxio.f:290
#2 0x000000000063d4b8 in dpdxio (ij=-6, epo=0.0011759015688124989, jmat=3, ldedx=.TRUE.) at dedx/dpdxio.f:4
#3 0x0000000000668077 in getlet (ij=-6, ekin=0.0011759015688124989, pla=0.093634648116316513, tdelta=-1, matlet=3) at dedx/getlet.f:114
#4 0x000000000058b9f8 in master.0.usrsco (__entry=__entry@entry=11, ppcont=0.093634648116316513, jreg=4, tzi=0.80608054848703115, tyi=-0.55591941443693105,
txi=0.20294766321134811, ekcont=0.0011759015688124989, llo=2, icall=201, rul0=1, kreg=3, zb=0.093511209356933064, yb=-0.40904608516820284,
xb=0.24879224356942328, ijinp=-6) at score/usrsco.f:6193
#5 0x000000000059af24 in usrscy (ijinp=-6, xb=0.24879224356942328, yb=-0.40904608516820284, zb=, txi=0.20294766321134811,
tyi=-0.55591941443693105, tzi=0.80608054848703115, kreg=3, jreg=4, rul0=1, icall=201, llo=2, ekcont=0.0011759015688124989, ppcont=0.093634648116316513)
at score/usrsco.f:5284
A stack trace has to be read from bottom to top. So the interesting line is actual number 1, which was where the code crashed and you can see (in bold) that this was in the scoring routines related to LET. So that’s where in your input you then have to start looking around. At that time the sampling has already finished and the particle is well on it’s way.
Thanks a lot @horvathd and @ctheis,
the problem is indeed related to the input USRYIELD card, which is wrong. This can also be seen in the above stack trace by @ctheis: FLUKA is failing as it invokes the getlet function triggered by the USRYIELD choice of @KillMartin.
The material definition looks OK to me, but the problem is with the last USRYIELD field (WHAT(6) of the continuation card) that was left terribly empty. This combines two input values: the distribution type (that should be d2N/dx1dx2 and not include by default the beam inelastic cross section sigma, absolutely of no meaning here) and the material wrt which the LET shall be calculated by FLUKA (normally people use water, default is HYDROGEN, see the manual). Note that the latter material, which does not need to be the one of the concerned regions, must be anyway assigned to some region in the geometry, in order to be properly initialized.