Re: [Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL

[Pavel Ondračka]

On Tue, 2018-05-29 at 13:58 +0200, Peter Blaha wrote:
> I'm working on the new distribution, WIEN2k_18, where this variable 
> should be initialized.
> 
> It should come out within the next days ...

Thanks a lot, I'm looking forward to the new release.

Best regards
Pavel
> 
> On 05/29/2018 12:36 PM, Pavel Ondračka wrote:
> > On Wed, 2018-05-09 at 14:17 -0500, Laurence Marks wrote:
> > > You are right, this is a bug (potentially severe). In my local
> > > version I replaced somm with a more standard integration as somm
> > > interpolates to the origin (which is not right).
> > 
> > Will there be a fix for this bug?
> > 
> > Best regards
> > Pavel
> > > 
> > > On Wed, May 9, 2018 at 2:11 PM, Pavel Ondračka  > > ail.
> > > cz> wrote:
> > > > -- Původní e-mail --
> > > > Od: Laurence Marks 
> > > > Komu: A Mailing list for WIEN2k users  > > > n.ac
> > > > .at>
> > > > Datum: 9. 5. 2018 18:18:21
> > > > Předmět: Re: [Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
> > > > 
> > > > > Zamt is set by somm, which is a slightly inaccurate Simpson
> > > > > summation (the accuracy does not matter). Hence it does not
> > > > > need
> > > > > to be set previously.
> > > > 
> > > > Right, it is indeed set in the somm subroutine. The problem is
> > > > that
> > > > the DA variable (the local name for zamt variable in the somm
> > > > subroutine) is set for the first time on line 11, while it is
> > > > used
> > > > (read) for the first time earlier on line 10 (and this is the
> > > > line
> > > > when the gcc and valgrind complains)! Hence when the subroutine
> > > > is
> > > > called for the first time, the results depends on read from
> > > > uninitialized memory.
> > > > Best regards
> > > > Pavel
> > > >   
> > > > > _
> > > > > Professor Laurence Marks
> > > > > "Research is to see what everybody else has seen, and to
> > > > > think
> > > > > what nobody else has thought", Albert Szent-Gyorgi
> > > > > www.numis.northwestern.edu
> > > > > 
> > > > > On Wed, May 9, 2018, 10:42 AM Pavel Ondračka  > > > > emai
> > > > > l.cz> wrote:
> > > > > > Laurence Marks píše v St 09. 05. 2018 v 11:51 +:
> > > > > > > This appears to be due to a silly approach in gfortran,
> > > > > > > and
> > > > > > 
> > > > > > almost
> > > > > > > certainly is not an error/problem and can be ignored --
> > > > > > > see h
> > > > > > 
> > > > > > ttps://urldefense.proofpoint.com/v2/url?u=https-
> > > > > > 3A__s=DwIGaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6w
> > > > > > s=
> > > > > > U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=R1lxmwh4Y3r4y
> > > > > > Rx1Z
> > > > > > yR4NN9mpSe7RuaT974qRm6Uhfw=KDobN5dacXxTk7OUpO1BdJBY45FBX3
> > > > > > 4Hf6
> > > > > > Q9hTempg0=
> > > > > > > tackoverflow.com/questions/44308577/ieee-underflow-flag-
> > > > > > > ieee-
> > > > > > > denormal-in-fortran-77.
> > > > > > > 
> > > > > > 
> > > > > > While I do agree that in most cases this is harmless, it
> > > > > > can
> > > > > > also
> > > > > > suggest a bug.
> > > > > > 
> > > > > > I only looked at dstart for the TiC and I have this
> > > > > > specific
> > > > > > example:
> > > > > > 
> > > > > > dstart for a TiC case prints a "Note: The following
> > > > > > floating-
> > > > > > point
> > > > > > exceptions are signalling: IEEE_DENORMAL" line. If you trap
> > > > > > this with
> > > > > > -ffpe-trap='denormal' flag, to inspect in gdb, the
> > > > > > offending
> > > > > > line is
> > > > > > then:
> > > > > > Program received signal SIGFPE, Arithmetic exception.
> > > > > > 0x0041dc48 in somm (dr=..., dp=...,
> > > > > > dpas=0.

Re: [Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL

[Peter Blaha]

I'm working on the new distribution, WIEN2k_18, where this variable 
should be initialized.


It should come out within the next days ...


On 05/29/2018 12:36 PM, Pavel Ondračka wrote:

On Wed, 2018-05-09 at 14:17 -0500, Laurence Marks wrote:

You are right, this is a bug (potentially severe). In my local
version I replaced somm with a more standard integration as somm
interpolates to the origin (which is not right).


Will there be a fix for this bug?

Best regards
Pavel


On Wed, May 9, 2018 at 2:11 PM, Pavel Ondračka  wrote:

-- Původní e-mail --
Od: Laurence Marks 
Komu: A Mailing list for WIEN2k users 
Datum: 9. 5. 2018 18:18:21
Předmět: Re: [Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL


Zamt is set by somm, which is a slightly inaccurate Simpson
summation (the accuracy does not matter). Hence it does not need
to be set previously.


Right, it is indeed set in the somm subroutine. The problem is that
the DA variable (the local name for zamt variable in the somm
subroutine) is set for the first time on line 11, while it is used
(read) for the first time earlier on line 10 (and this is the line
when the gcc and valgrind complains)! Hence when the subroutine is
called for the first time, the results depends on read from
uninitialized memory.
Best regards
Pavel
  

_
Professor Laurence Marks
"Research is to see what everybody else has seen, and to think
what nobody else has thought", Albert Szent-Gyorgi
www.numis.northwestern.edu

On Wed, May 9, 2018, 10:42 AM Pavel Ondračka  wrote:

Laurence Marks píše v St 09. 05. 2018 v 11:51 +:

This appears to be due to a silly approach in gfortran, and

almost

certainly is not an error/problem and can be ignored -- see h

ttps://urldefense.proofpoint.com/v2/url?u=https-
3A__s=DwIGaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=
U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=R1lxmwh4Y3r4yRx1Z
yR4NN9mpSe7RuaT974qRm6Uhfw=KDobN5dacXxTk7OUpO1BdJBY45FBX34Hf6
Q9hTempg0=

tackoverflow.com/questions/44308577/ieee-underflow-flag-ieee-
denormal-in-fortran-77.



While I do agree that in most cases this is harmless, it can
also
suggest a bug.

I only looked at dstart for the TiC and I have this specific
example:

dstart for a TiC case prints a "Note: The following floating-
point
exceptions are signalling: IEEE_DENORMAL" line. If you trap
this with
-ffpe-trap='denormal' flag, to inspect in gdb, the offending
line is
then:
Program received signal SIGFPE, Arithmetic exception.
0x0041dc48 in somm (dr=..., dp=...,
dpas=0.013585429144994965,
da=1.1588924125005173e-310, m=0, np=935) at somm.f:10
10D1=DA+MM

so this line looks completely harmless and some prints show why
the
compiler notes about this:

(gdb) print DA
$1 = 1.1588924125005173e-310
(gdb) print MM
$2 = 1

i.e. we just add a really small number (denormal, since
DOUBLE_MIN is
around 1.8e-308) to 1, which is completely OK. But lets take a
look
where this incredibly small value comes from...

(gdb) up
#1  0x004143c6 in make_spheres (lcore=.FALSE., luse=7)
at
make_spheres.F:81
81   call
somm(rat(1,ia),rhoat(1,ia),dx(ia),zamt,0,nptat(ia))

So this is the zamt variable, surprisingly grepping around for
zamt
finds nothing. As far as I can see it is not declared or
initialized
anywere in dstart. If I just missed something please correct
me! The
same goes for the zamt1 and zamt2.

Note that in this case we get lucky since the random memory
value is
effectively zero, however this might in my opinion lead to
problems if
you hit random memory with another value.
In fact running the dstart in vagrind shows this as well and
the
terminal is spammed with "Conditional jump or move depends on
uninitialised value(s)" and "Use of uninitialised value of size
8".

IMO this is a bug, so either the line needs to be changed to
somm(rat(1,ia),rhoat(1,ia),dx(ia),0,0,nptat(ia))
or the zamt variable needs to be declared and initialized
somewhere.
But I actually have no idea about the physical meaning of the
code so
please correct me if I just missed something.

Best regards
Pavel
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.theoch
em.tuwien.ac.at_mailman_listinfo_wien=DwIGaQ=yHlS04HhBraes5
BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnv
qKFdqWLwmqg0=R1lxmwh4Y3r4yRx1ZyR4NN9mpSe7RuaT974qRm6Uhfw=_8
Uru9zRH580QrhtgA9HnU1x81x6paXIOqJCFnOzZME=
SEARCH the MAILING-LIST at:  https://urldefense.proofpoint.com/
v2/url?u=http-3A__www.mail-2Darchive.com_wien-
40zeus.theochem.tuwien.ac.at_index.html=DwIGaQ=yHlS04HhBrae
s5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818j
nvqKFdqWLwmqg0=R1lxmwh4Y3r4yRx1ZyR4NN9mpSe7RuaT974qRm6Uhfw=
SJYF9VBF7xwkjpCyB76TXcIRXzDcFX3xCQlsoQ4RwIw=


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEA

Re: [Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL

[Pavel Ondračka]

On Wed, 2018-05-09 at 14:17 -0500, Laurence Marks wrote:
> You are right, this is a bug (potentially severe). In my local
> version I replaced somm with a more standard integration as somm
> interpolates to the origin (which is not right).

Will there be a fix for this bug?

Best regards
Pavel
> 
> On Wed, May 9, 2018 at 2:11 PM, Pavel Ondračka  cz> wrote:
> > -- Původní e-mail --
> > Od: Laurence Marks 
> > Komu: A Mailing list for WIEN2k users  > .at>
> > Datum: 9. 5. 2018 18:18:21
> > Předmět: Re: [Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
> > 
> > > Zamt is set by somm, which is a slightly inaccurate Simpson
> > > summation (the accuracy does not matter). Hence it does not need
> > > to be set previously.
> > 
> > Right, it is indeed set in the somm subroutine. The problem is that
> > the DA variable (the local name for zamt variable in the somm
> > subroutine) is set for the first time on line 11, while it is used
> > (read) for the first time earlier on line 10 (and this is the line
> > when the gcc and valgrind complains)! Hence when the subroutine is
> > called for the first time, the results depends on read from
> > uninitialized memory.
> > Best regards
> > Pavel
> >  
> > > _
> > > Professor Laurence Marks
> > > "Research is to see what everybody else has seen, and to think
> > > what nobody else has thought", Albert Szent-Gyorgi
> > > www.numis.northwestern.edu
> > > 
> > > On Wed, May 9, 2018, 10:42 AM Pavel Ondračka  > > l.cz> wrote:
> > > > Laurence Marks píše v St 09. 05. 2018 v 11:51 +:
> > > > > This appears to be due to a silly approach in gfortran, and
> > > > almost
> > > > > certainly is not an error/problem and can be ignored -- see h
> > > > ttps://urldefense.proofpoint.com/v2/url?u=https-
> > > > 3A__s=DwIGaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=
> > > > U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=R1lxmwh4Y3r4yRx1Z
> > > > yR4NN9mpSe7RuaT974qRm6Uhfw=KDobN5dacXxTk7OUpO1BdJBY45FBX34Hf6
> > > > Q9hTempg0=
> > > > > tackoverflow.com/questions/44308577/ieee-underflow-flag-ieee-
> > > > > denormal-in-fortran-77.
> > > > > 
> > > > 
> > > > While I do agree that in most cases this is harmless, it can
> > > > also
> > > > suggest a bug.
> > > > 
> > > > I only looked at dstart for the TiC and I have this specific
> > > > example:
> > > > 
> > > > dstart for a TiC case prints a "Note: The following floating-
> > > > point
> > > > exceptions are signalling: IEEE_DENORMAL" line. If you trap
> > > > this with
> > > > -ffpe-trap='denormal' flag, to inspect in gdb, the offending
> > > > line is
> > > > then:
> > > > Program received signal SIGFPE, Arithmetic exception.
> > > > 0x0041dc48 in somm (dr=..., dp=...,
> > > > dpas=0.013585429144994965,
> > > > da=1.1588924125005173e-310, m=0, np=935) at somm.f:10
> > > > 10D1=DA+MM
> > > > 
> > > > so this line looks completely harmless and some prints show why
> > > > the
> > > > compiler notes about this:
> > > > 
> > > > (gdb) print DA
> > > > $1 = 1.1588924125005173e-310
> > > > (gdb) print MM
> > > > $2 = 1
> > > > 
> > > > i.e. we just add a really small number (denormal, since
> > > > DOUBLE_MIN is
> > > > around 1.8e-308) to 1, which is completely OK. But lets take a
> > > > look
> > > > where this incredibly small value comes from...
> > > > 
> > > > (gdb) up
> > > > #1  0x004143c6 in make_spheres (lcore=.FALSE., luse=7)
> > > > at
> > > > make_spheres.F:81
> > > > 81   call
> > > > somm(rat(1,ia),rhoat(1,ia),dx(ia),zamt,0,nptat(ia))
> > > > 
> > > > So this is the zamt variable, surprisingly grepping around for
> > > > zamt
> > > > finds nothing. As far as I can see it is not declared or
> > > > initialized
> > > > anywere in dstart. If I just missed something please correct
> > > > me! The
> > > > same goes for the zamt1 and zamt2.
> > > > 
> > > > Note that in this case we get lucky since the random memory
> > > > value i

Re: [Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL

[Laurence Marks]

I can look -- but Peter is in charge of the code.

On Wed, May 9, 2018 at 2:30 PM, Pavel Ondračka <pavel.ondra...@email.cz>
wrote:

> -- Původní e-mail --
> Od: Laurence Marks <l-ma...@northwestern.edu>
> Komu: A Mailing list for WIEN2k users <wien@zeus.theochem.tuwien.ac.at>
> Datum: 9. 5. 2018 21:18:20
> Předmět: Re: [Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
>
> You are right, this is a bug (potentially severe). In my local version I
> replaced somm with a more standard integration as somm interpolates to the
> origin (which is not right).
>
>
> Thanks for looking into this, hopefully the fix is not too hard. BTW if I
> provide similar analysis also for the other occurrences of floating point
> exceptions and/or valgrind uninitialized read/write errors, would you be
> willing to check whether those are harmless or real problems as well?
>
>
> Best regards
>
> Pavel
>
>


-- 
Professor Laurence Marks
"Research is to see what everybody else has seen, and to think what nobody
else has thought", Albert Szent-Gyorgi
www.numis.northwestern.edu ; Corrosion in 4D: MURI4D.numis.northwestern.edu
Partner of the CFW 100% program for gender equity, www.cfw.org/100-percent
Co-Editor, Acta Cryst A
___
Wien mailing list
Wien@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

Re: [Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL

[Pavel Ondračka]

-- Původní e-mail --
Od: Laurence Marks <l-ma...@northwestern.edu>
Komu: A Mailing list for WIEN2k users <wien@zeus.theochem.tuwien.ac.at>
Datum: 9. 5. 2018 21:18:20
Předmět: Re: [Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
"
You are right, this is a bug (potentially severe). In my local version I 
replaced somm with a more standard integration as somm interpolates to the
origin (which is not right).

 
"
Thanks for looking into this, hopefully the fix is not too hard. BTW if I 
provide similar analysis also for the other occurrences of floating point 
exceptions and/or valgrind uninitialized read/write errors, would you be 
willing to check whether those are harmless or real problems as well?




Best regards

Pavel

"

"___
Wien mailing list
Wien@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

Re: [Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL

[Laurence Marks]

You are right, this is a bug (potentially severe). In my local version I
replaced somm with a more standard integration as somm interpolates to the
origin (which is not right).

On Wed, May 9, 2018 at 2:11 PM, Pavel Ondračka <pavel.ondra...@email.cz>
wrote:

> -- Původní e-mail --
> Od: Laurence Marks <l-ma...@northwestern.edu>
> Komu: A Mailing list for WIEN2k users <wien@zeus.theochem.tuwien.ac.at>
> Datum: 9. 5. 2018 18:18:21
> Předmět: Re: [Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
>
> Zamt is set by somm, which is a slightly inaccurate Simpson summation (the
> accuracy does not matter). Hence it does not need to be set previously.
>
>
> Right, it is indeed set in the somm subroutine. The problem is that the DA
> variable (the local name for zamt variable in the somm subroutine) is set
> for the first time on line 11, while it is used (read) for the first time
> earlier on line 10 (and this is the line when the gcc and valgrind
> complains)! Hence when the subroutine is called for the first time, the
> results depends on read from uninitialized memory.
>
> Best regards
>
> Pavel
>
>
>
>
> _
> Professor Laurence Marks
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought", Albert Szent-Gyorgi
> www.numis.northwestern.edu
>
> On Wed, May 9, 2018, 10:42 AM Pavel Ondračka <pavel.ondra...@email.cz>
> wrote:
>
> Laurence Marks píše v St 09. 05. 2018 v 11:51 +:
> > This appears to be due to a silly approach in gfortran, and almost
> > certainly is not an error/problem and can be ignored -- see
> https://urldefense.proofpoint.com/v2/url?u=https-3A__s=DwIGaQ=
> yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_
> T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=R1lxmwh4Y3r4yRx1ZyR4NN9mpSe7Ru
> aT974qRm6Uhfw=KDobN5dacXxTk7OUpO1BdJBY45FBX34Hf6Q9hTempg0=
> > tackoverflow.com/questions/44308577/ieee-underflow-flag-ieee-
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__tackoverflow.com_questions_44308577_ieee-2Dunderflow-2Dflag-2Dieee-2D=DwMFaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=UwZ1bSYK6i7lR0yGpC7Hknoy6JY6oBi3nk1UgjeA0DI=oXUXMikarmZPWkv9fORKiLM0LSpZVQPZ_CslUzYPWfY=>
> > denormal-in-fortran-77.
> >
>
> While I do agree that in most cases this is harmless, it can also
> suggest a bug.
>
> I only looked at dstart for the TiC and I have this specific example:
>
> dstart for a TiC case prints a "Note: The following floating-point
> exceptions are signalling: IEEE_DENORMAL" line. If you trap this with
> -ffpe-trap='denormal' flag, to inspect in gdb, the offending line is
> then:
> Program received signal SIGFPE, Arithmetic exception.
> 0x0041dc48 in somm (dr=..., dp=..., dpas=0.013585429144994965,
> da=1.1588924125005173e-310, m=0, np=935) at somm.f:10
> 10D1=DA+MM
>
> so this line looks completely harmless and some prints show why the
> compiler notes about this:
>
> (gdb) print DA
> $1 = 1.1588924125005173e-310
> (gdb) print MM
> $2 = 1
>
> i.e. we just add a really small number (denormal, since DOUBLE_MIN is
> around 1.8e-308) to 1, which is completely OK. But lets take a look
> where this incredibly small value comes from...
>
> (gdb) up
> #1  0x004143c6 in make_spheres (lcore=.FALSE., luse=7) at
> make_spheres.F:81
> 81   call
> somm(rat(1,ia),rhoat(1,ia),dx(ia),zamt,0,nptat(ia))
>
> So this is the zamt variable, surprisingly grepping around for zamt
> finds nothing. As far as I can see it is not declared or initialized
> anywere in dstart. If I just missed something please correct me! The
> same goes for the zamt1 and zamt2.
>
> Note that in this case we get lucky since the random memory value is
> effectively zero, however this might in my opinion lead to problems if
> you hit random memory with another value.
> In fact running the dstart in vagrind shows this as well and the
> terminal is spammed with "Conditional jump or move depends on
> uninitialised value(s)" and "Use of uninitialised value of size 8".
>
> IMO this is a bug, so either the line needs to be changed to
> somm(rat(1,ia),rhoat(1,ia),dx(ia),0,0,nptat(ia))
> or the zamt variable needs to be declared and initialized somewhere.
> But I actually have no idea about the physical meaning of the code so
> please correct me if I just missed something.
>
> Best regards
> Pavel
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
> https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.
> theochem.tuwien.ac.at_mailman_listinfo_wien=DwIGaQ=
> yH

Re: [Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL

[Pavel Ondračka]

-- Původní e-mail --
Od: Laurence Marks <l-ma...@northwestern.edu>
Komu: A Mailing list for WIEN2k users <wien@zeus.theochem.tuwien.ac.at>
Datum: 9. 5. 2018 18:18:21
Předmět: Re: [Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
"
Zamt is set by somm, which is a slightly inaccurate Simpson summation (the
accuracy does not matter). Hence it does not need to be set previously.

"



Right, it is indeed set in the somm subroutine. The problem is that the DA
variable (the local name for zamt variable in the somm subroutine) is set 
for the first time on line 11, while it is used (read) for the first time 
earlier on line 10 (and this is the line when the gcc and valgrind
complains)! Hence when the subroutine is called for the first time, the 
results depends on read from uninitialized memory.

Best regards

Pavel


 
"


_
Professor Laurence Marks
"Research is to see what everybody else has seen, and to think what nobody
else has thought", Albert Szent-Gyorgi
www.numis.northwestern.edu(http://www.numis.northwestern.edu)




On Wed, May 9, 2018, 10:42 AM Pavel Ondračka <pavel.ondra...@email.cz
(mailto:pavel.ondra...@email.cz)> wrote:

"Laurence Marks píše v St 09. 05. 2018 v 11:51 +:
> This appears to be due to a silly approach in gfortran, and almost
> certainly is not an error/problem and can be ignored -- see https://
urldefense.proofpoint.com/v2/url?u=https-3A__s=DwIGaQ=yHlS04HhBraes5BQ9
ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=R
1lxmwh4Y3r4yRx1ZyR4NN9mpSe7RuaT974qRm6Uhfw=KDobN5dacXxTk7OUpO1BdJBY45FBX34
Hf6Q9hTempg0=
(https://urldefense.proofpoint.com/v2/url?u=https-3A__s=DwIGaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=R1lxmwh4Y3r4yRx1ZyR4NN9mpSe7RuaT974qRm6Uhfw=KDobN5dacXxTk7OUpO1BdJBY45FBX34Hf6Q9hTempg0=)
> tackoverflow.com/questions/44308577/ieee-underflow-flag-ieee-
(http://tackoverflow.com/questions/44308577/ieee-underflow-flag-ieee-)
> denormal-in-fortran-77.
>

While I do agree that in most cases this is harmless, it can also
suggest a bug.

I only looked at dstart for the TiC and I have this specific example:

dstart for a TiC case prints a "Note: The following floating-point
exceptions are signalling: IEEE_DENORMAL" line. If you trap this with
-ffpe-trap='denormal' flag, to inspect in gdb, the offending line is
then:
Program received signal SIGFPE, Arithmetic exception.
0x0041dc48 in somm (dr=..., dp=..., dpas=0.013585429144994965,
da=1.1588924125005173e-310, m=0, np=935) at somm.f:10
10            D1=DA+MM

so this line looks completely harmless and some prints show why the
compiler notes about this:

(gdb) print DA
$1 = 1.1588924125005173e-310
(gdb) print MM
$2 = 1

i.e. we just add a really small number (denormal, since DOUBLE_MIN is
around 1.8e-308) to 1, which is completely OK. But lets take a look
where this incredibly small value comes from...

(gdb) up
#1  0x004143c6 in make_spheres (lcore=.FALSE., luse=7) at
make_spheres.F:81
81               call
 somm(rat(1,ia),rhoat(1,ia),dx(ia),zamt,0,nptat(ia))

So this is the zamt variable, surprisingly grepping around for zamt
finds nothing. As far as I can see it is not declared or initialized
anywere in dstart. If I just missed something please correct me! The
same goes for the zamt1 and zamt2.

Note that in this case we get lucky since the random memory value is
effectively zero, however this might in my opinion lead to problems if
you hit random memory with another value.
In fact running the dstart in vagrind shows this as well and the
terminal is spammed with "Conditional jump or move depends on
uninitialised value(s)" and "Use of uninitialised value of size 8".

IMO this is a bug, so either the line needs to be changed to
somm(rat(1,ia),rhoat(1,ia),dx(ia),0,0,nptat(ia))
or the zamt variable needs to be declared and initialized somewhere.
But I actually have no idea about the physical meaning of the code so
please correct me if I just missed something.

Best regards
Pavel
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at(mailto:Wien@zeus.theochem.tuwien.ac.at)
https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.theochem.tuwien.ac.
at_mailman_listinfo_wien=DwIGaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA
6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=R1lxmwh4Y3r4yRx1ZyR4NN9
mpSe7RuaT974qRm6Uhfw=_8Uru9zRH580QrhtgA9HnU1x81x6paXIOqJCFnOzZME=
(https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwIGaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=R1lxmwh4Y3r4yRx1ZyR4NN9mpSe7RuaT974qRm6Uhfw=_8Uru9zRH580QrhtgA9HnU1x81x6paXIOqJCFnOzZME=)
SEARCH the MAILING-LIST at:  https://urldefense.proofpoint.com/v2/url?u=http
-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_index.html=
Dw

Re: [Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL

[Laurence Marks]

Zamt is set by somm, which is a slightly inaccurate Simpson summation (the
accuracy does not matter). Hence it does not need to be set previously.

_
Professor Laurence Marks
"Research is to see what everybody else has seen, and to think what nobody
else has thought", Albert Szent-Gyorgi
www.numis.northwestern.edu

On Wed, May 9, 2018, 10:42 AM Pavel Ondračka 
wrote:

> Laurence Marks píše v St 09. 05. 2018 v 11:51 +:
> > This appears to be due to a silly approach in gfortran, and almost
> > certainly is not an error/problem and can be ignored -- see
> https://urldefense.proofpoint.com/v2/url?u=https-3A__s=DwIGaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=R1lxmwh4Y3r4yRx1ZyR4NN9mpSe7RuaT974qRm6Uhfw=KDobN5dacXxTk7OUpO1BdJBY45FBX34Hf6Q9hTempg0=
> > tackoverflow.com/questions/44308577/ieee-underflow-flag-ieee-
> > denormal-in-fortran-77.
> >
>
> While I do agree that in most cases this is harmless, it can also
> suggest a bug.
>
> I only looked at dstart for the TiC and I have this specific example:
>
> dstart for a TiC case prints a "Note: The following floating-point
> exceptions are signalling: IEEE_DENORMAL" line. If you trap this with
> -ffpe-trap='denormal' flag, to inspect in gdb, the offending line is
> then:
> Program received signal SIGFPE, Arithmetic exception.
> 0x0041dc48 in somm (dr=..., dp=..., dpas=0.013585429144994965,
> da=1.1588924125005173e-310, m=0, np=935) at somm.f:10
> 10D1=DA+MM
>
> so this line looks completely harmless and some prints show why the
> compiler notes about this:
>
> (gdb) print DA
> $1 = 1.1588924125005173e-310
> (gdb) print MM
> $2 = 1
>
> i.e. we just add a really small number (denormal, since DOUBLE_MIN is
> around 1.8e-308) to 1, which is completely OK. But lets take a look
> where this incredibly small value comes from...
>
> (gdb) up
> #1  0x004143c6 in make_spheres (lcore=.FALSE., luse=7) at
> make_spheres.F:81
> 81   call
> somm(rat(1,ia),rhoat(1,ia),dx(ia),zamt,0,nptat(ia))
>
> So this is the zamt variable, surprisingly grepping around for zamt
> finds nothing. As far as I can see it is not declared or initialized
> anywere in dstart. If I just missed something please correct me! The
> same goes for the zamt1 and zamt2.
>
> Note that in this case we get lucky since the random memory value is
> effectively zero, however this might in my opinion lead to problems if
> you hit random memory with another value.
> In fact running the dstart in vagrind shows this as well and the
> terminal is spammed with "Conditional jump or move depends on
> uninitialised value(s)" and "Use of uninitialised value of size 8".
>
> IMO this is a bug, so either the line needs to be changed to
> somm(rat(1,ia),rhoat(1,ia),dx(ia),0,0,nptat(ia))
> or the zamt variable needs to be declared and initialized somewhere.
> But I actually have no idea about the physical meaning of the code so
> please correct me if I just missed something.
>
> Best regards
> Pavel
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwIGaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=R1lxmwh4Y3r4yRx1ZyR4NN9mpSe7RuaT974qRm6Uhfw=_8Uru9zRH580QrhtgA9HnU1x81x6paXIOqJCFnOzZME=
> SEARCH the MAILING-LIST at:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_index.html=DwIGaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=R1lxmwh4Y3r4yRx1ZyR4NN9mpSe7RuaT974qRm6Uhfw=SJYF9VBF7xwkjpCyB76TXcIRXzDcFX3xCQlsoQ4RwIw=
>
___
Wien mailing list
Wien@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

Re: [Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL

[Pavel Ondračka]

Laurence Marks píše v St 09. 05. 2018 v 11:51 +:
> This appears to be due to a silly approach in gfortran, and almost
> certainly is not an error/problem and can be ignored -- see https://s
> tackoverflow.com/questions/44308577/ieee-underflow-flag-ieee-
> denormal-in-fortran-77.
> 

While I do agree that in most cases this is harmless, it can also
suggest a bug.

I only looked at dstart for the TiC and I have this specific example:

dstart for a TiC case prints a "Note: The following floating-point
exceptions are signalling: IEEE_DENORMAL" line. If you trap this with
-ffpe-trap='denormal' flag, to inspect in gdb, the offending line is
then:
Program received signal SIGFPE, Arithmetic exception.
0x0041dc48 in somm (dr=..., dp=..., dpas=0.013585429144994965,
da=1.1588924125005173e-310, m=0, np=935) at somm.f:10
10D1=DA+MM

so this line looks completely harmless and some prints show why the
compiler notes about this:

(gdb) print DA
$1 = 1.1588924125005173e-310
(gdb) print MM
$2 = 1

i.e. we just add a really small number (denormal, since DOUBLE_MIN is
around 1.8e-308) to 1, which is completely OK. But lets take a look
where this incredibly small value comes from...

(gdb) up
#1  0x004143c6 in make_spheres (lcore=.FALSE., luse=7) at
make_spheres.F:81
81   call
somm(rat(1,ia),rhoat(1,ia),dx(ia),zamt,0,nptat(ia))

So this is the zamt variable, surprisingly grepping around for zamt
finds nothing. As far as I can see it is not declared or initialized
anywere in dstart. If I just missed something please correct me! The
same goes for the zamt1 and zamt2.

Note that in this case we get lucky since the random memory value is
effectively zero, however this might in my opinion lead to problems if
you hit random memory with another value.
In fact running the dstart in vagrind shows this as well and the
terminal is spammed with "Conditional jump or move depends on
uninitialised value(s)" and "Use of uninitialised value of size 8".

IMO this is a bug, so either the line needs to be changed to 
somm(rat(1,ia),rhoat(1,ia),dx(ia),0,0,nptat(ia))
or the zamt variable needs to be declared and initialized somewhere.
But I actually have no idea about the physical meaning of the code so
please correct me if I just missed something.

Best regards
Pavel
___
Wien mailing list
Wien@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

Re: [Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL

[Laurence Marks]

This appears to be due to a silly approach in gfortran, and almost
certainly is not an error/problem and can be ignored -- see
https://stackoverflow.com/questions/44308577/ieee-underflow-flag-ieee-denormal-in-fortran-77
.

_
Professor Laurence Marks
"Research is to see what everybody else has seen, and to think what nobody
else has thought", Albert Szent-Gyorgi
www.numis.northwestern.edu

On Wed, May 9, 2018, 6:35 AM Ramsewak Kashyap  wrote:

> Sir,
> I am trying one most common example TiC in newly installed wien2k code. and 
> getting following error:
>
>
> next is setrmt
>  next is nn
> STOP NN ENDS
>  specify nn-bondlength factor: (usually=2) [and optionally dlimit, dstmax 
> (about 1.d-5, 20)]
>  DSTMAX:   20.000
>  iix,iiy,iiz   5   5   5   40.8936892
> 40.893689240.8936892
>
> ATOM  1  Ti ATOM  2  C
>  RMT(  1)=2.12000 AND RMT(  2)=1.74000
>  SUMS TO 3.86000  LT.  NN-DIST= 4.08937
>
> ATOM  2  C  ATOM  1  Ti
>  RMT(  2)=1.74000 AND RMT(  1)=2.12000
>  SUMS TO 3.86000  LT.  NN-DIST= 4.08937
> 0.0u 0.0s 0:00.00 0.0% 0+0k 0+0io 0pf+0w
>  next is sgroup
> >   sgroup(16:23:21) 0.0u 0.0s 0:00.00 0.0% 0+0k 0+0io 0pf+0w
>   Names of point group: m-3m   4/m -3 2/m   Oh
>   Names of point group: m-3m   4/m -3 2/m   Oh
> Number and name of space group: 225 (F m -3 m)
>  next is symmery
> >   symmetry  (16:23:21) Note: The following floating-point exceptions are 
> > signalling: IEEE_DENORMAL
> 0.0u 0.0s 0:00.00 0.0% 0+0k 0+0io 0pf+0w
>  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
> STOP LSTART ENDS
> >   inputfiles prepared   (16:23:21)
>  inputfiles prepared
>  next is kgen
> STOP KGEN ENDS
>   NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
>  length of reciprocal lattice vectors:   1.331   1.331   1.331  10.000  
> 10.000  10.000
>   47  k-points generated, ndiv=  10  10  10
>  next is dstart
> >   dstart  -p(16:23:21) running dstart in single mode
>
>
>
> --
> Ram
> ​ Kashyap
> Saha Institute of Nuclear Physics
> 9473811023
>
___
Wien mailing list
Wien@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