[gmx-developers] Hidden modules in gmx?

[Teemu Murtola]

Hi,

on the original topic of hidden modules, I don't think we should go there,
and I think that adding an extra level like 'gmx contrib my_tool' only adds
complexity without much added value. I suspect that the real problem (at
least one of them) is that 'gmx help' prints a disproportionately long list
of commands. This, and other help/manual parts, are the only places where
you really see the number of the modules.

The solution for that is to limit this list, and only show the full list
(preferably grouped) with something like 'gmx help commands'. In other
contexts, I don't think it matters much even if the list is long, and even
less so if the list is grouped reasonably. "Hidden" tools should be
reserved for truly user-invisible modules that are there only for some
obscure implementation reason; currently g_options is a prime example of
this. For brevity, I've also excluded obsolete modules (that only print
"This command has been removed") from the help listing.

For the "do-one-thing" principle, I agree to a certain extent, but there is
always a balance, since we are talking about processing potentially very
large amounts of data. If performing analysis tasks requires running five
different tools in a row, and all produce intermediate files in the
gigabyte range, the flexibility may defeat usability...

A good example (taken to the extreme to illustrate the point): one could
easily imagine that RDF computation could be divided into two steps for
additional flexibility: first computing the pairwise distances with one
tool, and doing the histogram with another. But the intermediate data will
be huge (typically much larger than the input trajectory), making the
result somewhat useless.

I can imagine adding support for serializing and deserializing the stuff
to/from stdout/stdin could be possible, and/or adding some domain-specific
language or scripting language bindings to be able to specify how the tools
should be chained, but that may be a lot of effort (not for 5.0) and
doesn't really make using the tools any easier. Plus it may be a lot of
code to maintain.

Just some thoughts from the time I still did these analyses myself. I've
tried to balance these things with the 'gmx distance' and 'gmx gangle'
tools: both tools (gangle in particular) provide control over what to
calculated, and also a set of output options. But by design, the raw data
is always the same format (and can be written out into a file for custom
processing), and all the output options work independently of the
calculation control options, allowing one to choose any combination.
Concrete suggestions are always welcome on how to better structure them if
people feel they are too "swiss-army-knife-like".

Best regards,
Teemu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130923/d4b65abd/attachment.html>