Hello everybody,
I'm new at Elk and I am learning how to use it. I noticed that, even when running the examples, I get the following message:
"Note; The following floating-point exceptions are signalling: IEEE_INVALID_FLAG IEEE_UNDERFLOW_FLAG"
Should I worry about it?
Thank you in advance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At least in the test cases, these appear to be harmless and due to calculations involving numbers very close to zero, perhaps compounded by the suggested compiler flag -O3 for somewhat aggressive optimization that may rearrange lines of code.
You could recompile the code with --fpe-trap=invalid to abort with a floating point exception instead so you can identify the cause in a debugger ( also add "-g" to get meaningful backtraces).
Or see if dropping the optimization level to -O2
is sufficient to get rid of the warning - it does on the laptop I am currently traveling with, though the performance penalty could be noticable on expensive, long-running calculations.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Following my own advice, I have now played around a bit with "make test": The most common cause for the IEEE fault warnings here is a code snippet in genffacgp.f90 that is
basically "if this variable is above a certain threshold, divide "expression" by it, else use "simpler formula that does not have that division". One of the optimizations enabled by -O3 either manages to pull the denominator test out of the loop, or, perhaps more likely, both versions of the expression are calculated and the "correct" result chosen afterwards. Adding -fno-tree-loop-vectorize after the -O3 undoes that specific optimization. test-008 exercises additional exchange-correlation code from xc_pwca.f90, the ieee traps there can be avoided by supplying -fno-tree-partial-pre to undo that side effect of -O3.
Note that so far I have not seen any indications of actual miscalculations in connection with the underflow/invalid warnings, and I have also not done any benchmarks to assess the performance effect of dropping these two subsets of loop optimizations.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello everybody,
I'm new at Elk and I am learning how to use it. I noticed that, even when running the examples, I get the following message:
"Note; The following floating-point exceptions are signalling: IEEE_INVALID_FLAG IEEE_UNDERFLOW_FLAG"
Should I worry about it?
Thank you in advance.
At least in the test cases, these appear to be harmless and due to calculations involving numbers very close to zero, perhaps compounded by the suggested compiler flag -O3 for somewhat aggressive optimization that may rearrange lines of code.
You could recompile the code with --fpe-trap=invalid to abort with a floating point exception instead so you can identify the cause in a debugger ( also add "-g" to get meaningful backtraces).
Or see if dropping the optimization level to -O2
is sufficient to get rid of the warning - it does on the laptop I am currently traveling with, though the performance penalty could be noticable on expensive, long-running calculations.
Following my own advice, I have now played around a bit with "make test": The most common cause for the IEEE fault warnings here is a code snippet in genffacgp.f90 that is
basically "if this variable is above a certain threshold, divide "expression" by it, else use "simpler formula that does not have that division". One of the optimizations enabled by -O3 either manages to pull the denominator test out of the loop, or, perhaps more likely, both versions of the expression are calculated and the "correct" result chosen afterwards. Adding -fno-tree-loop-vectorize after the -O3 undoes that specific optimization. test-008 exercises additional exchange-correlation code from xc_pwca.f90, the ieee traps there can be avoided by supplying -fno-tree-partial-pre to undo that side effect of -O3.
Note that so far I have not seen any indications of actual miscalculations in connection with the underflow/invalid warnings, and I have also not done any benchmarks to assess the performance effect of dropping these two subsets of loop optimizations.