<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#ffffff">
<p>Hi,<br>
</p>
<p>There's been a long discussion on Redmine
(<a class="moz-txt-link-freetext" href="http://redmine.gromacs.org/issues/685">http://redmine.gromacs.org/issues/685</a>) about the fact that
GROMACS has too many installed programs, and a strategy to reduce
the problem.<br>
</p>
<p>The consensus there was that it might be better if we re-wrap the
tools so that a call to <code>$ g_energy -f ener</code> becomes
something like <code>$ gromacs energy -f ener</code>. This keeps
the UNIX-style "one tool, one function" approach but changes the
invocation to help keep some underlying machinery cleaner and more
maintainable. It's not clear whether
mdrun would need to stay separate.</p>
Gains to users<br>
<ul>
<li>developers can spend more time on making new features and
fixing bugs than managing the flow of all those programs through
the build tree<br>
</li>
<li>packaging looks and is cleaner (which encourages people to
actually package GROMACS into major software distributions, so
users will more often have the option of installing a
pre-packaged binary)</li>
<li>consistent "look and feel" with (say) modern Unix SCM tools
(e.g. git, hg, svn)</li>
<li>elimination of existing name space inconsistencies (<code>gmx*</code>
tools vs <code>g_*</code> tools vs tools without prefixes)<br>
</li>
</ul>
Gains to developers<br>
<ul>
<li>fewer tools to install (smaller binary footprint, particularly
with static linking, reduced chance of future binary name space
clashes)</li>
<li>fewer tools to build (faster linking)</li>
<li>fewer source files that exist only to provide a <code>main()</code>
function</li>
<li>making a new tool is simpler<br>
</li>
<li>simpler CMake build scripts (maybe?)</li>
</ul>
Losses
<ul>
<li>users have to make changes in the way they think</li>
<li>existing scripts break (unless we provide compatibility
scripts during a changeover period)</li>
<li>tutorials will need updating<br>
</li>
<li>auto-completion support will need an upgrade (else <code>$
gromacs ener[TAB]</code> will fail to auto-complete to <code>$
gromacs energy</code> in the way that the git tools do)</li>
<li>new work making <code>$ gromacs help</code> do something
useful</li>
<li>Unix-style man page usage changes (people have to remember to
use <code>$ man gromacs-energy</code>, or <code>$ gromacs help
energy</code> or <code>$ gromacs energy -h</code>)</li>
<li>documentation references to tool names will need updating</li>
</ul>
Opportunities
<ul>
<li>making a user command like <code>$ gromacs enrgy</code> lead
to useful suggestions about what the user really wanted to enter
(like git does)</li>
<li>the changeover period also allows us to consider changing
names for some tools (e.g. <code>grompp</code> becomes <code>$
gromacs compile</code>, mdrun becomes <code>$ gromacs-run </code>or
<code>$ gromacs run</code>, <code>pdb2gmx</code> and <code>g_x2top</code>
can be renamed something that properly reflects their function
as topology builders (not file conversion utilities), <code>genbox</code>
becomes <code>$ gromacs solvate</code>)</li>
<li>merge the functionality of some tools during the changeover
period</li>
<li>make the tools precision-agnostic, so that <code>$ gromacs
covar -double </code>works (though this could probably be
done separately)<br>
</li>
</ul>
Details to be decided<br>
<ul>
<li>Will we use <code>$ mpirun gromacs-run</code> or <code>$
mpirun gromacs run </code>(with auto-detection of MPI
environment), or require separate build for <code>$ gromacs_mpi
run</code>?<br>
</li>
<li>Will the transition be gradual, or abrupt?</li>
</ul>
<br>
What do people think of the suggestions? Are there alternatives?
What would you like to see?<br>
<br>
Mark<br>
</body>
</html>