Vasp¶

Support tier: 1

Read information about support tiers.

Installed versions¶

Read information about how to load this software in your environment by searching for Lmod module.

General information¶

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." For more information see the VASP home page https://vasp.at and the VASP wiki.

VASP is not a free software and requires a software license. License handling at specific NAISS supercomputers is described below.---

VASP at Arrhenius¶

This section describes VASP installations on Arrhenius-CPU and GPU. For further information, also refer to the README-files on Arrhenius for running on CPU nodes:

/software/sse2/el9_epyc9005/manual/vasp/README.txt

/software/sse2/el9_gh200/manual/vasp/README.txt

• Note: right now VASP performance on Arrhenius GPU-node is much slower after a system change in August, we're working on a fix
• this page (and the README.txt files) will be updated as changes are made
• recommendations may change with system updates, as well as for clarity and better performance
• if questions or problems remain, e.g. to install special versions of VASP, or running calculations, you're very welcome to contact NAISS support

Further information & training¶

To get started with using VASP, refer to the extensive VASP wiki which includes many examples and topics, e.g. details for preparing the INCAR, POSCAR, POTCAR and KPOINTS input files. It can also be of interest to check the VASP forum and other resources available at the VASP webpage.

At times, NAISS training will arrange seminars and workshops on VASP, with a focus on beginners and best practices for running at NAISS supercomputers, check the schedule here. For recent events, see e.g. presentations and material for a workshop given in 2024, or a recent seminar.

License and access¶

VASP.5¶

For access to VASP.5 we need to check your license membership at the VASP portal. You might already have been added from a check done for an old NAISS cluster, e.g. Tetralith. If typing "groups" shows membership in "arrhpc-sse-license-vasp5", access is already active. If not yet added, please send a support request together with the email which was used for registration.

On Arrhenius, the latest version 5.4.4.pl2 is installed (also covered by VASP.6 license).

VASP.6¶

A VASP.6 license typically includes upgrades for 3 years. Thereafter, it needs to be renewed for further updates. The valid-to date can be found by login to the VASP portal. By generating a user specific license key for VASP.6, it's possible to run versions up to the end date (also shown inside the key). For the exact details on how to generate a key file, refer to instructions in:

/software/sse2/el9_epyc9005/manual/vasp/README.txt

POTCAR¶

The PAW potentials of the different elements are provided in the POTCAR libraries. Read more about on how to select them here. The latest POTCAR library (ver. 64) is not yet included with the VASP.6 license key system. It can be downloaded by the license holder (or contact person) at the VASP portal.

Previous POTCAR libs (ver. 52 and 54) distributed with VASP.5 are available with license in:

/software/sse2/el9_epyc9005/manual/vasp/POTCARs

Installations¶

• the binaries have hard-linked paths to their run-time libraries (i.e. no need to load any other modules)
• installation directories also contain makefile.include and a recipe file build.txt
• vdw_kernel.bindat file path is set for VASP =< 6.4.2, see comment
• read-only fix for POTCARs is applied, as done e.g. at Dardel and LUMI clusters
• HDF5 is typically enabled, necessary for py4vasp and some special tasks
• OpenMP is included for VASP.6, hybrid MPI/OpenMP calculations are possible

General notes and observations so far (which may depend on local setup and configurations):

• GNU+MPICH builds typically somewhat faster than Intel builds
• VASP.6 testsuite (ca. 300 tests) less failures for Intel as compared with GNU+MPICH. No failures on NVHPC+OMPI (GPU).

Modules¶

The VASP modules are found by:

module avail vasp

VASP binaries¶

When loading a module or setting a path to an installation, the following binaries become available

• vasp_std: the regular binary for more than 1 k-point
• vasp_gam: single gamma-point binary, for faster calculations (e.g. big supercells)
• vasp_ncl: for spin-orbit coupling and non-collinear calculations

Special builds¶

VASP can be compiled for use together with certain software and there are also patches which provide different functionalities. A list of common utility builds include:

