2.1. General Structure of the Input File

In general, the input file is a free format ASCII file and can contain:

  • one or more “simple” keyword lines that start with a “!” character,

  • one or more input blocks enclosed between an “%” sign and “end” that provide finer control over specific aspects of the calculation,

  • the specification of the coordinates, total charge, and spin multiplicity for the system, either with a %coords block, or more usually enclosed within two “*” symbols.

Here is an example of a simple input file that contains all three input elements:

! HF def2-TZVP

%scf
   convergence tight
end

* xyz 0 1
C  0.0  0.0  0.0
O  0.0  0.0  1.13
*

Comments in the file start by a “#”. For example:

# This is a comment. Continues until the end of the line

Comments can also be closed by a second “#”, as the example below where TolE and TolMaxP are two variables that can be user specified:

TolE=1e-5;    #Energy conv.#  TolMaxP=1e-6; #Density conv.#

The input may contain several blocks, which consist of logically related data that can be user controlled. The program tries to choose sensible default values for all of these variables. However, it is impossible to give defaults that are equally sensible for all systems. In general the defaults are slightly on the conservative side and more aggressive cutoffs etc. can be chosen by the user and may help to speed things up for actual systems or give higher accuracy if desired.

Note

  • The ORCA input is NOT case sensitive. UPPER CASE, lower case, or aNy cOMmBINAtiON are allowed. An exception is file names (e.g. for %MOInp or *XYZName), which are case-sensitive on Unix-like OSs.

  • In general, the order of the simple keywords and input blocks is not important – see Input Priority and Processing Order for the finer details.

2.1.1. Input Blocks

Input blocks start with “%”, followed by the block name and end with “end”. For example:

%method  
  method HF
END

A list of available input blocks is given in Section 2.1.6. No blocks need to be present in an input file but they can be present if detailed control over the behavior of the program is desired. Otherwise, most jobs can be defined via the simple keywords described in Section 2.1.7. Variable assignments within blocks have the following general structure:

VariableName Value
# or with an optional "=" sign
OtherVariableName = OtherValue

Values can be either numeric, quote-delimited strings (see below), or predefined aliases (such as HF in the example above), which are internally converted to some numeric representation.

Some variables are actually arrays. In this case several possible assignments are useful:

Array[1]  Value1
Array[1]  Value1,Value2,Value3
Array  Value1,Value2

Note

Arrays always start with index 0 in ORCA (this is because ORCA is a C++ program). The first line in the example gives the value “Value1” to Array[1], which is the second member of this array. The second line assigns Value1 to Array[1], Value2 to Array[2] and Value3 to Array[3]. The third line assigns Value1 to Array[0] and Value2 to Array[1].

Strings (such as filenames) must be enclosed in quotes. For example:

%scf
  MOInp  "Myfile.gbw"
end

Note that file names on Unix-like systems are case-sensitive (i.e., MYFILE.GBW and MyFile.gbw are different files). Under Windows the file names are not case sensitive.

Some input block keywords either open a nested sub-block, which must be closed with an additional end, or have a specific syntax, different from the simple variable assignment described above. For example:

%scf
  Guess PModel  # variable assignment
  SOSCF  # nested sub-block
    start 0.002  # variable assignment
  end  # closes the SOSCF sub-block
end
%mdci
  # special syntax
  MP2FragInter {1 1} {2 2}  
end
%basis
  NewGTO  # nested sub-block
    # special syntax inside
    H "def2-SVP"
    S 1
    1 0.05 1.0
  end  # closes the NewGTO sub-block
end

Finally, there are input “blocks” which only set a single variable and are not closed with “end”. These are listed in Table 2.2. For example:

%MOInp "MyFile.gbw"
%maxcore 3000

2.1.2. Input Priority and Processing Order

