Bug report: problems with constrained magnetic moment: VASP 6.3.2, OpenACC, R2SCAN

[arnab_kabiraj1]

Hi,
I am trying to constrain the direction of the magnetic moments of some specific sites of some 2D materials. I'm using the R2SCAN mgga functional and OpenACC. My INCAR looks like:

Code: Select all

ALGO = All
EDIFF = 1e-06
ENCUT = 520
IBRION = -1
ICHARG = 0
ISMEAR = 0
ISPIN = 2
ISYM = -1
I_CONSTRAINED_M = 1
KPAR = 2
LAECHG = False
LAMBDA = 50
LASPH = True
LCHARG = False
LMAXMIX = 4
LMIXTAU = True
LORBIT = 11
LORBMOM = True
LREAL = False
LSORBIT = T
LVHAR = False
LVTOT = False
LWAVE = True
MAGMOM = 0 0 0.004 0 0 0.004 0 0 0.004 0 0 0.004 0 0 -0.001 0 0 -0.001 0 0 -0.001 0 0 -0.001 0 0 -0.053 0 0 -0.053 0 0 -0.053 0 0 -0.053 0 0 -0.036 0 0 -0.036 0 0 -0.036 0 0 -0.036 0 0 -0.065 0 0 -0.065 0 0 -0.065 0 0 -0.065 0 0 -0.015 0 0 -0.015 0 0 -0.015 0 0 -0.015 0 0 0.023 0 0 0.023 0 0 0.023 0 0 0.023 0 0 -0.013 0 0 -0.013 0 0 -0.013 0 0 -0.013 0 0 1.545 1.545 0 0 0 0 -1.545 -1.545 0 0
METAGGA = R2SCAN
M_CONSTR = 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 -1 -1 0 0
NCORE = 1
NELM = 400
NELMIN = 6
NSIM = 4
NSW = 0
PREC = Accurate
RWIGS = 0.73 1.39 0.66 1.7 1.53
SIGMA = 0.01

But, the first step of OSZICAR looks like:

Code: Select all

       N       E                     dE             d eps       ncg     rms          ort

 E_p =  0.52673E-03  lambda =  0.500E+02
<lVp>=  0.10535E-02
 DBL = -0.52673E-03
 ion        MW_int                 M_int
  1  0.000  0.000 -0.001    0.000  0.000 -0.001
  2  0.000 -0.000  0.000    0.001 -0.001  0.001
  3 -0.001  0.000  0.000   -0.002 -0.000  0.001
  4  0.000  0.000 -0.000    0.000  0.001 -0.000
  5 -0.000 -0.000 -0.000   -0.000 -0.000 -0.000
  6  0.001  0.000  0.000    0.002  0.001  0.000
  7 -0.000  0.001 -0.000   -0.001  0.001 -0.001
  8 -0.000  0.000 -0.000   -0.000  0.001 -0.000
  9  0.000  0.000 -0.000    0.002  0.001  0.000
 10 -0.001 -0.000  0.000   -0.002 -0.000  0.000
 11 -0.000 -0.000 -0.000   -0.001 -0.001 -0.000
 12 -0.000  0.001  0.000   -0.000  0.002  0.000
 13 -0.001 -0.001  0.001   -0.003 -0.004  0.003
 14  0.002 -0.001 -0.001    0.003 -0.004 -0.004
 15  0.001 -0.001 -0.000    0.004 -0.003  0.000
 16  0.001 -0.001 -0.000    0.003 -0.002 -0.003
 17 -0.000  0.000  0.000   -0.000  0.001  0.001
 18  0.000  0.000 -0.000    0.001  0.000 -0.000
 19  0.001 -0.000 -0.000    0.002 -0.000 -0.001
 20 -0.000  0.000  0.000   -0.000  0.000  0.000
 21 -0.001 -0.001 -0.000    0.001 -0.002 -0.002
 22  0.000  0.000 -0.002   -0.001  0.002 -0.001
 23  0.000 -0.001 -0.001    0.001  0.001 -0.002
 24 -0.000  0.003 -0.000   -0.003  0.007 -0.003
 25  0.000 -0.004 -0.002   -0.000 -0.009 -0.000
 26 -0.003 -0.002  0.001   -0.005 -0.005 -0.000
 27 -0.002 -0.003  0.001   -0.007 -0.008 -0.001
 28  0.000  0.000 -0.001    0.001  0.002 -0.004
 29 -0.002  0.001 -0.001   -0.004  0.003 -0.001
 30 -0.002  0.001  0.001   -0.007  0.001  0.000
 31 -0.001 -0.001 -0.002   -0.001 -0.004 -0.002
 32 -0.001 -0.003 -0.001    0.000 -0.011 -0.002
 33 -0.000  0.001 -0.002    0.003  0.003 -0.004
 34  0.002 -0.000 -0.001    0.002  0.001 -0.005
 35  0.000 -0.000  0.000   -0.000 -0.001 -0.000
 36  0.003  0.003 -0.001    0.006  0.010 -0.000
DAV:   1    -0.298811971227E+06   -0.29881E+06   -0.56470E+06 13104   0.271E+04

This clearly means that the initial magnetic moments supplied through MAGMOM has not been applied to the sites. This calculation goes on without proper initialization, and as a result, the convergence becomes extremely bad, and in the end a random spin state (never the desired state) is found.
I have also noticed that this problem occurs randomly, changing some random value of MAGMOM sometime results in a proper initial moment configuration visible in OSZICAR, and the calculation converges to the desired state. However, more often than not, I'd say 80% of times, this problem occurs.
I have tried with different combinations of the following toolchain. None of them seems to be solving the issue.

VASP 6.3.2
VASP 6.3.1
VASP 6.2.1
nvhpc stack 22.5 (CUDA 11.7, compute 8.0)
nvhpc stack 22.7 (CUDA 11.7, compute 8.0)
fftw 3.3.10
Wannier90 3.1.0
hdf5 1.12.2
hdf5 1.12.1

I am running the calculations on a single node of a NVIDIA DGX Server Version 5.0.5, containing 256 AMD EPYC 7742 64-Core Processors and 8 A100-SXM4-40GB GPUs. The inputs and outputs of two examples are attached.

Thanks,
Arnab

[arnab_kabiraj1]

Update:
The problem seems to be stemming from the ICHARG tag. I have kept ICHARG = 0 in anticipation of restarting the calculation with a greater value of LAMBDA. VaspWiki says "If ISTART is internally reset due to an invalid WAVECAR file, ICHARG will be set to ICHARG=2." However, it seems to be not happening. Even if there's no valid WAVECAR, the ICHARG tag is not internally set to 2 (from 0) most of the time. A few times, with some small random changes in the given MAGMOMs, it is set to 2 (from 0), and VASP is working as expected for these cases.

[merzuk.kaltak]

Dear Arnab,

thank you for your post.
It is known to us that if calculations are started repeatedly with small changes in the input parameters, such as LAMBDA,
one should read the CHGCAR instead of the WAVECAR file by setting ICHARG=1.
However, this was not documented yet.
I have updated the wiki pages of CHGCAR and ICHARG accordingly.

[arnab_kabiraj1]

Hello,
Thanks for the response and the documentation update. I was under the impression that one should use WAVECAR to restart these calculations. One question, if a calculation starts with ICHARG =1 but with no valid CHGCAR or WAVECAR files, would it unambiguously fall back to ICHARG = 2?

[merzuk.kaltak]

Yes,
vasp should revert to ICHARG=2 if no valid CHGCAR is present.