Requests for technical support from the VASP group should be posted in the VASP-forum.

Precompiler flags

From Vaspwiki
Revision as of 08:04, 14 July 2021 by Vaspmaster (talk | contribs) (→‎Deprecated/Not-recommended)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Recommended

-DHOST=[string]
A string (20 characters max.) that describes the platform on which VASP is compiled, e.g.:
-DHOST=\"LinuxIFC\"
for a Linux host using an Intel fortran compiler.
-DMPI
Set this to compile the parallel version of VASP.
-Duse_collective
Set this to use MPI collectives in the all-to-all communication and global summations.
In case one specifies this, the value of MPI_BLOCK (below) will be meaningless.
-DMPI_BLOCK=[integer]
Specifies the block size used by the in-house MPI all-to-all communication and global summations.
-DscaLAPACK
Set this to use scaLAPACK.
-DCACHE_SIZE=[integer]
Specifies the size of the cache memory. Only used by the in-house real-to-complex FFT routines (fft3dlib.F).
By default these are no longer used, instead we use the real-to-complex FFT routines from fftw3.
-Davoidalloc
Set this to use automatic instead of allocatable arrays in many routines related to the real space projection operators.
-Dvasp6
Set this to activate all VASP.6.X.X specific features.
N.B.: This flags should always be set when compiling VASP.6.X.X, except in case one wants to compile the CUDA-C GPU-port. The latter, however, is now considered to be deprecated and will be discontinued completely in future. To run VASP (>= 6.2.0) on GPUs we strongly recommend you to use the OpenACC GPU-port of VASP.
-Dtbdyn
Adds the advanced molecular dynamics routines.
-Dfock_dblbuf
Uses double buffer technique for the computation of exchange potential. Available as of VASP.6, N/A for the CUDA-C GPU-port.


For the OpenACC GPU-port

-D_OPENACC
Mandatory: Activate all OpenACC related code paths.
-DUSENCCL
Mandatory: Use the NVIDIA Collective Communications Library (NCCL) instead of MPI for relevant instances of collective reduction operations (MPI_Allreduce).
-DUSENCCLP2P
Optional but strongly recommended (requires NCCL >= 2.7.8): Use the NVIDIA Collective Communications Library (NCCL) instead of MPI for relevant instances of all-to-all operations (MPI_Alltoallv).
-Dqd_emulate
Mandatory: To compile the OpenACC GPU-port you need either the NVIDIA HPC-SDK or a recent version (>= 19.10) of PGI's Compilers & Tools. Both of these compilers do not natively support quadruple precision and require the use of the QD library to emulate quadruple precision arithmetic.
-DMPI
Mandatory: See above.
-Dvasp6
Mandatory: See above.
-Dfock_dblbuf
Mandatory: See above.


For hybrid MPI + OpenMP parallelisation

-D_OPENMP
Mandatory: Activate all OpenMP related code paths.
-DMPI
Mandatory: See above.
-Dfock_dblbuf
Optional but strongly recommended: See above.


Optional

-Duse_shmem
Use MPI-3 shared memory segments to reduce memory demands. This can be really helpful to keep the memory demands of GW calculations at an acceptable level.
-DVASP_HDF5
Set this to add support for reading and writing HDF5 files. This option is available since VASP 6.2.0.
-DVASP2WANNIER90 and -DVASP2WANNIER90v2
Set this to include the interface between VASP and Wannier90.
Up to VASP 6.1.x you need to set -DVASP2WANIER90 to interface with Wannier90 v.1.x, and -DVASP2WANNIER90v2 for Wannier90 v.2.x, and add the Wannier90 library to makefile.include.
Since VASP 6.2.0 you need to set -DVASP2WANNIER90 to interface with Wannier90 v.2.x or v.3.x.
-Dlibbeef
Set this to include the BEEF class of van-der-Waals functionals.
N.B.: one needs to add libbeef to makefile.include.
-DDFTD4
Set this to include the DFTD4 van-der-Waals functional.
Note that you need to install DFTD4 and add it to the makefile.include
-DPROFILING
Switches on detailed profiling of the code. This carries a (slight) performance penalty.


Deprecated/Not-recommended

-DnoAugXCmeta
This option was added to compute the metaGGA contributions from the non-augmented pseudo density (instead of the augmented density). There is a condition concerning the behavior of the von-Weizsäcker kinetic energy density (second derivative of the charge density) and the kinetic energy density computed from the orbitals ingrained into TPSS and revTPSS. This condition can be strongly violated when one augments the charge density. For the TPSS and revTPSS the functionals can become unstable in those cases. SCAN and its derivates (RSCAN, R2SCAN, etc) do not assume the aforementioned conditions to be met and remain stable for the augmented density as well so this option should not be used as it may negatively affect the final results.

Contents