[gmx-developers] Hidden modules in gmx?

Tsjerk Wassenaar tsjerkw at gmail.com
Mon Sep 23 08:55:27 CEST 2013


For the analysis tools, I think the do-one-thing-do-it-well approach is far
superior than the swiss-army-knife one. Several of the old analysis tools
have rather obscure features that confuse people (like the option -ref in
g_covar). But the code for those options is often also hacked in, making
the base code cluttered and hard to read. As an example, try handing the
g_rms code to a student to learn how the RMSD is calculated. If analysis
tools are dedicated to a single task, it also helps in making the code
clear enough to understand and check what they do. And it makes it easier
for those that need some alternative analysis to copy and edit, or write
from scratch.

Just my two cents,


On Mon, Sep 23, 2013 at 7:43 AM, Erik Lindahl <erik.lindahl at scilifelab.se>wrote:

> Hi,
> On Sep 23, 2013, at 7:21 AM, David van der Spoel <spoel at xray.bmc.uu.se>
> wrote:
> >>
> > Another (prettier) way rather than hiding the tools would be to
> introduce an extra level in gmx,
> I think the problem with that option is that it brings back the problem of
> mixing well-tested code with lots of less tested routines contributed by
> any developer who wanted to do a quick hack for his own analysis, and it
> gives the appearance those routines too are part of core Gromacs since they
> just require another command specifier.
> In particular for new tools I think we should require them to be small,
> clear and well-documented code-wise, with fewer options and much less fancy
> analysis built-in (because the number of possible combinations explodes
> when one tries to do five things at a time), and also make sure we have a
> responsible maintainer for each tool before considering inclusion in the
> main distribution. I like the unix idea that each program should only do
> one thing, but do it well.
> Obviously, we'll have to be a bit more lenient with old tools, but the
> goal should be the same for those!
> Cheers,
> Erik
>  --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.

Tsjerk A. Wassenaar, Ph.D.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130923/a8d05733/attachment.html>

More information about the gromacs.org_gmx-developers mailing list