VASP (Vienna Ab initio Simulation Package)

VASP is a software package for performing ab-initio quantum-mechanical calculation of a periodic arrangement of atoms using the projector-augmented wave method and a plane wave basis set. The package can perform density-functional-theory (DFT) calculations, or many-body-perturbation-theory (MBPT) like GW etc. Please consult the documentation to get a more detailed overview of its feature set.

NOTE: we are currently in the process of simplifying the way in which VASP is accessed. In the future we will aim to provide a smaller core of standard installs, but offer support for users interested in specialized modules.

Online information from VASP developers targeted towards users

• Homepage

• Documentation

• User forum

• Tutorials

• Workshops

Supported Versions

We aim to provide fully installed versions for the last two releases of VASP that require separate licenses. At time of writing this covers VASP 6.4.x and VASP 6.5.x licenses. VASP 5.x will be supported on a case-by-case basis for users lacking a 6+ license, but we note that this has proven more and more challenging to install and test on the latest hardware. We aim to have the latest patch version for every minor release please open a ticket if you require a different patch version.

Version	Saga	Betzy	Olivia
5.4.4pl2	Yes	No	No
6.3.x	No	No	No
6.4.x	Yes	Yes	Yes
6.5.x	Yes	Yes	Yes
6.6.x	No	No	Yes

License and access policy

VASP is a commercial software package that requires a license for all who wants to use it. Note: We are currently in a transition period regarding how VASP access is managed on our systems, depending on the version you intend to use.

For VASP versions below 6.6.0

For a user to get access to VASP installed on the Sigma2 systems they must perform the following steps:

• The users group must have a valid VASP licence. To acquire a licence, please consult the Get a license section at the VASP website.

• User identification is performed using email, so please make sure you supply the correct email. Send us a message at contact@sigma2.no where you request access to VASP and supply your email address that is associated with your VASP license. Remember that this might not be the address you are currently using to communicate. In order to figure this out, log in to your VASP portal and double check the email address listed there. Or ask your license holder to verify what email address you should use. We will then, using our maintainer access to the VASP portal verify that you hold a valid license to VASP 6 and/or VASP 5. If you have access we will add you to the vasp6 and/or vasp5 group. Members of these groups have access to the VASP modules containing the necessary software.

Notice that the VASP license is backwards compatible, meaning that if you are issues a VASP 6 license you also have access to VASP 5.

For VASP versions 6.6.0 and newer

For version 6.6.0 and above, we are rolling out a new self-service authentication method. Instead of requiring group membership, you will generate a personal license key directly on the cluster. You only need to do this once.

Note: The VASP 6.6.x modules and the license generation script are only available on the compute nodes. You must request a brief interactive session to access them.

1. Start an interactive session: Request a quick compute node allocation. (Note: The exact salloc parameters below are tailored for Olivia. If you are on Saga or Betzy, you may need to adjust or omit the --partition and --mem flags based on that system’s SLURM configuration).

   salloc --account=<your account> --nodes=1 --ntasks-per-node=1 --partition=small --time=00:05:00 --mem=100MB
   

2. Load the required modules: Once your allocation is granted and you are on a compute node, load the base environment and the VASP module.

   module load NRIS/CPU
   module load VASP/6.6.0-intel-2024a-vanilla
   

3. Generate your key: Run the request script and follow the prompts to authenticate. Note: You will need the same username and password you use to log into the VASP portal.

   vasp_request_license_key.sh
   

4. Save your key: Move the newly generated file into a hidden directory in your home folder so it automatically applies to all future jobs.

   mkdir -p $HOME/.vasp
   mv vasp_license $HOME/.vasp/vasp_license
   

(Advanced users: You may also place the vasp_license file directly in your job’s working directory, or specify a custom path by exporting the VASP_LICENSE_FILE environment variable).

Alternative Method: Manual / Local Script Execution

If you prefer not to start an interactive session on the cluster you can manually run the underlying bash script.

