# Structure of the restart file¶

All data that may be retrieved from the restart file must be stored in a specific location on the restart file. If you’re simply using a TAPE21 result file or a TAPE13 checkpoint file you don’t need to bother about this: ADF has put all data in the right place; the following discussion is primarily for those who want to manipulate the restart file or even construct one themselves.

Since the restart file must be a kf file, the location of the data is of the form Section%Variable, specifying the section and the variable name. The section and variable names are case sensitive. See the utilities document for general information about kf files.

If the specified variable is not present in the specified section on the restart file - or if there is no such section at all - the data is not used, usually without an error message. In some cases a few global tests are carried out on the retrieved data; if they fail the tests the data are not used and a warning - in some cases an error abort - may be issued by the program.

KF files are binary files and so are the TAPE21 result file, the TAPE13 checkpoint file and generally any restart files. If you wish to edit and modify the contents, or just inspect them, the standard KF utilities can be used. Apply pkf to get a survey of the sections and variables on the file, dmpkf to get a complete ASCII version of the file and udmpkf to transform an ASCII version - presumably edited and modified - back into binary format. Please consult the Scripting Section for further information about the standard KF utilities.

**Data on the restart file**

Follows a survey of all data items that the program may search for on the restart file.

**SCF data**

`Fit%coef_SCF`

- The fit-expansion of the charge density to be used as start-up for the next SCF. Without these restart fit data the first SCF will start from the (fitted) sum-of-fragments charge density.
`Fit%coef_FreqCenter`

- Only in a Frequencies run: the fit-expansion of the SCF-converged equilibrium geometry. It usually helps to get a somewhat better start-up of the SCF in displaced geometries.

If the noSCF option is used to the restart key, any Fit%coef_? data on the restart file are ignored.

**Coordinates**

`Geometry%xyz`

- Cartesian atomic coordinates. The option nogeo suppresses using such data. In a Frequencies or continued Linear Transit run, they may be read but will be ignored (i.e. replaced by other coordinates data from the restart file, see below).

In most applications, when coordinates are read (and used) from the restart file, only *Cartesian* coordinates are retrieved and the corresponding Z-matrix values are computed from them, using the Z-matrix *structure* defined in the atoms data block. This is one of the reasons why the ATOMS key must be used even when the atomic coordinates are supplied on the restart file.

**Hessian**

`GeoOpt%Hessian_CART`

`GeoOpt%Hessian inverted_CART`

`GeoOpt%Hessian_ZMAT`

`GeoOpt%Hessian inverted_ZMAT`

- All these four varieties are searched for if the new run searches for a restart Hessian matrix at all, that is: in an optimization, Linear Transit or Transition State search. As the names should suggest these variables stand for the Hessian, respectively the inverse of the Hessian in Cartesian or z-matrix coordinates. In all cases the full square matrix must be present, with dimension the number of atomic coordinates, 3 times the number of atoms. This holds also for z-matrix coordinates. The 6 dummy coordinates play no role, the corresponding matrix elements in the Hessian should be zero. The order of atoms is the same as in the input.

If a Hessian is searched for on the restart file, all four possibilities above are tried and the first one found is used, the other ones being ignored. The order in which they are tried is:

If the current run uses *Cartesian* coordinates as optimization variables, then first the two cart varieties are tried, and vice versa for *z**-matrix* optimization.

In a minimization (simple optimization or Linear Transit) first the *inverted* variety is tried; in a Transition State search the normal (not inverted) Hessian is looked for first.

Note: If a z-matrix Hessian is retrieved from the restart file the program will use the underlying z-matrix *structure* to derive a Cartesian Hessian from it. In such case the restart file must also contain:

`GeoOpt%kmatrix`

- The z-matrix structure (references to the atoms in this matrix assume the ordering of atoms as used internally by the program).

Note: the kmatrix on the file need not be identical to the kmatrix used in the current calculation. In fact, the current calculation may not even have a z-matrix structure.

