Structure of the Input¶
Much of the general remarks about input for ADF apply also to related property and analysis programs, which are also described in this document.
Units of length and angle¶
Geometric lengths and angles are in units defined by:
UNITS
length Angstrom / Bohr
angle Degree / Radian
End
Angstrom and Bohr, respectively Degree and Radian, are recognized strings. Each of the subkeys is optional, as is the key UNITS itself. Defaults: Angstrom for lengths, and Degree for angles.
Including an external file¶
You can include an external ASCII file in the input with the INLINE
key:
INLINE FileName
The file name should include the path, either absolute or relative to the run-directory.
The content of the file FileName
is included in the input at the point where the INLINE
key occurs (the INLINE
key may occur any number of times in the input).
The INLINE
feature makes it easy to pack your preferred settings in one file and use them in every run with minimum input-typing effort, or can be used to include files containing the atomic coordinates.
Title, comment¶
TITLE Title
Title may be any string. The program combines it (that is, the first approximately 50 characters) with date and time of the job to construct the* job identification.* The job identification is used to stamp an identification on result files, which will be read and printed if such a file is used again, for instance as a fragment file.
The job identification will also be echoed in the output header to identify the current run. By default the date and time are combined with a dummy string. In Create mode the title is first read from the data file that supplies the basis functions etc and can then be overwritten via input.
Note that, contrary to some other programs, ADF does not take the first input record as a title.
You can put more remarks in the input file to be echoed in the standard output file; these will not become part of the job identification:
COMMENT
text
...
end
The text records are copied to the output header, directly after the job identification.
The key COMMENT may occur any number of times; all text blocks are printed in the output header with a blank line between any two text blocks.
General remarks on input structure and parsing¶
Most keys are optionals. Defaults values will be used for keys that are not specified in the input
Keys/blocks can either be unique (i.e. they can appear in the input only once) or non-unique. (i.e. they can appear multiple times in the input)
The order in which keys or blocks are specified in the input does not matter. Possible exceptions to this rule are a) the content of non-standard blocks b) some non-unique keys/blocks)
Comments in the input file start with one of the following characters:
#
,!
,::
:# this is a comment ! this is also a comment :: yet another comment
Empty lines are ignored
The input parsing is case insensitive (except for string values):
# this: UseSymmetry false # is equivalent to this: USESYMMETRY FALSE
Indentation does not matter and multiple spaces are treaded as a single space (except for string values):
# this: UseSymmetry false # is equivalent to this: UseSymmetry false
Keys¶
Key-value pairs have the following structure:
KeyName Value
Possible types of keys:
- bool key
The value is a single Boolean (logical) value. The value can be
True
(equivalentlyYes
) orFalse
(equivalentlyNo
.). Not specifying any value is equivalent to specifyingTrue
. Example:KeyName Yes
- integer key
The value is a single integer number. Example:
KeyName 3
- float key
The value is a single float number. For scientific notation, the E-notation is used (e.g. \(-2.5 \times 10^{-3}\) can be expressed as
-2.5E-3
). The decimal separator should be a dot (.
), and not a comma (,
). Example:KeyName -2.5E-3
- string key
The value is a string, which can include white spaces. Only ASCII characters are allowed. Example:
KeyName Lorem ipsum dolor sit amet
- multiple_choice key
The value should be a single word among the list options for that key (the options are listed in the documentation of the key). Example:
KeyName SomeOption
- integer_list key
The value is list of integer numbers. Example:
KeyName 1 6 0 9 -10
- float_list key
The value is list of float numbers. The convention for float numbers is the same as for Float keys. Example:
KeywordName 0.1 1.0E-2 1.3
Blocks¶
Blocks give a hierarchical structure to the input, grouping together related keys (and possibly sub-blocks). In the input, blocks generally span multiple lines, and have the following structure:
BlockName
KeyName1 value1
KeyName2 value2
...
End
Headers
For some blocks it is possible (or necessary) to specify a header next to the block name:
BlockName someHeader
KeyName1 value1
KeyName2 value2
...
End
Compact notation
It is possible to specify multiple key-value pairs of a block on a single line using the following notation:
# This:
BlockName KeyName1=value1 KeyName2=value2
# is equivalent to this:
BlockName
KeyName1 value1
KeyName2 value2
End
Notes on compact notation:
The compact notation cannot be used for blocks with headers.
Spaces (blanks) between the key, the equal sign and the value are ignored. However, if a value itself needs to contain spaces (e.g. because it is a list, or a number followed by a unit), the entire value must be put in either single or double quotes:
# This is OK: BlockName Key1=value Key2 = "5.6 [eV]" Key3='5 7 3 2' # ... and equivalent to: BlockName Key1 value Key2 5.6 [eV] Key3 5 7 3 2 End # This is NOT OK: BlockName Key1=value Key2 = 5.6 [eV] Key3=5 7 3 2
Non-standard Blocks
A special type of block is the non-standard block. These blocks are used for parts of the input that do not follow the usual key-value paradigm.
A notable example of a non-standard block is the Atoms
block (in which the atomic coordinates and atom types are defined).
Input parsing changes in ADF2018¶
The input file parsing for ADF and its properties programs has changed from the 2017 to the 2018 version.
New syntax for a few keywords¶
In order to adapt ADF to the new (more strict) input format, the syntax of a few keywords had to be changed. The following table contains the list of keywords that have changed in ADF2018. Note that the block key DEFINE was removed.
key in ADF2017 and before | key in ADF2018 and later / comments |
---|---|
CorePotentials | CorePotentials is now a block (and not an general key/block) |
Define | removed |
Dependency | Dependency is now a block (and not a key) |
EField | Split into EField and PointCharges |
ETSNOCV | ETSNOCV is now a block (and not a key) |
Excitations -> Davidson | Excitations -> Davidson is now a block (and not a key) |
Excitations -> Exact | Excitations -> Exact is now a block (and not a key) |
Geometry -> Converge Value | Geometry -> Converge -> Grad Value |
Geometry -> Frequencies | Geometry -> Frequencies is now a block (and not a key) |
Geometry -> TransitionState | Geometry -> TransitionState is now a block (and not a key) |
Integration Value | Integration -> Accint Value |
LinearScaling | LinearScaling is now a block (and not an general key/block) |
ModifyStartPotential | ModifyStartPotential is now a block (and not an general key/block) |
Occupations | Split into Occupations and IrrepOccupations |
Restart -> Value | Restart -> File -> Value |
Response -> Units | Removed optional units for FrqBeg and FrqEnd in Response block |
SCF -> ADIIS | SCF -> ADIIS is now a block (and not a key) |
SCF -> ARH | SCF -> ARH is now a block (and not a key) |
SCF -> DIIS | SCF -> DIIS is now a block (and not a key) |
SlaterDeterminants | SlaterDeterminants is now a block (and not an general key/block) |
SOPert | SOPert is now a block (and not a key) |
Thermo -> T | Split into Thermo -> TMin and TMax |
Strict parsing of input file¶
In ADF2018 and later exact keyword matching is used, meaning that keywords abbreviations (or extensions) are not allowed. In ADF2017 (and previous versions) the parsing of the input file was tolerant and it would allow for abbreviations and extension of keywords.
In the example below, only the first version is allowed in ADF2018 and later, while the second and third version will trigger an input syntax error:
# This is the proper input syntax:
SCF
Converge 1.0E-7
End
# In ADF2017 you could (for some keywords) use abbreviations. e.g.:
SCF
Conv 1.0E-7
End
# or extensions. e.g.:
SCF
Convergence 1.0E-7
End
# Keywords abbreviations and extensions are NOT ALLOWED in ADF2018 and later.