In more complicated calculations, the input can get quite involved. Therefore it is worth knowing how it is internally processed by the program:

  • First, all the simple input lines (starting with “!”) are collected into a single string.

  • The program looks for all known keywords in a predefined order, regardless of the order in the input file.

  • An exception are basis sets: if two different orbital basis sets (e.g. ! def2-SVP def2-TZVP) are given, the latter takes priority. The same applies to auxiliary basis sets of the same type (e.g. ! def2/J SARC/J).

  • Some simple input keywords set multiple internal variables. Therefore, it is possible for one keyword to overwrite an option, set by another keyword. We have tried to resolve most such cases in a reasonable way (e.g. the more “specific” keyword should take precedence over a more “general” one) but it is difficult to foresee every combination of options.

  • Next, the block input is parsed in the order it is given in the input file.

  • Most block input keywords control a single variable (although there are exceptions). If a keyword is duplicated, the latter value is used.

  • In principle, the same block may exist multiple times with different variables set within. However, some blocks “reset” certain internal data whenever they are opened, or have certain mandatory contents, which must be present in each block instance (and override previous instances). Therefore, it is not recommended to have multiple instances of the same block.

Consider the following (bad) example:

! def2-TZVP UKS
%method
  functional BP86
  correlation C_LYP
  SpecialGridAtoms[1]  26, 27
  SpecialGridIntacc 8,  8,  8
  SpecialGridAtoms 28, 29
end
! PBE def2-SVP RKS

Using the rules above, one can figure out why it is equivalent to this one:

! UKS BLYP def2-SVP
%method
  SpecialGridAtoms 28, 29, 27
  SpecialGridIntacc 8,  8,  8
end

2.1.3. Global Memory Use

Some ORCA modules (in particular those that perform some kind of wavefunction based correlation calculations) require large scratch arrays. Each module has an independent variable to control the size of these dominant scratch arrays. However, since these modules are never running simultaneously, we provide a global variable MaxCore that assigns a certain amount of scratch memory to all of these modules. Thus:

%MaxCore 2000

sets 2000 MB as the limit for these scratch arrays. This limit applies per processing core. Do not be surprised if the program takes more than that – this size only refers to the dominant work areas. Thus, you are well advised to provide a number that is no more than 75-80% of your physical memory. Some memory-hungry operations will take longer if given less than the required memory, while others will abort completely if MaxCore is insufficient. The default value is 4GB, which is plenty for most standard DFT calculations. For coupled clusters and the like, at least 8GB are recommended.

2.1.4. Changing the Default BaseName

ORCA generates a number of output files, as well as many temporary files, which are removed at the end of a successful run. To prevent filename clashes, all generated files start with the same prefix or BaseName. This is usually inferred from the name of the input file by removing the extension, i.e. running ORCA with MyJob.inp will create MyJob.gbw, MyJob.properties.txt, etc. It is also possible to set the BaseName explicitly using the %base variable. In the following example, the names of all generated files will start with job1, regardless of the name of the input file:

%base "job1"

2.1.5. Jobs with Multiple Steps

Warning

The $new_job feature is a deprecated function. Using $new_job might result in erratic results and strange behavior of succeeding calculations. Please use the compound feature of ORCA for tasks like this – it is safer and by far more powerful!

ORCA supports input files with multiple jobs. This feature is designed to simplify series of closely related calculations on the same molecule or calculations on different molecules. The objectives for implementing this feature include:

  • Calculate of a molecular property using different theoretical methods and/or basis sets for one molecule.

  • Calculations on a series of molecules with identical settings.

  • Geometry optimization followed by more accurate single points and perhaps property calculations.

  • Crude calculations to provide good starting orbitals that may then be used for subsequent calculations with larger basis sets.

For example consider the following job that in the first step computes the g-tensor of BO at the LDA level, and in the second step using the BP86 functional.

# -----------------------------------------------------
! LSD DEF2-SVP TightSCF KeepInts
# -----------------------------------------------------
%eprnmr gtensor 1 end

* int 0 2
   B  0  0  0   0      0  0
   O  1  0  0   1.2049 0  0
*

# *************************************************
# ****** This starts the input for the next job   *
# *************************************************
$new_job
# --------------------------------------------------
! BP86 DEF2-SVP SmallPrint ReadInts NoKeepInts
# --------------------------------------------------
%eprnmr gtensor 1 end

