NEWMODECAR from a Dimer calculation

[jianmin]

Dear Prof. Graeme,

I noticed that a file named NEWMODECAR is generated after a Dimer calculation is done. Does it mean that we could use this NEWMODECAR file for next run if the former run is not complete?

In some cases, the Dimer calculation (let name it Job 1) is not complete after 50 NSW steps. If I setup a new job to continue it, can I use the MODECAR from Job 1?

Thanks for your time.

[graeme]

That's right, the NEWMODECAR should replace the MODECAR in the subsequent calculation.

[jianmin]

Thanks a lot for your reply, Prof. Graeme.

[dwblay]

I have a question regarding the restart of Dimer jobs, so I will put it here since this thread deals with that topic. I am using the dimer method to search for the first-order saddle point associated with the highest-energy image of a CI-NEB job I performed for a surface reaction TS search.

I am currently limited to only 24 hours of wall-time because of mpi errors on our cluster, so I have to restart my dimer jobs each day. This has proven to be a source of delay because the dimer restart is not perfectly clean. The error in the forces will be on the order of, let's say, 2E-2 eV/A at the end of the prematurely terminated dimer job (my value for EDIFFG is 1E-3). When I restart, using the previous CONTCAR and NEWMODECAR (I've tried it with and without the previous WAVECAR), the curvature begins with a high positive number (instead of the previously negative number) and with the errors on forces being at least an order of magnitude higher than those at the end of the previous job.

My thought is that this happens because when the dimer job restarts, it does not have a good initial guess for the Hessian, and starts somewhat blindly. I have tried both the CG (IOPT=2) and LBFGS (IOPT=1) optimizers in hope of finding better restart performance, but didn't see a large difference. Is there a way to supply the optimizer with a better guess for the Hessian or a flag that can be turned on to carry over the limited memory line searches from the previous LBFGS optimization?

Thanks!

[graeme]

This probably has to do with a technical issue related to the dimer and the writing of the CONTAR. In the dimer method, the geometry being calculated by vasp is either at the center of the dimer, or displaced by the distance NdR. The current position is written to the CONTCAR. So if a displaced image is being calculated and you restart by copying the CONTCAR to the POSCAR, you can find that the force and curvature will change (typically both increase).

To solve this problem, we write a CENTCAR, which is always at the center of the dimer. Use this as your new POSCAR and you should see the calculation restart from where it left off. If you use our vfin.pl script, this will be done automatically.

[dwblay]

Great - thanks for your reply. I was unaware that I should restart with the CENTCAR. I've been using this method for several days now, and everything seems to be restarting well .... now if I can just get my forces to fall below 0.01-0.02 eV/A!