UT theoretical chemistry code forum

Hi,
I downloaded the vtstcode from the CVS server but I have trouble to compile the sources with the pgf 5.2 compiler:

/opt/mpich2/bin/mpif90 -Mfree -tp k8-64 -i4 -O3 -fast -fastsse -c bfgs.f90

PGF90-S-0083-Vector expression used where scalar expression required (bfgs.f90: 92)
PGF90-W-0189-Argument number 2 to dirkar: association of scalar actual argument to array dummy argument (bfgs.f90: 95)
PGF90-S-0083-Vector expression used where scalar expression required (bfgs.f90: 121)
PGF90-S-0083-Vector expression used where scalar expression required (bfgs.f90: 141)
PGF90-W-0189-Argument number 2 to kardir: association of scalar actual argument to array dummy argument (bfgs.f90: 145)
PGF90-S-0038-Symbol, r, has not been explicitly declared (bfgs.f90)
PGF90-S-0038-Symbol, f, has not been explicitly declared (bfgs.f90)
0 inform, 2 warnings, 5 severes, 0 fatal for bfgs_step
PGF90-S-0074-Illegal number or type of arguments to sum - keyword argument array (bfgs.f90: 157)
PGF90-S-0038-Symbol, change_in_r, has not been explicitly declared (bfgs.f90)
PGF90-S-0038-Symbol, change_in_f, has not been explicitly declared (bfgs.f90)
PGF90-S-0038-Symbol, w, has not been explicitly declared (bfgs.f90)
PGF90-S-0038-Symbol, outter_product, has not been explicitly declared (bfgs.f90)
PGF90-S-0038-Symbol, matrixmultiply, has not been explicitly declared (bfgs.f90)
PGF90-S-0038-Symbol, aa, has not been explicitly declared (bfgs.f90)
PGF90-S-0038-Symbol, outerproduct, has not been explicitly declared (bfgs.f90)
PGF90-S-0038-Symbol, vdot, has not been explicitly declared (bfgs.f90)
PGF90-S-0038-Symbol, u, has not been explicitly declared (bfgs.f90)
PGF90-S-0038-Symbol, uu, has not been explicitly declared (bfgs.f90)
0 inform, 0 warnings, 11 severes, 0 fatal for invh_update

I understand that the CVS versions are for development but still could you tell me how to compile them and in which order (which seems to matter).

Secondly, how are your optimizers different from the VASP code? Do they achieve better performance?

And last but not least, does the number of images in a NEB run affect the stability of the convergence to the MEP? I use 5 images due to a lack of MPI nodes at the moment and the convergence is quite poor (vtstcode from the website).

Thank you very much. I appreciate your help.

You have caught us in the middle of some major developments. As you found out, the code in cvs does not work yet.

We are adding some new features to the NEB code, and some new optimizers which will work with the NEB/Dimer/Lanczos saddle point finding methods, and with regular vasp runs.

Besides the basic steepest-descent and quick-min (damped dynamics), we have a different version of conjugate gradients and lbfgs which seem (in our limited testing) to converge faster than those implemented in vasp. Also, these methods have no explicit dependence upon the energy, so they can be used with our saddle point finding methods. Tests on empirical potentials indicate that these second order methods are roughly 2-3 times faster than quick-min, both for the NEB and regular minimizations. The main reason we are making these changes is to have a faster and stable optimizer for the NEB in VASP.

To some extent, the NEB convergence criteria is dependent upon the number of images. If you are using the climbing-image, there needs to be enough images to define the reaction coordinate near the saddle. Too few images will cause the climbing-image to oscillate without converging. The number depends upon the complexity (curvature) of the path. For simple paths, you can sometimes get away with just the 1 climbing image. For a long, curved path, such as those typical of molecules dissociating on a surface, you might require on the order of 8 images.

We have also found that the second order optimizers can require more images to converge smoothly. For example, in one test case, quick-min was found to converge a 3 image band, whereas conjugate gradients and lbfgs need 4-5. Once stable, however, extra images do not help.

As an empirical rule of thumb I have found it to be sufficient resolution of the MEP (in most cases) to have about 0.5 Ang's between the images, and preferably no more than 1.0 Ang.