[Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL

[Pavel Ondračka]

Ramsewak Kashyap píše v St 09. 05. 2018 v 17:04 +0530:

I did check the rest of the FPEs in the init_lapw and they seem to be
more or less harmless.

> >   symmetry	(16:23:21) Note: The following floating-point
> exceptions are signalling: IEEE_DENORMAL

Here I was not able to reproduce the signal at first, it only happens
once in about five runs, and running it under the gdb probably changes
the memory layout so I was not able to trap it. However valgrind shows
one problem:

==11648== Use of uninitialised value of size 8
==11648==    at 0x5A08D13: __printf_fp_l (in /usr/lib64/libc-2.26.so)
==11648==    by 0x5A02680: printf_positional (in /usr/lib64/libc-
2.26.so)
==11648==    by 0x5A053F1: vfprintf (in /usr/lib64/libc-2.26.so)
==11648==    by 0x5A2D10F: vsnprintf (in /usr/lib64/libc-2.26.so)
==11648==    by 0x5A0C6AE: snprintf (in /usr/lib64/libc-2.26.so)
==11648==    by 0x4FD50B6: ??? (in /usr/lib64/libgfortran.so.4.0.0)
==11648==    by 0x4FD63C3: ??? (in /usr/lib64/libgfortran.so.4.0.0)
==11648==    by 0x4FCD98C: ??? (in /usr/lib64/libgfortran.so.4.0.0)
==11648==    by 0x4FCDF9C: ??? (in /usr/lib64/libgfortran.so.4.0.0)
==11648==    by 0x410DA2: matrot_ (matrot.f:39)
==11648==    by 0x405089: class_ (class.f:332)
==11648==    by 0x402204: MAIN__ (symmetry.f:248)

It originates on line matrot.f:39

      write(66,16)       (XPRI(ix),ix=1,3),IFotro

where the XPRI is written to the output file.
The XPRI was passed to the matrot on class.f:332

      call matrot(zvec,yvec,ixy,rotloc,rotold,label)

as the yvec variable which is declared at the beginning of the file
class.f:8

dimension lm(2,49),zvec(3),yvec(3),rotloc(3,3),rotold(3,3)

but is not initialized before being passed to the matrot.

The XPRI is initialized later in the matrot subroutine, and only this
write to output file depends on the uninitialized value, hence this is
probably safe. It might lead to random output on the first
  y-rotation vector:  0.0000  0.0000  0.0000    0
line in case.outputs file (the first three numbers can have any value),
but unless this is read by some other program later, there should be no
other unwanted behavior (at least for the case of TiC). Also the
subnormal FPE is only produced when the random memory corresponding to
yvec (XPRI) has a specific pattern corresponding to subnormal number
(the sign and mantisa bits are zero), hence the randomness in the
reproducibility.

It can be fixed/silenced by initializing yvec to zero at the beginning
of class.f.

>  next is lstart 
>  2 Atoms found: Ti C 
> generate atomic configuration for atom 1 : Ti
> generate atomic configuration for atom 2 : C
>   SELECT XCPOT:
>   recommended: PBE    [(13) GGA of Perdew-Burke-Ernzerhof 96]
>                LDA    [( 5)]
>                WC     [(11)  GGA of Wu-Cohen 2006]
>                PBESOL [(19) GGA of Perdew etal. 2008]
>   SELECT ENERGY to separate core and valence states:
>   recommended: -6.0 Ry (check how much core charge leaks out of MT-
> sphere)
>   ALTERNATIVELY: specify charge localization (between 0.97 and 1.0)
> to select core state
> Note: The following floating-point exceptions are signalling:
> IEEE_UNDERFLOW_FLAG IEEE_DENORMAL

Here the underflow occurs in

#2  0x0000000000422682 in exchpw91 (d=8189.4727386259055,
s=2.7217425894173313, u=609.12528147145906, v=-273.35831133580342, 
    ex=-23.328241105666848, vx=-828.50827606010284) at pbe1.f:389
389	      P2 = DEXP(-A4*S2)
(gdb) print A4
$1 = 100
(gdb) print S2
$2 = 7.4078827230481599
(gdb) print P2
$3 = 4.5701072240315305e-321

An underflow for such exponential is expected and hence there is no
problem here IMO.

I'll take a look at the floating point signals in the main scf cycle
later.

Best regards
Pavel