• constrained structure relaxation, available by default from 6.5.0
• Wannier90, code for generating maximally-localised Wannier functions
• BEEF, package for BEEF-vdW functionals and Bayesian error estimates
• libxc, library of exchange-correlation and kinetic energy functionals
• VASP VTST Tools, source code and scripts for finding saddle points and evaluating transition state theory (TST) rate constants
• VASPsol, implicit solvation model that describes the effect of electrostatics, cavitation, and dispersion on the interaction between a solute and solvent
• VASPsol++, framework for implementing complex continuum fluid models If a special installation is needed, check with NAISS support.

List of installations at Arrhenius¶

For an overview and quick update, also refer to the README.txt files at Arrhenius:

/software/sse2/el9_epyc9005/manual/vasp/README.txt
/software/sse2/el9_gh200/manual/vasp/README.txt

6.6.1 (w90)¶

This is the most recent version 6.6.1. It is a patch release, for the serious bug in 6.6.0 (see below) and other fixes. Available modules:

VASP/6.6.1-gcc-2026.03-mpich
GPU/VASP/6.6.1-max1node-nvhpc-25.9-cu13.0

/software/sse2/el9_epyc9005/manual/vasp/6.6.1.17072026
/software/sse2/el9_gh200/manual/vasp/6.6.1.17072026

6.6.0 (hpc2: patch)¶

Version 6.6.0 was a major update. For example, with X-ray absorption using BSE, cRPA, Nuclear Magnetic Resonance (NMR), checkpointing for phonon calculations. Also new features and improvements for machine-learning force fields. Note: a serious bug was found in this version, forces with meta-GGA functionals were wrong in the spin-polarized case (ISPIN=2). Therefore, use the patched hpc2 module! Available modules:

VASP/6.6.0-hpc2-gcc-2026.03-mpich
VASP/6.6.0-gcc-2026.03-mpich
GPU/VASP/6.6.0-hpc2-max1node-nvhpc-25.9-cu13.0
GPU/VASP/6.6.0-max1node-nvhpc-25.9-cu13.0

/software/sse2/el9_epyc9005/manual/vasp/6.6.0.06032026
/software/sse2/el9_gh200/manual/vasp/6.6.0.06032026

6.5.1¶

Version 6.5.1 included many fixes and improvements of the previous major update. Available modules:

VASP/6.5.1-gcc-2026.03-mpich
GPU/VASP/6.5.1-max1node-nvhpc-25.9-cu13.0

/software/sse2/el9_epyc9005/manual/vasp/6.5.1.10032025
/software/sse2/el9_gh200/manual/vasp/6.5.1.10032025

6.5.0¶

Version 6.5.0 included new features and improvements, in particular for electron-phonon coupling, BSE and machine-learned force fields. Available modules:

VASP/6.5.0-gcc-2026.03-mpich
GPU/VASP/6.5.0-max1node-nvhpc-25.9-cu13.0

/software/sse2/el9_epyc9005/manual/vasp/6.5.0.16122024
/software/sse2/el9_gh200/manual/vasp/6.5.0.16122024

6.4.3¶

Version 6.4.3 included new features, fixes and improvements, e.g. interface to libMD. Extra builds include using intel-2025b. The paths are:

/software/sse2/el9_epyc9005/manual/vasp/6.4.3.19032024
/software/sse2/el9_gh200/manual/vasp/6.4.3.19032024

6.4.2¶

Version 6.4.2 included several fixes, mostly related to the ML part. Extra builds include using intel-2025b. The paths are:

/software/sse2/el9_epyc9005/manual/vasp/6.4.2.20072023
/software/sse2/el9_gh200/manual/vasp/6.4.2.20072023

6.3.2 (VTST, VASPsol, VASPsol++)¶

Version 6.3.2 included assorted bug fixes and improvements from earlier VASP.6. Extra builds include using intel-2025b, for this CPU-build also VTST together with VASPsol or with VASPsol++ are available. The path is:

/software/sse2/el9_epyc9005/manual/vasp/6.3.2.27062022

5.4.4.pl2 (w90)¶

This is the last patched update of VASP.5. Available modules:

VASP/5.4.4-gcc-2026.03-mpich

/software/sse2/el9_epyc9005/manual/vasp/5.4.4.16052018

Running on Arrhenius-CPU¶

Note that an Arrhenius CPU-node is "big" with 2x128 = 256 cores, so corresponding to "8x Tetralith" or "2x Dardel-CPU" nodes, with ca. 3 GB RAM per core (similar to Tetralith) and ca. 12 GB/core for a fewer number of "fat memory" nodes.

