VASP compiled with MPICH2- LAPACK ZPOTRF error

Message

sudhakar · #1 Post by **sudhakar** » Mon Sep 25, 2006 9:01 pm

Hi

I was testing the mpivasp and I encountered a weird error. Initially when I used the USPP POTCAR file the mpivasp worked perfectly fine.

So in the next step I used the PAW POTCAR and my test calculations crashes with the foloowing error.

running on 2 nodes
distr: one band on 1 nodes, 2 groups
vasp.4.6.28 25Jul05 complex
POSCAR found : 1 types and 2 ions
LDA part: xc-table for Ceperly-Alder, standard interpolation
POSCAR, INCAR and KPOINTS ok, starting setup
WARNING: wrap around errors must be expected
FFT: planning ... 1
reading WAVECAR
LAPACK: Routine ZPOTRF failed! 4
LAPACK: Routine ZPOTRF failed! 4

I don't understand how the USPP POTCAR works and the PAW one fails

Any comments ?

Thanks

#2 Post by **admin** » Tue Sep 26, 2006 11:06 am

Did you start the PAW run with exactly the same input parameters as the US-PP one?

sudhakar · #3 Post by **sudhakar** » Tue Sep 26, 2006 7:19 pm

yes everything stays exactly the same... only the POTCAR was changed. The test system was just to calculate the total energy of H2 molecule.

ashinde · #4 Post by **ashinde** » Fri Sep 29, 2006 4:52 pm

I've had the same error, and I used PAW POTCAR as well. I haven't tried with USPP. I'm not sure why that specific subroutine fails either.

#5 Post by **admin** » Tue Oct 03, 2006 8:38 am

sorry, I cannot reproduce this error with any of the standard VASP-PPS, neither the US nor the PAW ones, there is definitely no bug in the potentials or the code which may be the reason for this error.

The error is due to a LAPACK call, ZPOTRF computes the Cholesky factorization of a complex Hermitian positive definite matrix A.
If the installation of the LAPACK is done correctly and the input is reasonable otherwise (KPOINTS, INCAR,POSCAR), the reasons of the error might be
-) the RMM-DIIS algorithm (in case you use it) fails for this step (electronic optimisation),
-- switch to a different algorithm (ALGO = Normal or IALGO = 38 (blocked Davidson) may be more stable)
-) maybe, the first ionic relaxation step lead to an unreasonable geometry (compare the input and output geometries of the first ionic iteration step for both runs).
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= (0.1)