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 <[email protected]> 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
_______________________________________________ Pw_forum mailing list [email protected] http://pwscf.org/mailman/listinfo/pw_forum