A "natural unit" on Arrhenius CPU-node is a NUMA-zone which contains 32 cores, so if a job isn't "too big" it's useful to benchmark it starting from multiples of NUMA-zones, 32, 64 and so on. In most cases, this is a better approach than starting from full nodes on Arrhenius.

Beware of using #SBATCH -N 1 on Arrhenius-CPU, since this always allocates a full node with 256 cores (unless that's the goal).

• NCORE=32 (or 16), if allocating multiples of 32 (16) cores in a job, typically a big improvement from default (NCORE=1)
• NSIM=8, 16, 32 usually some improvement from default (NSIM=4)
• KPAR, i.e. k-point parallelisation, can give a big improvement, but not always, it's important to check. Default is KPAR=1. Check number of k-points in e.g. IBZKPT, divide evenly over NUMA-zones or nodes

Best is to perform tests, e.g. check electronic steps of the same type by "grep LOOP OUTCAR". This becomes more important for larger jobs and using more resources (efficient scaling).

The project cost based in "core-hours" depends on how long (walltime) a certain amount of resources (cores) are allocated, independent on actual usage (since if they're allocated, they're removed from the available resource pool). Therefore efficient usage is important, such that more work can be done in total.

CPU job script examples¶

For CPU runs it's typically recommended to use the MPI helper script "mpprun". For further details check mpprun --help. Though at the moment, if running the gcc-2026.03-mpich builds on a single node (or partial node), it's recommended to instead use srun.

In the examples below a module is loaded for access to VASP, alternatively one can set the direct path to use a specific build, e.g.:

export PATH=/software/sse2/el9_epyc9005/manual/vasp/6.6.1.17072026/gcc-2026.03-mpich/hpc1:$PATH

export PATH=/software/sse2/el9_epyc9005/manual/vasp/6.6.1.17072026/intel-2025b/hpc1:$PATH
export I_MPI_ADJUST_REDUCE=3

Example 1: regular job using 32 cores

#!/bin/bash
#SBATCH -A naiss20XX-Y-ZZZ-cpu
#SBATCH -p cpu
#SBATCH -t 1:00:00
#SBATCH -n 32
#SBATCH -J vasp

module load VASP/6.6.1-gcc-2026.03-mpich
srun -n 32 --mpi=pmi2 -m block:block vasp_std

Example 2: similar as above, but using an intel build

#!/bin/bash
#SBATCH -A naiss20XX-Y-ZZZ-cpu
#SBATCH -p cpu
#SBATCH -t 1:00:00
#SBATCH -n 32
#SBATCH -J vasp

export PATH=/software/sse2/el9_epyc9005/manual/vasp/6.6.1.17072026/intel-2025b/hpc1:$PATH
export I_MPI_ADJUST_REDUCE=3
mpprun vasp_std

Example 3: memory hungry job, if one gets OOM (Out Of Memory), allocate more cores, e.g. from 32 to 64 cores for larger memory

#!/bin/bash
#SBATCH -A naiss20XX-Y-ZZZ-cpu
#SBATCH -p cpu
#SBATCH -t 1:00:00
#SBATCH -n 64
#SBATCH -J vasp

module load VASP/6.6.0-gcc-2026.03-mpich
srun --mem=0 -n 32 --mpi=pmi2 -m block:block vasp_std

An alternative way is to allocate several OpenMP threads per rank, but not use all of them for the calculation. For example, allocate "-n 32 - c 2" and set

export OMP_NUM_THREADS=1
srun -n 32 -c 1 --mpi=pmi2 -m block:block vasp_std

export OMP_NUM_THREADS=2
srun -n 32 -c 2 --mpi=pmi2 -m block:block vasp_std

A different solution is to use the "fat memory" nodes available on Arrhenius-CPU with #SBATCH -p gpu, this can also be combined with the above methods.

Running on Arrhenius-GPU¶

For VASP, a single MPI-rank is used per GPU, with a number of OpenMP threads over the corresponding ARM CPU. Each Arrhenius GPU-node has 4x Nvidia GH200 superchips, which consists of a Hopper GPU and Grace CPU (72 cores). For efficient calculations, it's reasonable to start with testing a single superchip.

