[gmx-developers] Plans for GROMACS 5.0

[Mark Abraham]

Hi gmx-developers,

With the release of 4.6 completed, we're moving towards finalising the
plans for GROMACS 5.0. The core team will be much more open about the
direction GROMACS will take, and invites input from interested developers
to help do that best. Much of the core team is based in Stockholm and
funded by EU & Swedish grants that will determine how those people will
spend their time on GROMACS. However, we won't be making big decisions
behind closed doors. Neither can we broadcast every little detail here! If
you want to stay well informed and participate in the future directions of
GROMACS, then contributing to the discussions on gmx-developers, on
http://redmine.gromacs.org/ and in code review on
http://gerrit.gromacs.orgwill be great for you and us! There will be
regular developer
teleconferences to discuss the important issues of the moment.

*Planned features for 5.0*

The core team will continue to focus on raising GROMACS to greater heights
of performance, scalability and algorithmic flexibility, and doing so will
require a lot of work revamping the APIs within GROMACS. The current
thoughts on the major new features of 5.0 are:

   1. After several years of discussion and preliminary planning, GROMACS
   will move from being a C project to a C++ project. The idea here is to do
   some heavy lifting now to allow the GROMACS project to continue to achieve
   its scalability and performance goals in the medium term, and on the way
   make life easier for people wanting to add features, fork the project, etc.
   That's going to be a lot of work! It will certainly not be a complete
   re-write. Initially, work will focus on constructing C++ APIs over the
   existing C code, as a way for us to expand our ability to write code tests,
   as well as expand our code documentation with Doxygen, handle errors
   better, etc. We have preliminary ideas about the subset of C++ that is
   appropriate (currently at
   http://www.gromacs.org/index.php?title=Developer_Zone/Programming_Guide/Allowed_C%2b%2b_Features),
   but will be looking to flesh out existing content on the webpages into a
   more comprehensive Developers Manual, as we learn more about what works and
   what doesn't. In particular, we will be trying to avoid putting too much
   pressure on HPC C++ compilers - so things like exotic template
   meta-programming are definitely not going to happen!
   2. Support the TNG compressed trajectory file format (
   http://link.springer.com/article/10.1007/s00894-010-0948-5)
   3. Reworking the integration framework to produce better physics via
   more algorithms (e.g. various forms of Monte Carlo) - see
   http://redmine.gromacs.org/issues/1137 for discussion
   4. Start work on a data-driven task-parallel framework for the
   integration loop to enhance strong scaling possibilities (discussion
   currently "in house" in Stockholm)
   5. New QM/MM framework (David van der Spoel and Lee-Ping Wang)
   6. New NMR refinement support (David van der Spoel and Erik Marklund)
   7. Have a single GROMACS executable that includes tools, mdrun, whatever
   precisions were compiled so that the installation footprint is much
   smaller. Also remove libmd, which was causing name collisions. See
   http://redmine.gromacs.org/issues/685 for discussion.

If any of that proves infeasible in the time frame we have in mind, we'll
feel free to remove it or reduce its scope in order to make a high quality
release on time.

*Other new features*

Inevitably, the C++ transition will make life hacking within and around
GROMACS painful. The usual recommendation for when to do code refactoring
is when feature development is not taking place, and that works in reverse,
too :-) People wishing to implement new features during the transition
period will need to either

   - accept the inevitability of API changes, and keep their eyes and ears
   open,
   - work from the 4.6 code base (e.g. branch release-4-6 in the GROMACS
   code repository), or
   - wait until 5.0 appears and start work then.

As always, the team is prepared to consider proposals for new features
(e.g. start a discussion on gmx-developers or Redmine). Often the core team
won't have the resources to implement or maintain new features ourselves -
we're already very stretched for 5.0. Even if the wider team does accept an
external feature, or has done so in the past, if

   - the contributor isn't around, and
   - the remaining team don't value the feature highly, and
   - maintaining the code causes problems, and
   - particularly if nobody has contributed tests for the feature,

that feature might have to be removed until some of the above changes.

*Timeline for 5.0*

We're acutely aware that the timeline for previous GROMACS releases has
been vague and has drifted on endlessly. This will change. In future, we
will produce timed releases, rather than feature-driven releases. If a
feature is not complete enough for the release roadmap, it will wait for
the next release, or be included in only partial form. For 5.0:

   - any large-scale code patches hitting lots of code paths (e.g. features
   1, 3 and 4) will need to be largely complete by November 1, 2013 to allow
   adequate time for testing how well they work with features of GROMACS that
   were not upper-most in their authors' minds as they wrote them
   - betas will be released over December and January (after beta1, no new
   features, no planned API changes, no features expected to be removed;
   considerations of correctness and performance will drive decisions here)
   - release candidate 1 on February 1, 2014
   - final release of 5.0 around March 1, 2014

The dates are guidelines, and the core team will use its judgement about
how strictly to follow them, but they will be flexible on the scale of
days, not months.

Subsequent major releases will happen at least once a year.

*How can you help?*
*
*
Even if you haven't got time to write code for new features, if you're
thinking of doing so, and particularly if you have C++ experience, you will
be most welcome on the code review team. All the existing developers are
expected to contribute to code review, naturally, but ideas from fresh
minds are usually good for everyone. You can sign up at
http://gerrit.gromacs.org with your OpenID (e.g. gmail account) any time.
Then, drop us an email saying how you think you can help, and we'll give
you review permissions. Just signing up will make you eligible to submit
code patch proposals, too.

If you know something is broken, incomplete, badly documented, etc. please
submit a report on http://redmine.gromacs.org.

If there's functionality in 4.6 that is really important for you, and which
isn't tested by our current test set (which is rather limited), please talk
to us about helping with generating some tests!

Happy GROMACSing!

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130208/56ae836d/attachment.html>