ADF as an AMS engine

With the 2018 release of the Amsterdam Modeling Suite, we have started to turn what used to be separate programs (e.g. DFTB and BAND) into libraries used by the new AMS driver program. In this more modular setup these libaries, which we refer to as engines, calculate energies and gradients, while the AMS driver steers the calculation over the potential energy surface, in e.g. a geometry optimization or molecular dynamics calculation. A good introduction to this new setup can be found in the beginning of the new AMS manual.

We also plan to convert ADF into an AMS engine, which means that ADF will cease to exist as a separate program and will instead be used through the AMS driver. In the 2019 release this has not yet happened and ADF is still the standalone program that it has always been. Nevertheless, the AMS driver already has a few features that the standalone ADF program is missing, e.g. a PES scan task, which is basically the multidimensional generalization of a linear transit calculation. In order to make this functionality also available for ADF, there is an ADF engine in the AMS driver, which simply wraps the standalone ADF program and thereby makes it usable through AMS. In this way the AMS driver can run the ADF program under the hood to calculate energy and gradients, as if it was a library.

It is relatively straightforward to run AMS with the ADF engine. Basically one just makes an Engine ADF block that contains the normal ADF keywords as they are documented in this manual. In order to perform a calculation with ADF running as an AMS engine, using a TZP basis and the PBE exchange-correlation functional, we would, for example, put the following engine block into the AMS input:

Engine ADF
      Type TZP
      GGA PBE

One should keep the following points in mind when using ADF as an AMS engine in the 2019 release:

  1. One should only use keywords that are relevant for an ADF single point calculation. It obviously does not make sense to have ADF perform a geometry optimization, when the AMS driver just wants to pick up the energy and gradients for a specific geometry. There are some checks for this in AMS, e.g. it will not let users put the Geometry block in the ADF engine input, but probably not all of these cases are checked automatically, so users should be extra careful and keep the ADF engine input to a minimum. The following keywords should definitely not be put into the ADF engine input:
    • Geometry
    • AnalyticalFreq
    • Fragments
    • Symmetry
    • Title
  2. The overhead of running ADF through AMS is relatively large. Furthermore ADF is not restarted from step to step when running through AMS, i.e. it’s SCF cycle will always start from scratch, even if the geometry barely from the last step, e.g. during the last steps a geometry optimization. It is also run with Symmetry NOSYM, which depending on the system geometry might result in another performance penalty.
  3. The AMS driver has the be run in serial (e.g. with NSCM=1) when using ADF as an engine. This is necessary because not all MPI implementations support nested MPI runs, and it is generally more useful to have the AMS driver run serially and then run ADF in parallel using MPI. By default the spawned ADF process will use all available (physical) cores, but this behavior can be changed with the NSCM_AMSEXTERNAL environment variable.

As of the 2019 release of AMS, we recommend using the ADF engine only for tasks which are not supported by the standalone ADF program. Some examples:

For some tasks we do not recommend the internal ADF implementation, instead we recommend using the AMS implementation: