[gmx-developers] plans for GROMACS 2017 release cycle
alexxy at omrb.pnpi.spb.ru
Fri Mar 10 06:45:13 CET 2017
Erik Lindahl писал 09-03-2017 23:01:
> I think the python API is one of the most important things we'll
> introduce in a long time, but for that reason we definitely shouldn't
> push anything in last-minute.
> However, within the next ~2 months I hope we can see a vivid
> discussion with use cases and specifications in Redmine, and end up
> with a compromise that satisfies most of us (nobody will get all their
> wishes). From my point-of-view I feel that it's important that we
> achieve long-term stability so the existing API in principle never
> changes (although it will expand), and that it "feels" like a
> first-class python interface suitable for large-scale &
> high-throughput scripting (rather than wrappers for C/C++ code).
A year ago situation about pyapi was the same, and there were no
comments or discussion since ~ Feb 2016 [see gerrit].
To my point of view some working pyapi is better then no pyapi at all.
There also things that can be easily done with old C api, but cannot
with current trajectoryanalisys one (e.g. two-or-more pass trajectory
analysis tool) However it can be done with pipelines using pyapi.
> So, I'll cast a strong vote that Python should wait for the 2018
> release - because it's too important to rush and get wrong :-)
> On Thu, Mar 9, 2017 at 8:52 PM, Alexey Shvetsov
> <alexxy at omrb.pnpi.spb.ru> wrote:
>> Mark Abraham писал 09-03-2017 19:03:
>> On Thu, Mar 9, 2017 at 3:49 PM Alexey Shvetsov
>> <alexxy at omrb.pnpi.spb.ru> wrote:
>> I'd like to add python api for gromacs as a suggestion (however we
>> to fix it first to work with current changes for trajectoryanalysis)
>> I suspect we've not done anywhere near enough groundwork (yet) for
>> this. Offhand, we should have a clear understanding of the scope
>> ("expose the trajectoryanalysis C++ API" seems to be that of the
>> current RFC patch in gerrit), how that adds value to users, and
>> whether the approach will be able to offer a suitably stable UI. We
>> also need to consider which versions of Python make sense to support
> I think we can support both versions, however py3 is prefferable.
>> How does a script using it look? (Your link to
>> https://biod.pnpi.spb.ru from the Redmine no longer seems to work?)
>> Does that compare reasonably to offerings like
>> http://www.mdanalysis.org/pages/basic_example/  or
>> http://mdtraj.org/1.8.0/examples/introduction.html . What lessons
>> we learned from them, and what aspects of other related python
>> toolsets should we plan to incorporate, so that users will find
>> themselves able to get the benefit of rapid compiler-free
> Currently we also have standalone version of py-api 
> This version expose to users
> * all topology fields
> * selections from trajectoryanalysis
> * trajectoryanalysis api
> This version also include simple example of how to use it.
> So users can use it for one-time-use tools and prototyping with
> ability to use all numpy/scipy and other python related machinery.
> Version that listed in changeset on gerrit also includes possibility
> for pipelining modules
> So it can pass data between them or use many modules (e.g. select,
> distance, sasa, rdf, any c++ api module), reading trajectory only
>> There's widespread interest in something like this, and active work
>> over the medium term from some of our US colleagues, but if SIP is
>> vehicle for exposing a C++ API to python, then we probably need
>> to do some design work to make a C++ layer suitable for that, or a
>> python layer on top of the SIP. Particularly because "exposure to
>> Python" was never part of Teemu's initial design.
> Some design work was already done, but there still many things that
> can be improved.
> However even current version already usable for simple tools.
> PS biod link wasnt worked because of electricity work in server room
> =) now links should work
>> Mark Abraham писал 09-03-2017 17:42:
>> It's time to start preparing for this year's release. Consistent
>> previous practice, we will have a soft deadline for work proposed
>> inclusion to have appeared in Gerrit in approximately final form,
>> we'll make a release candidate from the first patch on a new
>> release-2017 branch. That branch will thereafter be open, in the
>> way, for all manner of fixes, docs and tests, with patches
>> expected to
>> focus on stability, correctness and minimal disruption.
>> from that branch, we might make a future release candidate, and at
>> some point a final release.
>> For target dates I propose:
>> * April 1 - proposals available in gerrit in approximately final
>> * May 1 - ship release candidate
>> * May 15 - ship second release candidate if that seems useful
>> * June 1 - ship 2017 final if there are no known serious problems
>> There's a fair bit of work currently in gerrit that is refactoring
>> suit long term needs. There's no strong reason to push to get such
>> things in the release, but review and submission are welcome in
>> usual way. I do suggest that we avoid any further cleanup patches
>> touch lots of lines or lots of files until after the 2017 release,
>> make life easier on those preparing work for that release and
>> fixes forward.
>> After we ship 2017, and have incorporated any bug fixes we want to
>> back port, I will make a final 5.1 patch release and declare that
>> branch closed to future work. Similarly, I'll make another 2016
>> release, and thereafter that branch will have the policy of being
>> only to fixes for things that might affect scientific results.
>> My focus will be on the integration of Aleksei's PME-on-GPU
>> implementation, as well as several non-code GROMACS activities.
>> Erik hopes to rush out some new templated kernel infrastructure,
>> he has a grant application on April 6, so perhaps we will relax
>> April 1 cutoff for that - but based on history, there will be no
>> promises either way ;-)
>> David's energy analysis framework is pretty close to good shape,
>> some final effort there would be a nice achievement.
>> Berk hopes to get in some more of his conserved quantities for
>> integrators, and perhaps with Viveca some of the AWH
>> (that needs a lot of refactoring, however...)
>> Are there any other things people would like to flag for
>> Are there good reasons to suggest alternative dates?
>> Best Regards,
>> Alexey 'Alexxy' Shvetsov, PhD
>> Department of Molecular and Radiation Biophysics
>> FSBI Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
>> Leningrad region, Gatchina, Russia
>> mailto:alexxyum at gmail.com
>> mailto:alexxy at omrb.pnpi.spb.ru
> Best Regards,
> Alexey 'Alexxy' Shvetsov, PhD
> Department of Molecular and Radiation Biophysics
> FSBI Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
> Leningrad region, Gatchina, Russia
> mailto:alexxyum at gmail.com
> mailto:alexxy at omrb.pnpi.spb.ru
> 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
>  or send a mail to gmx-developers-request at gromacs.org.
> Erik Lindahl <erik.lindahl at gmail.com>
> Professor of Biophysics, Dept. Biochemistry & Biophysics, Stockholm
> Science for Life Laboratory, Box 1031, 17121 Solna, Sweden
>  http://www.mdanalysis.org/pages/basic_example/
>  http://mdtraj.org/1.8.0/examples/introduction.html
>  http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List
>  http://www.gromacs.org/Support/Mailing_Lists
Alexey 'Alexxy' Shvetsov, PhD
Department of Molecular and Radiation Biophysics
FSBI Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
Leningrad region, Gatchina, Russia
mailto:alexxyum at gmail.com
mailto:alexxy at omrb.pnpi.spb.ru
More information about the gromacs.org_gmx-developers