[Pw_forum] Fwd: Final iteration often crashes after structure optimization

Paolo Giannozzi p.giannozzi at gmail.com
Sat Aug 15 13:22:35 CEST 2015


Thank you for providing an important piece of information. The final step
of variable-cell optimization has always been a significant source of
trouble, producing in return a negligible amount of useful information,
IMHO (at least for knowledgeable users). I was convinced that there was a
problem only in the presence of constraints (see here:
http://qeforge.qe-forge.org/gf/project/q-e/tracker/?action=TrackerItemEdit&tracker_item_id=170&start=0
) but apparently the problem is more general. It is likely related to the
way plane waves are distributed: the final run should perform the same
calculation as a single scf step with final cell and coordinates and all
other input data unchanged, but for some reason, it does something slightly
different.

Paolo

On Mon, Aug 10, 2015 at 2:01 PM, Cohen, Ronald <rcohen at carnegiescience.edu>
wrote:

> Lowering ecutrho makes things worse not better. But I understand the
> problem better. It is a problem with load balancing. This problem only
> arises when R & G space division>1 . With R & G space division=1 it never
> crashes in this way. However, the performance with R & G space division=4
> is astounding compared with R & G space division=1. I have 16 k-points, yet
> with npool=16 it takes 74 seconds for the first k-point, and with nppol=4
> on 16 processors (R & G space division=4) it takes 16 seconds--a speedup of
> 4.6 with the same number of processors! Yet 20% of the time or so R & G
> space division>1 fails, presumably because of a load balancing problem. The
> solution is to rebalance the R & G space divisions. Is there a developer
> out there familiar with this?
>
> --
Paolo Giannozzi, Dept. Chemistry&Physics&Environment,
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/users/attachments/20150815/32ed8e48/attachment.html>


More information about the users mailing list