Gnu: IEEE_DIVIDE_BY_ZERO IEEE_UNDERFLOW_FLAG IEEE_DENORMAL

[sbenkorichi]

@mcgratta @marcosvanella @gforney
Each time a simulation finishes successfully a note is displayed as the following:

STOP: FDS completed successfully (CHID: Test_Edev_case1)
Note: The following floating-point exceptions are signalling: IEEE_DIVIDE_BY_ZERO IEEE_UNDERFLOW_FLAG IEEE_DENORMAL

Doing some reading on this, this warning was added in june 2013 since Fortran 2008 standard require this type of reporting. So, with any version after gfortran-4.8 , this warning will be displayed.
This type of issue is caused by the internal LAPACK library, it calls a function IEEECK that does certain checks.

Normal exceptions of IEEE can be ignored:

IEEE_UNDERFLOW_FLAG is triggered when the result of an expression exceeds the precision of the variable being assigned the value. For most MESH variables this means a number smaller than E-38. This exception will also trigger IEEE_DENORMAL. This pair of flags can be triggered by parts of CLASS and WATDRN. The underflow error is typically inconsequential and should have no impact on the results of the simulation. It can be ignored.

Bad exceptions of IEEE
IEEE_DIVIDE_BY_ZERO is triggered when a number is divided by zero. This is more likely to occur by invalid drainage properties than bad parameterization. A common cause of the error is a cell that has invalid drainage properties, with drainage area, grid area, channel length, and/or channel slope set to zero.

One way to trace this warning is through adding this debugging flag: -ffpe-trap=invalid,zero .

-ffpe-trap=zero,overflow,underflow tells Fortran to trap the listed floating point errors (fpe). Having zero on the list means that if you divide by zero the code will die rather than setting the result to +INFINITY and continuing. Similarly, if overflow is on the list it will halt if you try to store a number larger than can be stored for the type of real number you are using because the exponent is too large.

Trapping underflow will halt if you compute a number that is too small because the exponent is a very large negative number. For 8-byte floating point numbers, this happens if the number is smaller than approximate 1E-324. If you don’t trap underflows, such numbers will just be set to 0, which is generally the correct thing to do. But computing such small numbers may indicate a bug of some sort in the program, so you might want to trap them.

Some reference for more info:
https://docs.oracle.com/cd/E19957-01/806-3568/ncg_handle.html
https://gcc.gnu.org/onlinedocs/gfortran/Debugging-Options.html

[sbenkorichi]

I found a fix to disable this note by adding another flag for the compiler: -ffpe-summary='none'
The simulation finishes with no warnings.

[sbenkorichi]

It's a bit a challenging to determine the real cause of this warning, it's not happening all times. Take for instances, the examples in detectors or extinction directory, they finish with no warnings, as for the majority of other input files they would throw this warning at the end.

[marcosvanella]

Salah, I looked into this issue with the test.fds case you set for the previous restart issue.

I used the -ffpe-trap=invalid,denormalized,zero,underflow,overflow flag to catch practically all floating point exceptions with an error.

The floating point exception I found at startup using the gnu debugger was in line 1300 of irad.f90. A normalized number was being multiplied by a denormalized number (very small number, e^(-70000)). This should not be a problem, as in fast math (optimized code) all these denormalized numbers are flushed to zero.

My take is, use:

-ffpe-trap=invalid,zero,overflow -ffpe-summary=none

as debug flags for gnu targets. These will trap with errors the divide by zero, overflow and invalid (i.e. SQRT(-1.0)) FPEs. The rest of the FPEs are of less importance and we leave them out.

I'll make a pull request with this change, so you test your cases, to see if things look good.

[sbenkorichi]

Marcos,
the flag you intend to set it for mpi_gnu_linux_64 or for the debug only?

[marcosvanella]

Debug only. Were we seeing the FPE summaries in optimized mode also?

[sbenkorichi]

Of course, it's happening in the optimised mode.
My suggestion is also to include at least -ffpe-summary='none' for the -O2 optimised mode, you wouldn't want each time a user report about these warnings that the compiler is sending. This way, at least we can make Gnu works as intel since it's ignoring them.

[marcosvanella]

Yeah, I just saw that. I'll add the suppress summary also on optimized targets.

[sbenkorichi]

Agreed !

[sbenkorichi]

Ok, they're gone.
I don't have much to do at this point.
Do you want to keep it open or close it?

[mcgratta]

Nice work. Let't close these off as we fix them.