The Vienna Ab initio Simulation Package (VASP) is a computer program for atomic scale materials modelling, e.g. electronic structure calculations and quantum-mechanical molecular dynamics, from first principles.
VASP computes an approximate solution to the many-body Schrödinger equation, either within density functional theory (DFT), solving the Kohn-Sham equations, or within the Hartree-Fock (HF) approximation, solving the Roothaan equations. Hybrid functionals that mix the Hartree-Fock approach with density functional theory are implemented as well. Furthermore, Green's functions methods (GW quasiparticles, and ACFDT-RPA) and many-body perturbation theory (2nd-order Møller-Plesset) are available in VASP.
In VASP, central quantities, like the one-electron orbitals, the electronic charge density, and the local potential are expressed in plane wave basis sets. The interactions between the electrons and ions are described using norm-conserving or ultrasoft pseudopotentials, or the projector-augmented-wave method. To determine the electronic groundstate, VASP makes use of efficient iterative matrix diagonalisation techniques, like the residual minimisation method with direct inversion of the iterative subspace (RMM-DIIS) or blocked Davidson algorithms. These are coupled to highly efficient Broyden and Pulay density mixing schemes to speed up the self-consistency cycle.
Licensing Terms and Conditions
vasp6
. Please refer to the VASP web site for more information.Alps (GH200)
How to run
A precompiled user environment containing VASP with MPI, OpenMP, OpenACC and Wannier90 support is available. Due to license restrictions, the VASP images are not directly accessible in the same way as other applications. To access VASP uenv images, please follow the following guide: Accessing Restricted Software
To load the VASP user environment:
uenv start vasp/v6.5.0:v1 --view=vasp
The vasp_std
, vasp_ncl
and vasp_gam
executables are now available for use.
Any SLURM script for more than one task must include export MPICH_GPU_SUPPORT_ENABLED=1
, since VASP relies on GPU aware MPI and the job will fail otherwise.
It's recommended to use the SLURM option --gpus-per-task=1
, since VASP may fail to properly assign ranks to GPUs when running on more than one node. This is not required when using the CUDA MPS wrapper for oversubscription of GPUs.
VASP uses GPU aware MPI features and optionally Nvidia NCCL for communication. NCCL provides improved communication, but it is disabled when using more than one task per GPU.
In some cases, using multiple tasks per GPU can be beneficial on the GH200 architecture, as it increases GPU utilization. This requires the use of CUDA MPS, which currently has to be launched manually before the application.
The CUDA MPS wrapper can be found at: Oversubscription of GPU cards
Bulding VASP from Source
To build VASP from source, the develop
view must first be loaded:
uenv start vasp/v6.5.0:v1 --view=develop
All required dependencies can now be found in /user-environment/env/develop
. Note that libraries might not be found when executing vasp, if the makefile does not include additional rpath linking options or LD_LIBRARY_PATH
has not been extended.
The following makefile.include
examples for GH200 with the develop
view loaded take care of setting all required paths and architecture flags:
- v6.4.3: makefile.include.v6.4.3.gh200
- v6.5.0: makefile.include.v6.5.0.gh200
The detection of MPI CUDA support does not work properly with Cray MPICH. The provided precompiled binaries of VASP are patched and only require export MPICH_GPU_SUPPORT_ENABLED=1
to be set. When compiling from source, it's also required to set export PMPI_GPU_AWARE=1
to disable the CUDA support check within VASP. Alternatively, since version 6.5.0, the build option -DCRAY_MPICH
can be added to disable the check at compile time.
Scaling
On GH200, VASP typically doesn't scale well to large number of nodes. However, scaling behavior varies greatly between types of jobs.
The following shows scaling of three different cases, where the runtime of a single task is used as reference.
Using more than one task per GPU can provide a benefit on one or two GPUs, but there are (currently) performance issues on higher number of GPUs, and in some cases VASP can hang during the execution. Therefore, in most cases it is recommended to limit a job to one task per GPU when using a full node with four GPUs or more.