| 查看: 1041 | 回复: 2 | ||
| 【奖励】 本帖被评价2次，作者wuli8增加金币 2 个 | ||
| 当前主题已经存档。 | ||
[资源]
【转帖】Compilation of VASP on Opteron/Rocks cluster Ametisti with Pathscale
|
||
|
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... |
回复此楼
2楼2009-05-23 17:09:17
3楼2009-08-07 15:14:10
5