[gmx-developers] plans for GROMACS 2017 release cycle

Thu Mar 9 21:01:44 CET 2017

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).

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/ or
>> http://mdtraj.org/1.8.0/examples/introduction.html. 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
>
> 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 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.
>

-- 
--
Erik Lindahl <erik.lindahl at gmail.com>
Professor of Biophysics, Dept. Biochemistry & Biophysics, Stockholm
University
Science for Life Laboratory, Box 1031, 17121 Solna, Sweden
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20170309/1c5b6fd8/attachment.html>