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

Problems running VASP: crashes, internal errors, "wrong" results.


Moderators: Global Moderator, Moderator

Post Reply
Message
Author
lahaye
Jr. Member
Jr. Member
Posts: 98
Joined: Fri Apr 14, 2006 5:08 am
Location: Suwon - Korea

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

#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.
Last edited by lahaye on Fri Nov 24, 2006 11:50 pm, edited 1 time in total.

admin
Administrator
Administrator
Posts: 2921
Joined: Tue Aug 03, 2004 8:18 am
License Nr.: 458

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

#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?
Last edited by admin on Mon Nov 27, 2006 9:04 am, edited 1 time in total.

xianghjun

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

#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.
Last edited by xianghjun on Mon Nov 27, 2006 1:43 pm, edited 1 time in total.

lahaye
Jr. Member
Jr. Member
Posts: 98
Joined: Fri Apr 14, 2006 5:08 am
Location: Suwon - Korea

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

#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.
Last edited by lahaye on Mon Dec 18, 2006 2:10 am, edited 1 time in total.

csfn

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

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

[quote="'smallblacktext'>[ Edited Sat Jan 19 2008, 01:48PM "]</span>
Last edited by csfn on Sat Jan 19, 2008 12:44 pm, edited 1 time in total.

admin
Administrator
Administrator
Posts: 2921
Joined: Tue Aug 03, 2004 8:18 am
License Nr.: 458

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

#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)
Last edited by admin on Wed Jan 23, 2008 3:24 pm, edited 1 time in total.

tsemi
Newbie
Newbie
Posts: 18
Joined: Mon Mar 09, 2009 1:38 pm
License Nr.: 704
Location: Golden Colorado USA

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

#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?
Last edited by tsemi on Mon Jan 18, 2010 4:21 pm, edited 1 time in total.

jkg001
Newbie
Newbie
Posts: 2
Joined: Thu May 13, 2010 4:38 pm

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

#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>
Last edited by jkg001 on Thu May 13, 2010 5:01 pm, edited 1 time in total.

giacomo giorgi
Full Member
Full Member
Posts: 122
Joined: Tue Mar 10, 2009 2:04 am

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

#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
Last edited by giacomo giorgi on Thu Nov 21, 2013 10:08 am, edited 1 time in total.

WJoost
Newbie
Newbie
Posts: 1
Joined: Sun Dec 01, 2013 8:02 pm

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

#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
Last edited by WJoost on Sun Dec 01, 2013 8:12 pm, edited 1 time in total.

Post Reply