Evaluators¶

The ForceField engine can evaluate energies and forces with two different implementations, called evaluators. Both use the same force field parameters and describe the same physics, but they differ in performance and in which features they support:

The legacy evaluator is the original implementation. It supports every force field type and every option of the engine.
The OpenMM evaluator is based on the OpenMM molecular simulation library. It can run on GPUs, which makes it much faster for large systems, and it is planned to become the default.

You select the evaluator with the UseLegacyEvaluator keyword:

UseLegacyEvaluator Yes/No

UseLegacyEvaluator

Type:: Bool
Default value:: Yes
Description:: Use the legacy internal force field evaluator instead of OpenMM. Default Yes; will flip to No once OpenMM is the validated default. The OpenMM evaluator is experimental and not compatible with all ForceField settings at the moment.

In the current release the legacy evaluator is still the default. The evaluator that is actually used is reported in the header of the output file.

Engine ForceField
   UseLegacyEvaluator No
EndEngine

Features that require the legacy evaluator¶

A few force field types and options cannot be evaluated with OpenMM. If your input uses one of them while the OpenMM evaluator is selected, AMS automatically falls back to the legacy evaluator for the whole calculation and prints a warning. The results are correct; you only need to be aware that such a calculation does not run on the OpenMM path. Set UseLegacyEvaluator Yes explicitly if you want to avoid the warning.

APPLE&P (Type APPLE&P): the polarizable APPLE&P force field is only available through the legacy evaluator.
Soft-core potentials (SoftCorePotentials with Enabled Yes): these are used for free energy perturbation and are not evaluated by OpenMM.
Repulsion linearization (LinearizationEnergyForRepulsion): specifying this keyword selects the legacy evaluator.
Tripos 5.2 (Type Tripos5.2): the out-of-plane (inversion) interaction of the Tripos 5.2 force field is not supported by the OpenMM evaluator.

Options that the OpenMM evaluator ignores¶

The following options only take effect with the legacy evaluator. With the OpenMM evaluator they are ignored and a warning is printed. The calculation is still performed with the OpenMM evaluator.

EwaldSummation%Tolerance: use EwaldSummation%ForceErrorTolerance to control the accuracy of the Ewald summation instead.
EwaldSummation%RealSpaceCutoff: with OpenMM the real-space cutoff always equals the non-bonded cutoff (NonBondedCutoff).
EwaldSummation%GridSpacing: only used when EwaldSummation%Alpha is set explicitly.
NeighborListSkin: OpenMM manages its own neighbor list.
PairInteractionTapering: only the difference between None (no tapering) and any other value is honored; the specific tapering method has no effect.

Numerical and performance differences¶

The two evaluators implement the same physics with different algorithms, for example a different particle-mesh Ewald scheme and a different switching function close to the non-bonded cutoff. Energies and forces are therefore consistent to within the usual numerical accuracy of the methods, but they are not bit-for-bit identical between the two evaluators.

On the OpenMM path the energies and forces are evaluated on a GPU when one is available, which is typically much faster for large systems. The OpenMM evaluator is therefore the better choice for large-scale molecular dynamics.