I'm going to put these all together at first, and then start breaking them up when we move from proposals and discussion to actual tasks.
I. Remove the iterative structure required for MTTK integration with
constraints. MTTK integration will be left in (still a very nice
formalism), but only for systems without constraints. This way,
we get the benefits for some systems (like LJ) without the ugly
and often-unstable-in-single precision iteration. This will help
solve some of the issues with the difficulty to work with the md
framework. I'll discuss how to get longer timesteps with MTTK
below . . . One disadvantage: Will not be able to do do full,
'correct' pressure control _dynamics_ with constraint systems,
but pressure control is a bit artificial already; one will at
least be able to constant pressure sampling using a MC barostat
(see below). This is a todo in the next month or two (MRS). It
will make it possible to make the integrator much simpler.
II. Convert the md integrator to a full Trotter decomposition framework.
This will have a number of advantages going forward. It will
make it much easier to fit md and md-vv into the same framwork.
Note that this does not _change_ either integrator; it just
changes how it is written out and makes in more clear what steps
go together in the code and where to put modifications. This is
partly already in the code but not included. This formalism
easily extends to the pressure control and temperature control
algorithms; again, in most cases, this is the formalism that's
implemented already, it's just a matter of rewriting it so it's
easier to see where to add additional code when new methods are
III. Make it easier to do multtstep integration using the Trotter
It's already possible to do types of multistep integration usign
the Trotter decomposition framework; for example, doing pressure
control or temperature control only every N steps. However, it
would be useful to make it possible to only evaluate certain
components of the potential energy / force every N steps as well,
where N can varied independently for each component.
This will make a number of things possible, such as
1) harmonic bonds with short timesteps, with long timesteps for the
2) more rigorous short/long cutoff integration
3) Make it less computationally intensive to do PME/LJ, as this only needs to be called
relatively rarely (10-20 steps, likely). We know that PME/LJ is required for getting
lipid densities to be cutoff independent.
IV. Adding a MC Barostat
This consists in random volume changes, accept and reject based on
Boltzmann weight exp(-(E+PV)). This has an advantage that there
is no need for fancy integrators for NPT, which is giant pain, and
the virial doesn't even need to be calculated -- Virial only needs
to be calculated when you want to see the pressure (every
nstcalcenergy) Generalizable to anisotropic very easily. MTTK is
especially a giant pain, and requires iteration to work with
constraints, and current Parrinello-Rahman is incorrect because it
uses mismatched virial and kinetic energies.
One disadvantage: this will require a second force/energy
calculations per application (though only every nstpcouple steps).
Computationally, this is not a big problem, but it will require
making it easier to run do_force multiple times in a loop. Again,
only the energy must be calculated additional times, not the
V. Redo the main md loop to allow for either MC or MD.
Now that MD can be seen as rejectionless MD, so it is easiest to
write the 'parent' loop as MC., with MD being a type of
MC with 100% acceptance. Clearly point IV (MC barostat) fits under this as
well. Expanded ensemble and replica exchange also fit into this.
Advantage: lots of potential advantages for calculating
thermodynamic quantities and equilibrium ensembles. Lots of
interest in improving MC in gromacs. Could be very useful with
implicit solvent, especially, where large conformation changes
could be made. Aggregation in implicit solvent can particularly
be made faster. Also very useful for simple fluids.
Disadvantage: Makes it a little bit more complicated, but not
much. Payoff should be worth it. As long as the general
formalism is set up, extending MC by other developers or volunteers
is very easy.