Getting started · ORCA User Guide

On this page

What is ORCA?
Install check
First run — single point on H₂O
Output and scratch files
Running in parallel
Setting memory

What is ORCA?

ORCA is a general-purpose quantum chemistry package developed at the Max-Planck-Institut für Kohlenforschung, particularly strong in transition-metal chemistry and spectroscopy (CASSCF, NEVPT2, DLPNO-CCSD(T), …) and free for academic use. For the program's background, downloads, and the full manual, see the official forum. This guide pulls just the parts of that manual you reach for most often and lays them out for practical use.

Install check

ORCA is downloaded from the official forum (orcaforum.kofo.mpg.de) after registering an academic account. Linux, macOS, and Windows binaries are provided. Every example in this guide runs on 5.0.2, 5.0.4, and 6.0.0.

The first thing to check after installation is whether the orca executable is on your PATH. In a terminal:

# locate the binary
which orca

Absolute path is required for parallel runs

For parallel calculations ORCA needs the absolute path of its binary on PATH. Look it up with which orca and add it explicitly, e.g. export PATH=/path/to/orca:$PATH. Relative paths or shell aliases cause OpenMPI to fail to locate the parallel executable. While you are at it, set LD_LIBRARY_PATH for the OpenMPI shared libraries as well.

First run — single point on H₂O

An ORCA input file is plain ASCII, and the conventional extension is .inp. The example below takes the single-point energy of one water molecule at the B3LYP / def2-SVP level.

# my_first.inp — single-point energy of water
! B3LYP def2-SVP

* xyz 0 1
  O   0.000000   0.000000   0.119262
  H   0.000000   0.763239  -0.477047
  H   0.000000  -0.763239  -0.477047
*

What each line does, in short — the full syntax comes in 02 · Input file structure:

Lines starting with ! are the keyword line; this one sets the method (B3LYP) and the basis set (def2-SVP).
Lines surrounded by * form the coordinate block; xyz requests Cartesian coordinates and 0 1 means total charge 0 and multiplicity 1 (closed shell).
Lines starting with # are treated as comments.

Run it as:

# Linux / macOS
orca my_first.inp > my_first.out

# Windows (Command Prompt)
orca my_first.inp > my_first.out

Always redirect the output

ORCA writes all results to standard output. You must redirect with > output_file; otherwise the result scrolls past on screen and is lost.

A successful run ends with a message like this near the bottom of the output file:

FINAL SINGLE POINT ENERGY       -76.321274411145

                            ****ORCA TERMINATED NORMALLY****

The number on the FINAL SINGLE POINT ENERGY line is the energy in Hartree. Seeing that message means the run reached the end — nothing more.

"Terminated normally" ≠ result is trustworthy

As the manual emphasises, an ORCA TERMINATED NORMALLY message does not guarantee a meaningful result. For example, a geometry optimisation that hits its maximum number of iterations without converging will also print this message. Whether the job actually did what you wanted always has to be confirmed by reading the rest of the output file.

Output and scratch files

Running ORCA produces a handful of additional files in the same directory as the input. The most important ones are:

File	Description
`basename.out`	The standard-output file. The main human-readable result.
`basename.gbw`	Binary molecular-orbital file (Geometry-Basis-Wavefunction). Used as input for restarts or follow-up calculations.
`basename.xyz`	Cartesian coordinates of the optimised geometry.
`basename_trj.xyz`	Trajectory of all intermediate geometries from the optimisation.
`basename.engrad`	Text file with energy and gradient.
`basename.hess`	Hessian file generated during a frequency calculation.
`basename.property.txt`	Various molecular properties (dipole, polarisability, …).
`basename.*.tmp`	Scratch files; cleaned automatically on a normal termination.

Cleanup after an abnormal termination

If ORCA does not terminate normally, the .tmp files are left behind. Best to remove them before the next run:

rm basename*.tmp     # Linux / macOS
del basename*.tmp    # Windows

Running in parallel

ORCA uses OpenMPI (Linux / macOS) or MS-MPI (Windows) for parallel calculations. The number of processes can be set in two ways:

# Option 1: simple keyword (PAL2 – PAL64 are supported)
! B3LYP def2-SVP PAL8

# Option 2: %pal block (any positive integer)
%pal
   nprocs 12
end

The manual's practical guidance is roughly:

RI-DFT: scales well up to ~16 cores; overhead dominates beyond that.
Hybrid DFT, HF: usable up to 16–24 cores.
Coupled cluster: typically 8–16 cores.
Numerical derivatives (NumFreq, NumGrad): many independent displacements, so many cores can be used effectively — up to roughly 6 × atoms × (4–8).

ORCA 6 adds another layer: parallelism can be split across displacements. For example, 32 total processes can be arranged as "4 processes × 8 groups" to handle eight displacements simultaneously:

%pal
   nprocs       32  # total processes
   nprocs_group  4  # processes per displacement
end

Setting memory

Correlated modules (MP2, CCSD, MRCI, …) need large scratch arrays. Memory per core is set with %maxcore, in megabytes:

# 4 GB per core (total usage ≈ nprocs × maxcore)
%maxcore 4000

Out-of-memory errors

If an SCF aborts with a message like "Please increase MaxCore", raise %maxcore within the limits of your physical memory. The value refers only to the main working buffer; total ORCA memory use is somewhat larger. A safe practice is to budget 60–70 % of the available RAM. For a 64 GB machine running 8 cores in parallel, starting at %maxcore 5000 is reasonable.

Once a first run goes through cleanly you are halfway there. What is left is writing input files the way you want — which is exactly what the next chapter is for.