[Wien] Help Request for making WIEN2K (ver18.2) programs executable.

Wed Oct 24 09:24:18 CEST 2018

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).

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.

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.

Best regards

Pavel

---------- Původní e-mail ----------
Od: Gavin Abo <gsabo at crimson.ua.edu>
Komu: wien at zeus.theochem.tuwien.ac.at
Datum: 24. 10. 2018 4:19:56
Předmět: Re: [Wien] Help Request for making WIEN2K (ver18.2) programs 
executable. 
"Those gfortran warnings have been seen in symmetry [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17396.html 
] and dstart [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17389.html 
], which if I recall correctly were resolved by the fixes seen on the 
updated page [ http://susi.theochem.tuwien.ac.at/reg_user/updates/ ]:

VERSION_18.1: 1.6.2018
SRC_dstart: fix of zamt initialization
SRC_symmetry: setting yvec,zvec=0

>From the above, you can see that uninitialized variables in the code 
tend to be the cause of those type of warnings.  Apparently, ifort 
either handles them better (or ignores the issue).

It is not surprising and perhaps expected that those warnings might 
appear in more programs than just lapw0.  As I mentioned before, WIEN2k 
compiled with gfortran is less vetted and less maintained by the 
developers [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18018.html 
].  I suppose that is one drawback of using that free compiler. Though, 
I suppose Intel's recent 2016 or newer ifort compiler standardization 
changes breaking some of the WIEN2k code is perhaps not better in some 
cases [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17542.html 
].  So, pick your poison.

As mentioned on stackoverflow page at the link in the previous post at 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17385.html ,

I think the statement there describes well the meaning of those warning 
messages:

They can be a "hint about numerical problems in your code, but it is not 
an error per se."

Adding "-ffpe-summary=none" to the compiler settings might suppress that 
warning message when compiling with gfortran. However, I don't recommend 
doing that as it might suppress other more important warnings/errors.  
Someday in the future, 'maybe' the WIEN2k code could be reprogrammed to 
remove that warning message (which I think would be the proper way to 
remove that message).

In summary, unless you can fix the code yourself to remove the error, 
you would have the ignore them and continue on with your calculation 
unless it results in something absurdly wrong.

P.S., Pavel has been good at gfortran debugging and resolving those, 
which has been quite appreciated.  Though, I believe he is a user (not 
developer) less obligated to help fix such problems.

On 10/23/2018 2:27 PM, Ashwani Kumar wrote:
> thank you, Program compiled successfully withour any error. I tried to 
> remove manually but still some error occurred, Followed Mr. Gavin's 
> method (from previous thread) for LIBXC link to R_LIBS. Done 
> successfully. But while running an example of TiC (to check everything 
> is fine), STDOUT file shows warning message (for lapw0 and lapw2) but 
> program executed without error. I checked makefile, makefile.orig (and 
> makefile.orig_14 also for lapw0) and found nothing suspicious.
> **************************************************************************
********
> in cycle 9    ETEST: .0000154200000000   CTEST: .0009143
> STOP  LAPW0 END
> Note: The following floating-point exceptions are signalling: 
> IEEE_DENORMAL
> STOP  LAPW1 END
> STOP  LAPW2 END
> Note: The following floating-point exceptions are signalling: 
> IEEE_DENORMAL
> STOP  CORE  END
> Note: The following floating-point exceptions are signalling: 
> IEEE_INVALID_FLAG IEEE_DIVIDE_BY_ZERO IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
> STOP  MIXER END
> ec cc and fc_conv 1 0 1
> in cycle 10    ETEST: .0000051000000000   CTEST: .0005302
> STOP  LAPW0 END
> Note: The following floating-point exceptions are signalling: 
> IEEE_DENORMAL
> STOP  LAPW1 END
> STOP  LAPW2 END
> Note: The following floating-point exceptions are signalling: 
> IEEE_DENORMAL
> STOP  CORE  END
> Note: The following floating-point exceptions are signalling: 
> IEEE_INVALID_FLAG IEEE_DIVIDE_BY_ZERO IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
> STOP  MIXER END
> ec cc and fc_conv 1 0 1
> in cycle 11    ETEST: .0000031500000000   CTEST: .0000970
> STOP  LAPW0 END
> Note: The following floating-point exceptions are signalling: 
> IEEE_DENORMAL
> STOP  LAPW1 END
> STOP  LAPW2 END
> Note: The following floating-point exceptions are signalling: 
> IEEE_DENORMAL
> STOP  CORE  END
> Note: The following floating-point exceptions are signalling: 
> IEEE_INVALID_FLAG IEEE_DIVIDE_BY_ZERO IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
> STOP  MIXER END
> ec cc and fc_conv 1 1 1
>
> >   stop
> **************************************************************************
****************************************
> Please make me understand why the warning message appearing.
>
> thanks
> Ashwani Kumar
_______________________________________________
Wien mailing list
Wien at zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.
tuwien.ac.at/index.html
"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20181024/37522c43/attachment-0001.html>