Jump to: navigation, search
VAMP/VASP is a package for performing ab-initio quantum-mechanical molecular dynamics (MD) using pseudopotentials and a plane wave basis set. The approach implemented in VAMP/VASP is based on a finite-temperature local-density approximation (with the free energy as variational quantity) and an exact evaluation of the instantaneous electronic ground state at each MD-step using efficient matrix diagonalization schemes and an efficient Pulay mixing. These techniques avoid all problems occurring in the original Car-Parrinello method which is based on the simultaneous integration of electronic and ionic equations of motion. The interaction between ions and electrons is described using ultrasoft Vanderbilt pseudopotentials (US-PP) or the projector augmented wave method (PAW). Both techniques allow a considerable reduction of the necessary number of plane-waves per atom for transition metals and first row elements. Forces and stress can be easily calculated with VAMP/VASP and used to relax atoms into their instantaneous ground state.
5.4.4 (18Apr17)
5.4.1 (05Feb16) with patches 14032016 and 03082016
5.3.2 (13Sep12)
5.2.12 (11Nov11)
5.2.11 (23Dec10)
5.2.2 (15Apr09)
4.6.36 (17Feb09)
VASP homepage
Those users who have access to VASP (see Access below) can also access the full set of pseudo-potentials distributed with VASP via the VASP_POT environment variable set by a modulefile.
All data-sets for VASP5 were updated/downloaded from the VASP website on 2016-08-09. When additional information is provided in the accompanying readme files, it is present below; otherwise, the snapshot date is according to the VASP portal.
  • $VASP_POT/pot_LDA/: US LDA (snapshot 2014-04-18)
  • $VASP_POT/potpaw_LDA/: PAW LDA (snapshot 2010-05-05)
  • $VASP_POT/potpaw_LDA_52/: "new" PAW LDA (readme file 2012-05-04)
  • $VASP_POT/potpaw_LDA_54/: "new" PAW LDA (readme file 2015-09-04)
  • $VASP_POT/potpaw_PBE/: PAW GGA (PBE) (snapshot 2010-05-06)
  • $VASP_POT/potpaw_PBE_52/: "new" PAW GGA (PBE) (readme file 2012-05-04)
  • $VASP_POT/potpaw_PBE_54/: "new" PAW GGA (PBE) (readme file 2015-09-04)
  • $VASP_POT/pot_GGA/: USPP GGA (PW91) (snapshot 2014-04-18)
  • $VASP_POT/potpaw_GGA/: PAW GGA (PW91) (readme file 2003-09-16)
vdW-DF kernel
The pre-calculated kernel for the vdW-DF functional distributed with VASP5 is located here $VASP_POT/vdw_kernel.bindat.
  • vasp - default complex version built with -DNGZhalf
  • vasp.gamma - gamma-point version built with -DNGZhalf -DwNGZhalf
  • vasp.noncollinear - special version built without the -DNG* options to enable spin-orbit coupling calculations
  • vasp.tbdyn - special version built with -Dtbdyn (VASP 5.3.2 only)
While VASP is not available to the general ACENET community we have an agreement with VASP to allow it to be run on our systems and for us to have a standardized copy available to those with their own licenses. If you have your own VASP license please contact support via email. We will contact VASP to verify your status. You will then be added to the vasp4 and/or vasp5 software group depending on what version(s) you are licensed for.
Different version of VASP are compiled with different compilers and require specific modulefiles to be loaded before run. Users are encouraged to try to load a VASP modulefile interactively before submitting jobs in order to determine which other modulefiles it depends upon. For example
 $ module load vasp/5.2.11
 WARNING: vasp/5.2.11 cannot be loaded due to missing prereq.
 HINT: the following modules must be loaded first: openmpi/intel
Oftentimes, it's easier to clear the shell environment first with the purge command and then load required modules. Below is an example of such a submission script for VASP 5.3.2:
#$ -cwd
#$ -l h_rt=01:00:00
#$ -pe ompi* 4

module purge
module load intel openmpi/intel vasp/5.3.2

mpirun vasp
And here is an example for VASP 5.4.4
#$ -cwd
#$ -l h_rt=01:00:00
#$ -pe ompi* 4

module purge
module load intel/16 openmpi/intel/1.8.8 vasp/5.4.4

mpirun vasp
Users may find that VASP built with Intel compilers (version 5.2.1x and newer) crash and dump core files for certain types of calculations (particularly involving tweaking the parameter ENCUTGW in INCAR). The problem can be fixed by specifying an additional parameter in the submission script (shown below) which increases the memory stack size of the application to 500MB per process or more. The user may find they have to adjust h_stack to still higher values for larger systems.
#$ -l h_stack=500M
On the other hand, if your VASP job runs successfully without h_stack, explicitly specifying it might result in a crash (see Memory Management).