1. Create a new file named request_vasp_license.sh and paste the following code into it. (Note: while at the moment we only have VASP6.6 on Olivia you may need to alter the @tag to the cluster you are targeting in the future).

   #!/bin/bash
   HPC_LICENSE="WA21-0049@olivia" #@cluster
   URL="[https://vasp.at/vasp-portal/api/license_key](https://vasp.at/vasp-portal/api/license_key)"
   JSON_FILE=response.json
   
   echo "Please login to your VASP portal account:"
   read -p "Username: " username
   for (( i = 0; i < 3; i++ )); do
       read -p "Password: " -s password
       if [[ ! -z "$password" ]]; then
           break
       fi
       echo "Password is empty, try again."
   done
   if [[ -z "$password" ]]; then
       echo "Password is empty, aborting."
       exit 1
   fi
   echo ""
   response_code=$(curl -s \
       -u "$username:$password" \
       -H "User-Agent: Bash (VASP Script)" \
       -d hpc_user_name=$(whoami) \
       -d hpc_user_id=$(id -u) \
       -d hpc_license="$HPC_LICENSE" \
       -o $JSON_FILE \
       -w "%{http_code}" \
       -X POST $URL)
   if [[ "$response_code" == "200" ]]; then
       jq -r '.license_key + "signature = \"" + .signature + "\""' $JSON_FILE > vasp_license
       error=0
   else
       echo "Status Code: $response_code"
       jq -r '"Error details: " + .detail' $JSON_FILE
       error=1
   fi
   rm $JSON_FILE
   exit $error
   

2. Make the script executable and run it:

   chmod +x request_vasp_license.sh
   ./request_vasp_license.sh
   

3. This will generate a vasp_license file in your current directory. Transfer or move this file into $HOME/.vasp/vasp_license on the cluster.

Parallelization

Good performance with VASP is extremely dependant on good parallelization settings. For most users this means tuning the NPAR and KPAR tags in the INCAR file. While we cannot share detailed benchamrking we find that good results are roughly in the line with those given by vasp: https://www.vasp.at/wiki/index.php/NPAR https://www.vasp.at/wiki/index.php/KPAR

For many users one can use a stable NPAR across many systems and nodes and get good results. KPAR tends to be much more system dependant and we strongly recommend some benchmarking depending on the number of nodes and ‘irreducible kpoints’.

Users can check the first few lines of the OUTCAR on a new run, e.g.,

executed on             <System>
running  XXX mpi-ranks, on    X nodes
each image running on  XXX cores
distrk:  each k-point on  XXX cores,    X groups
distr:  one band on NCORE=  XX cores,   XX groups

The user should confirm the outputs here match their expectations.

For quick benchmarking it is often useful to look at the speed of a single SCF step, e.g. by setting NELM=1. Often most information regarding benchmarking happens in the first step, e.g., if your settings are 2x faster for this first step it will likely remain so for the entire run. It can be helpful to look at both the final timing information at the end of the OUTCAR as well as the LOOP information for each SCF step (not to be confused with the LOOP+ information at the end of each ionic step)

Usage: Olivia

The CPU version of VASP is the most tested, an experimental version of GPU vasp is also available (see below). To run VASP with CPU a good starting point is:

#SBATCH --account=<your account>
#SBATCH --time=1:00:00 # adjust as needed 
#SBATCH --nodes=1 # adjust as needed
#SBATCH --mem-per-cpu=2955M
#SBATCH --ntasks-per-node=256
#SBATCH --network=single_node_vni

module reset
module load NRIS/CPU
module load VASP/6.5.1-intel-2024a # or VASP/6.4.3-intel-2024a
srun vasp_std # or vasp_ncl or vasp_gam

For those who have migrated from the service taken out of service; FRAM - please be mindful to adjust your parallelization settings. A good starting point is using --ntasks-per-node=256 with NPAR = 16 to be a good starting point for many cases. We found that for many systems using KPAR = <1/2 number nodes> to work well, but only if your system contains more than one k-point. Again the above is only a starting point.

Experimental GPU VASP

