Page 1 of 2

trouble in converge

Posted: Thu Mar 02, 2017 8:26 am
by weiyidan
Dear professor,
Thanks for creating such a valuable tool.
Although several trials have been done successfully.However, there was a big trouble with my calculation that my images seemed hard to converge. And this problem confused me several days without any process.
Here is my experimental details and problems. My purpose was to exchange the vacancy with the atom to form divacancy at last (shown by the POSCAR in every image fold). when I do the simulation, the first with IOPT=7 seemed to work well , and the next step with IOP=1 were in a trouble as forces of images started to grow with structures becoming chaos which did not move in the designed route.
So i am glad you can help me to solve the confusing problem and thanks for you attention.[attachment=1]iopt=1.rar[/attachment][attachment=0]iopt=7.rar[/attachment]

Re: trouble in converge

Posted: Thu Mar 02, 2017 8:42 pm
by graeme
It looks like you have gone back to an unrelaxed POSCAR file in 00 for your second run. Atoms 66 and 116 relaxed by over 1 Ang when you minimize the 00 geometry. When you went back to your unrelaxed structure, the large distance between the 00 and 01 geometries is causing the high force and poor optimization. I do not see this as related to IOPT=7 or 1.

Re: trouble in converge

Posted: Fri Mar 03, 2017 12:24 am
by weiyidan
thanks for reply.
you mean, the number of images was not enough?
while the number is about 3 by dist.pl, will it need insert 7 or more images to make the clneb converge?

Re: trouble in converge

Posted: Fri Mar 03, 2017 1:33 am
by graeme
No, please read what I wrote carefully.

You used an unrelaxed structure for the initial state in your iopt=1 calculation.

Re: trouble in converge

Posted: Fri Mar 03, 2017 1:52 pm
by weiyidan
thanks professor, i am so awkward that such a foolish mistake is made by myself[attachment=0]neb.rar[/attachment].
I tried instantly as i saw your reply with the structure being corrected. however the force seemed to fluctuate at about 0.4 in some images. can you analyse the reason causing this phenomenon?
here is the results by nebef.pl
--------------------------------------------------------------------
0 0.009947 -1151.241600 0.000000
1 0.071643 -1150.666100 0.575500
2 0.030774 -1150.411700 0.829900
3 0.045459 -1151.190500 0.051100
4 0.090289 -1152.114800 -0.873200
5 0.078145 -1152.272400 -1.030800
6 0.004599 -1152.627800 -1.386200
----------------------------------------------------------------------
....
----------------------------------------------------------------------
0 0.009947 -1151.241600 0.000000
1 0.277905 -1150.674100 0.567500
2 0.283754 -1150.483700 0.757900
3 0.154239 -1151.179900 0.061700
4 0.165508 -1152.106200 -0.864600
5 0.034650 -1152.282600 -1.041000
6 0.004599 -1152.627800 -1.386200
-----------------------------------------------------------------------
....
-----------------------------------------------------------------------
0 0.009947 -1151.241600 0.000000
1 0.504257 -1150.697900 0.543700
2 0.404121 -1150.632400 0.609200
3 0.245564 -1151.101900 0.139700
4 0.465760 -1152.075600 -0.834000
5 0.062965 -1152.285300 -1.043700
6 0.004599 -1152.627800 -1.386200
-----------------------------------------------------------------------
.....
.....
here is the lastest results
----------------------------------------------------------------------
0 0.009947 -1151.241600 0.000000
1 0.144278 -1150.938400 0.303200
2 0.019405 -1150.768800 0.472800
3 0.305582 -1151.024000 0.217600
4 0.204902 -1151.231100 0.010500
5 0.128716 -1152.240100 -0.998500
6 0.004599 -1152.627800 -1.386200
----------------------------------------------------------------------
----------------------------------------------------------------------
0 0.009947 -1151.241600 0.000000
1 0.144278 -1150.911100 0.330500
2 0.019405 -1150.768800 0.472800
3 0.305582 -1151.024000 0.217600
4 0.204902 -1151.231100 0.010500
5 0.128716 -1152.200600 -0.959000
6 0.004599 -1152.627800 -1.386200
-----------------------------------------------------------------------
0 0.009947 -1151.241600 0.000000
1 0.144278 -1150.911100 0.330500
2 0.019405 -1150.768800 0.472800
3 0.305582 -1151.024000 0.217600
4 0.204902 -1151.231100 0.010500
5 0.128716 -1152.200600 -0.959000
6 0.004599 -1152.627800 -1.386200
------------------------------------------------------------------------
thanks,best wishes for you .

