NaN in self-consistent GW calculation
Posted: Mon May 20, 2013 8:27 pm
Hello,
I'm trying to do self-consistent GW calculations on iron pyrite. The DFT run goes fine, and the first iteration of the GW calculation seems to go fine, but on the second iteration I get nothing but NaN's for my eigenvalues at some k-points. After that the calculation hangs. This is a very reproducible problem that occurs on multiple platforms with both gnu and Intel compilers as well as with both mvapich2 and openmpi libraries. I had the problem on the TACC resource Stampede and was in contact with the tech support there. They were able to reproduce the problem but were unable to solve it.
My INCAR file is as follows:
encut=600
ediff=1e-8
GGA=PE
PREC=accurate
lreal = auto
ismear = 0
NBANDS=576
nomega = 100
encutgw=200
algo = scGW
nelm = 15
sigma=0.05
LWAVE=.TRUE.
LOPTICS=.TRUE.
LPEAD=.TRUE.
KPAR=4
The really bizarre thing is that, when I run on my local cluster I have the problem. But if I use only 8 processors per node instead of the full 16, the problem goes away. This trick does not work on Stampede.
I know it's a weird question but any help you could give would be greatly appreciated.
Thanks,
Brian Kolb
I'm trying to do self-consistent GW calculations on iron pyrite. The DFT run goes fine, and the first iteration of the GW calculation seems to go fine, but on the second iteration I get nothing but NaN's for my eigenvalues at some k-points. After that the calculation hangs. This is a very reproducible problem that occurs on multiple platforms with both gnu and Intel compilers as well as with both mvapich2 and openmpi libraries. I had the problem on the TACC resource Stampede and was in contact with the tech support there. They were able to reproduce the problem but were unable to solve it.
My INCAR file is as follows:
encut=600
ediff=1e-8
GGA=PE
PREC=accurate
lreal = auto
ismear = 0
NBANDS=576
nomega = 100
encutgw=200
algo = scGW
nelm = 15
sigma=0.05
LWAVE=.TRUE.
LOPTICS=.TRUE.
LPEAD=.TRUE.
KPAR=4
The really bizarre thing is that, when I run on my local cluster I have the problem. But if I use only 8 processors per node instead of the full 16, the problem goes away. This trick does not work on Stampede.
I know it's a weird question but any help you could give would be greatly appreciated.
Thanks,
Brian Kolb