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
Engine ADF Basis Type TZP End XC GGA PBE End EndEngine
One should keep the following points in mind when using ADF as an AMS engine in the 2019 release:
- 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
Geometryblock 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:
- 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
Symmetry NOSYM, which depending on the system geometry might result in another performance penalty.
- 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 behaviour can be changed with the
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, e.g. multidimensional PES scans.