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

[Laurence Marks]

Interesting. I assume that this is with -so. Does the sum :PUP+:PDN obey
the fcc selection rules? (You can also look at the PW in case.clmsum &
case.valup/dn.)

_____
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/e5ed9805/attachment.html>