**Transition State**

In a continued TS run the program retrieves, apart from general geometry *optimization* data such as the Hessian - see above - only the latest TS search vector: the eigenvector of the (approximate) Hessian that points to the Transition State. All other TS-specific data are input-determined with corresponding defaults.

The TS search vector is stored in:

`TS%mode to follow`

- A list of atomic coordinates (Cartesian or Z-matrix, depending on the type of optimization variables used. The underlying list of atoms has the atoms not necessarily in the order in which they have been given in input: rather they are grouped together by atom type.

**Linear Transit**

In a continued Linear Transit (LT) calculation the continuation run proceeds from where the previous run stopped. The total number of points by which the transit is scanned, the current point (its index and the Cartesian coordinates), the accumulated results of completed points on the transit etc. are copied from the restart file. If the restart file contains a section LT, then all relevant data must be present on it and correct (i.e. matching those of the current run: same number of LT *parameters*, and of course the same molecule.

`LT%nr of points`

- The number of points by which the LT is scanned; this is identical to the Fortran variable ltimax in the code. The value on the restart file applies in the calculations and overwrites any input/default value (see the subkey
*lineartransit*of the geometry block) `lt%current point`

- Index of the current LT scan point. This is where the program will continue. In a non-restart LT run, this index initializes at 1.
`LT%Energies`

- An array with energy values, one for each LT point. When the LT run is completed, this array allows you to map out the energy along the LT path. The values for the completed LT points are stored on the restart file. This size of the array on the restart file must (at least) be the total number of points on the complete path.
`LT%Parameters`

- Initial and final values for the LT parameters, which describe roughly the path (all other coordinates may be optimized at each point, depending on other input keys). The values from the restart file overwrite input values. The input values should be supplied, however, as if it were a non-restart run.
`LT%atmcrd`

- zmat if a z-matrix structure is available for the molecule, cart otherwise. This is used to control printing of results. It does not define the type of optimization variables: see the next item.
`LT%geocrd`

- zmat or cart: the type of optimization variables. This defines in which type of coordinates the LT parameters are defined and any optimization of other coordinates takes place.
`LT%xyz`

- Cartesian coordinates for
*all*LT points: 3*atoms*ltpoints. The size of the array must conform to this. Only the values of the completed LT points*and*those of the current point are relevant. Those of the current LT point are used as initial coordinates to start the current run. `LT%zmatrix`

- Same for the Z-matrix coordinates. They should match the Cartesian coordinates for the completed LT points (this is not checked). Those for the current LT point will be recomputed from the current
*Cartesian*coordinates.

**IRC**

In a continued Intrinsic Reaction Coordinate (IRC) calculation, the continuation run processes the path(s) as specified in input. Any info for such path(s) on the restart file will then be used to continue from there. If the restart file contains the relevant IRC sections, see below, then all relevant data must be present on it and correct (i.e. matching those of the current run.

The sections on file pertaining to the IRC are:

IRC: this section contains information about the central (TS) point, which variables are optimized in each of the IRC points, the connection matrix defining the z-matrix structure, etc.

IRC_Forward and IRC_Backward: these sections contain the data of the two paths from the Transition State down to the two adjacent local energy minima: for each point the distance from the previous point and the local curvature and molecular properties such as energy, atomic charges and dipole moment.

`LT%nr of points`

- The number of points by which the LT is scanned; this is identical to the Fortran variable ltimax in the code. The value on the restart file applies in the calculations and overwrites any input/default value (see the subkey
*lineartransit*of the geometry block) `LT%current point`

- Index of the current LT scan point. This is where the program will continue. In a non-restart LT run, this index initializes at 1.
`lt%Energies`

- An array with energy values, one for each LT point. When the LT run is completed, this array allows you to map out the energy along the LT path. The values for the completed LT points are stored on the restart file. This size of the array on the restart file must (at least) be the total nr of points on the complete path.
`lt%Parameters`

- Initial and final values for the LT parameters, which describe roughly the path (all other coordinates may be optimized at each point, depending on other input keys). The values from the restart file overwrite input values. The input values should be supplied, however, as if it were a non-restart run.
`lt%atmcrd`

- zmat if a z-matrix structure is available for the molecule, cart otherwise. This is used to control printing of results. It does not define the type of optimization variables: see the next item.
`lt%geocrd`

- zmat or cart: the type of optimization variables. This defines in which type of coordinates the LT parameters are defined and any optimization of other coordinates takes place.
`lt%xyz`

- Cartesian coordinates for
*all*LT points: 3*atoms*ltpoints. The size of the array must conform to this. Only the values of the completed LT points*and*those of the current point are relevant. Those of the current LT point are used as initial coordinates to start the current run. `LT%zmatrix`

- Same for the Z-matrix coordinates. They should match the Cartesian coordinates for the completed LT points (this is not checked). Those for the current LT point will be recomputed from the current
*Cartesian*coordinates.

**Frequencies**

In the continuation of a Frequencies calculation all Frequencies-related data are retrieved from the section Freq on the restart file. (SCF fit data are, as always, retrieved from the section Fit). A fairly large number of items will be read and must all be present (*if* a section Freq is present in a restart file supplied to a Frequencies run). Technical parameters such as the type of numerical differentiation, size of displacements etc. are read from the restart file. Any input specifications are ignored.

`Freq%kountf`

- Counter of number of geometries completed. In a non-restart run this is initialized at zero; in a restart it is read from the file.
`Freq%nraman`

- Flag for RAMAN calculations
`Freq%numdif`

- 1 or 2: defines numerical differentiation used to compute the force constants from the gradients in slightly displaced geometries (by 1-point or 2-point differentiation).
`Freq%disrad`

- Size of displacement for Cartesian or bond-length displacements.
`Freq%disang`

- Size of angular (bond angle, dihedral angle) displacements.
`Freq%atmcrd`

- zmat or cart: specifies whether a z-matrix structure is present. This does not define the type of displacement coordinates, see the next item.
`Freq%geocrd`

- Type of coordinates in which the displacements are carried out: zmat or cart
`Freq%nfree`

- Number of free and independent displacement variables.
`Freq%idfree`

- References from the atomic coordinates (in internal order) to the independent displacement variables.
`Freq%all freedoms`

- (logical) flags whether or not the complete energy surface is scanned around the equilibrium or only part of the internal degrees of freedom are used.
`Freq%xyz`

- equilibrium coordinates (internal order of atoms).
`Freq%kmatrix`

- Z-matrix structure. Pointers are indexed by and refer to atoms in the internally used order.
`Freq%zmatrix`

- Z-matrix coordinates of the equilibrium geometry (internal ordering of atoms).
`Freq%rigids`

- 6 rigid motion vectors (one may be zero, in case of a linear molecule). Each vector has as many components as there are atomic coordinates. The values correspond to the internal ordering of atoms.
`Freq%xyz displaced`

- Cartesian coordinates of displaced geometry to carry out now. In a non-restart run this would be the equilibrium geometry.
`Freq%zmatrix displaced`

- Similar for the Z-matrix coordinates.
`Freq%Dipole previous`

- dipole vector (3 components) for the last geometry handled.
`Freq%Dipole`

- dipole at the equilibrium geometry.
`Freq%Dipole derivatives`

- Derivatives of the dipole wrt atomic coordinate displacements.
`Freq%Gradients previous`

- Energy gradients (derivatives wrt atomic coordinate displacements) in the last handled geometry.
`Freq%Force constants`

- Matrix of force constants. This is, together with the
*Dipole derivatives*the final quantity to compute. At each cycle of the Frequencies data are added to it. Upon completion of the Frequencies cycles the frequencies and normal modes are computed from it. Together with the dipole derivatives it then also yields the InfraRed intensities.