VTST 2.x code updates
Moderator: moderators
VTST 2.x code updates
The vtstcode.tar.gz has been updated to version 2.0. This new code has many significant changes including:
- Force based optimizers that work with the NEB/dimer/Lanczos methods. These optimizers include conjugate gradients, quick-min, lbfgs, and fire. The optimizer is selected with the IOPT variable. If one of these optimizers is selected, the INCAR variables IBRION should be set to 3 and POTIM to 0. This tells vasp to do damped dynamics with a zero time step. In this way, the built-in vasp optimizers will not move the ions. The new optimizers are designed to improve the efficiency of the transition state finding methods, but they can also be used with normal vasp minimization runs.
- The dimer method has been modified to work with a single image instead of two. This has reduced the total number of force evaluations required to find a saddle. The setup for a dimer and lanczos run are now the same. Both use a MODECAR file to store the direction along the lowest curvature mode.
- The NEB code has been simplified. We no longer support variable spring constants along the band -- this is not a popular option given that the climbing image does the job of finding the saddle point. The double-nudging force-projections have been implemented, although we have not found this to improve convergence of the NEB.
Known issues:
- The force-only conjugate gradient and lbfgs algorithms use a finite-difference / Newton's method line minimization step. In the finite-difference step, the forces can increase. Close to a minimum, every other step will have this artificial rise in the force -- it does not mean that the method is not converging. In the future, we will find a way to hide or systematically reduce the finite difference step so that convergence does not appear rough.
- These methods have only been tested in our group, and there are bound to be a few bugs. If you find any, or have problems with the methods, please let us know and we’ll fix them.
- Force based optimizers that work with the NEB/dimer/Lanczos methods. These optimizers include conjugate gradients, quick-min, lbfgs, and fire. The optimizer is selected with the IOPT variable. If one of these optimizers is selected, the INCAR variables IBRION should be set to 3 and POTIM to 0. This tells vasp to do damped dynamics with a zero time step. In this way, the built-in vasp optimizers will not move the ions. The new optimizers are designed to improve the efficiency of the transition state finding methods, but they can also be used with normal vasp minimization runs.
- The dimer method has been modified to work with a single image instead of two. This has reduced the total number of force evaluations required to find a saddle. The setup for a dimer and lanczos run are now the same. Both use a MODECAR file to store the direction along the lowest curvature mode.
- The NEB code has been simplified. We no longer support variable spring constants along the band -- this is not a popular option given that the climbing image does the job of finding the saddle point. The double-nudging force-projections have been implemented, although we have not found this to improve convergence of the NEB.
Known issues:
- The force-only conjugate gradient and lbfgs algorithms use a finite-difference / Newton's method line minimization step. In the finite-difference step, the forces can increase. Close to a minimum, every other step will have this artificial rise in the force -- it does not mean that the method is not converging. In the future, we will find a way to hide or systematically reduce the finite difference step so that convergence does not appear rough.
- These methods have only been tested in our group, and there are bound to be a few bugs. If you find any, or have problems with the methods, please let us know and we’ll fix them.
problem compiling using new VTSTcode, chain.f90
Hello,
I downloaded your new release yesterday and tried to compile vasp on our cluster and got the follwoing error.
./preprocess <chain.F | /usr/bin/cpp -P -C -traditional >chain.f90 -DMPI -DHOST=\"LinuxIFC\" -DIFC -Dkind8 -DNGZhalf -DCACHE_SIZE=8000 -DPGF90 -Davoidalloc -DMPI_BLOCK=500 -DPROC_GROUP=8 -DRPROMU_DGEMV -DRACCMU_DGEMV
mpif90 -FR -lowercase -O3 -xW -tpp7 -c chain.f90
module CHAIN
Error FCE37 : Module OPT not found
module subroutine CHAIN_FORCE
module subroutine CHAIN_INIT
CHARACTER*1 :: CHARAC
^
Comment 15 at (261:chain.f90) : This feature is obsolescent in Fortran 95
module function LHYPER_NUDGE
module subroutine SUM_CHAIN
module subroutine AND_CHAIN
1 Error
compilation aborted for chain.f90 (code 1)
make: *** [chain.o] Error 1
Is the code you have now on the web debugged already? I am using mpich2 and IFC, mpif90 for compiling.
Thanks in advance
I downloaded your new release yesterday and tried to compile vasp on our cluster and got the follwoing error.
./preprocess <chain.F | /usr/bin/cpp -P -C -traditional >chain.f90 -DMPI -DHOST=\"LinuxIFC\" -DIFC -Dkind8 -DNGZhalf -DCACHE_SIZE=8000 -DPGF90 -Davoidalloc -DMPI_BLOCK=500 -DPROC_GROUP=8 -DRPROMU_DGEMV -DRACCMU_DGEMV
mpif90 -FR -lowercase -O3 -xW -tpp7 -c chain.f90
module CHAIN
Error FCE37 : Module OPT not found
module subroutine CHAIN_FORCE
module subroutine CHAIN_INIT
CHARACTER*1 :: CHARAC
^
Comment 15 at (261:chain.f90) : This feature is obsolescent in Fortran 95
module function LHYPER_NUDGE
module subroutine SUM_CHAIN
module subroutine AND_CHAIN
1 Error
compilation aborted for chain.f90 (code 1)
make: *** [chain.o] Error 1
Is the code you have now on the web debugged already? I am using mpich2 and IFC, mpif90 for compiling.
Thanks in advance
Can you make sure that the new objects:
dimer.o dynmat.o neb.o lanczos.o sd.o cg.o qm.o lbfgs.o bfgs.o fire.o opt.o
are all listed before chain.o in the makefile. My guess is that they are after, so that chain.o is being built before opt.o, and it is complaining about not finding the opt module.
These instructions are also at:
http://theory.cm.utexas.edu/vtsttools/downloads/
dimer.o dynmat.o neb.o lanczos.o sd.o cg.o qm.o lbfgs.o bfgs.o fire.o opt.o
are all listed before chain.o in the makefile. My guess is that they are after, so that chain.o is being built before opt.o, and it is complaining about not finding the opt module.
These instructions are also at:
http://theory.cm.utexas.edu/vtsttools/downloads/
Re: VTST 2.0 code update
V2.03d (02/18/09)
- module for calculating instantons included (note that the extra object instanton.o is needed in the vasp Makefile)
- fixed in a vector projection in the doubly nudged elastic band (thanks to Craig Plaisance)
- allow lbfgs for regular (non NEB) optimizations
Changes to the following vtstscripts, many of which are related to a change in file formats in vasp5
- Vasp.pm, akmc*, chg2cube, chgsplit, diffcon, kdb*, quad, vasp2con, vclean, xdat2pos, xdat2xyz
- module for calculating instantons included (note that the extra object instanton.o is needed in the vasp Makefile)
- fixed in a vector projection in the doubly nudged elastic band (thanks to Craig Plaisance)
- allow lbfgs for regular (non NEB) optimizations
Changes to the following vtstscripts, many of which are related to a change in file formats in vasp5
- Vasp.pm, akmc*, chg2cube, chgsplit, diffcon, kdb*, quad, vasp2con, vclean, xdat2pos, xdat2xyz
Re: VTST 2.0 code update
Hi,
I remember, in version 2.03b, the lbfgs method can already be used for the rugular (e.g., geometry optimization) calculations. Then, what's new in the lbfgs method?
I also remember in this page (http://theory.cm.utexas.edu/vtsttools/optimizers/), it was said all the optimizer methods can be used for the regular calculations. However, I can not find this sentence any more. Does this mean that something is changed?
Thank you for your kind attention.
Yi-An
I remember, in version 2.03b, the lbfgs method can already be used for the rugular (e.g., geometry optimization) calculations. Then, what's new in the lbfgs method?
I also remember in this page (http://theory.cm.utexas.edu/vtsttools/optimizers/), it was said all the optimizer methods can be used for the regular calculations. However, I can not find this sentence any more. Does this mean that something is changed?
Thank you for your kind attention.
Yi-An
Re: VTST 2.0 code update
The bug fixed in 2.03b for "regular" runs had to do with optimization methods that used a finite different step. The neb was checked for convergence before moving the ions. This was not the case when doing a regular geometry optimization of a single configuration.
All of the IOPT optimizers can be used for regular, NEB, or dimer runs. The lbfgs method, being our most efficient, was explicitly tested for this.
All of the IOPT optimizers can be used for regular, NEB, or dimer runs. The lbfgs method, being our most efficient, was explicitly tested for this.
Re: VTST 2.0 code update
What settings need to be used for just a geometry relaxation? Do i need to have a separate compilation of vasp with the new optimizers or do i just need to set ICHAIN equal to something?
thanks
thanks
Re: VTST 2.0 code update
I downloaded the latest version of the codes and I found that there are some bugs in the latest version (July 11, 2011). For example,
neb.f90(133): error #6404: This name does not have a type, and must have an explicit type. [DIR2CAR]
dir2car=latt_a
------^
neb.f90(133): error #6366: The shapes of the array expressions do not conform. [DIR2CAR]
dir2car=latt_a
------^
neb.f90(134): error #6404: This name does not have a type, and must have an explicit type. [CAR2DIR]
car2dir=latt_b
------^
neb.f90(134): error #6366: The shapes of the array expressions do not conform. [CAR2DIR]
car2dir=latt_b
------^
and,
opt.f90(75): error #5082: Syntax error, found IDENTIFIER 'LATT_A' when expecting one of: * , <END-OF-STATEMENT> ; [ / = =>
REAL(q) :: hstress(3,3)latt_a(3,3),latt_b(3,3)
-----------------------------^
compilation aborted for opt.f90 (code 1)
make: *** [opt.o] Error 1
and,
opt.f90(75): error #5082: Syntax error, found IDENTIFIER 'LATT_A' when expecting one of: * , <END-OF-STATEMENT> ; [ / = =>
REAL(q) :: hstress(3,3)latt_a(3,3),latt_b(3,3)
-----------------------------^
compilation aborted for opt.f90 (code 1)
make: *** [opt.o] Error 1
This version cannot be compiled successfully!
Chen
neb.f90(133): error #6404: This name does not have a type, and must have an explicit type. [DIR2CAR]
dir2car=latt_a
------^
neb.f90(133): error #6366: The shapes of the array expressions do not conform. [DIR2CAR]
dir2car=latt_a
------^
neb.f90(134): error #6404: This name does not have a type, and must have an explicit type. [CAR2DIR]
car2dir=latt_b
------^
neb.f90(134): error #6366: The shapes of the array expressions do not conform. [CAR2DIR]
car2dir=latt_b
------^
and,
opt.f90(75): error #5082: Syntax error, found IDENTIFIER 'LATT_A' when expecting one of: * , <END-OF-STATEMENT> ; [ / = =>
REAL(q) :: hstress(3,3)latt_a(3,3),latt_b(3,3)
-----------------------------^
compilation aborted for opt.f90 (code 1)
make: *** [opt.o] Error 1
and,
opt.f90(75): error #5082: Syntax error, found IDENTIFIER 'LATT_A' when expecting one of: * , <END-OF-STATEMENT> ; [ / = =>
REAL(q) :: hstress(3,3)latt_a(3,3),latt_b(3,3)
-----------------------------^
compilation aborted for opt.f90 (code 1)
make: *** [opt.o] Error 1
This version cannot be compiled successfully!
Chen