ADF Restart files
*****************

When an ADF calculation terminates abnormally - not controlled by the
program itself, for instance after a core dump due to some bug - there
will usually be a file TAPE13, which serves as a checkpoint file.
TAPE13 can be used to restart the calculation at a point not too far
before the fatal condition occurred. It contains only data for the
restart, but none of the special analysis data on adf.rkf that would
be useful for analysis, to serve as a fragment file, etc.

TAPE13 is updated during the calculation but discarded upon normal
termination, namely when all relevant information has been saved on
adf.rkf. At that point all info that would have been on TAPE13 is
present on adf.rkf. If you wish to keep TAPE13 anyway - for instance
because you plan a restart after normal termination and don't intend
to keep the substantially bigger adf.rkf - you must use the SAVE key.

Upon normal (i.e. program-controlled) termination of a calculation,
the adf.rkf result file can be used for restart purposes. When a crash
occurs, however, chances are that adf.rkf has not correctly been
closed and that its data structure is inconsistent: during the
calculation large portions of adf.rkf are kept in memory rather than
on file, and only at the point of final termination, all data is
flushed to file.

During a running optimization the system's geometry is written out to
the AMS driver's output file "ams.rkf" after every step.

**General remarks**

ADF restart files (adf.rkf or TAPE13) should be included using the key
EngineRestart in the AMS part of the input. Other important keys in
case of restarts in the AMS part of the input are LoadEngine (adf.rkf
or TAPE13) and LoadSystem (ams.rkf). See the section on restarting a
geometry optimization in the AMS manual on how to restart a (crashed)
geometry optimization. Also for other tasks related to exploring the
PES, for example, a Linear Transit, Transition State, IRC or IR
Frequencies run, one should look in the AMS manual.

If one uses the key "LoadSystem" (ams.rkf) one should not include the
System block in the AMS part of the input, otherwise one would have
two systems. However, if one does not include the key "LoadSystem" one
has to include the System block in the AMS part of the input.
Depending on the type of restart the coordinates in the System block
may be different from those on the restart file. Obviously, if the
system on the restart file is not the same as defined in the System
block they cannot be completely unrelated. To let the restart data
make sense the runs should correspond to the same molecule (i.e. its
general definition in terms of fragment building blocks). The program
does not check all aspects related to this and certain abuses will
therefore survive the internal tests, but will surely lead to some
error later on: it is the user's responsibility to ensure that the
restart data match the calculation one has in mind.

If one uses the key "LoadEngine" one should not include the Engine ADF
block in the AMS part of the input. If one does not include the key
"LoadEngine" one has to include the Engine ADF block in the AMS part
of the input, which can be useful if one wants or has to change ADF
settings, for example SCF convergence settings. Note that in this case
all ADF engine settings, (like fragments, basis set, XC) must be
included, also those that did not change with respect to the restart
file, ADF will not read these settings from the restart file. Again:
it is the user's responsibility to ensure that the restart data match
the calculation one has in mind.

A restart file supplies data from a previous run that might be useful
in the current one. The applications are (combinations are possible):

* Get a better start in the (first) SCF procedure by providing the
  electronic charge density (in the form of fit coefficients or
  density matrix) from the preceding run (preferably adf.rkf)

* Continue an optimization by supplying the latest geometry
  (coordinates) from a previous run via the restart file (ams.rkf)
  using "LoadSystem" (rather than typing them in)

**WARNING:** The SCF and optimization procedures use *history* to
improve convergence behavior. Most of such history information is not
stored on a restart file. As a consequence, a restart may not continue
exactly as the original run would have done if it hadn't terminated.
In a SCF restart, for instance, the DIIS procedure has to rebuild the
information. The same holds for geometry optimizations, although
history plays usually not a very big role there.
