GNU compiler issue - IEEE_DIVIDE_BY_ZERO IEEE_UNDERFLOW_FLAG

[walleludvig]

Hi,

I am seeking advice on how to deal with what seems to be a GNU compiler issue.

Every time I run a simulation with significant amount of histories (>1e6) the simulation breaks and reporting the following:

Note: The following floating-point exceptions are signalling: IEEE_DIVIDE_BY_ZERO IEEE_UNDERFLOW_FLAG

I have had a look around for records of similar errors and on the thread firemodels/fds#5638 it is suggested to add a flag of
-ffpe-trap=invalid,zero,overflow -ffpe-summary=none at compilation. However, I am unsure how to implement this with an already configured EGSnrc system.

Has anyone else ran into this issue with EGSnrc simulations and may know how to overcome it? I would hope to maybe add the flag mentioned above to compilation of one of my BEAMnrc accelerators but also not quite sure how to do exactly that.

Any help or advice is appreciated.

Thanks :D

[rtownson]

I haven't come across this before. You can set compiler flags in the .conf files in HEN_HOUSE/specs/, probably just to either the fortran or C++ flags depending on which application you're using. Then recompile the application (and HEN_HOUSE/egs++ if you're using an egs++ app). Let us know if it helps.

[walleludvig]

Thanks for your response @rtownson. I attempted to add the flag mentioned above to my osx.conf file and a file named Fortran-suse11.4.conf and then recompile one of my BEAMnrc accelerators however no change was observed. Would you be able to please specify what application you suggest that I recompile exactly? (Apologies for my ignorance on the issue). I am trying to run BEAMnrc applications.

[rtownson]

Can you also share your material file?

[walleludvig]

Apologies... Yes here it is:

XSample.txt

[rtownson]

You could try switching to an older version of gcc. I didn't have any issues running 2e6 particles, on gcc 4.8.5 (very old, I know). Try gcc 8?

[walleludvig]

Hi @rtownson,

I will try this at a later point when I need to simulate an experiment with larger amount of histories locally. For now I will use a virtual machine with Linux to perform my larger simulations after having used my personal computer for troubleshooting the implementations of my simulations.

However thank you so much for your suggestions and responses to this thread. I will post an update once I have attempted to switch to an older version of gcc.

[walleludvig]

Hi @rtownson,

I am coming back to this issue as I still cannot simulate a large enough amount of histories for my purposes, however I am wondering if I quoted an incorrect upper range for number of histories earlier as I am also able to run the input file provided above with 2M histories, however anything significantly above that (e.g, 3M) crashes with the error
Note: The following floating-point exceptions are signalling: IEEE_DIVIDE_BY_ZERO. I am wondering if you would be able to test it out again but n-histories bigger than before (e.g., 3M or 5M)?

I also wonder why you think an older gcc compiler might work better? I am currently using gcc-13 (Homebrew GCC 13.1.0) 13.1.0, and a bit hesitant to change this for my current installation of EGSnrc. I have a fair bit of work on my current install, that I would have to transfer and re-compile, and in the past I have struggled to make this work smoothly when re-installing EGSnrc to change compiler links. However, if need be I will definitely do it :)

[crcrewso]

Just taking a step back to basics, it's been a long time since I've looked at the gcc quirks on macs. Could you try recompiling with -mcmodel=large as an optimization argument and see what that changes? I did a lot of work to make sure that EGS could routinely handle 1e9 histories and I thought we had this licked

[walleludvig]

Hi @crcrewso,

Thanks for taking a look at this. I tried re-compiling my BEAMnrc accelerator after adding -mcmodel=large to FOPT in HEN_HOUSE/specs/osx.conf. The complete set of optimisation flags here was then FOPT = -O2 -mtune=native -mcmodel=large.

I now get a ton of errors when trying to compile my accelerator, all saying error: invalid variant 'BLEAH' occurring in different places. e.g., error: invalid variant 'BLEAH' adrp x23, lC9104@BLEAH.

Does this tell you anything?

[walleludvig]

@rtownson thank you very much for this information, that's very useful to know. Maybe there is something wrong with the way that I've set my DBS up? I will be testing some variations to this now.

[walleludvig]

@rtownson & @crcrewso, I think I have resolved my issues for running more than ~2M histories now. I am not entirely sure what the cause of the issue was, but I've got an input file that's working now. I realised that I had but my bremsstrahlung splitting rejection plane a centimetre closer than intended so made that change, but I do not understand that this difference would impact my ability to run some number of histories.

However, when I run diff on the 2 input files (one which can handle maximum ~1.5M and one which can seemingly handle any number of histories) I get the following differences:

4c4
< 2000000, 33, 97, 99.99, 2, 2000, 0, 0,  NCASE ETC.
---
> 10000000000, 33, 97, 99.99, 2, 2000, 0, 0,  NCASE ETC.
9c9
< 0, 0, 0.516, 0.005, 0, 0, 0,  0 , ECUT,PCUT,IREJCT,ESAVE
---
> 0, 0, 0.516, 0.005, 0, 0, ,  0 , ECUT,PCUT,IREJCT,ESAVE
103c103
<  Z(cm) from zero reference plane= 11.5
---
>  Z(cm) from zero reference plane= 12.5

Does this tell either of you about the root of the issue I was experiencing?

[rtownson]

@blakewalters any idea why this would be the case? The segmentation fault happens only with the rejection plane at some positions: works fine at 12.5, seg fault at 11.5 even with different seeds, hangs at 10.5, seg fault at 9.5..

[ojalaj]

Sorry to bump into this thread, but does it matter that in BEAMnrc manual p. 93 it says that "The rejection plane is meant to be placed in the air layer between the bottom of the last component in the accelerator geometry and the scoring plane."

In the provided .egsinp file and in your discussion above the plane in either within CM "filter" or in CM "collim".

[ojalaj]

@walleludvig did you give a try what I suggested above?