<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    <blockquote type="cite"
cite="mid:CAOWoSSPiTn-zteukHXYLQG7fNn+7D2PmGYu+AShE5etz2KM13Q@mail.gmail.com">
      <div dir="auto">Speaking of ppcg, is there any published (or
        otherwise public) benchmark of ppcg vs Davidson and/or cg? For
        which cases can ppcg be expected to be faster?</div>
    </blockquote>
    <p>I don't know, I'm not an author of that part of code. I've just
      tested it out of curiosity in this particular case (i.e. very slow
      diagonalization)<br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAOWoSSPiTn-zteukHXYLQG7fNn+7D2PmGYu+AShE5etz2KM13Q@mail.gmail.com">
      <div dir="auto">Best regards,</div>
      <div dir="auto">Michal Krompiec, Merck KGaA </div>
      <div><br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Mon, Dec 14, 2020 at 2:12
            PM Lorenzo Paulatto <<a href="mailto:paulatz@gmail.com"
              moz-do-not-send="true">paulatz@gmail.com</a>> wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">p.p.s I
            mean diagonalization='ppcg'<br>
            <br>
            On 2020-12-14 15:10, Lorenzo Paulatto wrote:<br>
            > p.s. If you can use a newer version of QE that does
            calculation="ppcg" <br>
            > I found it to be much (i.e. 6x) faster in this case<br>
            ><br>
            > cheers<br>
            ><br>
            > On 2020-12-14 14:50, Lorenzo Paulatto wrote:<br>
            >> Hello,<br>
            >><br>
            >> I've had a look at the output, and a part for the
            cutoff which <br>
            >> appears a bit too high (you are probably safe with
            50/400Ry of <br>
            >> ecutwfc/ecutrho) I only see to small problems:<br>
            >><br>
            >> 1. the scf calculation is using 6 pools with 10
            k-points, which means <br>
            >> that 4 pools have twice as much work to do as the
            others. In the <br>
            >> ideal case, the number of pools should be a divisor
            of the number of <br>
            >> k-points (i.e. 2, 5 or 10 in your case). Also, it
            is recommended that <br>
            >> the number of CPUs in a pool are a divisor of the
            number of CPUs on <br>
            >> each computing node, to avoid too much inter-node
            communication. In <br>
            >> your case, the best choice with 72 CPUs (on two
            nodes?) could be 2 <br>
            >> pools. You may gain a bit of time, but this is not
            going to change a <br>
            >> lot. You should consider using more CPUs if you
            have the budget. For <br>
            >> example, 10 pools of 12 or 18 CPUs each.<br>
            >><br>
            >> 2. The bands calculation runs on 12 CPUs and has a
            single k-point, <br>
            >> while each pool of the SCF one has up to 2
            k-points. We would expect <br>
            >> that the bands calculation take about half as an
            scf step, i.e. about <br>
            >> 50 seconds. However, the bands calculation has some
            trouble <br>
            >> diagonalizing the Hamiltonian, you see it writes:<br>
            >><br>
            >>      ethr =  2.76E-12,  avg # of iterations =120.0<br>
            >><br>
            >> while typically the very last scf diagonalization
            is<br>
            >><br>
            >>      ethr =  2.98E-12,  avg # of iterations =  3.3<br>
            >><br>
            >> This is because, the scf calculation can start with
            a very good guess <br>
            >> good the wavefunction, while the bands calculation
            does not. It is <br>
            >> still faster than doing the entire scf procedure,
            but just by a <br>
            >> factor ~2.3<br>
            >><br>
            >> Fortunately, you do not usually need the
            eigenvalues to a precision <br>
            >> of 10e-12. You can set the threshold by hand using
            the keyword <br>
            >> diago_thr_init, I guess 1.d-6 should be tight
            enough. However, double <br>
            >> check what you get in output, because I am
            half-suspecting that it <br>
            >> may be over-written by the value in the restart
            file<br>
            >><br>
            >> cheers<br>
            >><br>
            _______________________________________________<br>
            Quantum ESPRESSO is supported by MaX (<a
              href="http://www.max-centre.eu" rel="noreferrer"
              target="_blank" moz-do-not-send="true">www.max-centre.eu</a>)<br>
            users mailing list <a
              href="mailto:users@lists.quantum-espresso.org"
              target="_blank" moz-do-not-send="true">users@lists.quantum-espresso.org</a><br>
            <a
              href="https://lists.quantum-espresso.org/mailman/listinfo/users"
              rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.quantum-espresso.org/mailman/listinfo/users</a></blockquote>
        </div>
      </div>
      <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">www.max-centre.eu</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>
  </body>
</html>