An experimental GPU compiled version of VASP can be run as follows: This image is built on top of the nvhpc:25.1-devel-cuda12.6-ubuntu24.04 image, see associated def file.

Currently only one node is supported.

This may be run using for VASP6-5 users. (VASP6.4 users should use nvhpc_25.1_cuda12.6_u24.04_vasp.6.4.3.sif instead) :

#SBATCH --account=<your account>
#SBATCH --time=1:00:00
#SBATCH --nodes=1
#SBATCH --mem=500G
#SBATCH --ntasks-per-node=250
#SBATCH --network=single_node_vni
#SBATCH --partition=accel
#SBATCH --gpus-per-node=4

module load NRIS/GPU
module load hpc-container-wrapper
export OMPI_MCA_btl=smcuda,vader,self
apptainer exec --nv /cluster/work/support/container/nvhpc_25.1_cuda12.6_u24.04_vasp.6.5.1.sif  mpirun -np 4 vasp_std

Note that we cannot use more than one rank per GPU because of the use of NCCL, see: https://www.vasp.at/wiki/OpenACC_GPU_port_of_VASP

Running the job will result in the following errors:

INFO:    gocryptfs not found, will not be able to use gocryptfs
[LOG_CAT_ML] You must specify a valid HCA device by setting:
-x HCOLL_MAIN_IB=<dev_name:port> or -x UCX_NET_DEVICES=<dev_name:port>.
If no device was specified for HCOLL (or the calling library), automatic device detection will be run.
In case of unfounded HCA device please contact your system administrator.
[gpu-1-57:904030] Error: ../../../../../ompi/mca/coll/hcoll/coll_hcoll_module.c:310 - mca_coll_hcoll_comm_query() Hcol library init failed

These may be ignored.

Since the GPU compiled VASP is new we very much appreciate any comments on its use. We find setting NPAR=1 or 2 and KPAR=1 or 2 is a good starting point for many calculations.

Advanced Usage: Building Custom VASP Modules

While we provide standard VASP installations, some users may require specialized modifications (e.g., specific patches, custom transition state tools, or unique library combinations). You can compile and maintain your own VASP modules securely in your home directory using the same infrastructure we use.

What is EasyBuild?

EasyBuild is the software build and installation framework we use to deploy the central software stack on Sigma2 clusters. It uses configuration files called “EasyConfigs” (.eb files) to automate the complex process of resolving dependencies, applying patches, compiling source code, and generating the final module files.

By leveraging EasyBuild for your custom installations, you ensure your software is compiled with the exact same highly optimized toolchains (compilers, MPI, math libraries) as the official system modules.

For a comprehensive guide on how this framework operates on our clusters, please read the official Sigma2 EasyBuild Documentation.

---

Custom VASP Module: Prepare your Source Files

Because VASP is commercially licensed, you must provide your own copy of the source code. You cannot use the central system tarballs. 1. Log into the VASP portal and download the source code for the version you want to build (e.g., vasp.6.5.1.tgz). 2. Download any add-on source files you need (e.g., VTST, VASPsol). 3. Transfer these .tgz files to a directory you own on the cluster (e.g., $HOME/vasp_sources/).

Custom VASP Module: Finding Existing Modules and EasyConfigs

The easiest way to write a custom EasyConfig is to copy and modify one of our official system files. There are two main ways to find them:

Method A: Find .eb files using EasyBuild’s search tool Once you load the EasyBuild module, you can search the central repository for all available VASP configuration files:

module load EasyBuild
eb --search VASP

This will output a list of paths. You can copy the .eb file that closest matches your desired version to your working directory.

Method B: Extract the .eb file from an installed module Every time a module is installed on our systems, a copy of the exact .eb file used to build it is saved inside its installation directory. If you know you want to modify a specific module (e.g., VASP/6.5.1-intel-2024a-vanilla), load it and look in its easybuild folder:

