[gmx-developers] plans for GROMACS 2017 release cycle

Fri Mar 10 07:48:02 CET 2017

Hi Alexey!

I'm well aware there hasn't been a vivid discussion in Gerrit; I think one reason for that is the comments in redmine #1625 (mostly by Teemu) expressing concerns about the design choices that weren't addressed/discussed much (not blaming anybody, just an observation).

Now, there are of course several of us who could have been more involved to push this, but we also have another dozen of things to push, so we need to rely a bit on self-organization :-)  Rather than arguing about the past, I think the key conclusion is that we need a public discussion thread with use cases and API design suggestions with links in redmine asap. 

Cheers,

Erik

--
Erik Lindahl <erik.lindahl at scilifelab.se>
Professor of Biophysics
Science for Life Laboratory
Stockholm University & KTH
Office (SciLifeLab): +46 8 524 81567
Cell (Sweden): +46 73 4618050
Cell (US): +1 267 3078746

> On 10 Mar 2017, at 06:45, Alexey Shvetsov <alexxy at omrb.pnpi.spb.ru> wrote:
> 
> Hi Erik!
> 
> Erik Lindahl писал 09-03-2017 23:01:
>> Hi,
>> 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 :-)
>> Cheers,
>> Erik
>> On Thu, Mar 9, 2017 at 8:52 PM, Alexey Shvetsov
>> <alexxy at omrb.pnpi.spb.ru> wrote:
>>> Hi!
>>> Mark Abraham писал 09-03-2017 19:03:
>>> Hi,
>>> On Thu, Mar 9, 2017 at 3:49 PM Alexey Shvetsov
>>> <alexxy at omrb.pnpi.spb.ru> wrote:
>>> Hi!
>>> I'd like to add python api for gromacs as a suggestion (however we
>>> need
>>> 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/ [1] or
>>> http://mdtraj.org/1.8.0/examples/introduction.html [2]. What lessons
>>> have
>>> 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
>>> prototyping?
>> Currently we also have standalone version of py-api [1]
>> 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
>> once.
>>> 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
>>> the
>>> vehicle for exposing a C++ API to python, then we probably need
>>> first
>>> 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.
>> [1]
>> http://biod.pnpi.spb.ru/gitweb/?p=alexxy/gromacs-pyapi.git;a=summary
>> [3]
>> PS biod link wasnt worked because of electricity work in server room
>> =) now links should work
>>> Mark
>>> Mark Abraham писал 09-03-2017 17:42:
>>> Hi,
>>> It's time to start preparing for this year's release. Consistent
>>> with
>>> previous practice, we will have a soft deadline for work proposed
>>> for
>>> inclusion to have appeared in Gerrit in approximately final form,
>>> then
>>> we'll make a release candidate from the first patch on a new
>>> release-2017 branch. That branch will thereafter be open, in the
>>> usual
>>> way, for all manner of fixes, docs and tests, with patches
>>> expected to
>>> focus on stability, correctness and minimal disruption.
>>> Thereafter,
>>> 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
>>> form
>>> * 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
>>> to
>>> 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
>>> the
>>> usual way. I do suggest that we avoid any further cleanup patches
>>> that
>>> touch lots of lines or lots of files until after the 2017 release,
>>> to
>>> make life easier on those preparing work for that release and
>>> merging
>>> 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
>>> patch
>>> release, and thereafter that branch will have the policy of being
>>> open
>>> 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,
>>> but
>>> he has a grant application on April 6, so perhaps we will relax
>>> the
>>> 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,
>>> so
>>> 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
>>> implementation
>>> (that needs a lot of refactoring, however...)
>>> Are there any other things people would like to flag for
>>> attention?
>>> Are there good reasons to suggest alternative dates?
>>> Mark
>>> --
>>> 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 [4]
>> before posting!
>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists [5]
>> * For (un)subscribe requests visit
>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
>> [6] 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
>> University
>> Science for Life Laboratory, Box 1031, 17121 Solna, Sweden
>> Links:
>> ------
>> [1] http://www.mdanalysis.org/pages/basic_example/
>> [2] http://mdtraj.org/1.8.0/examples/introduction.html
>> [3] http://biod.pnpi.spb.ru/gitweb/?p=alexxy/gromacs-pyapi.git;a=summary
>> [4] http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List
>> [5] http://www.gromacs.org/Support/Mailing_Lists
>> [6] https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> 
> -- 
> 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