[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