* int 0 2
   B  0  0  0   0      0  0
   O  1  0  0   1.2049 0  0
*

What happens if you use the $new_job feature is that all calculation flags for the actual job are transferred from the previous job and that only the changes in the settings must be input by the user. Thus if you turn on some flags for one calculation that you do not want for the next, you have to turn them off again yourself (for example the use of the RI approximation)! In addition, the default is that the new job takes the orbitals from the old job as input. If you do not want this you have to overwrite this default by specifying your desired guess explicitly.

2.1.6. List of Input Blocks

Table 2.1 lists the known input block names, along with any accepted synonyms/aliases. The keywords defined in each block are listed in the respective section of the manual and references to these lists are also given in the table. The list of “blocks” which are not closed with end is given in Table 2.2.

Table 2.1 Input block keywords. Synonyms are given in parentheses.

Block

Description (Keyword Reference)

autoci

Autogenerated single- and multi-reference correlation methods (Section 3.12.9)

basis

Basis sets (Table 2.41)

casresp

CASSCF static linear response (Section 5.26.6)

casscf

CASSCF/NEVPT2 and DMRG calculations (Section 3.14.4)

chelpg

CHELPG charges (Section 5.1.8.1)

cim

Cluster-in-molecules calculations (Section 3.11.9)

cis (tddft)

CIS and TD-DFT calculations (Section 5.6.19)

compound

Compound jobs (Section 8.2)

conical

Optimization of conical intersections (Section 4.9)

coords

Input of atomic coordinates (Section 2.2)

cosmors

OpenCOSMO-RS options (Section 2.13.6.2)

cpcm

Conductor-like Polarizable Continuum Model (Section 2.13.8)

docker

Host-guest docking algorithm (Table 4.11)

eda

(Table 5.28)

elprop

Electric properties (Section 5.20.2)

eprnmr

EPR and NMR properties (Section 5.21.9; g-tensor: Table 5.13, HFC: Table 5.14, ZFS: Table 5.16, Mössbauer: Table 5.18)

esd

Excited state dynamics (Section 5.5.12)

frag

Automatic fragmentation procedure (Table 2.62)

freq

Vibrational frequencies (Section 4.7.4)

geom

Geometry optimization (Table 4.3; Scan: Table 4.4, TS: Table 4.5)

goat

Global optimization algorithm (Table 4.8)

ice (iceci,cipsi)

Iterative configuration expansion CI calculations (Section 3.15.11)

irc

Intrinsic reaction coordinate calculations (Section 4.4.2)

lft

Ligand field theory utility orca_lft (Section 9.2.15)

loc

Localization of orbitals (Section 9.2.5)

mcrpa

CASSCF linear response (Section 5.8.6)

md

Molecular dynamics (Table 7.1)

mdci

Single reference correlation methods (Section 3.11.14; RHF EOM-CC: Table 5.11, UHF EOM-CC: Table 5.12, STEOM-CC: Section 5.10.1, MR-EOM-CC: Section 3.21.4, LED: Section 5.38.7, ADLD/ADEX: Section 5.38.8.3, HFLD: Table 5.37)

mecp

Minimum energy crossing points optimization (Section 4.10.1)

method

Choice of computation method and various options

mm

Molecular mechanics force-fields (Section 3.24.5)

mp2

MP2 calculations (Section 3.10.1; DLPNO: Section 3.10.10, DLPNO/gradient: Section 3.10.11, DLPNO/response: Section 3.10.11.1, DLPNO/multi-level: Section 3.10.11.3, OO-RI-MP2: Section 3.10.14.2, regularized: Section 3.10.15)

mrcc

Multi-reference CC calculations (Section 3.13)

mrci

Multi-reference CI calculations (Section 3.20.15)

mtr

Normal mode trajectory/scan (Section 5.6.17.1)

nbo

NBO analysis (Section 5.2)

ndoparas

Parameters for NDO-based semi-empirical methods (Table 3.21)

neb

NEB calculations (Section 4.6.14)

numgrad

