<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* 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></head><body lang=EN-US link=blue vlink="#954F72"><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></body></html>