What Is VASP

VASP (Vienna Ab initio Simulation Package) is a DFT code based on a plane-wave basis and the PAW (projector augmented-wave) method. In this tutorial it is responsible for finalizing structures (Chapter 03) and for the hybrid functional reference (Chapter 11). This chapter surveys VASP's input and output structure.

What VASP Is

• A DFT code based on plane waves + PAW. Since the basis is not attached to atoms, basis quality can be converged systematically with a single cutoff energy (ENCUT).
• It is a commercial code. Using it requires a license, and redistribution of the code and of the PAW datasets (POTCAR) is prohibited. Licenses are usually held per research group or institution.
• Even so, it is used as the de facto standard in solid-state electronic structure. The reasons come down to three — ① robust, validated PAW datasets covering essentially all elements are shipped with the code, ② its functional range is broad, from structural optimization and MD to hybrid functionals and various post-processing, and ③ decades of accumulated literature make it easy to compare and validate results against prior work.

VASP's role in this tutorial is supporting but important — it computes the same structure with a plane-wave basis independent of the LCAO basis (SIESTA), confirming that the results are not artifacts of one particular basis. The comparative perspective between the two codes was summarized in What Is SIESTA.

The Four Main Input Files

Unlike SIESTA, VASP has fixed input file names. Place the following four files in the working directory and you are ready to run.

File	Role
INCAR	Calculation directives — what to compute and how (tag = value)
POSCAR	Structure — lattice vectors and atomic coordinates
KPOINTS	k-point sampling
POTCAR	Per-element PAW pseudopotentials

INCAR — Calculation Directives

A text file in tag = value format. There are hundreds of tags, but most are left at their defaults and only the core tags below are set according to the situation.

Tag	Meaning	Notes
ENCUT	Plane-wave cutoff (eV)	The single parameter setting basis quality. POTCAR carries the recommended minimum (ENMAX)
ISMEAR	Electron occupation smearing scheme	0 = Gaussian (safe), $-5$ = tetrahedron (DOS, static calculations), 1·2 = Methfessel–Paxton (metal relaxation)
SIGMA	Smearing width (eV)	Paired with ISMEAR. The smaller it is, the less energy contamination from smearing
EDIFF	Electronic SCF convergence criterion (eV)	Force quality is directly tied to SCF convergence, so keep it tight for relaxations
EDIFFG	Ionic loop termination criterion	Negative means a force criterion — e.g., $-0.01$ terminates when every atom's force magnitude is below 0.01 eV/Å
IBRION	Ionic motion algorithm	$-1$ = ions fixed (single point), 2 = conjugate gradient (relaxation)
ISIF	What to relax	2 = atomic positions only, 3 = positions + cell
NSW	Maximum number of ionic steps	0 means a single-point calculation
ISPIN	Spin polarization	1 = unpolarized (default), 2 = collinear spin polarized
LORBIT	Orbital projection output	11 generates lm-decomposed PDOS (DOSCAR) and PROCAR

A minimal example — for a single-point SCF this much suffices.

INCAR (minimal example)

SYSTEM = C4 chain single point
ENCUT  = 500
ISMEAR = 0
SIGMA  = 0.05
EDIFF  = 1E-8

The full INCAR for relaxation is explained tag by tag in Chapter 03.

POSCAR — Structure

The format is fixed by line position.

POSCAR

C4 chain                                  <- line 1: comment
1.0                                       <- line 2: overall scaling factor
  15.00   0.00   0.00                     <- lines 3-5: lattice vectors (Å)
   0.00  15.00   0.00
   0.00   0.00   5.16
C                                         <- line 6: element list
4                                         <- line 7: number of atoms per element
Direct                                    <- line 8: coordinate format
  0.50  0.50  0.00                        <- from line 9: atomic coordinates
  0.50  0.50  0.25
  0.50  0.50  0.50
  0.50  0.50  0.75

• Direct vs Cartesian — Direct (first letter D) means fractional coordinates relative to the lattice vectors, Cartesian (first letter C) means orthogonal coordinates in Å. Note that the scaling factor (line 2) multiplies both the lattice vectors and Cartesian coordinates.
• The element order on line 6 determines the POTCAR concatenation order. If this correspondence is broken, the wrong pseudopotential is attached to an atom.
• Selective dynamics — adding a Selective dynamics line before the coordinate-format line lets you specify, with flags such as T T F after each atomic coordinate, whether motion is allowed (T) or fixed (F) per direction. It is used for partial relaxations, such as fixing the bottom layers of a surface slab.

KPOINTS — k-Point Sampling

KPOINTS

Gamma-centered 1x1x32 (transport axis z only)
0
Gamma
 1 1 32
 0 0 0

• Line 1 is a comment; the 0 on line 2 means "generate the grid automatically."
• Line 3 is the grid type — Gamma (first letter G) is a Gamma-centered grid including the Γ point, Monkhorst (first letter M) is a Monkhorst-Pack grid. An even-division Monkhorst-Pack grid does not pass through Γ, so the two schemes can give different results. Hexagonal cells require Gamma-centered because of symmetry, and otherwise, when in doubt, Gamma-centered is the safe choice.
• Line 4 is the number of divisions along each direction, line 5 is the shift.

