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" <[email protected]> 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" <[email protected]> > 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 >> [email protected] >> 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= >> >
_______________________________________________ Wien mailing list [email protected] http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/[email protected]/index.html
