<html>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 /> <blockquote type="cite" cite="ec4a4df7-0b88-a064-f623-f88db8946b9d@sissa.it"> </blockquote><meta http-equiv="Content-Type" content="text/html; "><p><tt>6.d-9 is still too large.. it should be something like 1d-13 to aim at a smaller scf estimate.</tt></p><p><tt>are you really starting from the scf charge and wfcs of the same conficuration ? </tt></p><p><tt>stefano</tt></p><div class="moz-cite-prefix">On 16/08/20 22:05, Antoine Jay wrote:</div><blockquote type="cite" cite="mid:95e-5f399180-7-18ffe700@217565433"><meta http-equiv="content-type" content="text/html; ">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 class="moz-txt-link-rfc2396E" href="mailto:degironc@sissa.it"><degironc@sissa.it></a> a écrit:<br /> <blockquote type="cite" cite="5ec133b6-d166-8498-f13a-e97b9f59275b@sissa.it"> </blockquote> <meta http-equiv="Content-Type" content="text/html; "><p><tt>Hi Antoine,</tt></p><p><tt>  don't know exactly why you get this result but one thing you can try is to set diag_thr_init</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 class="moz-cite-prefix">On 14/08/20 17:09, Antoine Jay wrote:</div><blockquote type="cite" cite="mid:20d3-5f36a900-7-74857900@63487644"><meta http-equiv="content-type" content="text/html;
          ">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 /> <fieldset class="mimeAttachmentHeader"> </fieldset><pre class="moz-quote-pre" wrap="">_______________________________________________
Quantum ESPRESSO is supported by MaX (<a class="moz-txt-link-abbreviated" moz-do-not-send="true" href="http://www.max-centre.eu/quantum-espresso">www.max-centre.eu/quantum-espresso</a>)
users mailing list <a class="moz-txt-link-abbreviated" moz-do-not-send="true" href="mailto:users@lists.quantum-espresso.org">users@lists.quantum-espresso.org</a>
<a class="moz-txt-link-freetext" moz-do-not-send="true" href="https://lists.quantum-espresso.org/mailman/listinfo/users">https://lists.quantum-espresso.org/mailman/listinfo/users</a></pre></blockquote><br /><br /><br /> <fieldset class="mimeAttachmentHeader"> </fieldset><pre class="moz-quote-pre" wrap="">_______________________________________________
Quantum ESPRESSO is supported by MaX (<a class="moz-txt-link-abbreviated" href="http://www.max-centre.eu/quantum-espresso">www.max-centre.eu/quantum-espresso</a>)
users mailing list <a class="moz-txt-link-abbreviated" href="mailto:users@lists.quantum-espresso.org">users@lists.quantum-espresso.org</a>
<a class="moz-txt-link-freetext" href="https://lists.quantum-espresso.org/mailman/listinfo/users">https://lists.quantum-espresso.org/mailman/listinfo/users</a></pre></blockquote><br /><br /><br /> </html>