<div dir="ltr">I think it is timely to also add the Rotational Constraints Algorithm from Andrea Amadei, in a modified, robust, parallelized form, as I have it in 4.5/4.6. I could use a hand with the GIT/Gerrit stuff, though :) <div>
<br></div><div>Cheers,</div><div><br></div><div>Tsjerk</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 27, 2013 at 4:20 PM, Justin Lemkul <span dir="ltr">&lt;<a href="mailto:jalemkul@vt.edu" target="_blank">jalemkul@vt.edu</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
On 9/27/13 8:55 AM, Mark Abraham wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi devs,<br>
<br>
The time has come to make concrete plans in the lead-up to 5.0. On this list on<br>
February 8 I said:<br>
<br>
    We&#39;re acutely aware that the timeline for previous GROMACS releases has been<br>
    vague and has drifted on endlessly. This will change. In future, we will<br>
    produce timed releases, rather than feature-driven releases. If a feature is<br>
    not complete enough for the release roadmap, it will wait for the next<br>
    release, or be included in only partial form. For 5.0:<br>
    * any large-scale code patches hitting lots of code paths will need to be<br>
    largely complete by November 1, 2013 to allow adequate time for testing how<br>
    well they work with features of GROMACS that were not upper-most in their<br>
    authors&#39; minds as they wrote them<br>
    * betas will be released over December and January (after beta1, no new<br>
    features, no planned API changes, no features expected to be removed;<br>
    considerations of correctness and performance will drive decisions here)<br>
    * release candidate 1 on February 1, 2014<br>
    * final release of 5.0 around March 1, 2014<br>
    The dates are guidelines, and the core team will use its judgement about how<br>
    strictly to follow them, but they will be flexible on the scale of days, not<br>
    months.<br>
    Subsequent major releases will happen at least once a year.<br>
<br>
<br>
This is still the plan. Major stuff should be visible in gerrit for review (and<br>
work on integration) by early November. Things do not have to be &quot;feature<br>
complete&quot; at that time, but by December 1 the core functionality needs to seem<br>
to work. Bug fixing is certainly expected. Minor feature completion can occur in<br>
the early parts of the beta phase (e.g. I think &quot;make this integrator work with<br>
the pull code&quot;, &quot;apply OpenMP to this bottle-neck&quot;, &quot;fix CMake hackery&quot; are all<br>
OK, but not &quot;add kernels for Haswell,&quot; &quot;add support for &lt;fancy new QM package&gt;,&quot;<br>
or &quot;refactor t_your_least_favourite_struct&quot;<u></u>). I&#39;m not keen on deferring a whole<br>
feature from beta1 with a plan to put it in beta2. I think that just leads to<br>
deadline creep, because now that feature has had less of any beta testing. The<br>
subset that works should go in beta 1, and we can evaluate at the time whether<br>
the remaining changes are minor enough to accept for beta 2.<br>
<br>
There is no guarantee anybody&#39;s pet feature will get in. Every change is<br>
competing for limited reviewer resources, so you will need to do your best to<br>
look good. That means<br>
* building your karma by participating in review,<br>
* having your work in progress on gerrit, so you can take advantage of Jenkins<br>
testing,<br>
* having your branch merged up to date,<br>
* constructing commits that implement a single logical entity<br>
* having Doxygen documentation of the code,<br>
* updating the manual at the same time,<br>
* having used admin/uncrustify.sh to prettify your code, and<br>
* showing working test cases.<br>
Help with all these things is available - do ask on this list/Redmine/gerrit!<br>
<br>
Things we discussed in Stockholm this week that I&#39;m aware people plan to<br>
prioritise trying to get into 5.0 are:<br>
* get Verlet kernels feature complete, and consider using a kernel generator<br>
script (perhaps also for GPU) - Erik, Berk, Szilard<br>
* MD loop and data structure cleanup - Mark<br>
* implement new integrator formalism - Michael, Mark<br>
* LJ-PME - Christian, Erik<br>
* TNG - Magnus, Mark<br>
* new QM/MM handling - David + team<br>
* improved collective error handling - Szilard, Mark<br>
* enhancements to pull code? (I forget now what this was about!)<br>
* support for PDBx/mmCIF since PDB is deprecated - Rossen, Mark<br>
* porting some selected tools to new analysis framework - Rossen<br>
* analysis framework (and lots of other useful things) - Teemu<br>
Other stuff is welcome, but speak up fast!<br>
<br>
</blockquote>
<br></div></div>
One of the things I mentioned at the conference was to add new polarization methods.  It will hinge on all of the work being done on the integrators, so I&#39;m in a bit of a holding pattern until I see how some of that shakes out.  In the redmine issue on mdrun features, Michael and David had expressed an interest here, as well, but I&#39;m willing to do my best to spearhead it.  From talking with Michael at the conference, it should be relatively straightforward to do what we&#39;re looking at.<br>

<br>
-Justin<br>
<br>
-- <br>
==============================<u></u>====================<br>
<br>
Justin A. Lemkul, Ph.D.<br>
Postdoctoral Fellow<br>
<br>
Department of Pharmaceutical Sciences<br>
School of Pharmacy<br>
Health Sciences Facility II, Room 601<br>
University of Maryland, Baltimore<br>
20 Penn St.<br>
Baltimore, MD 21201<br>
<br>
<a href="mailto:jalemkul@outerbanks.umaryland.edu" target="_blank">jalemkul@outerbanks.umaryland.<u></u>edu</a> | <a href="tel:%28410%29%20706-7441" value="+14107067441" target="_blank">(410) 706-7441</a><br>
<br>
==============================<u></u>====================<div class="HOEnZb"><div class="h5"><br>
-- <br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/<u></u>mailman/listinfo/gmx-<u></u>developers</a><br>
Please don&#39;t post (un)subscribe requests to the list. Use the www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@<u></u>gromacs.org</a>.<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Tsjerk A. Wassenaar, Ph.D.<br><br>
</div>