Feature #1137

Updated by Michael Shirts over 7 years ago

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
decomposition framework.

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 Monte Carlo 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.

Thoughts? I can probably handle a lot of the gruntwork here, though there are some places help would be useful; for example, in adding the ability to call only parts of the force calculation each time.