Re: trouble in converge

Posted: Fri Mar 03, 2017 2:16 pm
by weiyidan
professor,as the progress goes, the fore is becoming large and larger. what is wrong with my calculation。—.—
-----------------------------------------------------------------------
0 0.009947 -1151.241600 0.000000
1 1.457864 -1150.657000 0.584600
2 1.015996 -1150.757500 0.484100
3 0.847598 -1151.729400 -0.487800
4 0.566457 -1150.619800 0.621800
5 0.477245 -1152.028700 -0.787100
6 0.004599 -1152.627800 -1.386200
-----------------------------------------------------------------------

Re: trouble in converge

Posted: Fri Mar 03, 2017 7:09 pm
by graeme
I have a couple of suggestions / observations.

First, you have assumed a symmetric process in which both participating atoms move at the same time. The process actually occurs by breaking symmetry. In your first calculation you found a path that had fairly low forces but the highest energy image was not near a first order saddle. A more careful convergence shows a lower energy pathway with an intermediate minimum (see attached).

Second, IOPT=1 relies on estimating curvatures from differences in forces. Your forces need to be sufficiently accurate for this, and more accurate than a first-order optimizer such as IOPT=3 or 7. Setting ediff=1e-8 will improve performance for IOPT=1 (also demonstrated in the attached calculation).

I suggest that you first find the intermediate minimum and then do two separate NEB calculations to find the individual steps in your reaction mechanism.

Re: trouble in converge

Posted: Sat Mar 04, 2017 4:17 am
by weiyidan
thanks for your advice and suggestion.
I will follow your idea to do my successive work and show my results to help others.
(*∩_∩*)

Re: trouble in converge

Posted: Sat Mar 04, 2017 12:34 pm
by weiyidan
Dear professor,
i have some questions to consult you,
1.as for iopt=1 or 2 with structures having converged by iopt=7 or 3, whether the lower the ediff means to converge better or not? how can i determine the proper value?
2.If there are some charges with the structure, how can the structure converge whether a lower ediff can be useful?
thanks for helping me. it seems that i just a small shrimp in the ocean, so i am grateful to your assistance.

Re: trouble in converge

Posted: Sat Mar 04, 2017 2:41 pm
by graeme
The convergence criterion for the atoms should be determined by the magnitude of the force (ediffg = -something). The ediff parameter determines the convergence criterion for the electronic structure. There is no 'right' answer for the the appropriate value, it depends upon your calculation. Calculations which rely on curvature information, or linear response in general, typically require a lower value of ediff. As with all parameters, you need to do convergence tests and then get a feel for what parameters are important for both accuracy and computational cost.

Re: trouble in converge

Posted: Sun Mar 05, 2017 12:20 am
by weiyidan
thanks professor,
you help me a lot, can you recommend some references to me in order to deepen my understanding?

Re: trouble in converge

Posted: Wed Mar 08, 2017 3:42 pm
by wc5879
This might be helpful:

Benchmarks for Characterization of Minima, Transition States, and Pathways in Atomic, Molecular, and Condensed Matter Systems
by Samuel Chill, JCTC

Re: trouble in converge

Posted: Thu Mar 09, 2017 12:36 am
by weiyidan
thanks

Problem with Vasp version

Posted: Wed Apr 12, 2017 1:18 pm
by yetchen
Dear Prof. Henkelman,

In your previous reply in a post "trouble in converge" (viewtopic.php?f=2&t=2887&sid=3f25d3f601 ... fde80ff0a6), you uploaded a complete job (neb2.tar.gz, as attached) calculated by Vasp 5.4.1-gamma. This job is converged in 80 steps. However, when we tested this job using Vasp 5.3.5(see the attached file, vasp5.3.5.tar.gz), it's not converged over 100 steps. It's strange and why?

Thank you

Re: trouble in converge

Posted: Wed Apr 12, 2017 2:46 pm
by graeme
I'm not sure what is different between the 5.4 and 5.3 calculations, but I'm confident that it is not in the VTST code.

My guess is that the use of LBFGS with an intermediate minimum and so few images is making the calculation only marginally stable. If you look at your path, there are two barriers and the second is being resolved with just one image. Additionally, the path can have a sharp change in direction at an intermediate minimum. Try minimizing image 03 and then run separate paths, one from 00 to a minimized 03, and a second from the minimized 03 to 06, both with 5 images. Start with IOPT=3, TIMESTEP=0.1 and look for smooth, yet possibly slow, convergence. Then you can switch to LBFGS to speed things up.