Dear Sir,
I'm trying to calculate MEP using Climbing NEB ( 1 or 3 images are interpolated), however, it is not convergent. The energy is very strange, goes to a possitive value.
I find there's the warning information in the output file "WARNING in EDDRMM: call to ZHEGV failed, returncode = 6 3 3". Is it related to the problem?
In addition, will the final state affect the MEP search? If the final state is not the global minimum but the local minimum, is the interpolated image able to converge?
Here is my input file:
NEB
ENCUT = 400
GGA = PE
ISMEAR = 1
SIGMA = 0.4
ISIF = 0
IALGO = 48
EDIFF = 1.0E-4
EDIFFG = -1.0E-3
IMAGES = 1
SPRING = -5
IBRION = 3
POTIM = 0.10
LCLIMB=.TRUE.
NSW = 300
LREAL = .FALSE.
LCHARG = .False.
Many thanks
Zhang Jia
Problem in claculating MEP
Moderator: moderators
Are the forces high and energies positive at the first step, or do they go bad during convergence?
If the problem is in the first iteration, the problem is likely due to a poor initial band. Using our nebmake.pl script between converged endpoints is a good way to get started. If you still get a problem, look to see if atoms move close to each other in the initial band. If they do, see:
viewtopic.php?t=172
For your second question, it is possible to find a saddle between unconverged initial and final states, but this is somewhat unstable in that an aggressive optimizer can cause intermediate images to move towards local minima. That said, it can often work just fine - I do not think this is causing the problems you are seeing.
If the problem is in the first iteration, the problem is likely due to a poor initial band. Using our nebmake.pl script between converged endpoints is a good way to get started. If you still get a problem, look to see if atoms move close to each other in the initial band. If they do, see:
viewtopic.php?t=172
For your second question, it is possible to find a saddle between unconverged initial and final states, but this is somewhat unstable in that an aggressive optimizer can cause intermediate images to move towards local minima. That said, it can often work just fine - I do not think this is causing the problems you are seeing.
Thank you for your prompt reply.
Here is the force information after the 1st iteration. It seems that the forces are quite big. I wonder which force I should check, is it "Forces:max atom, RMS ...."?
In addition, the current image is generated by nebmake.pl script.
I should use neb_pushapart.pl to re-generate POSCAR, right?
Thanks a lot.
NEB: forces: par spring, perp REAL, dneb 0.000000 19.902381 0.000000
NEB: distance to prev, next image, angle between 0.861493 0.861493 179.
99999
NEB: projections on to tangent (spring, REAL) 0.000000 -1.222515
FORCES: max atom, RMS 14.436323 4.157755
FORCE total and by dimension 19.939892 13.013148
Here is the force information after the 1st iteration. It seems that the forces are quite big. I wonder which force I should check, is it "Forces:max atom, RMS ...."?
In addition, the current image is generated by nebmake.pl script.
I should use neb_pushapart.pl to re-generate POSCAR, right?
Thanks a lot.
NEB: forces: par spring, perp REAL, dneb 0.000000 19.902381 0.000000
NEB: distance to prev, next image, angle between 0.861493 0.861493 179.
99999
NEB: projections on to tangent (spring, REAL) 0.000000 -1.222515
FORCES: max atom, RMS 14.436323 4.157755
FORCE total and by dimension 19.939892 13.013148
You only need to use the push apart script if any atoms get close together (<1 Ang) in the initial band.
A force of 10-20 eV/Ang is large, but not nessecarily problematic for an initial band. If this is the highest force along the band, you can probably relax the band. Start with roughly 20 iterations using IBRION=3 and POTIM=0.01 until the forces drop below 1 eV/Ang.
A force of 10-20 eV/Ang is large, but not nessecarily problematic for an initial band. If this is the highest force along the band, you can probably relax the band. Start with roughly 20 iterations using IBRION=3 and POTIM=0.01 until the forces drop below 1 eV/Ang.
Sorry to bother you again.
Here is the new force information at 25th iteration when POTIM = 0.01 is performed. You mentioned the forces drop below 1eV/A. Does it point to "Force total" or "Forces: max atom, RMS"? There are several force values, I 'm not sure which one is the benchmark.
Many Thanks.
NEB: forces: par spring, perp REAL, dneb 1.196571 4.323338 0.000000
NEB: distance to prev, next image, angle between 1.276959 1.037645 95.
659743
NEB: projections on to tangent (spring, REAL) -1.196571 -0.098952
FORCES: max atom, RMS 2.389106 0.901714
FORCE total and by dimension 4.324470 2.375987
Here is the new force information at 25th iteration when POTIM = 0.01 is performed. You mentioned the forces drop below 1eV/A. Does it point to "Force total" or "Forces: max atom, RMS"? There are several force values, I 'm not sure which one is the benchmark.
Many Thanks.
NEB: forces: par spring, perp REAL, dneb 1.196571 4.323338 0.000000
NEB: distance to prev, next image, angle between 1.276959 1.037645 95.
659743
NEB: projections on to tangent (spring, REAL) -1.196571 -0.098952
FORCES: max atom, RMS 2.389106 0.901714
FORCE total and by dimension 4.324470 2.375987
The 1eV/Ang is a rough rule of thumb for switching to a more aggressive optimizer or a larger time step. You could run a little longer with POTIM=0.01.
The different forces are just different ways of measuring the magnitude of the force vector. Vasp compares the 'max atom' or the maximum magnitude of the force on any one atoms with -EDIFFG to decide convergence.
The different forces are just different ways of measuring the magnitude of the force vector. Vasp compares the 'max atom' or the maximum magnitude of the force on any one atoms with -EDIFFG to decide convergence.
Re: Problem in claculating MEP
Hi,
I've been encountering that same error message. According to the VASP forum, it is due to a failure of the algorithm you are using, e.g. IALGO=48.
If you are curious, take some time to read these remarks:
http://cms.mpi.univie.ac.at/vasp-forum/ ... .php?3.214
Regards,
C.
[quote="zhangj"]Dear Sir,
I'm trying to calculate MEP using Climbing NEB ( 1 or 3 images are interpolated), however, it is not convergent. The energy is very strange, goes to a possitive value.
I find there's the warning information in the output file "WARNING in EDDRMM: call to ZHEGV failed, returncode = 6 3 3". Is it related to the problem?
In addition, will the final state affect the MEP search? If the final state is not the global minimum but the local minimum, is the interpolated image able to converge?
Here is my input file:
NEB
ENCUT = 400
GGA = PE
ISMEAR = 1
SIGMA = 0.4
ISIF = 0
IALGO = 48
EDIFF = 1.0E-4
EDIFFG = -1.0E-3
IMAGES = 1
SPRING = -5
IBRION = 3
POTIM = 0.10
LCLIMB=.TRUE.
NSW = 300
LREAL = .FALSE.
LCHARG = .False.
Many thanks
Zhang Jia[/quote]
I've been encountering that same error message. According to the VASP forum, it is due to a failure of the algorithm you are using, e.g. IALGO=48.
If you are curious, take some time to read these remarks:
http://cms.mpi.univie.ac.at/vasp-forum/ ... .php?3.214
Regards,
C.
[quote="zhangj"]Dear Sir,
I'm trying to calculate MEP using Climbing NEB ( 1 or 3 images are interpolated), however, it is not convergent. The energy is very strange, goes to a possitive value.
I find there's the warning information in the output file "WARNING in EDDRMM: call to ZHEGV failed, returncode = 6 3 3". Is it related to the problem?
In addition, will the final state affect the MEP search? If the final state is not the global minimum but the local minimum, is the interpolated image able to converge?
Here is my input file:
NEB
ENCUT = 400
GGA = PE
ISMEAR = 1
SIGMA = 0.4
ISIF = 0
IALGO = 48
EDIFF = 1.0E-4
EDIFFG = -1.0E-3
IMAGES = 1
SPRING = -5
IBRION = 3
POTIM = 0.10
LCLIMB=.TRUE.
NSW = 300
LREAL = .FALSE.
LCHARG = .False.
Many thanks
Zhang Jia[/quote]