My Community

It is not exactly a physics question. But I wonder if the result is still reasonable or not when "WARNING in EDDRMM: call to ZHEGV failed, returncode=xx" occurred

there seems to be an error in your LAPACK installation, unfortunately these kind of errors sometimes occur on certain machine types.
1) try to use a different LAPACK (e.g. the lapack_double.o provided in vasp.4.lib
2) switch to the Davidson algorithm for electronic optimisation (ALGO=Normal) and
-- uncomment the #USE_ZHEEVX statement in the
davidson.F, subrot.F, and wavpre_noio.F files
(vasp.4.6) and then
-- recompile VASP.
Doing so, other equivalent LAPACK subroutines are used.

The problem is I cannot compile the lapack_double.f file correctly, with an error:
fortcom: Info: lapack_double.f, line 12704: This directive is not supported on this platform.
*DIR$ NOVECTOR
------^
My system is IA64 on linux, the makefile is as:

.SUFFIXES: .inc .f .F
#-----------------------------------------------------------------------
# Makefile for Portland Group F90/HPF compiler
# the makefile was tested only under Linux on Intel platforms
# however it might work on other platforms as well
#
# this release of vasp.4.lib contains lapack v2.0
# this can be compiled with pgf90 compiler if the option -O1 is used
#
# Mind: one user reported that he had to copy preclib.F diolib.F
# dlexlib.F and drdatab.F to the directory vasp.4.4, compile the files
# there and link them directly into vasp
# for no obvious reason these files could not be linked from the library
#
#-----------------------------------------------------------------------

# C-preprocessor
CPP = gcc -E -P -C $*.F >$*.f
FC=ifort

CFLAGS = -O
FFLAGS = -O3 -FI
FREE = -FR

DOBJ = preclib.o timing_.o derrf_.o dclock_.o diolib.o dlexlib.o drdatab.o


#-----------------------------------------------------------------------
# general rules
#-----------------------------------------------------------------------

libdmy.a: $(DOBJ) lapack_double.o linpack_double.o lapack_atlas.o
-rm libdmy.a
ar vq libdmy.a $(DOBJ)

# files which do not require autodouble
lapack_min.o: lapack_min.f
$(FC) $(FFLAGS) $(NOFREE) -c lapack_min.f
lapack_double.o: lapack_double.f
$(FC) $(FFLAGS) $(NOFREE) -c lapack_double.f
lapack_single.o: lapack_single.f
$(FC) $(FFLAGS) $(NOFREE) -c lapack_single.f
lapack_atlas.o: lapack_atlas.f
$(FC) $(FFLAGS) $(NOFREE) -c lapack_atlas.f
linpack_double.o: linpack_double.f
$(FC) $(FFLAGS) $(NOFREE) -c linpack_double.f
linpack_single.o: linpack_single.f
$(FC) $(FFLAGS) $(NOFREE) -c linpack_single.f

.c.o:
$(CC) $(CFLAGS) -c $*.c
.F.o:
$(CPP)
$(FC) $(FFLAGS) $(FREE) $(INCS) -c $*.f
.F.f:
$(CPP)
.f.o:
$(FC) $(FFLAGS) $(FREE) $(INCS) -c $*.f
----------------------------
I dont know how to deal with it. would you likt to help me?

Um, that's just a warning. The compilation should continue.

Failing that, simply remove those lines!!

I know how to avoid ZHEGV fail by using DAV instead of RMM. in the latter case ZHEGV fail still occurs even I have changed to the lapack lib provided in vasp.4.lib. My question is if the results still reliable when this warning occurs, beacuse I still want to use RMM method?

I am having a similar problem, but only for a certain calculation. I'm trying to do a crystal of Yb2O3 with an atom of Lu inserted. I've done the opposite (Yb in Lu2O3) with no problem, but this one either reports the ZHEGV problem or gets into a situation where each electronic iteration changes the energy by +/- 1e7 eV. The other problem didn't cause me any problem. I'm using the potpaw_GGA potentials. Any suggestions would be greatly appreciated.

Interesting Buber I never had this problem until I started using the series Y,Yb,Lu. Forgive me, but I assume that the results are valid... the scf electronic convergence would not have completed.... I