Dimer Method: High Torque When Restarting

[dimer_user]

So far I have had great success with the dimer method, but with one exception: when I restart dimer calculations, the first torques and curvatures are significantly larger than the last iteration from the prior calculation. Restarted dimer calculations typically rotate by about 20-30 degrees for the first rotation step (up to 40 degrees), and usually the second step features a smaller 10-20 degree rotation. These are significantly larger than the last rotations from the prior calculation which are typically <= 1 degree.

Am I restarting dimer calculations incorrectly? What I do now is copy the CENTCAR file to POSCAR, and copy NEWMODECAR to MODECAR without changing anything else.

Based on the significant rotation angles, and qualitatively looking at the geometry after each SCF step from the OUTCAR file, it seems that NEWMODECAR might actually contain the 45-degree-rotated vector from the rotational steepest descent step instead of the true dimer axis corresponding to the geometry in the CENTCAR file.

In case it's relevant, my OUTCAR files report VTST version 3.1 and I manually set the following VTST-related INCAR values:
EDIFF = 2e-7
ICHAIN = 2
IOPT = 2
FDSTEP = 1e-2
DdR = 1e-2
DRotMax = 2
DFNMin = 0.01
DFNMax = 1.0

[graeme]

I think there has been evidence of this problem in the past. Thank you for bringing it up again; I will revisit this issue next week and try to get to the bottom of it.

[arosen]

Has this issue been resolved? I am finding identical behavior when I restart the dimer method using the `vfin.pl` script and VTST 3.1 (with VASP 5.4.1). The force continues off where the first job finished, but the torque/curvature/angle are all very high in the first iteration (with torque, curvature, and angle all being between 10-20), whereas it was quite low at the end of the first job.

[graeme]

Ah, I'll bump this up my to-do list. Goodness, that was over a year ago!

[arosen]

Time flies! If any additional information would be helpful, let me know. I've attached the two DIMCARs, but it's just reiterating the prior post.

[dimer_user]

As a temporary workaround, one can make a Python script that looks for the dimer method information printed to OUTCAR. The mode direction can be extracted by subtracting the coordinates of the two geometries used for the finite-difference curvature calculation, i.e. the first two geometries for each dimer iteration. Care must be taken to identify which geometry correspond to the start of a dimer iteration so my general-purpose script is not elegant at all.

If one uses the VTST CG method and DRotMax = 1, however, then if I recall correctly there are exactly 4 SCF steps per dimer iteration. In that case, geometries 0, 4, 8, ... are one endpoint of the dimer, and 1, 5, 9, ... are the other endpoint. Then you can get the m^th iteration's dimer axis by subtracting geometry 4*m from geometry 4*m+1. If you use ASE this is pretty easy:

from ase.io import read # ASE can read OUTCAR files
from numpy import savetxt
trajectory = read('OUTCAR')
m = (len(trajectory)-1)/4 # get last valid m
mode = trajectory[4*m+1].positions - trajectory[4*m].positions # N x 3 numpy array, already in MODECAR format
savetxt('NEWMODECAR_2',mode) # save to NEWMODECAR_2

The dimer calculation can then be restarted by copying NEWMODECAR_2 to MODECAR, and CENTCAR to POSCAR. I probably should have posted this a long time ago, but once I included it in a restart script I forgot about it!

[arosen]

Thanks for the workaround idea! I do use ASE, so this will likely be quite useful!

[graeme]

I've updated the vtstcode to version 3.2 (svn 174) with a fix for the dimer mode writing problem.

[arosen]

Fantastic, thank you for getting to that so promptly! Looking forward to the update, as I have a lot of dimer calculations in my near future!

[arosen]

If I wish to use `dimmins.pl` on dimer calculations that have finished on the prior version of VTST, is there any way to do this accurately without rerunning the converged dimer on the newest version of VTST? I'm not sure exactly what the issues were with the MODECAR. Also, I believe the documentation for the `dimmins.pl` script may be a little misleading. It says it takes two POSCAR files as input, but really one of those should be a MODECAR, right?

[graeme]

Ah, you are probably right, I will update the documentation.

I think that you will either need to run a few steps with a new dimer calculation to re-orient the dimer and get a good modecar file. Alternatively, you might be able to use the commands that "dimer_user" suggested, which I believe extracts the correct modecar from the OUTCAR file. Unfortunately, you can't trust the NEWMODECAR from older versions of VTST -- that is my fault.

[arosen]

Thanks for the reply. To prevent any unexpected errors, I think I'll just rerun the converged dimers using the updated VTST then. It shouldn't require many steps.