<html><body>It would be probably reasonable to add the "-ffpe-summary=none" to the default gfortran flags to not scare a new users (as this "issue") is being brought up over and over again (hint to prof. Blaha).<br><div><br></div><div>In fact, I tried quite hard to debug lot of those things and in general to hunt down the uninitialized stuff and the remaining ones (at least in the common codepaths) should be harmless. IIRC the denormals in lapw0 and lapw2 comes from something like "exp(-big_number)" which is completely OK and the scary ones IEEE_INVALID_FLAG IEEE_DIVIDE_BY_ZERO in mixer come from lapack-netlib/SRC/ieeeck.f function which is intentionally doing all the divide by zero and infinity math to check if it can depend on the compliance with the IEEE 754 standard.</div><div><br></div><div>Regarding the ifort vs gfortran, this is mostly a matter of personal taste. gfrortan strictly adheres to the Fortran specification and this caused some issues in the Wien2k code. gfortran is also somewhat slower but this is due to much more conservative default flags. At -O2 gfortran won't do any SIMD vectorization or loop unrolling in general, no link-time (interprocedural) optimizations and it strictly adheres to IEEE compliance (and does a lot or other stuff, like properly setting errno after library calls etc. which ifort does not do with the Wien2k flags). I can maybe someday write some blogpost which flags to use to get ifort-like behavior and speed.<br></div><div><br></div><div>Best regards</div><div>Pavel<br></div><div><br></div><div><br></div><aside>
---------- Původní e-mail ----------<br>
Od: Gavin Abo <gsabo@crimson.ua.edu><br>
Komu: wien@zeus.theochem.tuwien.ac.at<br>
Datum: 24. 10. 2018 4:19:56<br>
Předmět: Re: [Wien] Help Request for making WIEN2K (ver18.2) programs
executable.
</aside><br><blockquote data-email="gsabo@crimson.ua.edu">Those gfortran warnings have been seen in symmetry [ <br>https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17396.html <br>] and dstart [ <br>https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17389.html <br>], which if I recall correctly were resolved by the fixes seen on the <br>updated page [ http://susi.theochem.tuwien.ac.at/reg_user/updates/ ]:<br><br>VERSION_18.1: 1.6.2018<br>SRC_dstart: fix of zamt initialization<br>SRC_symmetry: setting yvec,zvec=0<br><br> From the above, you can see that uninitialized variables in the code <br>tend to be the cause of those type of warnings. Apparently, ifort <br>either handles them better (or ignores the issue).<br><br>It is not surprising and perhaps expected that those warnings might <br>appear in more programs than just lapw0. As I mentioned before, WIEN2k <br>compiled with gfortran is less vetted and less maintained by the <br>developers [ <br>https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18018.html <br>]. I suppose that is one drawback of using that free compiler. Though, <br>I suppose Intel's recent 2016 or newer ifort compiler standardization <br>changes breaking some of the WIEN2k code is perhaps not better in some <br>cases [ <br>https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17542.html <br>]. So, pick your poison.<br><br>As mentioned on stackoverflow page at the link in the previous post at <br>https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17385.html ,<br><br>I think the statement there describes well the meaning of those warning <br>messages:<br><br>They can be a "hint about numerical problems in your code, but it is not <br>an error per se."<br><br>Adding "-ffpe-summary=none" to the compiler settings might suppress that <br>warning message when compiling with gfortran. However, I don't recommend <br>doing that as it might suppress other more important warnings/errors. <br>Someday in the future, 'maybe' the WIEN2k code could be reprogrammed to <br>remove that warning message (which I think would be the proper way to <br>remove that message).<br><br>In summary, unless you can fix the code yourself to remove the error, <br>you would have the ignore them and continue on with your calculation <br>unless it results in something absurdly wrong.<br><br>P.S., Pavel has been good at gfortran debugging and resolving those, <br>which has been quite appreciated. Though, I believe he is a user (not <br>developer) less obligated to help fix such problems.<br><br>On 10/23/2018 2:27 PM, Ashwani Kumar wrote:<br>> thank you, Program compiled successfully withour any error. I tried to <br>> remove manually but still some error occurred, Followed Mr. Gavin's <br>> method (from previous thread) for LIBXC link to R_LIBS. Done <br>> successfully. But while running an example of TiC (to check everything <br>> is fine), STDOUT file shows warning message (for lapw0 and lapw2) but <br>> program executed without error. I checked makefile, makefile.orig (and <br>> makefile.orig_14 also for lapw0) and found nothing suspicious.<br>> **********************************************************************************<br>> in cycle 9 ETEST: .0000154200000000 CTEST: .0009143<br>> STOP LAPW0 END<br>> Note: The following floating-point exceptions are signalling: <br>> IEEE_DENORMAL<br>> STOP LAPW1 END<br>> STOP LAPW2 END<br>> Note: The following floating-point exceptions are signalling: <br>> IEEE_DENORMAL<br>> STOP CORE END<br>> Note: The following floating-point exceptions are signalling: <br>> IEEE_INVALID_FLAG IEEE_DIVIDE_BY_ZERO IEEE_UNDERFLOW_FLAG IEEE_DENORMAL<br>> STOP MIXER END<br>> ec cc and fc_conv 1 0 1<br>> in cycle 10 ETEST: .0000051000000000 CTEST: .0005302<br>> STOP LAPW0 END<br>> Note: The following floating-point exceptions are signalling: <br>> IEEE_DENORMAL<br>> STOP LAPW1 END<br>> STOP LAPW2 END<br>> Note: The following floating-point exceptions are signalling: <br>> IEEE_DENORMAL<br>> STOP CORE END<br>> Note: The following floating-point exceptions are signalling: <br>> IEEE_INVALID_FLAG IEEE_DIVIDE_BY_ZERO IEEE_UNDERFLOW_FLAG IEEE_DENORMAL<br>> STOP MIXER END<br>> ec cc and fc_conv 1 0 1<br>> in cycle 11 ETEST: .0000031500000000 CTEST: .0000970<br>> STOP LAPW0 END<br>> Note: The following floating-point exceptions are signalling: <br>> IEEE_DENORMAL<br>> STOP LAPW1 END<br>> STOP LAPW2 END<br>> Note: The following floating-point exceptions are signalling: <br>> IEEE_DENORMAL<br>> STOP CORE END<br>> Note: The following floating-point exceptions are signalling: <br>> IEEE_INVALID_FLAG IEEE_DIVIDE_BY_ZERO IEEE_UNDERFLOW_FLAG IEEE_DENORMAL<br>> STOP MIXER END<br>> ec cc and fc_conv 1 1 1<br>><br>> > stop<br>> ******************************************************************************************************************<br>> Please make me understand why the warning message appearing.<br>><br>> thanks<br>> Ashwani Kumar<br>_______________________________________________<br>Wien mailing list<br>Wien@zeus.theochem.tuwien.ac.at<br>http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien<br>SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html<br></blockquote></body></html>