non-collinear: "LAPACK: Routine ZPOTRF failed!"

Message

lahaye · #1 Post by **lahaye** » Fri Nov 24, 2006 11:50 pm

Hi,

I understand that this could be a LAPACK bug, but I use
a LAPACK download from a few weeks ago, so it's fairly
recent.

This is my vasp output:

POSCAR, INCAR and KPOINTS ok, starting setup
WARNING: wrap around errors must be expected
FFT: planning ... 1
reading WAVECAR
reading wavefunctions of collinear run, up
reading wavefunctions of collinear run, down
the WAVECAR file was read sucessfully
charge-density read from file: Graphite
magnetization density read from file 1
LAPACK: Routine ZPOTRF failed! 1

And the executable bails out.

It's using the WAVECAR and CHGCAR of a former
collinear run. I have added to the former INCAR file:
LSORBIT = .TRUE.
SAXIS = 0 0 1 ! direction of the magnetic field
ISYM = 0
and removed the MAGMOM line.

Any idea why LAPACK suddenly bails out
for this non-collinear run?

Thanks,
Rob.

#2 Post by **admin** » Mon Nov 27, 2006 9:04 am

did you use a POSCAR that matches the geometry for which CHGCAR was generated?

xianghjun · #3 Post by **xianghjun** » Mon Nov 27, 2006 1:43 pm

I encountered the same problem,
and I solved this problem by deleting the collinear WAVECAR.
Maybe it is related to the different k-points between collinear and non-collinear calculations.

lahaye · #4 Post by **lahaye** » Mon Dec 18, 2006 2:10 am

admin wrote:
did you use a POSCAR that matches the geometry for which CHGCAR was generated?

xianghjun wrote:
I solved this problem by deleting the collinear WAVECAR

I used the correct POSCAR file; the problem seems to be indeed the
collinear WAVECAR file. When I delete that file, the calculation does
not have the LAPACK error.
Also: I believe this is NOT a bug in LAPACK, as this happens with both
vasp linked against LAPACK 3.1.0 (latest version), and linked against
Intel's MKL/LAPACK libraries.

This is then either a bug in the code, or the VASP guide lines are not
correct. I followed the guidelines of:
http://cms.mpi.univie.ac.at/vasp/vasp/node144.html
especially the steps recomended at the end:
"The recommended procedure for the calculation of magnetic anisotropies"

In a collinear run, I produce the WAVECAR and CHGCAR files.
I then adjust the INCAR file to:

Code: Select all

 LSORBIT = .TRUE.
 ICHARG = 11  ! non selfconsistent run, read CHGCAR
 SAXIS =  0 0 1  ! direction of the magnetic field
 NBANDS = 68  ! 2 * number of bands of collinear run
 GGA_COMPAT = .FALSE.  ! improves the numerical precission of GGA
 ISYM = 0

The vasp run then says:

Code: Select all

 vasp.4.6.28 25Jul05 complex 
 POSCAR found :  3 types and   11 ions
 LDA part: xc-table for Pade appr. of Perdew
 WARNING
 Full k-point grid generated
 Inversion symmetry is not applied
 found WAVECAR, reading the header
  number of k-points has changed, file:  41 present:  81
  trying to continue reading WAVECAR, but it might fail
 WARNING: stress and forces are not correct
 POSCAR, INCAR and KPOINTS ok, starting setup
 FFT: planning ...           1
 reading WAVECAR
 reading wavefunctions of collinear run, up
 reading wavefunctions of collinear run, down
 the WAVECAR file was read sucessfully
 charge-density read from file: Graphite                                
 magnetization density read from file 1
 LAPACK: Routine ZPOTRF failed!           1

As I mentioned before, when omitting the WAVECAR file, this problem
does not occur. Any idea why the VASP guide and practice are
contradicting each other here?

Moreover: the VASP guide warns that the non-collinear part of the code
is still in preliminar beta stage and might still have serious bugs.
Could this be one of them?

Regards,
Rob.

csfn · #5 Post by **csfn** » Sat Jan 19, 2008 12:44 pm

[quote="'smallblacktext'>[ Edited Sat Jan 19 2008, 01:48PM "]</span>

#6 Post by **admin** » Wed Jan 23, 2008 3:24 pm

if the k-mesh is changed, the old charge density is of course not a self-consistent solution with respect to the new mesh, therefore the stress and forces are not necessarily correct if the run is not converged to self-consistency itself.
also, the read k-points from WAVECAR (and the respective wavefunction coefficients) may differ from the newly generated k-mesh (and hence be inconsistent)

tsemi · #7 Post by **tsemi** » Mon Jan 18, 2010 4:21 pm

How to resolve this issue please? It doesn't seem like a proper solution to simply regenerate a WAVECAR. Since the runs are now non-self-consistent, the WAVECAR will be incorrect, yes?

jkg001 · #8 Post by **jkg001** » Thu May 13, 2010 5:01 pm

I also ran into this problem, but I found a solution. The problem comes from doing previous calculations with a reduced k-point mesh produced by symmetry operations.

I imagine you generated the k-mesh automatically. The failed SOC run should have produced an IBZKPT file. If you peek inside it, you should see all the kpoints reported with a weighting factor of 1. If this is the case, take this file, and rename it KPOINTS. Setting ISYM=0, re-do your collinear calculation using this new file to generate your kpoint mesh. The WAVECAR and CHGCAR files you produce should be compatible with SOC calculations. Just make sure you use the exact same k-point mesh and set NBANDS = 2*collinear-run value.
<span class='smallblacktext'>[ Edited Thu May 13 2010, 07:03PM ]</span>

giacomo giorgi · #9 Post by **giacomo giorgi** » Thu Nov 21, 2013 10:08 am

What about doing at first a single point self-consistent run with LSORBIT=.TRUE.;ISYM=0 on top of the previously optimized geometry without LSORBIT=.TRUE.;ISYM=0 and then once the WAVECAR is generated doing the non-selfconsistent run (LSORBIT=.TRUE.;ISYM=0;ICHARG=11)? I did it finding results in good agreement with experiments

WJoost · #10 Post by **WJoost** » Sun Dec 01, 2013 8:12 pm

I received a similar error on a calculation with 64 Ti atoms and a few O interstitials in VASP 5.3.2. The starting positions were not well relaxed. I used the following INCAR settings:

PREC = Normal
LREAL = Auto
ISMEAR = 1
SIGMA = 0.2
ISPIN = 1
IALGO = 48
ENCUT = 520
IBRION = 1
NSW = 100
EDIFFG = -1E-02
ISIF = 2
NSIM = 4
NPAR = 8
LPLANE = .TRUE.
LWAVE = .FALSE.

The work directory did not contain a pre-existing WAVECAR, CHG, or CHGCAR. I found that the error would occur after the first few self-consistent steps within the first ionic step. Changing from "IALGO = 48" to "ALGO = Fast" solved the problem.

Will