Numerical gradients (Section 2.23.2)

output

Control of output (Table 2.6)

pal

Parallel jobs (Section 2.5)

paras

Input of geometric parameters, equivalent to paras or pardef in %coords (Section 2.2.4)

plots

Plot generation (Section 9.1)

qmmm

Multiscale (QM/MM) calculations (Section 6.1)

rel

Relativistic options (Table 2.55; SOC: Section 5.28)

rocis

Restricted-open-shell CIS (Section 5.7.7)

rr

Resonance Raman and absorption/fluorescence band-shape calculations via orca_asa (Section 5.16.4)

scf

SCF procedure settings (Section 2.6; TRAH-SCF: Section 2.6.7.4, AVAS: Section 3.14.7, ROHF: Section 3.1.1, native xTB: Table 3.29, \(\Delta\)SCF: Table 5.27, initial guess: Section 2.20, rotate MOs: Section 2.20.7 )

shark

SHARK integral package (Section 2.15.6)

solvator

Explicit solvation algorithm (Table 4.9)

symmetry (sym)

Spatial symmetry recognition (Table 2.67)

vpt2

Vibrational perturbation theory (Section 5.19)

xtb

Options for the xtb program interface (Table 3.26)
Table 2.2 Input keywords, which are prefixed with % but have no closing end.

Keyword

Value

Description (Reference)

base

"<BaseName>"

Base name for the files created by the job (Section 2.1.4)

cclib

"<FileName>"

File with one-particle coupling coefficients for ICE-CI (Section 3.15.12)

id

"<string>"

Deprecated! Identifier for the job used to summarize computed energies (Section 2.11.1)

ljcoefficients

"<FileName>"

File with Lennard–Jones coefficients for PHVA (Section 4.3.5)

maxcore

4096

Maximum heap memory to use in MB, default: 4GB (Section 2.1.3)

moinp

"<FileName>"

GBW file from which to read guess MOs for the MORead guess (Section 2.20.5)

pointcharges

"<FileName>"

File to read external point charges from (Section 2.2.6)

2.1.7. Simple Keyword Lines

It is possible to give a line of keywords that assign certain variables that normally belong to different input blocks. The syntax for this “simple input” is line-oriented. A keyword line starts with the “!” sign and can contain any number of space-separated keywords. The input file can contain any number of keyword lines and they do not need to be at the beginning (although that is common practice) – see also Input Priority and Processing Order.

! Keyword1 Keyword2
! Keyword3

Most simple input keywords are documented in the relevant section of the manual. Table 2.3 provides references to these sections, grouped by topic. Since simple keywords are usually related to variables within one or more input blocks, it is also instructive to consult the documentation for the respective block – see Table 2.1.

Table 2.3 References to the documentation of simple input keywords. Related input blocks are also listed.

Keyword Group

Reference

Input block

Run types and method classes

Table 2.4

method

Basis sets

Table 2.40

basis

DFT functionals

method

Dispersion corrections

Table 3.13

method

Composite (3c) methods

Table 3.32

NDO-based semi-empirical methods

Table 3.27

method

Native xTB-based methods

Table 3.22

method

Second order Møller–Plesset perturbation theory

Table 3.34

mp2

Single-reference correlated methods via MDCI

Table 3.43

mdci

Correlated methods using automatic code generation (AUTOCI)

Section 3.12.2

autoci

CASSCF

Table 3.46

casscf

Multireference correlated methods via MRCI

Table 3.51

mrci

Excited states via correlated wavefunction-based methods

mdci

Initial guess

Table 2.68

scf

SCF procedure

Table 2.11

scf

Integral approximations (RI/COSX)

Table 2.44

method

Relativistic methods

Table 2.54

rel

Implicit solvation (CPCM)

Table 2.56

cpcm

Spin-orbit coupling operator

Table 5.19

rel

Numerical integration grids

Table 2.48

method

Integral storage and handling

Table 2.58

scf

Population analysis

Table 5.1

output

Output control

Table 2.8

output

Nudged elastic band method

Section 4.6.14

neb