Error EDDDAV: Call to ZHEGV failed

 

在AMD平台上遇到了个问题，Intel的似乎没出现过

PS:注意$(FC) $(FFLAGS)中间空格

Compilation of VASP on Opteron/Rocks cluster Ametisti with Pathscale 2.2.1 Fortran compiler

These observations apply to the serial version of VASP. The parallel section dealing with VASP on Ametisti using the MPI interface will be included later.
I used the makefile from Janne Blomqvist at Helsinki University of Technology (Thanks Janne).

Few things were noticed after a successful compilation.

Serial version problems:

Problem 1 : Error EDDDAV: Call to ZHEGV failed.
Problem 2 : lib-4201 : UNRECOVERABLE library error
Problem 3 : WARNING in EDDRMM: call to ZHEGV failed, returncode = 6 3 9

Parallel version problems:
Will be added at some later date

Problem 1)

The test calculation for copper system (benchmark.tar.gz, download from the VASP ftp-server) stops with an error message:
"Error EDDDAV: Call to ZHEGV failed. Returncode = 9 1 8".

The actual numbers change at the end of the error, but the message means that a LAPACK library call failed.


Solution:

The subroutine davidson.F must be handled with lower optimization setting
Add the following lines to the end of the VASP Makefile:

davidson.o : davidson.F
              $(CPP)
              $(FC) $(FFLAGS) -O1 -c $*$(SUFFIX)

(You remembered to use the TAB key instead of spaces with the second and the third line, right?)


Problem 2)

After lowering the davidson subroutine optimization level the calculation ends with another error:

"lib-4201 : UNRECOVERABLE library error: Unable to find error message (check NLSPATH, file lib.cat)
Encountered during a direct access unformatted READ from unit 21. Fortran unit 21 is connected to a direct unformatted unblocked file: "TMPCAR"
/opt/gridengine/default/spool//compute-0-4/job_scripts/10170: line 31: 16997 Aborted (core dumped) ./vasp_path_serial >vasp_path_serial.out"


Solution:

Change/add the IWAVPR=10 line to your INCAR file. This is from the VASP manual, FAQ section, page 149

"Question: I am running VASP on a SGI Origin, and the simple benchmark (benchmark.tar.gz) fails with lib-4201 :
UNRECOVERABLE library error READ operation tried to read past the end-of-record.
Encountered during a direct access unformatted READ from unit 21
Fortran unit 21 is connected to a direct unformatted unblocked file:
"TMPCAR" IOT Trap
Abort (core dumped)

Answer: VASP extrapolates the wave functions between molecular dynamics time steps. To store the wave functions of the previous time
steps either a temporary scratch file (TMPCAR) is used (IWAVPR=1-9) or large work arrays are allocated (IWAVPR=11-19).
On the SGI, the version that uses a temporary scratch file does not compile correctly, and hence the user has to set IWAVPR to 10."


Problem 3)

When running the Hg benchmark (bench.Hg.tar.gz), the OUTCAR file has numerous lines saying:
"WARNING in EDDRMM: call to ZHEGV failed, returncode = 6 3 9"

Solution:

This issue is addressed in the VASP support forum (http://cms.mpi.univie.ac.at/vasp-forum/forum_viewtopic.php?3.214)
Short summary is given here. Possible reasons (this may, once again, be connected to failures calling LAPACK routines):

1) The diagonalization algorithm is not stable for your system
-> Change ALGO = Normal or ALGO = Fast in your INCAR file

2) Your geometry is not reasonable. Maybe your initial structure or the algorithm handling ion relaxation is giving a bad structure
-> Switch to a different ion relaxation scheme (IBRION line in your INCAR)
-> Reduce the step size of the first step by reducing the POTIM value in your INCAR

3) Problem with your LAPACK installation
-> Use the LAPACK routines that came with the VASP library tar-file (vasp.4.lib)

4) If the error does not go away even if you already did the thing described in part 1 (ALGO change), then there may be a problem with LAPACK.
-> Disable the calls to ZHEGV subroutine. This can be done by commenting the line

# define USE_ZHEEVX
in subroutines davidson.F, subrot.F and wavpre_noio.F.
-> Recompile VASP after you changed the subroutines

NOTE TO SELF:

These issues have much in common with the problems usually described with Silicon Graphics computers. How curious...

Jukka-Pekka Jalkanen
21.09.2005