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 fragment file, etc.

TAPE13 is upgraded 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 2 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 than 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 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.