[gmx-developers] future of tabulated bonded interactions

[Mark Abraham]

Hi,

A community by definition has to have mutual give and take, and
communication. A member of the community who wants to use GROMACS in their
scientific work, maybe modify it, and cite suitable past work is most
welcome to do that - most people will only do that - but they can't also
have much of a say in how the code will change unless that overlaps with a
lot of other people's needs. Almost everybody needs the core of mdrun
faster, and everybody needs core preparation and analysis tools to work
well, but this cannot happen while simultaneously paying the technical debt
for past development practices. It's inexcusable that we have a user on
gmx-users right now who gets a segfault with gmx trjconv -dump on the first
frame of their trajectory.

We should solicit widely for help with constructing tests and
documentation, but if people don't opt in, then they *have* opted out of
the active community.

So if e.g. votca chooses not to help with tabulated bondeds testing now,
then later decides they need OpenCL support, and discover that tabulated
bondeds were broken in 5.1 and then dropped for lack of interest, then they
have reason to work within the community to restore it. In the meantime,
the task parallelism people didn't have to consider how to refactor and
test bonded kernels that nobody needed, yet. If nobody is found who wants
to help in the meantime, then the community has literally voted not to
support the feature. And that's OK!

Mark

On Wed, 1 Jun 2016 16:21 Szilárd Páll <pall.szilard at gmail.com> wrote:

> Hi,
>
> I agree with Berk, but I'd go even further: if actions are taken as
> the previous ultimatum projects, I don't think anybody can claim that
> GROMACS is a community project -- not in the sense that it _serves_ a
> wider community. If the goal is to turn the page flush out most legacy
> code and keep only features that serve the narrow community of tightly
> coupled stakeholders, one may as well just state that upfront. If
> people care about the current feature set, they will likely just keep
> using old versions or maybe even fork.
>
> Cheers,
> --
> Szilárd
>
>
> On Wed, Jun 1, 2016 at 12:23 PM, Berk Hess <hess at kth.se> wrote:
> > Hi,
> >
> > While I agree we have a maintenance issue, this strategy will lead to all
> > features the current developers don't use/don't care about to disappear
> at a
> > high rate. There might be (or might not be) significant numbers of users
> in
> > the world using such features. The question is what happens then. Will
> > people abandon GROMACS? Keep using an old version? Or complain that some
> > feature is not there? If they complain, will something happen? I suspect
> > most people don't have the coding skills and GROMACS knowledge to
> > contribute. Not that I see another good solution though.
> > This is a point we should bring up at the telcon today.
> >
> > PS I do care about tabulated bondeds and a had looked at your change more
> > than once, but have not had the time yet to do a thorough enough review
> for
> > a +2.
> >
> > Cheers,
> >
> > Berk
> >
> >
> > On 01/06/16 12:06 , Mark Abraham wrote:
> >
> > Hi,
> >
> > While working on table support for the Verlet scheme a few months ago
> > (particularly, putting the tables into the .tpr for better user
> experience),
> > I added some tests for tabulated bonded interactions and discovered that
> > these have been broken in release-5-1, after we changed some command-line
> > handling for improved robustness elsewhere. That's because for a long
> time
> > the table filenames have been inferred by mdrun in a hacky way.
> >
> > So I've fixed them, and after two months Teemu found time to look at the
> > straightforward fix + tests. After a further month, nobody else has had
> time
> > to look. Meanwhile, it isn't worth me continuing development to support
> such
> > a feature until I see that somebody cares about it.
> >
> > We cannot continue like this. If the software is too
> large/broken/untested
> > for people to maintain, them we must make it smaller. And if we apply it
> to
> > tabulated bondeds, then it will also apply immediately to lots of the
> other
> > things that people say are nice to have if someone else will do the work
> to
> > fix the known problems. Even when someone has volunteered to support the
> > feature, if nobody will volunteer to review their maintenance patches,
> then
> > the feature cannot remain in the code.
> >
> > After we release 2016, I will make a checklist of mdrun features,
> platforms,
> > analysis tools, and solicit volunteers to a) maintain them, and b) review
> > related code changes. If stuff doesn't have volunteers by September 1,
> then
> > I will remove it forthwith. That goes for the group scheme and old-style
> > analysis tools, too! In future, if the volunteers for a feature aren't
> able
> > to help in practice, e.g. they say nothing at all for a month after a
> > problem surfaces or a patch needs review, then they'll be removed from
> > volunteer status, and if there's no replacement around, the feature goes.
> >
> > Your not-feeling-benevolent-today dictator,
> >
> > Mark
> >
> >
> >
> >
> > --
> > Gromacs Developers mailing list
> >
> > * Please search the archive at
> > http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> > posting!
> >
> > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> >
> > * For (un)subscribe requests visit
> > https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or
> > send a mail to gmx-developers-request at gromacs.org.
> --
> Gromacs Developers mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20160601/49d3b9d1/attachment-0001.html>