<html>Dear Pietro,<br />This happens always not only in library mode.<br />This does not happen with US pseudo.<br />In attached files: 1rst step and 2nd step with us and paw (and a paw with high diago accuracy for stephano).<br />The 2nd step is a relax so you can see that the sequence<br /> "Initial potential from superposition of free atoms<br /> + "a scf correction to at. rho is read from "rho.in" (rho.in is obtained from output_drho of the 1rst job so it's scf-at.pot)<br /> + "Starting wfcs from file"<br />is not equivalent (in the PAW case) to the potential extrapolation<br />" NEW-OLD atomic charge density approx. for the potential"<br /><br />Regards,<br /><br />Antoine Jay<br />LAAS-CNRS<br />Toulouse, France<br /><br /><br />Le Lundi, Août 17, 2020 09:36 CEST, Pietro Delugas <pdelugas@sissa.it> a écrit:<br /> <blockquote type="cite" cite="20200817073602.5F40B2006A@mta01a.spin.it"> </blockquote><meta http-equiv=Content-Type content="text/html; "><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style type="text/css"><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
font-size:10.0pt;
font-family:"Courier New";}
tt
{mso-style-priority:99;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Courier New";}
span.DefaultFontHxMailStyle
{mso-style-name:"Default Font HxMail Style";
font-family:"Calibri",sans-serif;
color:windowtext;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><div class="WordSection1"><p class="MsoNormal"><span class="DefaultFontHxMailStyle"><span style="font-size:12.0pt">Hi <o:p></o:p></span></span></p><p class="MsoNormal"><span class="DefaultFontHxMailStyle"><span style="font-size:12.0pt">It’s strange. Have you checked whether this happens only in library mode or always ? What about if you use uspp instead of paw ? <o:p></o:p></span></span></p><p class="MsoNormal"><span class="DefaultFontHxMailStyle"><span style="font-size:12.0pt"><o:p> </o:p></span></span></p><p class="MsoNormal"><span class="DefaultFontHxMailStyle"><span style="font-size:12.0pt"><o:p> </o:p></span></span></p><p class="MsoNormal">Sent from <a href="https://go.microsoft.com/fwlink/?LinkId=550986">Mail</a> for Windows 10</p><p class="MsoNormal"><span class="DefaultFontHxMailStyle"><span style="font-size:12.0pt"><o:p> </o:p></span></span></p><div style="mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal" style="border:none;padding:0in"><b>From: </b><a href="mailto:ajay@laas.fr">Antoine Jay</a><br /><b>Sent: </b>Monday, August 17, 2020 9:16 AM<br /><b>To: </b><a href="mailto:users@lists.quantum-espresso.org">Quantum ESPRESSO users Forum</a><br /><b>Subject: </b>Re: [QE-users]?==?utf-8?q? ?==?utf-8?q? ?= Same run not accelerated when starting from converged rho and wf</p></div><p class="MsoNormal"><span class="DefaultFontHxMailStyle"><span style="font-size:12.0pt"><o:p> </o:p></span></span></p><p class="MsoNormal">Dear Stephano,<br />I reduced diago_thr_init to 1.0D-13 but it changed nothing to the first estimated scf accuracy.:<br /><br /> Initial potential from superposition of free atoms<br /> a scf correction to at. rho is read from./calcforces_QE/step0000/initialization/initial_bassin/relax//results/dbed.relax.save/rho.in<br /> negative rho (up, down): 1.432E-02 0.000E+00<br /> Starting wfcs from file<br /> Checking if some PAW data can be deallocated...<br /> PAW data deallocated on 4 nodes for type: 1<br /> PAW data deallocated on 32 nodes for type: 2<br /> PAW data deallocated on 35 nodes for type: 3<br /> total cpu time spent up to now is 29.8 secs<br /> Self-consistent Calculation<br /> iteration # 1 ecut= 58.00 Ry beta= 0.10<br /> Davidson diagonalization with overlap<br /> c_bands: 5 eigenvalues not converged<br /> ethr = 1.00E-13, avg # of iterations = 40.0<br /> negative rho (up, down): 1.432E-02 0.000E+00<br /> total cpu time spent up to now is 813.3 secs<br /> total energy = -11390.75602693 Ry<br /> Harris-Foulkes estimate = -11390.75013390 Ry<br /> estimated scf accuracy < 0.00021610 Ry<br /> iteration # 2 ecut= 58.00 Ry beta= 0.10<br /> Davidson diagonalization with overlap<br /> ethr = 2.16E-08, avg # of iterations = 1.0<br />... and the rest of the file is the same as the qe.0002.out I send.<br /><br />Please note that I start from the wfcs of exactely the same configuration and parameters by using startingwfc='file',<br />but I do not use startingpot='file'.<br />Instead I have activated input_drho='rho.in'<br />This 'rho.in' file is a copy of the file 'rho.out' that have been created by activating the parameter input_drho='rho.out'.<br />This trick is done because sometimes, the atomic positions have a small variation (but not in this case).<br /><br />Please note that I already tried this trick on smaller systems plenty of times and I never saw this problem,<br />this is why I wonder if it is a problem of the system size or of the PAW pseudo for wich for example the becsum couldbe bad performed when some PAW data are deallocated:<br />" Checking if some PAW data can be deallocated...<br /> PAW data deallocated on 4 nodes for type: 1<br /> PAW data deallocated on 32 nodes for type: 2<br /> PAW data deallocated on 35 nodes for type: 3"<br /><br /><br />Regards,<br /><br />Antoine Jay<br />LAAS-CNRS<br />Toulouse, France<br /><br /><br /><br /><br /><br /><br /><br /><br />Le Dimanche, Août 16, 2020 23:20 CEST, Stefano de Gironcoli <degironc@sissa.it> a écrit:<br /> </p><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><p class="MsoNormal"> </p></blockquote><p><tt><span style="font-size:10.0pt">6.d-9 is still too large.. it should be something like 1d-13 to aim at a smaller scf estimate.</span></tt></p><p><tt><span style="font-size:10.0pt">are you really starting from the scf charge and wfcs of the same conficuration ? </span></tt></p><p><tt><span style="font-size:10.0pt">stefano</span></tt></p><div><p class="MsoNormal">On 16/08/20 22:05, Antoine Jay wrote:</p></div><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><p class="MsoNormal">Dear Stephano,<br />adding diago_thr_int=1.0D-8 does not change the first conv_thr (exept the average#of iterations)<br />As you said, the first value 1.0D-2 is detected to be too large and is updated to 6.0D-9 so I don't see why changing manually the first value would change something if it is already automatically changed...<br /><br />Antoine Jay<br />LAAS-CNRS<br />Toulouse, France<br /><br />Le Samedi, Août 15, 2020 17:10 CEST, Stefano de Gironcoli <a href="mailto:degironc@sissa.it"><degironc@sissa.it></a> a écrit:<br /> </p><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><p class="MsoNormal"> </p></blockquote><p><tt><span style="font-size:10.0pt">Hi Antoine,</span></tt></p><p><tt><span style="font-size:10.0pt"> don't know exactly why you get this result but one thing you can try is to set diag_thr_init</span></tt> ~ conv_thr/Nelec/10 so the first diagonalization is pushed tighter (if the wfcs are already very good it should not take too many iterations) and the computed dr2 estimate should be more faithful</p><p> now diag_thr_int is 1.d-2 then updated to 6.e-9 which is consistent with conv_thr ~6.d-5...</p><p> idk. you can try</p><p> stefano</p><p> </p><div><p class="MsoNormal">On 14/08/20 17:09, Antoine Jay wrote:</p></div><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><p class="MsoNormal">Dear all,<br /><br />I'am doing two consecutive scf calculations with exactly the same structure and parameters by calling qe6.5 as a library (attached output files).<br />For the second call, I use the options:<br />startingwfc='file' and input_rho ='rho.in'<br />where these inputs are the converged wfc1.dat and charge-density.dat of the first step.<br />Here I face two problems:<br /><br />-I expected that the initial scf accuracy is 10^-11 as obtained at the end of the first step, but it is only 10^-4.<br />How is it possible to explain such a decrease? I generally loose only 2 orders of magnitude by doing this.<br /><br />-Even with less scf iterations, the cpu time is greater.<br />Is it possible that some extra memory is allocated by qe when input rho and wfc are asked, and not desallocated?<br /><br />Note that until now, I have these troubles only when I use paw pseudopotentials on big systems.<br /><br />Regards,<br /><br />Antoine Jay<br />LAAS-CNRS<br />Toulouse France<br /><br /><br /><br /><br /><br /> </p><pre>_______________________________________________</pre><pre>Quantum ESPRESSO is supported by MaX (<a href="http://www.max-centre.eu/quantum-espresso">www.max-centre.eu/quantum-espresso</a>)</pre><pre>users mailing list <a href="mailto:users@lists.quantum-espresso.org">users@lists.quantum-espresso.org</a></pre><pre><a href="https://lists.quantum-espresso.org/mailman/listinfo/users">https://lists.quantum-espresso.org/mailman/listinfo/users</a></pre></blockquote><p class="MsoNormal"><br /><br /><br /> </p><pre>_______________________________________________</pre><pre>Quantum ESPRESSO is supported by MaX (<a href="http://www.max-centre.eu/quantum-espresso">www.max-centre.eu/quantum-espresso</a>)</pre><pre>users mailing list <a href="mailto:users@lists.quantum-espresso.org">users@lists.quantum-espresso.org</a></pre><pre><a href="https://lists.quantum-espresso.org/mailman/listinfo/users">https://lists.quantum-espresso.org/mailman/listinfo/users</a></pre></blockquote><p class="MsoNormal"><br /><br /><br /> </p><p class="MsoNormal"><span class="DefaultFontHxMailStyle"><span style="font-size:12.0pt"><o:p> </o:p></span></span></p></div><br /><br /><br /> </html>