CI-NEB convergence issue

[Ruoyan]

Hi all,
I encountered the convergence when I was doing CI-NEB calculations. I wanted to calculate in 2 steps, in the first step it should have converged to a low accuracy criteria; and after the first step, I would use the CONTCAR of each image, increase accuracy and do CI-NEB again. But in the first step, it couldn't converge. Here is the INCAR:

ENCUT = 500.000000
KSPACING = 0.150000
SIGMA = 0.050000
GGA = PE
# PREC = Accurate
ISMEAR = 0
ISTART = 0
KGAMMA = .TRUE.
LASPH = .TRUE.
LCHARG = .FALSE.
LWAVE = .FALSE.
EDIFF = 1e-5
EDIFFG = -0.5
IBRION = 3
POTIM = 0 # s2
IOPT = 7
NSW = 500
NELM = 200
# NELMIN = 5
IMAGES = 3
SPRING = -5
# LCLIMB = .TRUE. # s2
ICHAIN = 0
# ISYM = 0
LREAL = Auto # s2
NBANDS = 552
NCORE = 12
KPAR = 2
NPAR = 2

I also added my POSCARs. There are three images: POSCAR-1, POSCAR-2 and POSCAR-3. For POSCAR-0 and POSCAR-4, I optimized them separately, and used the CONTCAR as POSCAR. Here is optimization INCAR:
step1:

ENCUT = 500.000000
KSPACING = 0.150000 #Grid 3*3*3
GGA = PE
SIGMA = 0.050000
ISMEAR = 0
LASPH = .TRUE.
IBRION = 2

ISTART = 0
NELM = 100
NSW = 200
ISIF = 2
EDIFF = 1.00e-05
EDIFFG = -0.03
LREAL = Auto
ALGO = Fast
NCORE = 12
#PREC = Accurate
#LCHARG = .FALSE.
#LWAVE = .FALSE.

use CONTCAR as POSCAR in the step 2, and copy WAVECAR and CHAGCAR into the step 2 calculation folder, step 2 INCAR:

ENCUT = 500.000000
KSPACING = 0.150000 #Grid 3*3*3
GGA = PE
SIGMA = 0.050000
ISMEAR = 0
LASPH = .TRUE.
IBRION = 3
ISTART = 1 #
NELM = 100
NSW = 200
#ISIF = 3 #
EDIFF = 1.00e-05
EDIFFG = -0.03
#LREAL = .False. ##
#ALGO =
NCORE = 12
#PREC = Accurate
#LCHARG = .FALSE.
#LWAVE = .FALSE.

Does any one know why CI-NEB cannot converge? Thanks in advance!

[graeme]

I'll need a .tar.gz of the calculation to see what is going on. I can't figure out anything from 5 poscar files.

[Ruoyan]

Hi Professor,

Thank you so much for your reply.

I added the whole tar.gz file including INCAR, POSCAR, and OUTCAR.

The CI-NEB calculation can be checked by job.out file. Since I removed previous result, I reran it this morning for one hour. Previously, it ran ~450 ionic steps and couldn't converge.

Under each image folder 01, 02, 03, there is a defect.py file, which is used to generate image POSCAR. (I also tried to optimize images before CI-NEB, but it failed.)

There is a vaspforce.sh file under each image folder used to check force convergence. Previously, the result showed that the force is converged (all forces are lower than 0.5 eV/Å). They might not be converged under this folder because of limited running time.

I want to give you reply asap so that the information might not be enough. Please tell me if there's any more information I can supply.

Thanks!

[graeme]

I don't see a problem with this calculation. You do not have our code linked in so you can't use the climbing image, but otherwise it seems ok.

[Ruoyan]

Hi Professor,

Thank you for your reply. So you mean VTST code is not linked, right? Can I ask how to check whether this code is linked or not?

Thanks

[graeme]

your vasp binary does not have our vtstcode linked in.
To check, you can grep for VTST in the OUTCAR file.

Instructions for compiling vasp with the vtstcode are here:
https://theory.cm.utexas.edu/vtsttools/ ... ation.html

[Ruoyan]

Many thanks!

[Ruoyan]

Hi Professor,

I tried to use IDPP method implemented in ASE to interpolate images, and it works, the NEB calculation converged with the same INCAR parameter.

I also tried to do the same for another migration path, however, the images interpolated using IDPP method are not what I want. In those images, some of the atoms became very close to each other, which are obviously incorrect.

I was wondering, does that mean the second migration path that I assumed is incorrect, resulting in unreasonable images interpolated using IDPP?

Best

[graeme]

If you post the second path where the IDPP does not give you a sensible initial path, I can take a look at it.

[Ruoyan]

Hi Professor,

I attached the images generated by using get_images.py in the tar file. The CONTCAR-init and CONTCAR-final are optimized initial and final structures with a vacancy.

I'm sorry, I realized this description 'In those images, some of the atoms became very close to each other, which are obviously incorrect.' is inaccurate.

I focused on the vacancy migration path in [110] direction (between a lattice site and its second nearest neighbor site). Is this path correct according to the images shown in the folder? I'm a bit confused with the transition path that it generated.

BTW, can I ask one question unrelated to this? I generated the vacancy in the center, and I used PBC (periodic boundary conditions) box. The migration barrier should be the same no matter where I put the vacancy, right?

Thanks!

[graeme]

you just don't have the atoms aligned properly in terms of their ordering in the initial vs final configuration:

initial

...
7.0216564942662583 7.0216564942662583 7.0216564942662583
5.7854011707769049 8.5924886671983032 8.5924886671983032
7.2130445044587432 10.0724440734540899 10.0724440734540899
8.5924886671983032 5.7854011707769049 8.5924886671983032
10.0724440734540899 7.2130445044587432 10.0724440734540899
8.5924886671983032 8.5924886671983032 5.7854011707769049
10.0724440734540899 10.0724440734540899 7.2130445044587432

final

...
5.8124742537910041 5.8124742537910041 5.7854127817544141
7.3833024390451705 7.3833024390451705 7.0216975609548289
5.8124742537910041 8.6195872182455844 8.5925257462089952
7.2051288470192683 10.0808711529807304 10.0658998189651250
8.6195872182455844 5.8124742537910041 8.5925257462089952
10.0808711529807304 7.2051288470192683 10.0658998189651250
9.9026975609548291 9.9026975609548291 7.0216975609548289

[graeme]

and yes, with pbc, there is no difference where you make a vacancy

[Ruoyan]

Thank you Professor! That's really helpful!
I placed the atom, whose position had been changed, at the bottom of both the initial and final configurations, ensured the alignment of the other atoms' positions, and successfully obtained a proper transition path.