Calculation of migration energy using NEB method...

[prithwish]

Hi,
I am trying to calculate vacancy migration energy in metallic Fe using NEB method. For this purpose, I followed the method of NEB as outlined in VASP user's guide, i.e. at first I calculated the minimum energy configuration for two end points, then four images were created using linear interpolation method.
These four image configurations are supposed to be in higher energy configurations than the two extremums. But using NEB I am getting exactly opposite result, not only that , all these four images having the same energy.
Whether, NEB method isn't the right tool for doing such type of calculation or is there any mistake in my calculation? Ia m attaching here my INCAR file.
Looking forward for help.
Thanks in advance.
Prithwish
*********
INCAR
*********
System = iron

ISMEAR = 1 ! 1: Methfessel-Paxton order N; -1:Fermi-smearing.
SIGMA = 0.2 ! Smearing factor (in ev)
PREC = High ! sets cutoff and FFT grid
EDIFF = 1E-06 ! energy stoping criterion for electronic iteration
ICHARG = 2 ! start from scratch(this flag determines how to construct the
! initial charge density. 0:calculate charge density from
! initial wave functions; 1:read the charge density from file
! CHGCAR and extrapolate from the old positions to new positions.
! in PAW and LDA+U method be careful (see manual); 2:take
! super-positions of atomic charges; 4: read potential file from
! POT file; +10: non self-consisitent calculation,it means that
!charge density will be kept constant during whole electronic
!minimization.
INIWAV = 1 ! 0:take "jellium wave functions"; 1: fill wave functions arrays
! with random nos (safest full-proof switch).
ISTART = 0 ! start from scratch.Initialize the wave functions according to
! the flag INIWAV
NELM = 100 ! maximum of 100 electronic steps.
NELMIN = 5 ! maximum of two steps.
NELMDL = -5 !no update of charge for 3 steps.
LREAL = Auto !( making the calculation fast)
ALGO = VeryFast ! (making the calculation fast)
NSIM = 4 ! (making the calculation fast);blocked algorithm update;4
! bands
! at a time
ISPIN = 2 ! 1:non-spin polarized calculations; 2:spin-polarized calculation
MAGMOM = 53*1.5 ! (default: NIONS*1;for spin-pol cal a save default:expt
!mag mom *1.2 or 1.5)
SPRING = -5
IMAGES = 4

RWIGS = 1.5
LWAVE = .FALSE.
LCHARG = .FALSE.
LVTOT = .FALSE.

Ionic relaxation
NSW = 400 ! # of steps in optimization (default 0!)
ISIF = 2 ! 0: relax ions, 1,2:relax ions,calc stresses, 3:relax ion+cell
IBRION = 1 ! 1: quasi-NR, 2:CG algorithm for ions
NFREE = 10 ! number of DIIS vectors to save
POTIM = 0.5 ! reduce trial step in optimization

#Parallel Options
LPLANE = .TRUE.
LSCALU = .FALSE.
NPAR = 10 ! how many bands in parallel
NSIM = 4

[prithwish]

My POSCAR file of FIRST Image is :
*************
POSCAR
*************
Fe
2.83447999200000
3.0000000000000000 0.0000000000000000 0.0000000000000000
0.0000000000000000 3.0000000000000000 0.0000000000000000
0.0000000000000000 0.0000000000000000 3.0000000000000000
53
Direct
1.0230717516749999e-04 1.0230717516749999e-04 1.0230717516749999e-04
1.7083841515091425e-01 1.7083841515091425e-01 1.7083841515091425e-01
9.0468933629400000e-04 9.0468933629400000e-04 3.3354868082649258e-01
1.7110587069165778e-01 1.7110587069165778e-01 4.9586235506183202e-01
1.0230717516749999e-04 1.0230717516749999e-04 6.6634901199834018e-01
1.6640298049785676e-01 1.6640298049785676e-01 8.3329922978725368e-01
9.0468933629400000e-04 3.3354868082649258e-01 9.0468933629400000e-04
1.7110587069165778e-01 4.9586235506183202e-01 1.7110587069165778e-01
-2.8732286556150000e-03 3.3323406669648709e-01 3.3323406669648709e-01
1.6984663479000195e-01 4.9586235506183202e-01 4.9586235506183202e-01
9.0468933629400000e-04 3.3323406669648709e-01 6.6586124396721880e-01
1.6667043603860029e-01 5.0029778971488947e-01 8.3303177424651020e-01
1.0230717516749999e-04 6.6634901199834018e-01 1.0230717516749999e-04
1.6640298049785676e-01 8.3329922978725368e-01 1.6640298049785676e-01
9.0468933629400000e-04 6.6586124396721880e-01 3.3323406669648709e-01
1.6667043603860029e-01 8.3303177424651020e-01 5.0029778971488947e-01
1.0230717516749999e-04 6.6666362612834573e-01 6.6666362612834573e-01
1.6734690118069059e-01 8.3329922978725368e-01 8.3329922978725368e-01
3.3354868082649258e-01 9.0468933629400000e-04 9.0468933629400000e-04
4.9586235506183202e-01 1.7110587069165778e-01 1.7110587069165778e-01
3.3323406669648709e-01 -2.8732286556150000e-03 3.3323406669648709e-01
4.9586235506183202e-01 1.6984663479000195e-01 4.9586235506183202e-01
3.3323406669648709e-01 9.0468933629400000e-04 6.6586124396721880e-01
5.0029778971488947e-01 1.6667043603860029e-01 8.3303177424651020e-01
3.3323406669648709e-01 3.3323406669648709e-01 -2.8732286556150000e-03
4.9586235506183202e-01 4.9586235506183202e-01 1.6984663479000192e-01
4.5557486192522928e-01 4.5557486192522928e-01 4.5557486192522928e-01
3.3471250686339904e-01 3.3471250686339904e-01 6.6816072179221586e-01
5.0029778971488947e-01 5.0029778971488947e-01 8.3429101014816609e-01
3.3323406669648709e-01 6.6586124396721880e-01 9.0468933629400000e-04
5.0029778971488947e-01 8.3303177424651020e-01 1.6667043603860029e-01
3.3471250686339904e-01 6.6816072179221586e-01 3.3471250686339904e-01
5.0029778971488947e-01 8.3429101014816609e-01 5.0029778971488947e-01
3.3471250686339904e-01 6.6438280380030701e-01 6.6438280380030701e-01
4.9935386903205570e-01 8.3303177424651020e-01 8.3303177424651020e-01
6.6634901199834018e-01 1.0230717516749999e-04 1.0230717516749999e-04
8.3329922978725368e-01 1.6640298049785676e-01 1.6640298049785676e-01
6.6586124396721880e-01 9.0468933629400000e-04 3.3323406669648709e-01
8.3303177424651020e-01 1.6667043603860029e-01 5.0029778971488947e-01
6.6666362612834573e-01 1.0230717516749999e-04 6.6666362612834573e-01
8.3329922978725368e-01 1.6734690118069059e-01 8.3329922978725368e-01
6.6586124396721880e-01 3.3323406669648709e-01 9.0468933629400000e-04
8.3303177424651020e-01 5.0029778971488947e-01 1.6667043603860029e-01
6.6816072179221586e-01 3.3471250686339904e-01 3.3471250686339904e-01
8.3429101014816609e-01 5.0029778971488947e-01 5.0029778971488947e-01
6.6438280380030701e-01 3.3471250686339904e-01 6.6438280380030701e-01
8.3303177424651020e-01 4.9935386903205570e-01 8.3303177424651020e-01
6.6666362612834573e-01 6.6666362612834573e-01 1.0230717516749999e-04
8.3329922978725368e-01 8.3329922978725368e-01 1.6734690118069059e-01
6.6438280380030701e-01 6.6438280380030701e-01 3.3471250686339904e-01
8.3303177424651020e-01 8.3303177424651020e-01 4.9935386903205570e-01
6.6518518596143394e-01 6.6518518596143394e-01 6.6518518596143394e-01
8.3329922978725368e-01 8.3329922978725368e-01 8.3329922978725368e-01

[graeme]

Here is what might be happening: The entire system could be translating between the initial state and the first image(s). Then, the moving atom could jump to the product state between two intermediate images, and again translate back to the final state. In this case, all energies would be the same (assuming the initial and final states are equivalent).

The climbing-image modification to the NEB helps with this kind of problem, but another simple thing you can try is to freeze a single atom that is distant from the moving atom. This will help prevent overall translation, and will still give you the correct barrier. Another change that might help is to use IBRION=3 until the forces drop below around 0.1 eV. This translation problem tends to occur only when there are high forces combined with an aggressive optimizer.

[admin]

Ther may be another reason for that behavior (depending on which file you checked for the energies):
please always have a look at the total energies as written in OUTCAR
There has been a small bug in VASP, collecting the total energies of all nodes (images) before writing them to OSZICAR ( only OSZICAR is affected). --> please always check the OUTCAR file for the total energies of an NEB calculation

[prithwish]

Now its alright. Actually I was getting the error due to the above mentioned bug in NEB code. But I am facing another problem. My claculations are not getting converged. What are the relevant parameters I should check more carfully in order to get a successful NEB calculation?

[chenling]

[quote="admin"]Ther may be another reason for that behavior (depending on which file you checked for the energies):
please always have a look at the total energies as written in OUTCAR
There has been a small bug in VASP, collecting the total energies of all nodes (images) before writing them to OSZICAR ( only OSZICAR is affected). --> please always check the OUTCAR file for the total energies of an NEB calculation[/quote]

I guess I met the same bug as the OSZICAR really "looks" ugly with numerous badly formatted lines. Regardless of its format, what I am concerning is: 1. Is the total energy extracted from OUTCAR accurate in such a situation and 2. Does it affect the calculation efficiency and 3. If possible how can I solve this problem? Thanks.