My Community

Hi, I do calculations for transition metals with respect to primitive monoclinic structure containing 16 atoms. VASP runs in the cluster and uses 4 processors. The INCAR is listed below:
SYSTEM = A12
ENCUT = 330
EDIFF=0.000001
ISMEAR =1
SIGMA = 0.1
IBRION=2
ISIF=3
NSW=1000
EDIFFG = -0.01
AMIX = 0.02

During the electronic structure relaxation, it always display lots of warning messages “WARNING: Sub-Space-Matrix is not hermitian in DAV 4� and eventually the calculation fails with such error message “Error EDDDAV: Call to ZHEGV failed. Returncode = 47 315�

As seen, I set AMIX from the default value of 0.4 to 0.02, and the problem still exists.
What is the reason and how can I avoid such problem?
Many thanks.

there may be several reasons for this error, the most common are
1a) the input geometry was not reasonable (error occurs at the very first ionic step) or
1b) the last ionic relaxation step lead to an unreasonable geometry (compare the input and output geometries of the
last ionic relaxation steps). In that case it can be helpful to
--> switch to a different relaxation algorithm (IBRION-tag)
--> reduce the step size of the first step by setting POTIM explicitely
2) If this error shows up at all your calculations: The installation of the LAPACK on your machine was not done properly: use a different LAPACK, e.g. the LAPACK which is delivered with the code
(vasp.4.lib/lapack_double.o)
3) 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.

I got the same problem.
If you are using vasp 4.6. Try using "IALGO =48" in the INCAR file.
It solved the problem for me.

Hi,
I got the same problem on a sgi machine when running the Cu benchmark. Changing to IALGO=48 just changed the problem; then I get the messages:
.............
lib-4201: UNRECOVERABLE library error.

Encountered during a direct access unformatted READ from unit 21.
Fortran unit 21 is connected to a direct unformatted unblocked file: "TMPCAR"
IOT trap

core dumped
.....................

These messages appeared after 20 cycles of RMM: and one line beginnig with
1 T= 2080. E= -.90209009E+04 E0=...

Please help to solve. Concerning previous admin comments I should say that in the davidson, subrot and wavpre_noio files the variable "USE_ZHEEVX" does not control whether ZHEGV is used or not; this seems to depend rather on the definition of the variable "gammareal".

1) if you set USE_ZHEEVX
DSYEVX instead of DSYEV is used if gamma_real
ZHEEVX ZHEEV all other cases.
so it does not only affect the gamma-real version.


2) please have a look to the FAQs of the manual:
(http://cms.mpi.univie.ac.at/vasp/vasp/node265.html,
"I am running VASP on a SGI Origin, and the ...)
set IWAVPR=10

Hi,
I continue to have the previously reported problem found when trying to run the Cu benchmark on a sgi machine, i.e. the program aborts and the output ends with a series of lines such as

entering main loop
N E dE d eps ncg rms
rms(c)
WARNING: Sub-Space-Matrix is not hermitian in DAV 1, -18.497193968206293
WARNING: Sub-Space-Matrix is not hermitian in DAV 2, -106.6910638174717
WARNING: Sub-Space-Matrix is not hermitian in DAV 3, -3.4046873909742339
WARNING: Sub-Space-Matrix is not hermitian in DAV 4, -37.403094929979197
WARNING: Sub-Space-Matrix is not hermitian in DAV 5, 0.14502948098981785

followed by

Error EDDDAV: Call to ZHEGV failed. Returncode = 13 1 8

The earlier solution suggested by admin (suppressing the line #define USE_ZHEEVX in davidson.F, subrot.F, and wavpre_noio.F and recompiling VASP) does not work, i.e. the same error messages, and the same indication of ZHEGV failure, still appear. I may add now that the problem appears both with the lapack which comes with VASP and with a system-native lapack library.

The warnings given suggest that the problem actually appears at an earlier stage, in which a matrix is generated with inadequate values which make it nonhermitian, and consequently ZHEGV fails even if working correctly; the solution thus would not be to avoid using ZHEGV, but to avoid an incorrect generation of the said matrix.

Can someone give an idea to really solve the problem?

Please try if it works by adding "LSCALAPACK = .FALSE." in your INCAR.

Please try if it works by adding "LSCALAPACK = .FALSE." in your INCAR.

No; adding "LSCALAPACK = .FALSE." in INCAR makes no dfference, the problem continues the same.

I was successful to fix this problem by using IALGO=48 instead of IALGO=Default

unfortunately, when i set IALGO=48, the new warning is
WARNING in EDDRMM: call to ZHEGV failed, returncode = 6 314
how to solve this problem?

I face the same problem ,but it doesn't work .Any suggestions ?

I got the same problem and solution is easy:

I was using 32 cpu when I took the error and the error disappeared for 16 cpu.

cheers

I have the same problem during my calculation, and set IALGO=48 makes no difference either.

I got the same warning msgs a lot..
Fortunately after setting "ALGO = Fast" it disappeared.
It seems the same with IALGO = 48 .
<span class='smallblacktext'>[ Edited Mon Oct 08 2012, 12:06PM ]</span>