Proposal for integrator framework (do_md) in future GROMACS - Redmine #1137
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 added.
III. Make it easier to do multtstep integration using the Trotter decomposition framework.
It’s already possible to do types of multistep integration using 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
- harmonic bonds with short timesteps, with long timesteps for the nonbonded.
- more rigorous short/long cutoff integration
- 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(
). 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 loo Again, only the energy must be calculated additional times, not the forces.
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.
(from redmine: issue id 1137, created on 2013-02-05 by mrshirts)
- Revision 30113ccc by Mark Abraham on 2013-10-17T22:11:09Z:
Move mdrun trajectory writing into wrapper function Refs #1292, #1193, #1137 Change-Id: I3f19e0995ff7fab465184d5bab8c2683260af853
- Revision 8df8c14d by Mark Abraham on 2013-10-28T17:36:13Z:
Create fileio module This patch contains only code motion. There are no functional code changes. Moves lots of I/O code into src/gromacs/fileio. This means lots of changes to avoid having everything as a compile-time dependency of everything else because everything is pulled in via typedefs.h, etc. Note that src/gromacs/legacyheaders/filenm.h and src/gromacs/legacyheaders/types/filenm.h have been consolidated into src/gromacs/fileio/filenm.h. I/O code in files named stat*[ch] now lives in various new files in fileio. Files outside of the module now #include its header files in a proper way, e.g. #include #include "../fileio/filenm.h" or "gromacs/fileio/filenm.h" according to whether they are an installed header, or not. Files within the module are blessed and do not need that qualifier. This module installs most of its headers (because they're almost all inter-dependent; gmxfio_int.h is not installed because it is only useful internally, vmdio.h is not installed because it relies on a header from src/external) Files in new module * conform to preferred include-guard format. * have up-to-date copyright headers thanks to Teemu's automatic script * that are installed headers refer to other GROMACS include files via relative paths Moves mdrun trajectory writing into wrapper function. Removes small pieces of I/O code that was hiding behind "#if 0". Some pieces of I/O code specific to the gmxpreprocess module have remained there. Moved a cppcheck suppression to follow matio.cpp to its new home. Minor fix to xdrf.h logic, since it is now the subject of a CMake test. Refs #1292, #1193, #1137 Change-Id: I820036298d574966d596ab9e258ed8676e359184
- Revision 488464e7 by Mark Abraham on 2014-12-15T20:40:27Z:
Removing iteration + constraints framework Getting rid of iteration + constraints required by the use of MTTK + constraints, in order to simplify the main loop. Eliminated related variables and arguments that are now unused. Left some otherwise useless brace pairs in do_md(), so that uncrustify-friendly formatting was preserved, so we can more easily review this for correctness. Left TODOs to remove those braces later. Implemented mdrun check so that an old .tpr with MTTK + any form of constraints cannot be run. Refs #1137 Change-Id: I22816de7db4420a66341fa8bf35d967a71ad6568
- Revision 6ead809b by Mark Abraham on 2015-11-16T14:22:48Z:
Remove "support" for twin-range with VV integrators Group-scheme twin-range non-bonded interactions never worked with VV+constraints, and removing it was a to-do item. There are no plans to make it work with VV, and there are plans to remove the twin-range scheme entirely, as well as rework leap-frog more closerly into the Trotter scheme. Refs #1137, #1793 Change-Id: Ibd70b5397568bfcd328cd6dd1c5c99384d7aaca8
- Revision bd1807e6 by Mark Abraham on 2016-01-07T08:16:05Z:
Remove SD2 integrator This integrator has known problems, and is in all ways inferior to sd. It has no tests, and was deprecated in GROMACS 5.0. There are no plans to replace it. Old checkpoint files written by sd2 integrators will no longer be readable, but this is not a problem since continuing an MD simulation across minor versions is not supported, and sd2 has no replacement implementation anyway. Refs #1137 Change-Id: I71b688a67a80e1f55134e81dab7a11a66942cff4
- Revision efa13a69 by Mark Abraham on 2019-08-27T16:51:43Z:
Add integration tests for exact restarts These tests demonstrates the extent to which mdrun checkpoint restarts reproduce the same run that would have taken place without the restart. I've been working on these, and the bugs they exposed, for a few years, but the code has been fixed for a few years now. The tests don't run with OpenCL because they have caused driver out of memory issues. Refs #1137, #1793, #1882, #1883 Change-Id: I8bc441d945f13158bbe10f097e772ea87cc6a559
- integrator.pdf Integrator proposal