[gmx-developers] plans for Gromacs 5.1 release
Mark Abraham
mark.j.abraham at gmail.com
Thu Nov 27 14:49:27 CET 2014
On Wed, Nov 26, 2014 at 7:16 PM, Justin Lemkul <jalemkul at vt.edu> wrote:
>
> Hi All,
>
> My code for polarizable simulations with extended Lagrangian for our Drude
> force field is basically done. I have a few issues related to pdb2gmx left
> to address, but I plan to do that probably in the coming week. The changes
> are basically an extension of the md-vv integrator and are largely confined
> to:
>
> 1. A few new thermostat functions
> 2. A few new .mdp settings
>
That will mean bumping the .tpr version. This is fine, but please read and
follow the docs in tpxio.c. Not doing that properly can do terrrible things
to Jenkins builds when the expectations of the code and the contents of the
files don't match, leading to horrible pointer fails inside analysis tools.
Manually killing processes and re-triggering Jenkins jobs is something we'd
like to avoid at all costs. So, if the .mdp needs are fixed, then we can
separate the tpr I/O stuff into its own patch (e.g. issue a temporary fatal
error from mdrun if the .tpr has the new settings). This will let us get
that debugged and stable early, before adding the real code and test cases,
and avoiding any instability during times of high Jenkins demand. Running
the modified grompp under valgrind before uploading to Jenkins is a
reasonably easy way to be a good citizen here.
3. Small changes within the Trotter decomposition/update functions to call
> our special Drude routines
> 4. Compatibility with DD
>
> I need to merge in master at some point soon, and the code is all in the
> "drude" branch in git, but it should hopefully be reasonably easy to merge
> in. Most of the code is simply new, rather than large-scale modifications
> of existing stuff.
>
OK. You probably need both grompp and mdrun to issue fatal errors for the
range of relevant .mdp options that are unsupported. We would much rather
have
if (polarizable && !(md-vv && lincs && !pull && !freeze-groups && whatever))
{
gmx_fatal()
}
than permit untested code paths to run in the hands of users.
Mark
> -Justin
>
> On 11/26/14 12:42 PM, Shirts, Michael R. (mrs5pt) wrote:
>
>> Hi, all-
>> My goals for 5.1:
>>
>> * High priority:
>> o Resolve any lingering issues with proper framework to do free
>> energy
>> changes, so that everything is better documented and consistent,
>> and
>> addressing lingering questions.
>> + Topics include verifying Hamiltonian replica exchange, making
>> sure
>> integrated with pull code, deciding on best practices,
>> clearing out
>> redmine with free energy related issues, partially unifying
>> analysis
>> approaches. Adding a MBAR option into GROMACS would be nice,
>> but
>> may need to wait.
>> o Finally remove the iteration code (literally in the middle of
>> rebasing
>> the removed-iteration code to the current master when receiving
>> this email)
>> o At least partially reorganize the integrator framework
>> bookkeeping to be
>> cleaner and in the Trotter decomposition style. This would be a
>> code
>> reorganization, but should not be a feature change at this point.
>> So the
>> scope would be whatever is manageable.
>> * Going to try very hard
>> o Add an MC Barostat (especially important if removing iterative
>> MTTK in
>> above).
>> o Better document existing expanded ensemble framework and adding
>> features
>> from with Viveca's expanded ensemble framework to reduce code
>> duplication and harmonize approaches.
>>
>> * Priorities for 5.2
>> o Fully trotterizing the code to support multiple time steps
>> o A more complete MC framework
>> o Free energy calculations using linear basis scheme (requires
>> GPU-accelerated tabulated functions); this should accelerate free
>> energy
>> calculations by removing it form the inner , as well as removing
>> the
>> need to ever write free energy inner loops for SIMD or GPU.
>> o Multiple end states (instead of just A and B)
>> o Enveloping distribution sampling
>>
>> Best,
>> ~~~~~~~~~~~~
>> Michael Shirts
>> Associate Professor
>> Department of Chemical Engineering
>> University of Virginia
>> michael.shirts at virginia.edu
>> (434) 243-1821
>>
>> From: Mark Abraham <mark.j.abraham at gmail.com <mailto:
>> mark.j.abraham at gmail.com>>
>> Reply-To: "gmx-developers at gromacs.org <mailto:gmx-developers at gromacs.org
>> >"
>> <gmx-developers at gromacs.org <mailto:gmx-developers at gromacs.org>>
>> Date: Wednesday, November 26, 2014 at 12:18 PM
>> To: Discussion list for GROMACS development <gmx-developers at gromacs.org
>> <mailto:gmx-developers at gromacs.org>>, Christian Wennberg <chriwen at kth.se
>> <mailto:chriwen at kth.se>>, Iman Pouya <iman.pouya at gmail.com
>> <mailto:iman.pouya at gmail.com>>, Alfredo Metere <
>> alfredo.metere at scilifelab.se
>> <mailto:alfredo.metere at scilifelab.se>>, Anca Hamuraru <
>> anca at streamcomputing.eu
>> <mailto:anca at streamcomputing.eu>>, Vincent Hindriksen
>> <vincent at streamcomputing.eu <mailto:vincent at streamcomputing.eu>>
>>
>> Subject: [gmx-developers] plans for Gromacs 5.1 release
>>
>> Hi,
>>
>> It's time we got organized for the next minor release. Generally policy is
>> unchanged - we do a feature-change release at least once a year, and
>> bugfix
>> releases periodically on the last minor/major release. An "extra" release
>> for
>> some special purpose is negotiable.
>>
>> I propose
>>
>> * now:
>> + get code you want to be considered for 5.1 into gerrit (tag the
>> first
>> line of the commit message [RFC] or [WIP] if you know that the current
>> state of
>> the code is not a serious candidate for merging)
>> + get your karma up by participating in review of others' code
>> + reply to this email (or comment on your patches in gerrit) to
>> guide other
>> people about what might be important for them to review
>>
>> * mid-January:
>> + release 5.0.x
>> + release 5.1-beta from whatever is the tip of master branch at the
>> time
>> + fork release-5-1 branch then (still open for functionality changes
>> until
>> the 5.1-rc1 releases; gerrit's feature for cherry picking between
>> branches will
>> make this fork manageable)
>>
>> * early-to-mid February:
>> + release 5.1-rc1
>> + close release-5-1 to new functionality, it remains open for bug
>> fixes,
>> test cases, and documentation only
>> + test widely on any plausible machine and compiler for portability
>> and
>> correctness
>> + release 5.1-rc[234] if that seems like a good idea
>>
>> * mid-March:
>> + release 5.0.x for hopefully the last time, pretty much close
>> release-5-0
>> branch
>> + release 5.1
>> + remove the group cutoff scheme
>> + ...
>> + Profit!
>>
>> Do speak up if you have a suggestion for a change / request for special
>> consideration / whatever. I've deliberately left the Christmas period
>> open for
>> people who might want to do a last code push at that time, but a huge
>> patch
>> landing without warning on January 10... will probably get ignored by me.
>>
>> Please note that things like ongoing contribution with testing and code
>> review
>> are the primary things that might earn an authorship on Gromacs papers
>> (5.0 is
>> still on my TODO list, sorry) - adding some feature is awesome, but what
>> reward
>> structure we can offer needs to focus on the large amount of inglorious
>> work
>> that has to happen.
>>
>> Things team Stockholm are actively working on that we'd like to have
>> ready for
>> 5.1 (and the names of the primary people involved)
>> * new DD communication support (Berk)
>> * enhancements to pull code (Berk)
>> * Verlet scheme support for tables, vacuum, Generalized Born (Berk,
>> Alfredo)
>> * GPU support for tabulated interactions (Alfredo)
>> * GPU acceleration of (at least) dihedral interactions (Iman)
>> * combined FFTs for LJ-PME (Christian)
>> * offload of bonded interactions for enhancing load balance (Mark)
>> * support for latest CUDA offerings (Szilard)
>> * OpenCL non-bonded support (mostly Anca from
>> http://www.streamcomputing.eu, Mark)
>> * support for CPU-based SIMD on everything on the horizon (Erik)
>>
>> Like everything else, none of that's going to block releases, but since
>> 5.1 will
>> be the last minor release with the group cutoff scheme, feature
>> completion of
>> the Verlet scheme will be an internal priority for development, review,
>> and
>> testing. Full feature completion is unlikely to happen, so support for
>> twin-range multiple-time stepping, QM/MM, and AdReS may disappear unless
>> people
>> want to put the work in.
>>
>> There's a lot of code already in Gerrit awaiting review, particularly
>> from Teemu
>> on the analysis tools. I need to help out more there, but do check if he's
>> fixing stuff that you might care about!
>>
>> If you're working on code that you might want to get into 5.1, speak up!
>>
>> Happy reviewing!
>>
>> Mark
>>
>>
>>
> --
> ==================================================
>
> Justin A. Lemkul, Ph.D.
> Ruth L. Kirschstein NRSA Postdoctoral Fellow
>
> Department of Pharmaceutical Sciences
> School of Pharmacy
> Health Sciences Facility II, Room 629
> University of Maryland, Baltimore
> 20 Penn St.
> Baltimore, MD 21201
>
> jalemkul at outerbanks.umaryland.edu | (410) 706-7441
> http://mackerell.umaryland.edu/~jalemkul
>
> ==================================================
> --
> Gromacs Developers mailing list
>
> * Please search the archive at http://www.gromacs.org/
> Support/Mailing_Lists/GMX-developers_List before posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20141127/1b4fec2a/attachment-0001.html>
More information about the gromacs.org_gmx-developers
mailing list