<div dir="auto">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.)<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 5:36 AM, "Jaroslav Hamrle" <<a href="mailto:hamrle@karlov.mff.cuni.cz">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_<wbr>MBJ,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">Wien@zeus.theochem.tuwien.ac.<wbr>at</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.<wbr>theochem.tuwien.ac.at_mailman_<wbr>listinfo_wien&d=DwIGaQ&c=<wbr>yHlS04HhBraes5BQ9ueu5zKhE7rtNX<wbr>t_d012z2PA6ws&r=U_<wbr>T4PL6jwANfAy4rnxTj8IUxm818jnvq<wbr>KFdqWLwmqg0&m=bUtQ2-rp6rZ_<wbr>Fb4eLkE_<wbr>Ye7S7bN3X4CtfdUqQURN5sE&s=<wbr>yMgpsPYg5Q_<wbr>bN3I5bhvkGyvxgmLx4CLkO4HDCa3ZM<wbr>M4&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.<wbr>mail-2Darchive.com_wien-<wbr>40zeus.theochem.tuwien.ac.at_<wbr>index.html&d=DwIGaQ&c=<wbr>yHlS04HhBraes5BQ9ueu5zKhE7rtNX<wbr>t_d012z2PA6ws&r=U_<wbr>T4PL6jwANfAy4rnxTj8IUxm818jnvq<wbr>KFdqWLwmqg0&m=bUtQ2-rp6rZ_<wbr>Fb4eLkE_<wbr>Ye7S7bN3X4CtfdUqQURN5sE&s=<wbr>uMgLUPSM3EVs3UYAH3vo4bu8OK5CAe<wbr>8g8QuKu7zc7wc&e=</a><br>
</blockquote></div></div>