[gmx-developers] future of tabulated bonded interactions

Berk Hess hess at kth.se
Wed Jun 1 12:23:20 CEST 2016


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
>
>

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


More information about the gromacs.org_gmx-developers mailing list