[gmx-developers] functionality to deprecate in 2018 release

[Mark Abraham]

Hi,

We have a number of things that have been identified to be duplicate
functionality, or have serious implementation deficiencies that we should
warn users about before we remove them finally. So, I propose that in the
2018 release we have a note (e.g. to the .log file) advising users of this
functionality that it may go away, and where appropriate, what alternative
exists. We already do a similar thing for the group scheme.

People can volunteer to work on things in order to keep them, but "it's
important to me, but I won't commit resources to work on it" carries zero
weight. That's particularly true in cases where they've said that 6-36
months ago on the various Redmine issues that we've debated them on. ;-)

In particular:
* mdrun -multi (does not work reliably with files created by modules that
weren't designed to work with multi-simulations; works much more reliably
with -multidir because that uses the existing abstraction for a group of
related files, ie. a folder)
* BG/Q support (some aspects have been broken for a few versions, and most
places are phasing out their machines)
* CUDA compute capability 2.0 devices (more than 5 years old, and
deprecated also in recent CUDA versions)
* Generalized Born (will remove, has been mostly broken since version 4.6)
* QM/MM (except for areas Gerrit and Tomas are working on - what is your
intended scope here, please?)
* all-vs-all kernels (we might have a form of this available for the Verlet
scheme, but we will not prioritise that highly for 2019 release; it's only
really useful for GB or vacuum simulations)
* mdrun options -nsteps -confout -resetstep -resethway (the implementations
are bad, and/or duplicate gmx convert-tpr, and/or don't work reliably in
combination with tuning features; they are not things normal users should
ever use, and should be replaced by something implemented to do
benchmarking after tuning stabilizes; notably, we keep -maxh because that's
something useful for users)
* the ability of trjconv to concatenate files (trjcat is the tool for that)

Any other things people want to add or remove from that list? We might
raise some version requirements (possibly cmake or CUDA) but those aren't
things I think we should notify users about in advance. We should work on
breaking trjconv, trjcat, eneconv and editconf into a forest of sub-tools,
but I think that there's not any value in telling users anything about that
in advance.

We should also be aware that -deffnm is brittle in the same way that -multi
is, because our filename-handling machinery doesn't centralize changing the
prefix/suffix needed to support -deffnm or -multi. So I think we should
plan to announce -deffnm as deprecated in the 2019 release (and remove
after that). If we think that's useful enough to want to keep, we need
people to put up their hands for the work to make all the mdrun modules
work with it.

Thanks,

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20180104/8fe05aff/attachment.html>