Hi gmx-developers,<div><br></div><div>With the release of 4.6 completed, we&#39;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 &amp; Swedish grants that will determine how those people will spend their time on GROMACS. However, we won&#39;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 <a href="http://redmine.gromacs.org/">http://redmine.gromacs.org/</a> and in code review on <a href="http://gerrit.gromacs.org">http://gerrit.gromacs.org</a> will be great for you and us! There will be regular developer teleconferences to discuss the important issues of the moment.</div>
<div><br></div><div><b>Planned features for 5.0</b></div><div><br></div><div>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:</div>
<div><ol><li>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&#39;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 <a href="http://www.gromacs.org/index.php?title=Developer_Zone/Programming_Guide/Allowed_C%2b%2b_Features">http://www.gromacs.org/index.php?title=Developer_Zone/Programming_Guide/Allowed_C%2b%2b_Features</a>), 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&#39;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!</li>
<li>Support the TNG compressed trajectory file format (<a href="http://link.springer.com/article/10.1007/s00894-010-0948-5">http://link.springer.com/article/10.1007/s00894-010-0948-5</a>)</li><li>Reworking the integration framework to produce better physics via more algorithms (e.g. various forms of Monte Carlo) - see <a href="http://redmine.gromacs.org/issues/1137">http://redmine.gromacs.org/issues/1137</a> for discussion</li>
<li>Start work on a data-driven task-parallel framework for the integration loop to enhance strong scaling possibilities (discussion currently &quot;in house&quot; in Stockholm)</li><li>New QM/MM framework (David van der Spoel and Lee-Ping Wang)</li>
<li>New NMR refinement support (David van der Spoel and Erik Marklund)</li><li>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 <a href="http://redmine.gromacs.org/issues/685">http://redmine.gromacs.org/issues/685</a> for discussion.</li>
</ol><div>If any of that proves infeasible in the time frame we have in mind, we&#39;ll feel free to remove it or reduce its scope in order to make a high quality release on time.</div><br><div><b>Other new features</b></div>
<div><br></div><div>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</div>
</div><div><ul><li>accept the inevitability of API changes, and keep their eyes and ears open,</li><li>work from the 4.6 code base (e.g. branch release-4-6 in the GROMACS code repository), or</li><li>wait until 5.0 appears and start work then.</li>
</ul></div><div>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&#39;t have the resources to implement or maintain new features ourselves - we&#39;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 </div>
<div><ul><li>the contributor isn&#39;t around, and</li><li>the remaining team don&#39;t value the feature highly, and</li><li>maintaining the code causes problems, and</li><li>particularly if nobody has contributed tests for the feature,</li>
</ul>that feature might have to be removed until some of the above changes.</div><div><br></div><div><b>Timeline for 5.0</b></div><div><br></div><div>We&#39;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:</div>
<div><ul><li>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&#39; minds as they wrote them</li>
<li>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)</li>
<li>release candidate 1 on February 1, 2014</li><li>final release of 5.0 around March 1, 2014</li></ul>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.</div>
<div><br></div><div>Subsequent major releases will happen at least once a year.</div><div><br></div><div><b>How can you help?</b></div><div><b><br></b></div><div>Even if you haven&#39;t got time to write code for new features, if you&#39;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 <a href="http://gerrit.gromacs.org">http://gerrit.gromacs.org</a> with your OpenID (e.g. gmail account) any time. Then, drop us an email saying how you think you can help, and we&#39;ll give you review permissions. Just signing up will make you eligible to submit code patch proposals, too.</div>
<div><br></div><div>If you know something is broken, incomplete, badly documented, etc. please submit a report on <a href="http://redmine.gromacs.org">http://redmine.gromacs.org</a>.</div><div><br></div><div>If there&#39;s functionality in 4.6 that is really important for you, and which isn&#39;t tested by our current test set (which is rather limited), please talk to us about helping with generating some tests!</div>
<div><br></div><div>Happy GROMACSing!</div><div><br></div><div>Mark</div>