[gmx-developers] Reorganization of GROMACS programs
Mark Abraham
Mark.Abraham at anu.edu.au
Tue Feb 1 00:49:43 CET 2011
Hi,
There's been a long discussion on Redmine
(http://redmine.gromacs.org/issues/685) about the fact that GROMACS has
too many installed programs, and a strategy to reduce the problem.
The consensus there was that it might be better if we re-wrap the tools
so that a call to |$ g_energy -f ener| becomes something like |$ gromacs
energy -f ener|. 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.
Gains to users
* developers can spend more time on making new features and fixing
bugs than managing the flow of all those programs through the
build tree
* 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)
* consistent "look and feel" with (say) modern Unix SCM tools (e.g.
git, hg, svn)
* elimination of existing name space inconsistencies (|gmx*| tools
vs |g_*| tools vs tools without prefixes)
Gains to developers
* fewer tools to install (smaller binary footprint, particularly
with static linking, reduced chance of future binary name space
clashes)
* fewer tools to build (faster linking)
* fewer source files that exist only to provide a |main()| function
* making a new tool is simpler
* simpler CMake build scripts (maybe?)
Losses
* users have to make changes in the way they think
* existing scripts break (unless we provide compatibility scripts
during a changeover period)
* tutorials will need updating
* auto-completion support will need an upgrade (else |$ gromacs
ener[TAB]| will fail to auto-complete to |$ gromacs energy| in the
way that the git tools do)
* new work making |$ gromacs help| do something useful
* Unix-style man page usage changes (people have to remember to use
|$ man gromacs-energy|, or |$ gromacs help energy| or |$ gromacs
energy -h|)
* documentation references to tool names will need updating
Opportunities
* making a user command like |$ gromacs enrgy| lead to useful
suggestions about what the user really wanted to enter (like git does)
* the changeover period also allows us to consider changing names
for some tools (e.g. |grompp| becomes |$ gromacs compile|, mdrun
becomes |$ gromacs-run |or |$ gromacs run|, |pdb2gmx| and
|g_x2top| can be renamed something that properly reflects their
function as topology builders (not file conversion utilities),
|genbox| becomes |$ gromacs solvate|)
* merge the functionality of some tools during the changeover period
* make the tools precision-agnostic, so that |$ gromacs covar
-double |works (though this could probably be done separately)
Details to be decided
* Will we use |$ mpirun gromacs-run| or |$ mpirun gromacs run |(with
auto-detection of MPI environment), or require separate build for
|$ gromacs_mpi run|?
* Will the transition be gradual, or abrupt?
What do people think of the suggestions? Are there alternatives? What
would you like to see?
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20110201/280277e5/attachment.html>
More information about the gromacs.org_gmx-developers
mailing list