[QE-users] time consuming band structure calculation for a supercell

Lorenzo Paulatto paulatz at gmail.com
Mon Dec 14 16:09:22 CET 2020


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

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)



> Best regards,
> Michal Krompiec, Merck KGaA
>
> On Mon, Dec 14, 2020 at 2:12 PM Lorenzo Paulatto <paulatz at gmail.com 
> <mailto:paulatz at gmail.com>> wrote:
>
>     p.p.s I mean diagonalization='ppcg'
>
>     On 2020-12-14 15:10, Lorenzo Paulatto wrote:
>     > p.s. If you can use a newer version of QE that does
>     calculation="ppcg"
>     > I found it to be much (i.e. 6x) faster in this case
>     >
>     > cheers
>     >
>     > On 2020-12-14 14:50, Lorenzo Paulatto wrote:
>     >> Hello,
>     >>
>     >> I've had a look at the output, and a part for the cutoff which
>     >> appears a bit too high (you are probably safe with 50/400Ry of
>     >> ecutwfc/ecutrho) I only see to small problems:
>     >>
>     >> 1. the scf calculation is using 6 pools with 10 k-points, which
>     means
>     >> that 4 pools have twice as much work to do as the others. In the
>     >> ideal case, the number of pools should be a divisor of the
>     number of
>     >> k-points (i.e. 2, 5 or 10 in your case). Also, it is
>     recommended that
>     >> the number of CPUs in a pool are a divisor of the number of
>     CPUs on
>     >> each computing node, to avoid too much inter-node
>     communication. In
>     >> your case, the best choice with 72 CPUs (on two nodes?) could be 2
>     >> pools. You may gain a bit of time, but this is not going to
>     change a
>     >> lot. You should consider using more CPUs if you have the
>     budget. For
>     >> example, 10 pools of 12 or 18 CPUs each.
>     >>
>     >> 2. The bands calculation runs on 12 CPUs and has a single k-point,
>     >> while each pool of the SCF one has up to 2 k-points. We would
>     expect
>     >> that the bands calculation take about half as an scf step, i.e.
>     about
>     >> 50 seconds. However, the bands calculation has some trouble
>     >> diagonalizing the Hamiltonian, you see it writes:
>     >>
>     >>      ethr =  2.76E-12,  avg # of iterations =120.0
>     >>
>     >> while typically the very last scf diagonalization is
>     >>
>     >>      ethr =  2.98E-12,  avg # of iterations =  3.3
>     >>
>     >> This is because, the scf calculation can start with a very good
>     guess
>     >> good the wavefunction, while the bands calculation does not. It is
>     >> still faster than doing the entire scf procedure, but just by a
>     >> factor ~2.3
>     >>
>     >> Fortunately, you do not usually need the eigenvalues to a
>     precision
>     >> of 10e-12. You can set the threshold by hand using the keyword
>     >> diago_thr_init, I guess 1.d-6 should be tight enough. However,
>     double
>     >> check what you get in output, because I am half-suspecting that it
>     >> may be over-written by the value in the restart file
>     >>
>     >> cheers
>     >>
>     _______________________________________________
>     Quantum ESPRESSO is supported by MaX (www.max-centre.eu
>     <http://www.max-centre.eu>)
>     users mailing list users at lists.quantum-espresso.org
>     <mailto:users at lists.quantum-espresso.org>
>     https://lists.quantum-espresso.org/mailman/listinfo/users
>
>
> _______________________________________________
> Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
> users mailing list users at lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/users/attachments/20201214/a033569e/attachment.html>


More information about the users mailing list