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

[Mark Abraham]

Hi,

The near-silence has been deafening, so these issues are regarded as
closed. Anybody wanting a significant deviation from that plan will
find the onus on them to do the work! :-)

Cheers,

Mark

On Wed, Aug 14, 2013 at 5:06 PM, Mark Abraham <mark.j.abraham at gmail.com> wrote:
> 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
> http://redmine.gromacs.org/issues/1292.
>
> 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
> * GCT
> * 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
> works.
>
> 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,
> too!
>
> Cheers,
>
> Mark