<div dir="auto">No "0001" at the end (Google autocorrect strikes again).<br><br><div data-smartmail="gmail_signature">_____<br>Professor Laurence Marks<br>"Research is to see what everybody else has seen, and to think what nobody else has thought", Albert Szent-Gyorgi<br><a href="http://www.numis.northwestern.edu">www.numis.northwestern.edu</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Nov 28, 2017 6:35 AM, "Laurence Marks" <<a href="mailto:L-marks@northwestern.edu">L-marks@northwestern.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">A better response after more coffee.<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto">b) Try using "x kgen -fbz"</div><div dir="auto">c) Try using TEMPS rather than TETRA.</div><div dir="auto">d) Check the compiler options, and use -O1 -mp1 and perhaps add (at the end) -noftz.</div><div dir="auto">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.)</div><div dir="auto">f) Try regressing your mkl version if you can.</div><div dir="auto">g) Wait for Peter/Fabien to add ideas (or test themselves).<br><br><div data-smartmail="gmail_signature" dir="auto">_____<br>Professor Laurence Marks<br>"Research is to see what everybody else has seen, and to think what nobody else has thought", Albert Szent-Gyorgi<br><a href="http://www.numis.northwestern.edu" target="_blank">www.numis.northwestern.edu</a></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Nov 28, 2017 5:36 AM, "Jaroslav Hamrle" <<a href="mailto:hamrle@karlov.mff.cuni.cz" target="_blank">hamrle@karlov.mff.cuni.cz</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Laurence,<br>
<br>
thank you for your detailed answer.<br>
<br>
I have tried all your suggestions,<br>
- I changed case.in0 with increased oversampling by factor two (new<br>
parameters LUSE 26 and IFFTfactor 4)<br>
------------ start of case.in0 -----------<br>
TOT  XC_LDA (XC_PBE,XC_PBESOL,XC_WC,XC_MBJ<wbr>,XC_REVTPSSS)<br>
NR2V      IFFT  26  (R2V)<br>
    24   24   24    4.00  1    min IFFT-parameters, enhancement factor,<br>
iprint<br>
------------ end of case.in0 -----------<br>
<br>
- I also tried to impose strong convergence criteria to be -cc<br>
0.00000001 -ec 0.00000001<br>
<br>
However, in both cases, the ghost MLD remains practically identical as<br>
when using my default values (default Fe + convergence -cc 0.00001 -ec<br>
0.000001)<br>
<br>
Also, final :PUP 'Current' parameters remained practically the same for<br>
all the calculations (by about 2 digits), being like (for M001)<br>
PW CHANGE     H    K    L      Current       Change    Residue<br>
:PUP001:      0    0    0  2.10719649E-02  5.090E-10 -7.530E-09<br>
:PUP002:      0   -1   -1  3.67084665E-04 -7.004E-10 -3.572E-10<br>
:PUP003:      1   -1    0  1.82124988E-04 -3.669E-10 -2.211E-10<br>
:PUP004:      0    0   -2 -1.87471938E-03  6.192E-11  7.254E-10<br>
:PUP005:      0   -2    0 -3.75090680E-03  1.125E-10  1.378E-09<br>
:PUP006:      1   -1   -2 -3.46372731E-03  1.026E-10  1.378E-09<br>
:PUP007:      1   -2   -1 -6.92804324E-03  2.418E-10  2.776E-09<br>
:PUP008:      0   -2   -2 -7.14014083E-04  8.677E-11  2.032E-10<br>
:PUP009:      2   -2    0 -3.57036516E-04  4.298E-11  1.121E-10<br>
:PUP010:      0   -1   -3  2.62159615E-04  9.199E-11 -1.588E-10<br>
:PUP011:      0   -3   -1  2.62289930E-04  9.844E-11 -1.555E-10<br>
:PUP012:      1   -3    0  2.62219244E-04  9.133E-11 -1.551E-10<br>
Unfortunately, all reflections seems to be allowed for bcc (H+K+L is<br>
even), forbidden reflections of bcc are (H+K+L=odd), so I can not see<br>
how they get close to zero ;-)) But the idea is excellent.<br>
<br>
Thank you again and with my best regards<br>
<br>
Jaroslav<br>
<br>
On 27/11/17 15:27, Laurence Marks wrote:<br>
> Let me clarify slightly my comment about symmetry -- as I realized the<br>
> explanation (I think) and can also suggest something that might help.<br>
><br>
> First, concerning symmetry the explanation is I believe simple. If the<br>
> problem has a real symmetry operation such as inversion which is being<br>
> removed, then the Jacobian at the solution has zero's for charge<br>
> disturbances that break this symmetry. Because of this noise due to<br>
> numerical accuracy has a large effect, and almost certainly one has to<br>
> tighten the convergence criteria particularly -cc. You can monitor<br>
> this by looking at the :PUPXXX values in case.scfm and look how well<br>
> the forbidden reflections have converged to zero.<br>
><br>
> Second, do not be surprised about numerical issues. While the<br>
> calculations are done in double precision, there are many large sums<br>
> and in some cases double sums, and also numerical<br>
> integrations/differentiation. Any large sum or numerical<br>
> integration/differentiation in general reduces the numerical accuracy.<br>
> Hence even though double precision has an accuracy of 1D-15 the sum<br>
> may only be accurate to 1D-10 or even 1D-7. Also, the Intel ifort<br>
> compiler will reduce the numerical accuracy for speed if one is not<br>
> careful.<br>
><br>
> One thing that may help is to increase the oversampling in case.in0<br>
> for VXC, both that of the PW's and of the CLMs. A standard test is to<br>
> use LDA and see if the problem goes away, since oversampling is much<br>
> less relevant for this.<br>
><br>
> Of course your problem may have nothing to do with any of this....<br>
<br>
______________________________<wbr>_________________<br>
Wien mailing list<br>
<a href="mailto:Wien@zeus.theochem.tuwien.ac.at" target="_blank">Wien@zeus.theochem.tuwien.ac.a<wbr>t</a><br>
<a href="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=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.<wbr>com/v2/url?u=http-3A__zeus.the<wbr>ochem.tuwien.ac.at_mailman_lis<wbr>tinfo_wien&d=DwIGaQ&c=yHlS04Hh<wbr>Braes5BQ9ueu5zKhE7rtNXt_<wbr>d012z2PA6ws&r=U_T4PL6jwANfAy4r<wbr>nxTj8IUxm818jnvqKFdqWLwmqg0&m=<wbr>bUtQ2-rp6rZ_Fb4eLkE_Ye7S7bN3X4<wbr>CtfdUqQURN5sE&s=yMgpsPYg5Q_bN3<wbr>I5bhvkGyvxgmLx4CLkO4HDCa3ZMM4&<wbr>e=</a><br>
SEARCH the MAILING-LIST at:  <a href="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=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.<wbr>com/v2/url?u=http-3A__www.mail<wbr>-2Darchive.com_wien-40zeus.<wbr>theochem.tuwien.ac.at_index.<wbr>html&d=DwIGaQ&c=yHlS04HhBraes5<wbr>BQ9ueu5zKhE7rtNXt_d012z2PA6ws&<wbr>r=U_T4PL6jwANfAy4rnxTj8IUxm818<wbr>jnvqKFdqWLwmqg0&m=bUtQ2-rp6rZ_<wbr>Fb4eLkE_Ye7S7bN3X4CtfdUqQURN5s<wbr>E&s=uMgLUPSM3EVs3UYAH3vo4bu8OK<wbr>5CAe8g8QuKu7zc7wc&e=</a><br>
</blockquote></div></div>
</blockquote></div></div>