Note, in the majority of cases, it's expected that a single GH200 superchip will be the most efficient way to run a job.

The project cost is based on "GPU-hours", which is exactly as it sounds. Allocating 1x GH200 for 1h costs 1 GPU-hour and 2x GH200 for 1 h costs 2 GPU-hours.

Beware of using #SBATCH -N 1 on Arrhenius-GPU, since this always allocates a full node with 4 GPUs (unless that's the goal).

• NCORE isn't used on GPU (resets to = 1)
• NSIM=32, 64 typically some improvment using larger values than default = 4
• KPAR, i.e. k-point parallelisation, in some case gives a big speed-up. Divide evenly over GPUs or GPU-nodes. In particular, needed for efficiently running over several GPU-nodes
• OMP_NUM_THREADS, testing with -c 8, but higher values might increase performance. Max 72 (CPU cores) usually too high
• NBLOCK_FOCK=64 for hybrid (HSE06) calculations, sometimes improves (default = 32)
• Note that "too small" jobs aren't efficient to run on GPU, as compared with CPU. GPU is better for medium and larger sized jobs. Also hybrid (HSE06) jobs perform well
• As for CPU runs, one can do similar tests e.g. comparing electronic steps. What is best can really depend on specific job (and sometimes combination of parameters)

GPU job script examples¶

In the examples below one would need to set PATH to a VASP installation, alternatively loading a VASP module. At the moment one can use this 6.6.1 build:

export PATH=/software/sse2/el9_gh200/manual/vasp/6.6.1.17072026/nvhpc-25.9-cu13.0-ompi/tst1:$PATH

srun --mpi=pmix

The below recommendations may change depending on system updates, as well as for clarity and performance.

Note: the number of OpenMP threads (which are running on the CPU) are an example, during tests -c 8 was most often sufficient (and < 8 usually worse), but a larger number might give a speed-up depending on job. Typically, using the maximum 72 threads gave bit worse performance.

