VASP

The Vienna Ab initio Simulation Package (VASP) is an electronic-structure code for first-principles materials simulations, most commonly using density functional theory (DFT). LSU HPC and LONI HPC provide centrally installed CPU and NVIDIA GPU builds for users covered by the applicable institutional VASP license.

Recommended for most new calculations: vasp6/6.6.1-cpu

License-verification change: LSU HPC and LONI HPC are replacing the previous process—in which HPC staff manually verified a user's VASP license eligibility and added approved users to a local license group—with automatic personal license validation. VASP 6.6.1 already uses automatic validation; VASP 6.5.1 will switch to it on October 1, 2026. See Personal license setup.

VASP 6.6.1 license requirement: A license that covers only VASP 6.5.1 does not grant access to the VASP 6.6.1 modules. Requesting a personal key does not upgrade the license. Before using VASP 6.6.1, the license holder must renew or upgrade the group's VASP license to include 6.6.1, and the user must be registered under that updated license in the VASP Portal.

The same VASP module names are available on LSU HPC and LONI HPC.

Personal license setup

Under the automatic process, each user requests a personal key and VASP validates the user's eligibility when an executable starts. The username entered during the request must exactly match the username registered for the user's VASP Portal account, and that account must be eligible to use the requested VASP version.

License-validation schedule

The VASP 6.5.1 module names and normal Slurm workflow will not change on October 1. The additional requirement is the presence of a valid personal license-key file when VASP starts.

Request a personal key

The license key is site-specific. Run the request separately in each HPC environment where VASP will be used:

• LSU HPC: log in to either SuperMike3 or SuperMIC and run the commands below.
• LONI HPC: log in to either QB3 or QB4 and run the commands below.

If you have accounts on both LSU HPC and LONI HPC, run the complete procedure twice: once on an LSU HPC cluster and once on a LONI HPC cluster.

module load vasp6/6.5.1-cpu
mkdir -p ~/.vasp
cd ~/.vasp

Run the request script and enter your VASP Portal username when prompted:

$ request_license_key.sh
Please login to your VASP portal account:
Username:

A successful request creates:

~/.vasp/vasp_license

LSU HPC and LONI HPC use separate site licenses and filesystems. A key requested in one environment does not replace the key required in the other environment.

Do not share a personal VASP license key or use a key generated for another user.

If ~/.vasp/vasp_license already exists and VASP 6.6.1 starts successfully, no additional action is normally required for the October 1 transition.

Check whether a key file exists

if [[ -s ~/.vasp/vasp_license ]]; then
    echo "VASP license key found"
else
    echo "VASP license key is missing"
fi

This only confirms that the file exists and is not empty. VASP validates the key when the executable starts.

Revoke a personal key

If you requested an incorrect key or need to invalidate an existing key, load a VASP module and run:

module load vasp6/6.5.1-cpu
revoke_license_key.sh

After authenticating with your VASP Portal credentials, the script displays all active license keys associated with your account. Select the key for the appropriate site. If both your LSU HPC and LONI HPC keys must be revoked, repeat the procedure and select each key separately.

Once revoked, the key will be included in the site's revoked-keys list after its next scheduled update, and VASP will refuse to run with that key.

If the revoked key is the one stored in the current HPC environment, remove the now-invalid local file:

rm -f ~/.vasp/vasp_license

Deleting the local file by itself does not revoke the key in the VASP Portal. If you still need VASP access, follow the personal-key request procedure to generate a replacement key.

Quick start

To view the available versions:

module avail vasp

For a general CPU calculation using the recommended version:

module load vasp6/6.6.1-cpu
srun vasp_std

Use the full module name in job scripts so that a future software update does not silently change the VASP version used by a calculation.

Available modules

Each module provides the standard VASP executables:

• vasp_std: general calculations
• vasp_gam: gamma-point-only calculations
• vasp_ncl: noncollinear and spin-orbit-coupling calculations

Do not load more than one VASP module in the same environment. Before changing versions, unload the existing VASP module or use module purge when appropriate.

Which version should I use?

VASP 6.6.1

VASP 6.6.1 is recommended for new calculations when the user's VASP license includes access to this version. It contains newer functionality and corrections that are not present in VASP 6.5.1.

When changing an established workflow from 6.5.1 to 6.6.1, first run a smaller validation calculation and compare the quantities relevant to the project, such as energies, forces, stresses, and convergence behavior.

See the official VASP changelog for changes between releases.

VASP 6.5.1

VASP 6.5.1 is retained for compatibility and reproducibility. Continue using it when a project must reproduce earlier results or depends on an established 6.5.1 workflow.

VASP 6.5.1 currently uses the previous group-based license-verification mechanism. It will move to personal automatic license validation on October 1, 2026. The module names will not change.

What is the difference between CPU and GPU builds?

CPU builds

CPU builds run on regular CPU compute nodes and provide the broadest compatibility with VASP methods and optional external packages. Use a CPU build when:

• you are unsure whether a method is supported by the GPU implementation;
• the calculation is too small to use GPUs efficiently;
• the workflow requires a CPU-only third-party interface; or
• reproducibility with an established CPU workflow is important.

