Question about the "Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation."

Source Definition
1

Dear Fluka experts,
I am simulating sampling from phase file source.dat with source.f file. I simulated sampling 1 million times, but it would stop every 200,000 times and errors would occur.

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.

Backtrace for this error:
#0 0x758f9404251f in ???
at ./signal/…/sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
#1 0x62c416c6117f in ???
#2 0x62c416bea865 in ???
#3 0x62c416b54226 in ???
#4 0x62c416a13ce0 in ???
#5 0x62c416984600 in ???
#6 0x62c41697ae00 in ???
#7 0x758f94029d8f in __libc_start_call_main
at …/sysdeps/nptl/libc_start_call_main.h:58
#8 0x758f94029e3f in __libc_start_main_impl
at …/csu/libc-start.c:392
#9 0x62c41697c324 in ???
#10 0xffffffffffffffff in ???
Floating point exception (core dumped)
I don’t know what was wrong in my source.f file.
I hope you can help me.
Thank you,
Yongce

FLUKA_geometry.inp (3.3 KB)
source.zip (1.2 MB)

source_2.f (15.0 KB)

3

Hi Jianqui,

Happy to hear from you again. Sorry for the dealy, I will have time to look into your questions by the end of this week.

Cheers,
Jerzy

4

Hi again,

I need you to provide more explanation on what exactly your routine is trying to achieve.

When I try to run fluka with the file provided and with your routine compiled, I get a different error

 STOP Initial momentum mismatch!
Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
STOP STOP: FLUKA ABORTED

and in the .log file I get

 STOP Initial momentum mismatch!
Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
STOP STOP: FLUKA ABORTED

and it appears at random primary number depending on the initial random seed.
What I can see in your routine is that you are loading some information about the source particles from the file, but the only ones that are used are the particle type and kinetic energy.
Which FLUKA version are you using?

Anyway, I suggest that you revise the hardcoded formulas that compute the momentum and the directional cosines. The problem may lay somewhere there.

Cheers,
Jerzy

1 Like
5

Dear Jerzy Mikolaj Manczak,
sorry for late reply, Firstly, I am thankful that you trying to solve my question, but I dont know why we have a different error, As you can see, my error is “Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation”. And my routine is trying to simulating sampling from phase file source.dat with source.f file, and the directional cosines is that geted from a function, so I set the directional cosines like that function.
Maybe, as you said, my direction cosine is wrong, but the strange thing is why the first 15,000 times it works perfectly? And it looks more like fortran can’t compute some values that are close to zero.

Thak you for your generous answer,
Yongce

6

Dear Yongce,

I asked you about the FLUKA version that you are using, because my error file

 Abort called from LENESA reason Initial momentum mismatch! Run stopped!
 STOP Initial momentum mismatch!

points me to the lenesa.f routine which was added in the 4.4.0 FLUKA version released at the beginning of 2024. If you are not using this version or newer, it is expectable that we would not get the same error. Once we agree on that, we can try to proceed with the search for the solution to your problem.

Cheers,
Jerzy

1 Like
7

Hello,

One thing to imperatively address in your source_2.f is the normalization of the direction unit vector. In the first event you are apparently setting:

(gdb) p txflk(npflka)
$8 = 0.19035648128912375
(gdb) p tyflk(npflka)
$9 = 0.27654783893032658
(gdb) p tzflk(npflka)
$10 = -0.96099757248514595

These are not normalized:

(gdb) p txflk(npflka)**2 + tyflk(npflka)**2 + tzflk(npflka)**2
$11 = 1.0362306315081538

I may have spotted the original sin:

      TXFLK(NPFLKA) = SQRT(1 - TZFLK(NPFLKA)**2) * COS(-3.14159+2*FLRNDM(DUMMY2) * 3.14159)
      TYFLK(NPFLKA) = SQRT(1 - TZFLK(NPFLKA)**2) * SIN(-3.14159+2*FLRNDM(DUMMY2) * 3.14159)

Note that the dummy variable is indeed dummy, one does not have an expectation of getting the same random number if you pass the same dummy argument variable name.

Since you’re calling FLRNDM twice, you’re using two different azimuthal angles for the x and the y components. So no wonder that things are not properly normalized. Please rephrase it in a slightly superior way:

      XI = FLRNDM(DUMMY2)
      TXFLK(NPFLKA) = SQRT(1 - TZFLK(NPFLKA)**2) * COS(-3.14159+2*XI*3.14159)
      TYFLK(NPFLKA) = SQRT(1 - TZFLK(NPFLKA)**2) * SIN(-3.14159+2*XI*3.14159)

And while at it, let’s go in a further superior fashion:

      XI = FLRNDM(DUMMY2)
      STH = SQRT((1.0D0 - TZFLK(NPFLKA))*(1.0D0 + TZFLK(NPFLKA)))
      TXFLK(NPFLKA) =  STH * COS(-3.14159+2*XI*3.14159)
      TYFLK(NPFLKA) =  STH * SIN(-3.14159+2*XI*3.14159)

… and why lose digits of \pi when we can keep many more?

      XI  = FLRNDM(DUMMY2)
      STH = SQRT((1.0D0 - TZFLK(NPFLKA))*(1.0D0 + TZFLK(NPFLKA)))
      TXFLK(NPFLKA) =  STH * COS(-PIPIPI + 2.0D0*XI*PIPIPI)
      TYFLK(NPFLKA) =  STH * SIN(-PIPIPI + 2.0D0*XI*PIPIPI)

You may even do a final explicit unit normalization (dividing all three components by the square root of the sum of their squares).

Cesc

PS: I’ve not looked at the rest of the source_2.f though. @jemancza will be utterly delighted to further assist you.

2 Likes
8

Hello, Francesc Salvat Pujol
Thank you for your answer, I will try your solution and hope to hear good news from me.

Yongce