dimer method - deviate giving high forces

[sxd375]

Hi

I have been running a dimer calculation from NEB which seems to deviate giving high forces as below :

Step Force Torque Energy Curvature Angle
1 0.55683 1.55128 -814.42965 -3.31755 2.13037
1 0.55683 1.36002 -814.42965 -3.34471 3.01105
1 0.55683 1.03870 -814.42965 -3.35094 1.87785
1 0.55683 0.73668 -814.42965 -3.39867 1.44102
2 0.39639 1.81908 -814.43298 -3.23269 2.45838
2 0.39639 1.66381 -814.43298 -3.26763 4.42194
2 0.39639 1.19799 -814.43298 -3.29285 1.77352
2 0.39639 0.84590 -814.43298 -3.29202 1.62193
3 0.47974 1.19322 -814.43636 -3.21659 2.49974
3 0.47974 1.15723 -814.43636 -3.24913 2.12096
3 0.47974 0.94590 -814.43636 -3.31330 1.48972
4 0.67175 1.48542 -814.44205 -2.43040 2.61735
4 0.67175 1.76558 -814.44205 -2.47813 3.73607
4 0.67175 1.64703 -814.44205 -2.51237 1.99068
4 0.67175 1.54185 -814.44205 -2.52510 1.95258
4 0.67175 1.55595 -814.44205 -2.53398 2.56948
4 0.67175 1.43543 -814.44205 -2.54991 2.13284
4 0.67175 1.14508 -814.44205 -2.55834 2.09484
4 0.67175 1.17081 -814.44205 -2.55377 2.69903
4 0.67175 1.06978 -814.44205 -2.56770 1.43013
4 0.67175 0.66849 -814.44205 -2.60478 1.45437
5 1.14741 2.30985 -814.45511 -1.50894 2.66034
5 1.14741 1.64501 -814.45511 -1.56994 2.51603
5 1.14741 1.89726 -814.45511 -1.59959 3.00694
5 1.14741 1.84907 -814.45511 -1.61116 1.72414
5 1.14741 1.79065 -814.45511 -1.61278 1.02948
5 1.14741 1.80635 -814.45511 -1.62366 0.85204
5 1.14741 1.82234 -814.45511 -1.61843 0.37459
5 1.14741 1.83665 -814.45511 -1.61604 0.24601
5 1.14741 1.84797 -814.45511 -1.61401 0.14515

The above run shows max atom forces increasing from 0.18 to 0.53 using vef.pl. The curvature seems negative enough and even the angles are too small meaning it should converge to a saddle eventually and the forces should go down. I am using default values for dimer. Only DROTmax I have kept to 20 so that lowest curvatures modes are obtained in each step. And I think --lowering the DROTmax should not make it deviate, only can slow convergence. Can I lower it to even 1 here now that the curvatures are negative and angles are small ?

Please let me know what I am doing wrong in here.

[graeme]

This calculation looks ok. There is no guarantee that the force will drop during convergence. It does indicate that you are not close to a saddle, but the fact that you have a negative mode is the most important factor. You can lower DROTmax to speed things up, and then continue running and see if the forces eventually drop while maintaining the negative mode. If the lowest mode becomes positive, then you were not near a saddle.

[sxd375]

well Thanks

I have another question - can I use IBRION 1 (quasi newton) with low POTIM value and EDIFF 10^-5 in place of IOPT =2 that i am using here( Since IOPT 2 requires curvature calculation and EDIFF 10^-8 requires more running time on the cluster) ?

Though i tried IOPT 1 as well, but the DIMCAR showed a single rotation only for a number of normal optimisation steps running without the dimer rotating again.

[graeme]

Both IBRION=1 and 2 evaluate curvatures. You should be able to get away with an ediff value around 1e-5 for both optimizers.

You should not use IBRION=2 for dimer calculations because this implementation of conjugate gradients requires that the force be consistent with the energy, which is not the case when a method does a force projection. The IOPT optimizers all work with the dimer method. IBRION=1 and 3 should also be fine.

It sounds like something isn't right for your IOPT=1 calculation. If you attach it, I'll take a look.

[sxd375]

Thanks
But when I use IBRION 1 with some POTIM, I get the error :

CHAIN: Must set IOPT>0 to use the Dimer method

That means dimer can only work with optimisers not the usual quasi newton. That means I need to use IOPT 1 for LBFGS algorithm with high EDIFF values for accurate curvatures( And I guess IOPT 1 and IBRION 1 should work same way since I am working on a single image in case of dimer unlike in an NEB with more number of images)

Am I right here ?

[graeme]

Ah yes, you are right. I don't remember why we don't allow IBRION=1 with the dimer method, but I recognize the message that you report. And yes, IOPT=1 and IBRION=1 should be very similar, apart from implementation details.

[sxd375]

Sorry to bother u again.

I continued the dimer run as posted in the beginning of this thread and I got following DIMCAR with IOPT 2 :

Step Force Torque Energy Curvature Angle
1 2.04134 1.05964 -815.09297 -2.71707 1.46944
1 2.04134 0.94002 -815.09297 -2.73440 2.58905
2 2.18434 1.52218 -815.17822 -2.36991 1.84473
2 2.18434 1.26034 -815.17822 -2.40386 1.21567
2 2.18434 1.51801 -815.17822 -2.40858 1.03133
2 2.18434 1.53001 -815.17822 -2.40626 0.57566
2 2.18434 1.50157 -815.17822 -2.40380 0.31483
2 2.18434 1.48249 -815.17822 -2.40215 0.18780
2 2.18434 1.47130 -815.17822 -2.40099 0.11878
2 2.18434 1.46617 -815.17822 -2.40082 0.07632
2 2.18434 1.46054 -815.17822 -2.39969 0.05362
2 2.18434 1.45789 -815.17822 -2.39940 0.03560

with forces rising to 0.9 ev(max atom).

So now what options do I have ?
1. Do I need to change my initial MODECAR file (i.e. the starting guess for the dimer direction ? Please note I began this dimer with a converged CL_NEB, only issue was it gave multiple frequencies for TS.
Though I am not sure how to change the initial Modecar since I used neb2dim.pl and it took modecar from the MEP.
2. Or re-running with different optimiser will make a difference ?

Thanks

[graeme]

You are doing too many rotation iterations. The negative mode is nicely converged at -2.4 so you need to translate the dimer to converge to a saddle. You can safely lower DROTMax, or stick with the default value of 4.

[sxd375]

[quote=sxd375 post_id=9757 time=1520453277 user_id=8521]
well Thanks

I have another question - can I use IBRION 1 (quasi newton) with low POTIM value and EDIFF 10^-5 in place of IOPT =2 that i am using here( Since IOPT 2 requires curvature calculation and EDIFF 10^-8 requires more running time on the cluster) ?

Though i tried IOPT 1 as well, but the DIMCAR showed a single rotation only for a number of normal optimisation steps running without the dimer rotating again.
[/quote]
replying to the above

I have attached the dimer run for IOPT=1, which ran for a number of normal optimisation steps running without the dimer rotating again. I used default values for this optimiser. (I am not sure if LGLOBAL needs to be turned False, since here we have just 1 image in case of dimer run)
Please let me know if I am doing anything wrong.

[sxd375]

Dear Dr. Graeme

please let me know if you have any updates on this.

Thanks

[graeme]

There is something wrong here. It's on my list and I'll let you know when I figure out what's going on.

[sxd375]

Great Thanks