GPU builds

GPU builds offload supported calculations to NVIDIA GPUs. They must be submitted to a suitable GPU partition with GPU resources explicitly requested in the Slurm job.

Loading a GPU module does not request a GPU and does not accelerate a job running on a CPU-only node. GPU performance depends on the system size, calculation type, and parallel settings; a GPU build is not automatically faster for every calculation.

Before moving a production workflow to GPUs:

1. Confirm that the required VASP method and optional interfaces are supported.
2. Run a small correctness test against the CPU build.
3. Benchmark representative CPU and GPU jobs rather than assuming that the GPU build is faster.

What does TPC mean?

TPC is the local module label for a third-party-code-enabled VASP build. It is not a different VASP release and does not mean that the executable is generally faster.

Use a TPC module only when the calculation requires one of the optional interfaces listed below. For ordinary VASP calculations, use the corresponding standard CPU or GPU module.

Tested optional-interface support

This table lists the optional interfaces specifically tested and supported in the TPC builds. It does not attempt to list every capability built directly into VASP.

VASP's standard built-in DFT-D3 functionality does not require a TPC module.

The optional interfaces are documented in the official VASP build documentation.

Loading and running VASP

Load one VASP module in the Slurm job script before starting the executable:

module purge
module load vasp6/6.6.1-cpu

which vasp_std
srun vasp_std

Replace the module name and executable as required by the calculation. Add the appropriate account, partition, time, CPU, memory, and GPU requests for the selected LSU HPC or LONI HPC system.

CPU job template

#!/bin/bash
#SBATCH --job-name=vasp-cpu
#SBATCH --nodes=1
#SBATCH --ntasks-per-node=<TASKS_PER_NODE>
#SBATCH --time=<WALLTIME>
#SBATCH --account=<ALLOCATION>

module purge
module load vasp6/6.6.1-cpu

srun vasp_std

GPU job template

#!/bin/bash
#SBATCH --job-name=vasp-gpu
#SBATCH --nodes=1
#SBATCH --ntasks-per-node=<MPI_RANKS>
#SBATCH --gres=gpu:<GPUS_PER_NODE>
#SBATCH --partition=<GPU_PARTITION>
#SBATCH --time=<WALLTIME>
#SBATCH --account=<ALLOCATION>

module purge
module load vasp6/6.6.1-gpu

srun vasp_std

GPU partition names and node configurations differ among systems. Consult the applicable cluster documentation before replacing the placeholders.

Frequently asked questions

Which module should I use if I am unsure?

Use vasp6/6.6.1-cpu for a new calculation. Move to a GPU or TPC build only after identifying a specific hardware or optional-interface requirement.

Is the TPC build faster than the standard build?

Not necessarily. TPC indicates that optional third-party interfaces were enabled. It is not a performance tier.

Is the GPU build always faster than the CPU build?

No. Small calculations may not provide enough work to use a GPU efficiently, and performance depends strongly on the calculation type and parallel configuration. Benchmark a representative calculation.

Do I need a TPC module for DFT-D3?

No. Standard built-in VASP DFT-D3 functionality does not require a TPC module. DFT-D4 support is provided by vasp6/6.6.1.tpc-cpu.

Can I use DFT-D4 with a VASP GPU module?

No. DFT-D4 is not supported by the LSU/LONI VASP GPU modules. DFT-D4 has not been ported to GPUs with OpenACC or CUDA, and supported NVHPC compiler compatibility is not available for linking it with the NVIDIA GPU build of VASP. Use vasp6/6.6.1.tpc-cpu for DFT-D4 calculations.

Additional information:

• VASP Forum confirmation of the DFT-D4 GPU limitation
• dftd4/dftd4 issue #140: Support NVHPC compilers in meson build
• dftd4/dftd4 issue #20: CPU and GPU parallelization discussion

Do I need separate license keys for LSU HPC and LONI HPC?

Yes. If you use both environments, request a key once from SuperMike3 or SuperMIC on LSU HPC and separately request a key once from QB3 or QB4 on LONI HPC. Use the exact username registered with the VASP Portal for both requests.

Do I need to change my job script on October 1, 2026?

The VASP 6.5.1 module names and executable names will remain unchanged. Users must ensure that ~/.vasp/vasp_license exists and contains a valid personal key before a job starts.

Why did automatic license validation fail?

Check the following:

1. ~/.vasp/vasp_license exists and is not empty.
2. The key was generated in the correct environment: SuperMike3 or SuperMIC for LSU HPC, and QB3 or QB4 for LONI HPC.
3. The username entered in request_license_key.sh exactly matches the VASP Portal account.
4. The Portal account is associated with a valid license for the requested VASP version.
5. The job is loading the intended VASP module.

If the problem continues, contact LSU/LONI HPC Support at sys-help@loni.org.

What information should I provide when requesting support?

Include:

• the cluster name;
• the complete module name;
• the Slurm job ID;
• the submitted job script;
• the exact error message; and
• whether the same input succeeds with the corresponding CPU module.

Do not send the contents of ~/.vasp/vasp_license.

Additional resources

• VASP changelog
• VASP installation and optional-library documentation
• VASP known issues