[Wien] $DEC! NOOPTIMIZE equivalents in gfortran?

[Laurence Marks]

I changed the version to include a pre-converged MSR1

A fresh pair of eyes would be useful. The minimum is somewhere in the range
for atom 7 z 0.2610-0.2616, but it is very ill-conditioned and noisy. Why
is unclear.

On Thu, Aug 9, 2018 at 7:11 AM, Laurence Marks <L-marks at northwestern.edu>
wrote:

> Test case is not a simple question, as the Kahan summations in charge.f
> are used in lapw0/1/2 mixer and a few other places. I have noticed minor
> changes in energies (1E-5 Ryd) with preventing ifort from optimizing
> charge.f. However, this is very tricky as ifort does 80 bit operations and
> only later truncates to 64, so it could be that without optimization the
> results are less accurate. In an ideal world the compiler will use 80 bit
> carries and not optimize out the summation.
>
> If useful, a nasty ill-conditioned case is at
> https://drive.google.com/file/d/18xlI3-qf4RKOS8mWdR38bfo4a9Y
> q_t4u/view?usp=sharing
>
> You will need to do lstart/dstart then a few (15-25) MSR1 before switching
> to MSR1a. The convergence is somewhat random, some of this may be in the
> mixer and some elsewhere. By ill-conditioned I mean that if you first do 24
> MSR1 versus 25, the number of iterations to convergence, or even whether it
> converges will be different. Sometimes two runs from the same starting
> points converge (or not) in a different number of iterations.
>
> Where the ill-conditioning comes from is unclear to me.
>
>
> On Thu, Aug 9, 2018 at 3:21 AM, Pavel Ondračka <pavel.ondracka at email.cz>
> wrote:
>
>> I can look at the gfortran, what is your testcase?
>>
>> I tried to take a quick look with the full mixer using one random TiO2
>> case. I put a breakpoint after some random Kahan sum (specifically this
>> was at charge.f:150 in Wien2k 18.2) and I looked for the differences
>> between O0 and O2. I was actually looking for small differences, but
>> the value of sum was 0 with -O2 vs 739.29 with -O0!
>>
>> Hence in this case it looks like either the different optimization
>> levels influence the program flow, or the optimizations caused the
>> shift of the breakpoint to some other place.
>>
>> It might also be possible that this is a gdb problem since there is a
>> lot of
>> ** On entry to DHSEQR parameter number  4 had an illegal value
>> ** On entry to DGEBAL parameter number  3 had an illegal value
>> ** On entry to DGEHRD  parameter number  2 had an illegal value
>> spam which I have no idea about and <error reading variable ....
>> (access outside bounds of object referenced via synthetic pointer)>
>>
>> BTW valgrind is also not happy with the mixer (even at -O0 there are
>> lot of "Use of uninitialised value ... and On entry to DHSEQR parameter
>> number  4 had an illegal value )
>>
>> If you can produce a simple testcase, I'd be happy to look into the
>> Kahan sum problem, but at the moment I can't reproduce with the full
>> mixer due to the aforementioned problems.
>>
>> Best regards
>> Pavel
>>
>> Laurence Marks píše v St 08. 08. 2018 v 11:44 -0500:
>> > I am testing adding the compiler directive !DEC$ NOOPTIMIZE to the
>> > Kahan summations in charge.f in order to prevent ifort from
>> > optimizing the summation away. It seems to help.
>> >
>> > Does anyone know if there are equivalents in gfortran or other
>> > compilers? (I can't find anything for gfortran.)
>> >
>> > N.B., if anyone has experience with directives and wants to suggest
>> > others that may be faster but will avoid optimizing away the
>> > summation I am open to suggestions.
>> >
>> > _______________________________________________
>> > Wien mailing list
>> > Wien at zeus.theochem.tuwien.ac.at
>> > https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.the
>> ochem.tuwien.ac.at_mailman_listinfo_wien&d=DwIGaQ&c=yHlS04Hh
>> Braes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=U_T4PL6jwANfAy4r
>> nxTj8IUxm818jnvqKFdqWLwmqg0&m=QyQYMuoW6bN9WUM8q9rgMGkZX1qo4m
>> hebpNwy6CgZYg&s=AO9cbzTkaL7wjby4sVvXjic9gjJNqjr4Ok0j7lcCehA&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=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&
>> r=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0&m=QyQYMuoW6bN9
>> WUM8q9rgMGkZX1qo4mhebpNwy6CgZYg&s=JEkVkLlljxw4YibMTPxypqQqbu
>> 7L_RFseDpnQ2k4LC8&e=
>>
>> _______________________________________________
>> Wien mailing list
>> Wien at zeus.theochem.tuwien.ac.at
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.the
>> ochem.tuwien.ac.at_mailman_listinfo_wien&d=DwIGaQ&c=yHlS04Hh
>> Braes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=U_T4PL6jwANfAy4r
>> nxTj8IUxm818jnvqKFdqWLwmqg0&m=QyQYMuoW6bN9WUM8q9rgMGkZX1qo4m
>> hebpNwy6CgZYg&s=AO9cbzTkaL7wjby4sVvXjic9gjJNqjr4Ok0j7lcCehA&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=yHlS04HhBraes5
>> BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=U_T4PL6jwANfAy4rnxTj8IUxm818
>> jnvqKFdqWLwmqg0&m=QyQYMuoW6bN9WUM8q9rgMGkZX1qo4mhebpNwy6CgZY
>> g&s=JEkVkLlljxw4YibMTPxypqQqbu7L_RFseDpnQ2k4LC8&e=
>>
>
>
>
> --
> 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
>



-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20180809/b2cfc5fb/attachment.html>