quickmin vs aggressive optimizers

[gump_813]

Hi Graeme,

I often run into problems with converging a NEB run using aggressive optimizers like CG or GLBFGS. However, the same NEB calculations converge very well with quickmin as the optimizer, although it may take more than 200 steps to do that (very sluggish convergence when the forces on images are small). I tried to do a two-step calculation, first I converge the forces to a small value (~0.2 eV/A) and then switch to CG or GLBFGS, but the later optimizers still mess up the pre-converged path and refuse to converge in ~100 steps (the forces jump and keep high during the run, above 1ev/A ).

Have you met similar problems? How to deal with it? I can not provide data for you to analyse it. I deleted the unconverged calculations.

[graeme]

Ah, it is such a shame to delete runs that show interesting problems. Examining them is the best way to sort them out.

If you come across this again, we'd like to look at it. The more aggressive (second order) optimizers have the potential to be more efficient than quick-min, but they can also fail if their estimation of the curvatures are poor. For CG, you may need to increase the precision of the forces by lowering ediff. Also decreasing the max_move parameter if you see a sudden increase in the forces. For LBFGS, increasing the maximum inverse curvature can help with stability. But looking at a representative calculation would be best for diagnosing the problem.

[kai]

i had suffered similar problem before and it turned out to be related to my pathway involving two barriers with similar heights. if that is what you have, probably its better to break down the calculation