Add support for replica exchange and REST2

[lohedges]

This PR adds the low-level changes to sire required to support hamiltonian replica exchange and REST2 simulations using somd2. The PR modifies some existing sire functionality, adds some new functionality, and provides several fixes and enhancements.

Modified functionality:

• In order to facilitate replica exchange (repex) it was necessary to modify dynamics.run() such that samples (trajectory and energy frames) were not always recorded on exit. When performing repex we use dynamics.run() to perform many short cycles, only saving energies after each. Performance was massively impacted by the existing code where trajectory frames are always saved. The change closes [BUG] Frames and energies are always saved after dynamics.run() #256, with the sampling frequencies for energies and frames now decoupled from the run method, i.e. the are only ever recorded at a multiple of the frequency. This is validated in this test. Note that this doesn't affect the ability to run a short dynamics plot and commit changes to the system, since the coordinates are updated from the current OpenMM state when .commit() is called, so is unrelated to trajectory sampling, etc.

• The handling of NaN errors has been tweaked so that it's possible to catch and fix via minimisation when an exception is raised on any step within the dynamics.run(), rather than just on the first step, as long as no sampling has been performed (energy or trajectory frames). This improves the robustness of the dynamics blocks within somd2 and allows us to make use of auto_fix_minimise=True for all simulation types. Previously we ran things within our own try/except block with custom error handling.

New functionality:

• REST2 is supported by the new rest2_scale and rest2_selection kwargs to the .dynamics method. The first defines the scale factor to use for REST2 simulations, which specifies the temperature of the REST2 region relative to the rest of the system. I chose temperature, since this is what is commonly reported in the literature, although some codes use beta instead. I'm not sure if it's easier to think about making the REST2 region hotter or the interactions softer. I'm happy to use the inverse if preferred. (Internally the scale factor is inverted before scaling force constants, etc.) The rest2_selection is used to specify additional atoms to include in the REST2 region via a sire selection string. By default, all atoms in perturbable molecules are included. The selection provides a way of specifying other relevant atoms, e.g. ones in the protein binding site. When perturbable molecules are specified, then only those perturbable atoms are placed in the REST2 region, i.e. atoms that aren't specified are unaffected. This provides a way of selecting a sub-region of a perturbable molecule if desired.

• Modifications to dihedral and nonbonded terms are handled in two ways. Firstly we deal with terms in the perturbable region via the lambda lever code. To do so, we create a mask for atoms in the perturbable molecule that are affected by the REST2 modifications, which is determined via the selection described above. Secondly, we need to keep track of which torsion terms are proper dihedrals, since impropers are not modified. With this in place, we can then apply the REST2 scaling to the required terms when LambdaLever::setLambda() is called. Terms corresponding to atoms that are not within perturbable molecules are handled separately using the OpenMM Python API via the approach used by meld. The terms that are modified are pre-computed when instantiating the SOMMContext and are modified when calling SOMMContext.set_lambda() when a rest2_selection containing non-perturbable atoms has been specified. There is a fairly extensive unit test to make sure the appropriate terms are scaled correctly. This covers: 1) A perturbable molecule; 2) A selection of atoms within a perturbable molecule, and 3) A non-perturbable molecule.

• When calling dynamics.run() a user can now pass an optional rest2_scale_factors kwarg. This specifies the REST2 scale factor to use at each of the lambda_windows that are specified for energy evaluation. We only validate that there are the correct number of entries, not that the scale factors are valid, e.g. they should be 1 at the end states, etc. This validation is done at the somd2 level.

Fixes:

• I've fixed an issue with the Sire OpenMM minimiser which meant that exceptions where thrown prior to the thread state being restored, which would cause the program to crash. This closes Minimisation timeout exception not always caught somd2#63.

• I've added a small update to the sire.qm code to search for the QMForce by name before returning. (It is always named QMForce.) Currently it is always the first force that is added to the system so we can search by index. However, I'd rather make this change now so that we don't run into any surprises if the ordering changes in future. (This change is still covered by an existing unit test.)

• Closes Sire::IO::SDF can't handle a stereo value of 3 #270 by adding handling for double bond stereo info from SDF files.

• Closes [BUG] Positive formal_charge isn't converted to SDF charge field correctly #274 by adding handling for positive formal charge on SDF write.

Checklist

• I confirm that I have merged the latest version of devel into this branch before issuing this pull request (e.g. by running git pull origin devel): [y]
• I confirm that I have added a test for any new functionality in this pull request: [y]
• I confirm that I have added documentation (e.g. a new tutorial page or detailed guide) for any new functionality in this pull request: [y]
• I confirm that I have added a changelog entry to the changelog (we will add a link to this PR as part of the review): [y]
• I confirm that I have permission to release this code under the GPL3 license: [y]

@mb2055: Adding you since you are currently running simulations so can comment on any issues you encounter.
@chryswoods: Adding you so that you are aware of changes to the existing functionality. Let me know if any of these changes impact anything in ways that I might not have anticipated.

[lohedges]

Now fixed.