[Wien] different MLD for bcc structure for magnetic equivalent directions M001, M010 and M100

[Laurence Marks]

A better response after more coffee.

You might have found a simple (& therefore useful) case that highlights a
symmetry issue that I think is present, but have never been able to pin
down. The key now is to try and find some way to eliminate it, since it
could be in too many places (e.g. lapw[0-2], lapwso, sumpara, mixer). I
suggest sticking with LDA since this should eliminate most VXC issues.
Thoughts.

a) Please check case.struct and ensure that all the positions are 0.0 or
0.5 and similarly for translations, with no "000" at the end.
b) Try using "x kgen -fbz"
c) Try using TEMPS rather than TETRA.
d) Check the compiler options, and use -O1 -mp1 and perhaps add (at the
end) -noftz.
e) Test compiling lapw1 with -DoldScalapack. I may have the name/case
wrong, do a "grep -e ifdef *.F" in SRC_lapw1. (This changes with version.)
f) Try regressing your mkl version if you can.
g) Wait for Peter/Fabien to add ideas (or test themselves).

_____
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 Nov 28, 2017 5:36 AM, "Jaroslav Hamrle" <hamrle at karlov.mff.cuni.cz>
wrote:

> Dear Laurence,
>
> thank you for your detailed answer.
>
> I have tried all your suggestions,
> - I changed case.in0 with increased oversampling by factor two (new
> parameters LUSE 26 and IFFTfactor 4)
> ------------ start of case.in0 -----------
> TOT  XC_LDA (XC_PBE,XC_PBESOL,XC_WC,XC_MBJ,XC_REVTPSSS)
> NR2V      IFFT  26  (R2V)
>     24   24   24    4.00  1    min IFFT-parameters, enhancement factor,
> iprint
> ------------ end of case.in0 -----------
>
> - I also tried to impose strong convergence criteria to be -cc
> 0.00000001 -ec 0.00000001
>
> However, in both cases, the ghost MLD remains practically identical as
> when using my default values (default Fe + convergence -cc 0.00001 -ec
> 0.000001)
>
> Also, final :PUP 'Current' parameters remained practically the same for
> all the calculations (by about 2 digits), being like (for M001)
> PW CHANGE     H    K    L      Current       Change    Residue
> :PUP001:      0    0    0  2.10719649E-02  5.090E-10 -7.530E-09
> :PUP002:      0   -1   -1  3.67084665E-04 -7.004E-10 -3.572E-10
> :PUP003:      1   -1    0  1.82124988E-04 -3.669E-10 -2.211E-10
> :PUP004:      0    0   -2 -1.87471938E-03  6.192E-11  7.254E-10
> :PUP005:      0   -2    0 -3.75090680E-03  1.125E-10  1.378E-09
> :PUP006:      1   -1   -2 -3.46372731E-03  1.026E-10  1.378E-09
> :PUP007:      1   -2   -1 -6.92804324E-03  2.418E-10  2.776E-09
> :PUP008:      0   -2   -2 -7.14014083E-04  8.677E-11  2.032E-10
> :PUP009:      2   -2    0 -3.57036516E-04  4.298E-11  1.121E-10
> :PUP010:      0   -1   -3  2.62159615E-04  9.199E-11 -1.588E-10
> :PUP011:      0   -3   -1  2.62289930E-04  9.844E-11 -1.555E-10
> :PUP012:      1   -3    0  2.62219244E-04  9.133E-11 -1.551E-10
> Unfortunately, all reflections seems to be allowed for bcc (H+K+L is
> even), forbidden reflections of bcc are (H+K+L=odd), so I can not see
> how they get close to zero ;-)) But the idea is excellent.
>
> Thank you again and with my best regards
>
> Jaroslav
>
> On 27/11/17 15:27, Laurence Marks wrote:
> > Let me clarify slightly my comment about symmetry -- as I realized the
> > explanation (I think) and can also suggest something that might help.
> >
> > First, concerning symmetry the explanation is I believe simple. If the
> > problem has a real symmetry operation such as inversion which is being
> > removed, then the Jacobian at the solution has zero's for charge
> > disturbances that break this symmetry. Because of this noise due to
> > numerical accuracy has a large effect, and almost certainly one has to
> > tighten the convergence criteria particularly -cc. You can monitor
> > this by looking at the :PUPXXX values in case.scfm and look how well
> > the forbidden reflections have converged to zero.
> >
> > Second, do not be surprised about numerical issues. While the
> > calculations are done in double precision, there are many large sums
> > and in some cases double sums, and also numerical
> > integrations/differentiation. Any large sum or numerical
> > integration/differentiation in general reduces the numerical accuracy.
> > Hence even though double precision has an accuracy of 1D-15 the sum
> > may only be accurate to 1D-10 or even 1D-7. Also, the Intel ifort
> > compiler will reduce the numerical accuracy for speed if one is not
> > careful.
> >
> > One thing that may help is to increase the oversampling in case.in0
> > for VXC, both that of the PW's and of the CLMs. A standard test is to
> > use LDA and see if the problem goes away, since oversampling is much
> > less relevant for this.
> >
> > Of course your problem may have nothing to do with any of this....
>
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.
> theochem.tuwien.ac.at_mailman_listinfo_wien&d=DwIGaQ&c=
> yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=U_
> T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0&m=bUtQ2-rp6rZ_Fb4eLkE_
> Ye7S7bN3X4CtfdUqQURN5sE&s=yMgpsPYg5Q_bN3I5bhvkGyvxgmLx4CLkO4HDCa3ZMM4&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=bUtQ2-rp6rZ_Fb4eLkE_
> Ye7S7bN3X4CtfdUqQURN5sE&s=uMgLUPSM3EVs3UYAH3vo4bu8OK5CAe8g8QuKu7zc7wc&e=
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20171128/74b8d9f1/attachment-0001.html>