<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">sorry I missed your answer. <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">maybe we are missing to load the paw
part of the density. It is still written in a file apart. <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">we should open an issue on gitlab,
otherwise we will forget about it again <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Pietro <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 8/18/20 10:45 AM, Antoine Jay wrote:<br>
</div>
<blockquote type="cite"
cite="mid:5871-5f3b9580-d-2e39eb00@124657628">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
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
<a class="moz-txt-link-rfc2396E" href="mailto:pdelugas@sissa.it"><pdelugas@sissa.it></a> a écrit:<br>
<blockquote type="cite"
cite="20200817073602.5F40B2006A@mta01a.spin.it"> </blockquote>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">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
<a class="moz-txt-link-rfc2396E" 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">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" moz-do-not-send="true"><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" moz-do-not-send="true">www.max-centre.eu/quantum-espresso</a>)</pre>
<pre>users mailing list <a href="mailto:users@lists.quantum-espresso.org" moz-do-not-send="true">users@lists.quantum-espresso.org</a></pre>
<pre><a href="https://lists.quantum-espresso.org/mailman/listinfo/users" moz-do-not-send="true">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" moz-do-not-send="true">www.max-centre.eu/quantum-espresso</a>)</pre>
<pre>users mailing list <a href="mailto:users@lists.quantum-espresso.org" moz-do-not-send="true">users@lists.quantum-espresso.org</a></pre>
<pre><a href="https://lists.quantum-espresso.org/mailman/listinfo/users" moz-do-not-send="true">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>
<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>
<p><br>
</p>
</body>
</html>