UT theoretical chemistry code forum

Well, there are couple of problems that see by quickly scanning over your INCAR file. The dimer uses a finite difference scheme where the local curvature is estimated by the force difference in two points, that very close to each other. It is paramount then to calculate the force as accurately as po...

Where did you send it to, I never receive it? Plus there isn't much that I can do with the INCAR file alone.

I like the setup we have now for handling WAVECAR files. If people like to use them in a subsequent run then then there is nothing simpler than coping them back from the saved directory and un-zipping them. I prefer the simplicity over adding a tag or something to decide the a copy of the WAVECAR sh...

I usually like to converge the forces to values lower than 0.03 but that's of course just my own preference and not an empirical truth. When I start a new NEB calculation I often start with setting EDDIFG = -0.01. If that converges I decrease it to -0.005 and continue. I then continue in this fashio...

It is a bit hard to know why the dimer is converging slowly without all the input parameters. Maybe you could send us your run so we can take a look at it to see if there is something obviously wrong. Also make sure to use exactly the same setup as described for the DACAPO calculations, including us...

I don't really see any problem with the POSCAR file but we recommend setting the element symbols in the top line for our scripts to work properly, like: Ru N H 10.7876184200000 1.0000000000000000 0.0000000000000000 0.0000000000000000 0.0000000000000000 0.8660436140083640 0.0000000000000000 0.0000000...

First off, are you using our implementation of NEB (available at http://theory.cm.utexas.edu/vtsttools/) and what are the other calculations that you are comparing with? Are your calculations converged w.r.t. number of k-points, system size, spin, etc. What about pseudo-potentials and planewave ener...

Our NEB implementation should be airtight in regards to that aspect. I have never had any problems with it, but I guess anything is possible. But I usually try to set up the calculations in such a way that any boundary crossing is unlikely. So if you witness any funny business with our implementatio...

Converging the force to zero is more appropriate I think. So I commonly use:

EDDIF = 1.0E-4
EDDIFG = -1.0E-3

The vtstscripts packages contains many scripts that rely on output generated by our additions to VASP in vtstcode. But the nebmake.pl should work fine for you (as you have tried) even though you don't have the files in vtstcode compiled with VASP. Most of the scripts though you will have to use at y...

To set up a NEB calculation, using our toolbox, you begin with your initial and final images (say POSCAR_1 and POSCAR_2). Then you use the nebmake.pl script available as a part of vtstsscripts (http://theory.cm.utexas.edu/vtsttools/downloads/). See http://theory.cm.utexas.edu/vtsttools/scripts/ for ...

The CI-NEB will converge one image to the overall maximum of the MEP. If you need to isolate the other maxima better then you can either run a separate CI-NEB around a given maximum or launch a min-mode (dimer or lanczos) search from one of the images in the original CI-NEB.

I'm not sure what you mean.

The configuration is always in the POSCAR. The MODECAR contains the unstable mode, or the current guess for it. It will be generated at the end of each Lanczos step and if one is in place when a run is initiated then it will be read and the mode used as an initial guess for the Lanczos procedure ins...

Yes, a saddle point run using the Lanczos method uses the same input file as usual, i.e. POTCAR, KPOINTS, POSCAR and INCAR. A MODECAR is not strictly necessary for it to work. Note that there are no 01, 02 etc. subdirectories as for NEB or dimer runs. This is more like a regular structural minimizat...