<div dir="auto">Dear Lorenzo,</div><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><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">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">www.max-centre.eu</a>)<br>
users mailing list <a href="mailto:users@lists.quantum-espresso.org" target="_blank">users@lists.quantum-espresso.org</a><br>
<a href="https://lists.quantum-espresso.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.quantum-espresso.org/mailman/listinfo/users</a></blockquote></div></div>