WARNING in EDDRMM: call to ZHEGV failed, returncode = 6 3 9

Message

tgakic · #1 Post by **tgakic** » Tue Jun 28, 2005 7:42 am

Is someone familiar with this warning?

I get it 18796 times in a single run (1 ionic step), with different numbers at the end.
I try to compile vasp with pathscale and those warnings are when I run my customised
benchmark... Any ideeas?

Thank you,
Ionel

#2 Post by **admin** » Tue Jun 28, 2005 8:42 am

the error is due to a LAPCK call (ZHEGV):
ZHEGV computes all the eigenvalues, and optionally, the eigenvectors
of a complex generalized Hermitian-definite eigenproblem .
there may be several reasons for that error:
1) the RMM-DIIS diagonalisation algorithm is not stable for your specific
setup of the calculation.
--> use ALGO = Normal (blocked Davidson) or
ALGO = Fast (5 steps blocked Davidson, RMM-DIIS)
2)
a) maybe your input geometry was not reasonable (error occurs at the very first ionic
step, please have a look for the geometry data of your run in OUTCAR ) or
b) the last ionic relaxation step lead to an unreasonable geometry (compare the input
and output geometries of the last ionic relaxation steps in XDATCAR).
In that case (2b) it can be helpful to
--> switch to a different relaxation algorithm (IBRION-tag)
--> reduce the step size of the first step by setting POTIM smaller than the default
value
3) The installation of the LAPACK on your machine was not done properly:
use the LAPACK which is delivered with the code
(vasp.4.lib/lapack_double.o)
4) If the error persist although you switched to the Davidson algorithm:
on some architectures (especially SGI) some LAPACK routines are not working
properly. However, it is possible to avoid the usage of the ZHEGV subroutine
by commenting the line
#define USE_ZHEEVX
in davidson.F, subrot.F, and wavpre_noio.F and recompiling VASP.

mff7d · #3 Post by **mff7d** » Wed Jul 16, 2008 7:40 pm

I've looked at this problem and debugged it to some extent within our group, as I had the same issue. We found that there's an error in the way VASP calculates k-points when using the Monkhorst-pack scheme and that the problem would be fixed if we used Gamma centered instead.

#4 Post by **admin** » Thu Jul 17, 2008 2:29 pm

please have a look whether this is the same (known) issue of k-point symmetrisation as discussed in the k-points.pdf session of the VASP-workshop?