POTCAR — PAW Datasets

Build it by concatenating the per-element PAW files in exactly the element order of POSCAR line 6.

cat $POTCAR_DIR/C/POTCAR > POTCAR                       # single element
cat $POTCAR_DIR/Hf/POTCAR $POTCAR_DIR/Se/POTCAR > POTCAR  # multiple elements - in POSCAR order
grep TITEL POTCAR                                       # check the element order of the result

POTCAR is licensed material — do not distribute

POTCAR is an asset bound to the VASP license. Uploading it to a public repository or passing it to someone without a license is a license violation, and the example repository of this site contains no POTCAR files. Assemble them yourself from your institution's potpaw database.

Output File Dictionary

File	Contents	When to use
OUTCAR	Full log — energies, forces, stresses, eigenvalues, timings	The most detailed first thing to check
OSZICAR	One-line summary per step — electronic-step dE, ionic-step E0	Quickly tracking convergence progress
CONTCAR	Final (or latest) structure — same format as POSCAR	Restart — copy to POSCAR to continue
vasprun.xml	Structured XML of the whole run	Input for parsing tools such as pymatgen and ASE
CHGCAR	Charge density	Density visualization, initial density for restarts — large and regenerable
WAVECAR	Wavefunctions	Speeding up follow-up calculations — large and regenerable, not reusable if the cell changes
DOSCAR	DOS (including PDOS when LORBIT is set)	DOS/PDOS plots
EIGENVAL	Eigenvalues per k-point	Band plots
PROCAR	Orbital- and atom-resolved projections (LORBIT = 11)	Fat bands, orbital component analysis
LOCPOT	Local potential (requires output tags such as LVTOT)	Vacuum-level alignment, work function
IBZKPT	List of irreducible Brillouin zone k-points	Checking the k-points actually used
XDATCAR	Coordinate trajectory per ionic step	Visualizing relaxation/MD trajectories

The bulky CHGCAR and WAVECAR are regenerated by rerunning with the same input, so they are usually excluded when moving results. Conversely, OUTCAR, OSZICAR, CONTCAR, and the four input files must always be kept together — without them you cannot reconstruct later what that calculation was.

How to Read OSZICAR — Electronic and Ionic Loops

OSZICAR mixes two kinds of lines. Below is an excerpt shown to illustrate the format.

       N       E                     dE             d eps       ncg     rms          rms(c)
DAV:   1    -0.221893285000E+02   -0.22189E+02   -0.75173E+02   128   0.428E+01
DAV:   2    -0.229235436000E+02   -0.73421E+00   -0.71877E+00   256   0.512E+00
...
DAV:  12    -0.230284578000E+02   -0.32115E-08    0.11201E-08   128   0.231E-04   0.412E-05
   1 F= -.23028458E+02 E0= -.23028410E+02  d E =-.957337E-04

• Lines beginning with DAV: (or RMM:) are the electronic loop — the SCF iterations at fixed ions. E is the current energy and dE the change from the previous iteration. The electronic loop ends when the absolute value of dE falls below EDIFF.
• Lines beginning with a number are the ionic-loop summary — in 1 F= ... E0= ... d E = ..., the leading number is the ionic step index, F is the free energy including the smearing entropy term, E0 is the $\sigma \to 0$ extrapolated energy (the value to report), and d E is the change from the previous ionic step.
• If the relaxation is going well, the electronic loop gets shorter as ionic steps proceed (since it starts from the previous density). Conversely, if each step takes dozens of electronic iterations, that is a signal to inspect the SCF settings.

To see only the energy of the last ionic step, grep "E0=" OSZICAR | tail -n 1 is the one-line prescription. However, the termination verdict for a relaxation is made from the forces, not the energy — the procedure of checking in the force block of OUTCAR (grep -A 6 "TOTAL-FORCE" OUTCAR) whether every atom's force is below the EDIFFG criterion is practiced in Chapter 03.

The Habit of Saving stdout to a File

VASP leaves a voluminous log in OUTCAR, but runtime errors sometimes appear only on stdout/stderr — MPI abort messages, library errors, out-of-memory, and some numerical diagnostics are the typical cases. If you discard stdout when running, you will not be able to tell why a calculation stopped, so always redirect it to a file.

mpirun -np 4 vasp_std > vasp.out 2>&1

For the meaning of 2>&1 (merging stderr), see Linux and Terminal Basics. In batch scheduler environments the scheduler captures stdout into a job log file, but you should confirm where that file is created.

VASP's Role in This Tutorial

To summarize, VASP appears in two scenes in this tutorial.

1. Finalizing structures — the carbon chain relaxation is performed with VASP, and the resulting structure is cross-validated against SIESTA (Chapter 03).
2. Hybrid functional reference — it provides the reference electronic structure when correcting DFT level errors (Chapter 11).

The transport calculations themselves require localized orbitals, so SIESTA/TranSIESTA handles them. Keeping this division of labor in mind makes the workflows of the later chapters read naturally.