[Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
Pavel Ondračka
pavel.ondracka at email.cz
Tue May 29 15:01:11 CEST 2018
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 <pavel.ondracka at em
> > > ail.
> > > cz> wrote:
> > > > ---------- Původní e-mail ----------
> > > > Od: Laurence Marks <L-marks at northwestern.edu>
> > > > Komu: A Mailing list for WIEN2k users <wien at zeus.theochem.tuwie
> > > > 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 <pavel.ondracka@
> > > > > emai
> > > > > l.cz> wrote:
> > > > > > Laurence Marks píše v St 09. 05. 2018 v 11:51 +0000:
> > > > > > > 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&d=DwIGaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6w
> > > > > > s&r=
> > > > > > U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0&m=R1lxmwh4Y3r4y
> > > > > > Rx1Z
> > > > > > yR4NN9mpSe7RuaT974qRm6Uhfw&s=KDobN5dacXxTk7OUpO1BdJBY45FBX3
> > > > > > 4Hf6
> > > > > > Q9hTempg0&e=
> > > > > > > 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.
> > > > > > 0x000000000041dc48 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 0x00000000004143c6 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 at zeus.theochem.tuwien.ac.at
> > > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.th
> > > > > > eoch
> > > > > > em.tuwien.ac.at_mailman_listinfo_wien&d=DwIGaQ&c=yHlS04HhBr
> > > > > > aes5
> > > > > > BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=U_T4PL6jwANfAy4rnxTj8IUxm81
> > > > > > 8jnv
> > > > > > qKFdqWLwmqg0&m=R1lxmwh4Y3r4yRx1ZyR4NN9mpSe7RuaT974qRm6Uhfw&
> > > > > > s=_8
> > > > > > Uru9zRH580QrhtgA9HnU1x81x6paXIOqJCFnOzZME&e=
> > > > > > 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&d=DwIGaQ&c=yHlS04Hh
> > > > > > Brae
> > > > > > s5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=U_T4PL6jwANfAy4rnxTj8IUxm
> > > > > > 818j
> > > > > > nvqKFdqWLwmqg0&m=R1lxmwh4Y3r4yRx1ZyR4NN9mpSe7RuaT974qRm6Uhf
> > > > > > w&s=
> > > > > > SJYF9VBF7xwkjpCyB76TXcIRXzDcFX3xCQlsoQ4RwIw&e=
> > > > >
> > > > > _______________________________________________
> > > > > 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
> > >
> > >
> > >
> > > _______________________________________________
> > > 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@zeu
> > > s.th
> > > eochem.tuwien.ac.at/index.html
> >
> > _______________________________________________
> > 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
> >
>
>
More information about the Wien
mailing list