module load VASP/6.5.1-intel-2024a-vanilla
cp $EBROOTVASP/easybuild/*.eb my_custom_vasp.eb

Custom VASP Module: Creating a Custom EasyConfig (.eb file)

To add a feature like Wannier90 to a vanilla VASP build, you will modify the .eb configuration file you copied in the previous step.

(Note: While Wannier90 is included in many of our standard modules, this illustrates the general steps required to link external libraries. You will follow a similar pattern for VTST or BEEF. In general most add ons will follow a similar pattern)

Update the source paths to point to your personal downloads, and add the specific library dependencies and pre-build instructions.

Example Modifications:

# ... [Start with the copied VASP easyconfig] ...

# 1. IMPORTANT: Update the source path to point to YOUR downloaded tarball
local_vasp_tgz = '/cluster/home/<your_username>/vasp_sources/vasp.6.5.1.tgz'

sources = [local_vasp_tgz]
checksums = [
    'a53fd9dd2a66472a4aa30074dbda44634fc663ea2628377fc01d870e37136f61',  # Verify this matches your download
]

# 2. Add Wannier90 to dependencies (HDF5 is usually already there)
dependencies = [
    ('HDF5', '1.14.5'),
    ('Wannier90', '3.1.0'),
]

# 3. Add the compiler flags to prebuildopts
prebuildopts += "echo 'CPP_OPTIONS += -DVASP2WANNIER90' >> makefile.include && "
prebuildopts += "echo 'LLIBS      += -L$(EBROOTWANNIER90)/lib -lwannier' >> makefile.include && "

# ... [Continue with rest of the easyconfig] ...

Custom VASP Module: Configure the Environment and Build

To build your custom version, you must run EasyBuild from a compute node. We will use the system’s EasyBuild software to do the heavy lifting, but we will configure it to safely place the finished module in your personal directory so it doesn’t cause permission errors.

# 1. Start an interactive session
salloc --account=<your_project> --nodes=1 --time=02:00:00

# 2. Load the system's EasyBuild module
module load EasyBuild

# 3. Tell EasyBuild to install the finished software in your home directory
export EASYBUILD_PREFIX=$HOME/my-custom-modules

# 4. Run the build (--robot allows EasyBuild to automatically resolve dependencies like Intel compilers)
eb my_custom_vasp.eb --robot

Custom VASP Module: Using your Custom Module

Once the compilation finishes successfully, the module files will be located in your $HOME/my-custom-modules directory. The standard module load command won’t know they are there yet.

To make your custom module visible, you must add your new local repository to your module search path:

module use $HOME/my-custom-modules/modules/all
module load VASP/6.5.1-intel-2024a-custom # Adjust to match your exact module name

Tip: If you plan on using your custom module frequently, you can add the module use $HOME/my-custom-modules/modules/all line directly to your ~/.bashrc file so it is loaded automatically every time you log in.

Usage: Saga and Betzy

You can check which VASP versions are installed by executing:

$ module load VASPModules
$ module avail VASP

And load a particular module by executing (case sensitive):

$ module load VASP/6.4.1-intel-2021b-std-wannier90-libxc-hdf5-beef-<somehash>

where <somehash> is a hash that is computed based on the modifications done to the VASP source code, or extra libraries included. See below for more details. Most of the modules should be self explanatory for experienced VASP users and you might be able to just get the hash from inspecting the module names from module avail VASP. If not, please read below for addition description.

Please remember to use two module load commands. The first loads the location of all the VASP modules and the second command loads the actual VASP module. It is also possible, if you know what module you want to execute::

$ module load VASPModules VASP/6.4.1-intel-2021b-std-wannier90-libxc-hdf5-beef-<somehash>

Users have to supply the necessary input files, including any POTCAR files needed. They can be downloaded from the VASP portal you get access to with a valid VASP license. Also, please note that the POTCAR files are protected by the license so do not share them with anyone that does not have a license, including the support team, unless explicitly notified to do so.

The currently available modules (as of April 4th 2024) are as follows:

VASP/6.4.2-intel-2022b-wHDF5-nohash-wWannier recommended by default VASP/6.4.2-intel-2022b-wHDF5-wvtst-wsol if you need the vtst or sol packages VASP/5.4.4-intel-2022b if you need VASP5 VASP/5.4.4-intel-2022b-wvtst if you need VASP5 and the vtst package

Module naming scheme

There are now one module per VASP flavor (std - standard, gam - gamma only and ncl - non-collinear). Meaning when you now load a module, there is only one executable, vasp. For the example given above we load the module VASP/6.4.1-intel-2021b-std-wannier90-libxc-hdf5-beef-<somehash>. Here, <somehash> is a generated hash. i.e. d7238be44ec2ed23315a16cc1549a1e3 based on the versions of libraries and extensions. This is done to avoid a very long module names containing the version numbers if each library included etc. In the future we might chose to go with something more compact, e.g. VASP/6.4.1/<somehash>. For now, we believe it is convenient to directly see which VASP version and what libraries are there etc., but not necessarily the Wannier90, BEEF, libxc version etc. The mapping between the hash and exact version numbers can be found here:

VASP version	Hash	Wannier90 (tag)	VTST (svn)	BEEF (tag)	SOL (commit)	libxc (tag)	hdf5 (tag)	note
5.4.4 pl2	6dca52e0464347588557bc833ad7aef9	2.1.0	-	0.1.1	-	-	-	Saga
5.4.4 pl2	a695b2f1ed198f379d85666aef427164	2.1.0	-	0.1.1	0dc6b89b17e22b717cb270ecc4e1bbcfbb843603	-	-	Saga
5.4.4 pl2	14c961080ada8703431c19f060ae7c61	2.1.0	74	0.1.1	0dc6b89b17e22b717cb270ecc4e1bbcfbb843603	-	-	Saga
6.4.1	0a928426e459cf2aeab3d0bf8f441c74	3.1.0	-	0.1.1	-	5.2.2	1.14.1	Saga
6.4.1	17dde9df298cd4ade20f0051444fd46a	3.1.0	-	0.1.1	0dc6b89b17e22b717cb270ecc4e1bbcfbb843603	5.2.2	1.14.1	Saga
6.4.1	95b5f370a6e28c12e3ceb0addd48deb2	3.1.0	127	0.1.1	-	5.2.2	1.14.1	Saga
6.4.1	14b83fae861f986c955e51fe132d765d	3.1.0	127	0.1.1	0dc6b89b17e22b717cb270ecc4e1bbcfbb843603	5.2.2	1.14.1	Saga
6.4.1	7ec7231149f216987659e140f81251f9	3.1.0	-	0.1.1	-	-	-	Betzy
6.4.1	1328e4b3fe680ad53aed047704ea8b90	3.1.0	-	0.1.1	0dc6b89b17e22b717cb270ecc4e1bbcfbb843603	-	-	Betzy
6.4.1	c6ed3d20b98b13020d9bd2d8bce019c7	3.1.0	127	0.1.1	-	-	-	Betzy
6.4.1	2aed04d9a614793f1f8902b72d65bfb5	3.1.0	127	0.1.1	0dc6b89b17e22b717cb270ecc4e1bbcfbb843603	-	-	Betzy

Notice that the VASP version is not included when generating the hash, only the libraries and associated mods from the additions in the table above. Meaning, if we add a module with a new VASP version and do not need or do an update on any of the libraries, the hash should be the same.

Please note that existing modules with names not containing a hash in the end is now considered legacy. You might use them to reproduce old results and we will keep them around until the system is end of life. Also try to migrate your workload to the most recent version.

We would like feedback from the community how we can improve the module naming scheme going forward. Please keep in mind that whatever we chose have to support reproducability, which means that we should be able to say, give me VASP version x.y.z, with BEEF version x1.y1.z1 and Wannier90 with x2,y2,z2 etc.

The naming schemes of the modules are VASP/version-toolchain-vasp_flavor-extra_libraries_and_functionality-adaptions_source_code. Where:

• version determines the VASP version, e.g. 6.4.1.

• toolchain determines the toolchain used, typically which compilers, LAPACK, BLAS etc. routines have been used. This is based on the existing toolchains on the system. These can be inspected with module show intel/2021b for the particular system (e.g. saga). Typically, the toolchain is the vendor, e.g. intel followed by the version, e.g. 2021b. Notice that on Betzy, the name is GCC, even though we have used AOCC/AOCL to compile and link the VASP modules.

• vasp_flavor determines the VASP flavor, e.g. std for the standard flavor, gam for the gamma only (only works for one k-point) and ncl for the non-collinear flavor (makes it possible to let the spin go in any direction).

• extra_libraries_and_functionality determines if an additional package has been included, e.g. wannier90 (support for maximally-localised Wannier functions and the Wannier90), beef (to yield support for the BEEF functional and Bayesian error estimates), vtst (to yield support for additional transition state tools VTST), sol (to yield support for solvation models using VASPsol) and libxc (to yield support for the exchange and correlation library using libxc).

• adaptions_source_code determines if there has been adaptions to the source code, e.g. restrictions in the ionic motions. This can be the nor_<direction> which does not enable relaxation along the first, second and third lattice vector (with <direction> set as x, y and z, respectively). Or, onlyr_<direction>, with similar <directions>. Finally, nor_angles will not allow any relaxation of angles.

Further notes about the additional packages and how the modules have been constructed

The VTST scripts are available if you load a module with vtst and can be found in $EBROOTVASP/vtst after loading the VASP module containing vtst in its name.

The bee executable from the BEEF library can be found in $EBROOTBEEF/bin/bee after loading the VASP module containing beef in its name.

The wannier90.x and postw90.x executables of Wannier90 can be found in $EBROOTWANNIER90/bin/wannier90.x and $EBROOTWANNIER90/bin/postw90.x after loading the VASP module with wannier90 in its name.

Parallel functionality and library support.

All VASP and Wannier90 binaries are compiled with Intel MPI (Saga) or OpenMPI (Betzy) support. No OpenMP is presently enabled, but we are working to extend the modules to also include that for VASP 6. This also includes GPU support for the methods in VASP that support this. Hybrid OpenMP+MPI support is still not widely tested and it is rather complicated to reach an optimum with respect to tuning the distribution of load and very often the job ends up being slower than for only the MPI enabled VASP version.

Memory allocation for VASP

VASP is known to be potentially memory demanding. Quite often, you might experience to use less than the full number of cores on the node, but still all of the memory.

For relevant core-count, node-count, and amounts of memory, see the pages about Saga. There are two ways of increasing the memory pr. cpu over the standard node configuration:

• Increase the Slurm setting mem-per-cpu

• Utilize the nodes with more memory per cpu.

Remember you are accounted for the CPUs that would be reserved due to your demand for increased memory.

Special note about Betzy and AMD systems

Notice that on Betzy, libxc and hdf5 is not enabled due to issues with the AOCC/AOCL compilation setup. If you need this functionality, use Saga for now. Also, on Saga VASP has been compiled with an Intel toolchain, but on Betzy, we have used AOCC and AOCL, which gives the a similar setup for AMD. Due to the fact that there is no Easybuild setup for AOCL at the time of writing, the VASP modules on Betzy seem to be using the GCC toolchain in their name. This is entirely due to the fact that we used the GCC toolchain as a skeleton to build the necessary components to assemble what is in essence an AOCL toolchain. When an AOCL Easybuild setup is officially supported, we will remedy this by recompiling. This should then give a more correct name for the module.

Citation

When publishing results obtained with the software referred to, please do check your license agreement and the developers web page in order to find the correct citation(s). Also, remember to acknowledge Sigma2 for the computational resources.

Getting additional help

We have an application liaison at our disposal for VASP which can help users with particular VASP issues and/or possibly also domain specific problems. In order to get in contact with the application liaison, please submit a support request as documented here. If the ticket does not fall within regular support it will be forwarded.

However, before asking for help, please make sure you have gone through the tutorials and workshop material above that is relevant to you. Also, if your group would be interested in a dedicated VASP workshop, please reach out to support@nris.no with a request and we will try to gauge general interest and arrange it, possibly in collaboration with the VASP developers if need be.