[gmx-developers] plans for mdrun features to deprecate in GROMACS 5.0

Mark Abraham mark.j.abraham at gmail.com
Wed Aug 14 17:06:44 CEST 2013

Hi gmx-users and gmx-developers,

There are a number of features of GROMACS that we plan to drop for 5.0
(scheduled for early 2014). We don’t like doing this, but if things
are broken or cause developers pain, then they will go unless there is
manpower to support them. We’d like to keep you informed and hear how
much pain any of this might cause. Some features will be dropped
entirely, and others are likely to be reduced to explicit support only
for some cases. Some discussion has already occurred here

Things we plan to drop entirely:
* particle decomposition (see below)
* current QM support (this will be dropped, work on a replacement is
underway, planned for 5.0)
* writing of pair distance and/or time-averaged pair distance to
energy files during simulations with position/orientation restraints
* reaction-field-nec
* Encad-shift
* mdrun -ionize
* mdrun -seppot
* mdrun -ffscan
* OpenMM support

There are several algorithms (e.g. fancy kinds of restraints) that
have only ever worked with particle decomposition (if they work at
all...). We plan to support these only in serial.

Things that will likely only work in serial (ie. single-domain DD):
* ensemble- and time-averaged distance restraints
* L-BFGS energy minimization
* Generalized Born

In some cases, “in serial” might mean “in parallel (with DD) with an
extra communication stage that will make it work, but might scale
poorly.” Or “in parallel but if things diffuse too far, the simulation
will crash.” If you have working examples of any of the above in
parallel, we would be most interested to hear from you. We’d like to
construct test cases that show what works now, so that later if we are
able to support some kind of parallelism, we can show that it still

Things that won’t support constraints (because the implementations are
broken or missing):
* L-BFGS energy minimization
* MTTK pressure coupling

As always, what goes into GROMACS depends on people putting the work
in. If something above would affect you, then do speak up.
Contributions of working test cases are particularly valuable, but in
the end you might have to be the one to write the code to make the
test pass. You will have the option of continuing to use old code,



More information about the gromacs.org_gmx-developers mailing list