My Community

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.

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

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.

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: The vasp run then says: 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.

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

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)

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?

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>

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

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