<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>