Beware of requesting full nodes, e.g. -N 1, as that allocates all 4x GH200 on an Arrhenius-GPU node, if not also setting the use of 4 GPUs --gpus=4 and 4 MPI-ranks -n 4. The project cost is always the allocated resource x walltime, independent of actual use (since they're not in the resource pool when allocated).

Due to the high possible cost in GPU-hours in case a job stalls (i.e. runs the full walltime without producing output), it's advisable to not set the walltime "too high", unless needed.

Note: the NVHPC+OMPI build can not run on more than 1 GPU-node (max 4 GPUs) at the moment!

Changes in recommendations:

• to get all ARM-CPU memory, use srun --mem=0 instead of "#SBATCH --mem=0" (otherwise allocates whole GPU-node!)
• no need to set "#SBATCH --network=single_node_vni" anymore

Example 1: a job running on 1x GH200 (1 GPU + 1 CPU)

#!/bin/bash
#SBATCH -A naiss20XX-Y-ZZZ-gpu
#SBATCH -p gpu
#SBATCH -t 1:00:00
#SBATCH --gpus=1
#SBATCH -n 1
#SBATCH -c 72
#SBATCH -J vasp

module load GPU/VASP/6.6.1-max1node-nvhpc-25.9-cu13.0
srun --mem=0 --mpi=pmix -n 1 -c 8 --gpus 1 -m block:block vasp_std

Example 2: increase OpenMP threads on the CPU for the 1x GH200 job

#!/bin/bash
#SBATCH -A naiss20XX-Y-ZZZ-gpu
#SBATCH -p gpu
#SBATCH -t 1:00:00
#SBATCH --gpus=1
#SBATCH -n 1
#SBATCH -c 72
#SBATCH -J vasp

module load GPU/VASP/6.6.1-max1node-nvhpc-25.9-cu13.0
srun --mem=0 --mpi=pmix -n 1 -c 32 --gpus 1 -m block:block vasp_std

Problems & solutions¶

If a job crashes or fails in some way, have a look if there are warning messages in the slurm output file, slurm-JOBID.out. For a finished job, one can get a summary of its run using seff JOBID. The running or queued jobs on Arrhenius can be listed with

squeue -u $USER

Out of memory (OOM)¶

This is among the most common problems, it can be fixed either by increasing available RAM for a calculation, or by reducing its need. The easiest solution is to ask for more resources, so on a CPU-node increase the number of allocated cores (see job script example above). An alternative is to run on "fat memory" nodes, #SBATCH -p fat with an increase from ca. 3 to 12 GB/core. For GPU-nodes, one might need to run on more GPUs to access more memory, though first check that all the memory on the CPU part is allocated (srun --mem=0).

A different way is to reduce the need for memory by reducing the size of the problem (if possible), e.g. with fewer k-points or a smaller plane-wave energy cutoff ENCUT, or with fewer atoms in the supercell. Also refer to discussion at the VASP wiki on not enough memory and memory requirements.

Job stalls without crashing¶

We have seen that sometimes jobs using KPAR parallelisation stall, i.e. after some steps run the full walltime with no new output. If this happens, a possible solution might be to restart the job, or if that doesn't work to try a different installation. For example, test with an alternative build compiled with buildenv-intel/2025b-eb.

Another possibility, in particular if there are several jobs which stall at the same time, could be a temporary disturbance of filesystem I/O.

BRMIX: very serious problems the old and the new charge density differ¶

This is a common problem when using intel-MPI on Arrhenius (and previously Tetralith), it's related to MPI_REDUCE calls, which can be avoided by setting:

export I_MPI_ADJUST_REDUCE=3

VASP at Dardel¶

Also refer to the Dardel specific documentation for VASP.

Licenses¶

If you want to use VASP please contact us with information of the e-mail address that you have listed in the VASP global portal.

How to use VASP¶

General observations¶

• VASP is not helped by hyper-threading
• Running on fewer than 128 tasks per node allocates more memory to each MPI task. This can in some cases improve performance and is necessary if your job crashes with an out-of-memory (OOM) error. Further information can be found on the VASP wiki pages Memory_requirements and Not_enough_memory.

Parallelisation settings¶

Parallelisation over k-points is recommended when it is possible to do so. In practice, KPAR should be set to be equal to the number of nodes. Please also make sure that the k-points can be evenly distributed over nodes. For example, a calculation with 15 k-points can run on 15 nodes with KPAR=15. NCORE determines the number of cores that work on an individual orbital. A recommended value for NCORE is 16.

How to choose the number of cores¶

Rule of thumb¶

• 1 atom per core = Good
• 0.5 atom per core = Could work (but bad efficiency and time wasted)
• <0.5 atom per core = Don't do it

Explanation of above¶

• The number of bands is more important than the number of atoms, but typically you have about 4 bands/atom in VASP.

Checklist:¶

• Check how many you have in the calculation. Let's call this "NB".
• Cores = NB is best you can do.
• For better efficiency, typically 90%+, aim for at least 4 bands per core, i.e. Cores = NB/4
• If you can use k-point parallelisation ("KPAR"), use it! It improves scaling a lot. You can run up to cores = #kpts * NB / 4.
• You have now determined the number of cores.
• Look at this number. Does it look "strange"? Try to adjust the number of bands to make the number of cores more even, .e.g we don't want a prime number. Good numbers are multiple of 4,8,12,16 etc. For example, 512 bands is better than 501 (=3x167).
• Calculate the number of nodes necessary, e.g. 512 cores (128 cores/node) = 4 compute nodes.
• For a wide calculation with less than 4 bands per core, try decreasing the number of cores per node to 64, or even 32. You may also have to do this get memory available for each MPI rank. For VASP versions that have shared memory parallelisation implemented with OpenMP threading, you can use more than one thread per MPI rank.

Vasp Filenames¶

• vasp : this is normal regular VASP version for calculations using >1 k-point.
• vasp-gamma : gamma-point only version of VASP. Use this one if you only have the gamma point. It is much faster and uses less memory.
• vasp-noncollinear : VASP for noncollinear and spin-orbit coupling calculations.

BEEF functionals¶

This version of VASP has been compiled with support for BEEF functionals.

VASP VTST Tools¶

The VTST extension to VASP enables finding saddle points and evaluating transition state theory (TST) rate constants with VASP.

VTST Scripts¶

The VTST Perl scripts are available to perform common tasks to help with VASP calculations, and particularly with transition state finding.

VASPsol¶

VASPsol is an implementation of an implicit solvation model that describes the effect of electrostatics, cavitation, and dispersion on the interaction between a solute and solvent. Full documentation on how to use VASPsol documentation.

Short how to do¶

• Do a vacuum calculation for your system first and save the wavefunction file WAVECAR by specifying LWAVE = .TRUE. in the INCAR file.
• Start the solvation calculation from the vacuum WAVECAR, specify ISTART = 1 in the INCAR file.
• The solvation parameters are read from the INCAR file.
• In the simplest case the only parameter that need to be set is the solvation flag LSOL = .TRUE.

Potential files and vdW kernel¶

Projector augmented wave (PAW) potentials can be found at /pdc/software/24.11/other/vasp/potpaw-64/

To use one of the nonlocal vdW functionals one needs to put the file vdw_kernel.bindat into the run directory (along with INCAR, POSCAR, POTCAR and KPOINTS). This file can be found at /pdc/software/24.11/other/vasp/vdw_kernel/vdw_kernel.bindat.

Running Vasp¶

Here is an example of a job script requesting 128 MPI processes per node:

#!/bin/bash

#SBATCH -A naissYYYY-X-XX
#SBATCH -J my_vasp_job
#SBATCH -t 01:00:00
#SBATCH -p main

#SBATCH --nodes=2
#SBATCH --ntasks-per-node=128

module load PDC/24.11
module load vasp/6.4.3-vanilla

export OMP_NUM_THREADS=1

srun --hint=nomultithread vasp

Please also note that it is necessary set the SRUN_CPUS_PER_TASK environment variable in the job script so that srun can work as expected, see SLURM documentation.

#!/bin/bash

#SBATCH -A naissYYYY-X-XX
#SBATCH -J my_vasp_job
#SBATCH -t 01:00:00
#SBATCH -p main

#SBATCH --nodes=2
#SBATCH --ntasks-per-node=64
#SBATCH --cpus-per-task=2

module load PDC/24.11
module load vasp/6.4.3-vanilla

export OMP_NUM_THREADS=2
export OMP_PLACES=cores

export SRUN_CPUS_PER_TASK=$SLURM_CPUS_PER_TASK

srun --hint=nomultithread vasp

How to build VASP¶

These are the steps which were used to build the module vasp/6.5.1-vanilla.

Obtain and unpack the VASP source code¶

tar xf vasp.6.5.1.tgz
cd vasp.6.5.1

Apply readonly-patch¶

In order to lower the footprint on the file system in runtime, apply before compiling the readonly-patch

--- src/pseudo.F    2025-03-10 16:41:26.000000000 +0100
+++ src/pseudo_new.F    2025-05-05 08:57:54.000000000 +0200
@@ -233,7 +233,7 @@
 !        END IF
       END IF
 #endif
-      OPEN(UNIT=10,FILE=DIR_APP(1:DIR_LEN)//'POTCAR',STATUS='OLD',IOSTAT=IERR)
+      OPEN(UNIT=10,FILE=DIR_APP(1:DIR_LEN)//'POTCAR',ACTION='READ',STATUS='OLD',IOSTAT=IERR)
       IF (IERR/=0) THEN
          OPEN(UNIT=10,FILE='POTCAR',STATUS='OLD')
       ENDIF
--- src/string.F    2025-03-10 16:41:27.000000000 +0100
+++ src/string_new.F    2025-05-05 08:58:56.000000000 +0200
@@ -94,7 +94,7 @@
         integer, intent(out) :: ierr  !< error flag that will be set if accessing the file fails
         character(len=:), allocatable :: content
         integer file_unit
-        open(newunit=file_unit,file=filename,status='old',form='unformatted',access='stream',iostat=ierr)
+        open(newunit=file_unit,file=filename,status='old',form='unformatted',access='stream',action='read',iostat=ierr)

patch -p0 -b < POTCAR-readonly-651.patch

Configure the VASP makefile.include¶

Configure the makefile.include file as needed. For the globally installed VASP modules the file can be found in the directory $VASPROOT/example-files. Here are the settings used for the vasp/6.5.1-vanilla module.

# Default precompiler options
CPP_OPTIONS = -DHOST=\"Dardel\" \
              -DMPI -DMPI_BLOCK=65536 -Duse_collective \
              -DscaLAPACK \
              -DCACHE_size=65536 \
              -Davoidalloc \
              -Dvasp6 \
              -Dtbdyn \
              -Dfock_dblbuf \
              -D_OPENMP -DnoSTOPCAR

CPP         = cc -E -C -w $*$(FUFFIX) >$*$(SUFFIX) $(CPP_OPTIONS)

FC          = ftn -fopenmp
FCL         = ftn -fopenmp

FREE        = -ffree-form -ffree-line-length-none

FFLAGS      = -w -ffpe-summary=none

OFLAG       = -O2
OFLAG_IN    = $(OFLAG)
DEBUG       = -O0

# For what used to be vasp.5.lib
CPP_LIB     = $(CPP)
FC_LIB      = $(FC)
CC_LIB      = cc
CFLAGS_LIB  = -O
FFLAGS_LIB  = -O1
FREE_LIB    = $(FREE)

OBJECTS_LIB = linpack_double.o

# For the parser library
CXX_PARS    = CC
LLIBS       = -lstdc++

##
## Customise as of this point! Of course you may change the preceding
## part of this file as well if you like, but it should rarely be
## necessary ...
##

# When compiling on the target machine itself, change this to the
# relevant target when cross-compiling for another architecture
#VASP_TARGET_CPU ?= -march=native
#FFLAGS     += $(VASP_TARGET_CPU)

# For gcc-10 and higher (comment out for older versions)
FFLAGS     += -fallow-argument-mismatch

# BLAS and LAPACK (mandatory)
#OPENBLAS_ROOT ?= /path/to/your/openblas/installation
#BLASPACK    = -L$(OPENBLAS_ROOT)/lib -lopenblas

# scaLAPACK (mandatory)
#SCALAPACK_ROOT ?= /path/to/your/scalapack/installation
#SCALAPACK   = -L$(SCALAPACK_ROOT)/lib -lscalapack

#LLIBS      += $(SCALAPACK) $(BLASPACK)

# FFTW (mandatory)
#FFTW_ROOT  ?= /path/to/your/fftw/installation
#LLIBS      += -L$(FFTW_ROOT)/lib -lfftw3 -lfftw3_omp
#INCS       += -I$(FFTW_ROOT)/include

# HDF5-support (optional but strongly recommended, and mandatory for some features)
#CPP_OPTIONS+= -DVASP_HDF5
#HDF5_ROOT  ?= /path/to/your/hdf5/installation
#LLIBS      += -L$(HDF5_ROOT)/lib -lhdf5_fortran
#INCS       += -I$(HDF5_ROOT)/include

# For the VASP-2-Wannier90 interface (optional)
#CPP_OPTIONS    += -DVASP2WANNIER90
#WANNIER90_ROOT ?= /path/to/your/wannier90/installation
#LLIBS          += -L$(WANNIER90_ROOT)/lib -lwannier

# For the fftlib library (recommended)
#CPP_OPTIONS+= -Dsysv
#FCL        += fftlib.o
#CXX_FFTLIB  = CC -fopenmp -std=c++11 -DFFTLIB_THREADSAFE
#INCS_FFTLIB = -I./include -I$(FFTW_ROOT)/include
#LIBS       += fftlib
#LLIBS      += -ldl

# For machine learning library vaspml (experimental)
#CPP_OPTIONS += -Dlibvaspml
#CPP_OPTIONS += -DVASPML_USE_CBLAS
#CPP_OPTIONS += -DVASPML_DEBUG_LEVEL=3
#CXX_ML      = mpic++ -fopenmp
#CXXFLAGS_ML = -O3 -std=c++17 -pedantic-errors -Wall -Wextra
#INCLUDE_ML  = -I$(OPENBLAS_ROOT)/include

Load the build environment, Gnu toolchain¶

ml PDC/24.11
ml cpeGNU/24.11
ml cray-fftw/3.3.10.9

Build the VASP executables¶

make

Create symbolic links for the executables¶

cd bin
ln -s vasp_std vasp
ln -s vasp_ncl vasp_noncollinear
ln -s vasp_gam vasp_gamma