[gmx-developers] plans for GROMACS 2017 release cycle

[Eric Irrgang]

My goals for Python bindings would not be to run a Python script from
Gromacs, but to run Gromacs from Python. To do so, a lot of work is
warranted in generalizing the public and library APIs to decouple Gromacs
tools from terminal I/O and file I/O, and to make it easier to implement
module runners using a stable interface. The SIP-based project seems to be
tightly coupled to some fairly low-level details, while it seems reasonable
to me that the bindings for a scripting interface should be entirely
against public API functionality.

Two more goals are to allow copy-less data access across the bindings (via
the Python buffer protocol) and to provide the means for C++ objects to be
bound together via the Python interface (potentially from different shared
objects) so that the Python interpreter and bindings objects can be
invisible non-participants in C++-level API, particularly when MPI is
involved.

I don't know if these things are possible with SIP, but I'm having good
results with pybind11.

Additionally, I think it is important to offer compatibility with things
like numpy and Eigen-based tools without introducing dependencies.

A fair bit of work is warranted on the C++ side that would be influenced by
other issues. For instance, the future of reference-counted vector array
data structures ( https://redmine.gromacs.org/issues/1017 )

I was about to start a Redmine issue looking at just the trajectory
read/write interfaces with the idea of bringing the various trajectory
editing/manipulation functionality to a public API level, but would it be a
hassle in preparing for the 2017 release candidate to have a chain of
Gerrit changes sitting there with brand new API features?



On Thu, Mar 9, 2017 at 11:03 AM, Mark Abraham <mark.j.abraham at gmail.com>
wrote:

> 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
>
> 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 ht
> tp://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?
>
> 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.
>
> 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
>>
>
> --
> 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/20170309/ad1764e9/attachment.html>