Trouble with ISMEAR = -2 Calculation in VASP 6.4.3 even after patching

[5-1735]

I attempted to calculate an excited state for an NV- center in C-diamond using VASP v6.4.3 compiled for GPUs on NERSC. However, when using occupation-constraint (ISMEAR = -2, ALGO = All, LDIAG = FALSE, NBANDS = 164, NELECT = 254) the states relaxed back to the ground state. I specified FERWE and FERDO for each k-point (checked OUTCAR to obtain the number of irreducible k-points):

FERDO = 125*1.0 1.0 1.0 1.0 0.0 35*0.0
FERWE = 125*1.0 0.0 1.0 0.0 0.0 35*0.0

This resulted in occupations like the following at each k-point in the EIGENVAL file (results found in pre-patch_state1.tar):

down-spin channel= 125*1.0 1.0 1.0 1.0 0.0 35*0
up-spin channel= 125*1.0 1.0 0.0 0.0 0.0 35*0.0

VASP was subsequently recompiled on NERSC using the patch suggested on the following two VASP forum links to correct this behavior:

https://www.vasp.at/forum/viewtopic.php ... ion#p21231
https://www.vasp.at/forum/viewtopic.php ... ion#p21231

After rebuilding I tested the same calculation and obtained similar results (post-patch_state2.tar). However, when I changed FERDO and FERWE to the following:

FERDO = 125*1.0 1.0 1.0 0.0 1.0 35*0.0
FERWE = 125*1.0 1.0 0.0 0.0 0.0 35*0.0

I obtained in the EIGENVAL file:

down-spin channel = 125*1.0 1.0 1.0 0.0 1.0 35*0
up-spin channel= 125*1.0 1.0 0.0 0.0 0.0 35*0.0

I'm not sure why I get different behavior in these cases. I would like to be able to simulate the 3E excited state (state 1), can anyone help? Is there a patch I need or are one of my INCAR tags off?

[merzuk.kaltak]

Dear 5-1735,

Thank you for your report. I am waiting for GPU resources, will keep you updated.

Meanwhile, I was able to run your jobs successfully with the CPU version with a reduced k-point grid (222) performing only 2 ionic steps.
There was no patch necessary for 6.4.3 to obtain following eigenvalues.

Gamma-point for state 1:

Code: Select all

...
    122          7.545924        7.079432   1.000000   1.000000
    123          9.088662        8.732612   1.000000   1.000000
    124          9.202946        9.107400   1.000000   1.000000
    125          9.203205        9.087138   1.000000   1.000000
    126         10.722016       10.195901   0.000000   1.000000
    127         12.641185       11.794074   1.000000   1.000000
    128         12.596386       11.596931   0.000000   1.000000
    129         13.759502       13.716532   0.000000   0.000000
    130         13.869800       13.847899   0.000000   0.000000
    131         13.861143       13.837739   0.000000   0.000000
    132         14.001048       13.975975   0.000000   0.000000
    133         14.048206       14.010435   0.000000   0.000000
    134         14.047193       14.006972   0.000000   0.000000
...

For state 2:

Code: Select all

...
    122          7.448909        7.137649   1.000000   1.000000
    123          8.860475        8.726682   1.000000   1.000000
    124          9.145903        9.020285   1.000000   1.000000
    125          9.170240        9.048923   1.000000   1.000000
    126         10.506011       10.325422   1.000000   1.000000
    127         11.639465       11.072104   0.000000   1.000000
    128         11.888290       11.202111   0.000000   0.000000
    129         13.913700       13.820629   0.000000   1.000000
    130         13.949870       13.900465   0.000000   0.000000
    131         13.971742       13.922342   0.000000   0.000000
    132         14.079797       14.033457   0.000000   0.000000
    133         14.090815       14.034959   0.000000   0.000000
    134         14.095016       14.044448   0.000000   0.000000
...

From what I have seen in your log files, you start all your jobs by read an existing WAVECAR.
Could you run your jobs from a clean directory?

[merzuk.kaltak]

Running the jobs in a clean working directory on 1 GPU with version 6.4.3 produces the same results as reported above.

I suspect the reason for the discrepancy is related to the existing WAVECAR file.
Can you confirm?

[merzuk.kaltak]

FYI: In case you observe that the excited state disappears after some ionic steps, it might be helpful to switch off the wavefunction interpolation method with IWAVPR=0.

[5-1735]

Hello merzuk.kaltak, and thank you for your reply!

I have since obtained correct behavior by performing relaxations in both the up and down spin channels on gpu resources. I think you were correct, I just needed to restart, rather than use the previously converged ground-state wavefunctions.

However, when I attempted to get a self-consistent field calculation (instead of a relaxation) I got the attached bug report. Since then, I have performed a self-consistent field calculation after relaxation, and did not receive a bug report. I think this behavior may be due to being "far from" the minimum energy. Does this bug reflect anything wrong with the calculation itself?

[merzuk.kaltak]

To say more, I would need the output and input files. Please upload INCAR, POSCAR, stdout and if possible the OUTCAR.