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

Tue Nov 28 13:02:00 CET 2017

Ignore my last email, I had the wrong selection rules -- too early, not
enough coffee.

_____
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:58 AM, "Laurence Marks" <L-marks at northwestern.edu> wrote:

> 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.the
>> ochem.tuwien.ac.at_mailman_listinfo_wien&d=DwIGaQ&c=yHlS04Hh
>> Braes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=U_T4PL6jwANfAy4r
>> nxTj8IUxm818jnvqKFdqWLwmqg0&m=bUtQ2-rp6rZ_Fb4eLkE_Ye7S7bN3X4
>> CtfdUqQURN5sE&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=yHlS04HhBraes5
>> BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=U_T4PL6jwANfAy4rnxTj8IUxm818
>> jnvqKFdqWLwmqg0&m=bUtQ2-rp6rZ_Fb4eLkE_Ye7S7bN3X4CtfdUqQURN5s
>> E&s=uMgLUPSM3EVs3UYAH3vo4bu8OK5CAe8g8QuKu7zc7wc&e=
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20171128/63494f1b/attachment.html>