<div dir="ltr">Hi,<div><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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...</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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".</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Best regards,</div><div class="gmail_extra">Teemu<br><br></div></div>