[gmx-developers] Python interface for Gromacs

[Shirts, Michael (mrs5pt)]

Hi, Sébastien:
  
My personal thinking is that the obvious place to start is with the analysis
tools.  The main gromacs distribution is so optimized, and speed and
parallelization has cause different code components to be so intertwined,
that even if some parts were pythonified, it would not necessarily make
extending gromacs functionality any easier.  Even if it would make it easier
to write new python parts, there is so much interdependence you would still
have to rewrite the non-Python parts!  Maybe post version 5 this will make
more sense, but I don't see it as something that will make the community
more productive for the near or midrange future -- and would likely cause
result in many grey hairs for whoever tries to do it.

However, I think there are some potential places Python might be useful:

1) Python integration the analysis tools is a much more realistic and
potentially useful goal.  Analysis tools are mostly independent, and there
are a lot of numpy routines that would make certain analysis routines much
more portable and easy to write.  Also, analysis is usually not
time-critical, nor usually parallelize, so it's much easier to work with --
I haven't had good luck with Python parallelization, anyway.  Additionally,
the experience with Gromacs data structures gained with working on the
easier analysis tools would be extremely valuable for further integration.
I personally would consider using any pythonized analysis tools and am
willing to provide feedback and help!

2) After some work on analysis tools is done, a python version of grompp and
other setup tools may be useful as well, since the parsing (especially of
the topolgies) is a bit messy.  With this, then all the routines to
manipulate the python datafiles and data structures would be in place.

AFTER this, I could see a decade down the road a version of Gromacs that was
80% python and then 20% C/assembly/CUDA for the speed bottlenecks; and I
think that could very well be a good thing.  But I think that would require
a large number of intermediate steps along the way (such as those discussed
above) and those steps would have to be chosen very carefully.

Best,
~~~~~~~~~~~~
Michael Shirts
Assistant Professor
Department of Chemical Engineering
University of Virginia
michael.shirts at virginia.edu
(434)-243-1821


> From: Sébastien Buchoux <sebastien.buchoux at u-picardie.fr>
> Reply-To: Discussion list for GROMACS development <gmx-developers at gromacs.org>
> Date: Wed, 8 Sep 2010 15:51:47 -0400
> To: "gmx-developers at gromacs.org" <gmx-developers at gromacs.org>
> Subject: [gmx-developers] Python interface for Gromacs
> 
> Dear Gromacs developers,
> 
> Interfacing Gromacs with Python have been discussed on this
> list last year (mainly here:
> http://lists.gromacs.org/pipermail/gmx-developers/2009-March/003177.html) but,
> according to the Gromacs roadmap
> (http://www.gromacs.org/Developer_Zone/Roadmap), things are still to be done.
> Sorry if decisions were made in the meantime making this email out of scope.
> 
> I have been using Gromacs for a few years now and lately I have been
> playing with Gromacs source code. More precisely, I wanted to interface
> some of the Gromacs core stuff (pbc, neighbour searching...) with Python.
> To do so, I used pure C extensions (no C types nor SWIG) to handle calls
> to the C libs and to define new Python types to store gromacs-friendly C
> objects while allowing a more "pythonic" way to access them. (This
> approach is actually close to what the Numpy/Scipy guys did.)
> This is still at pretty early stage but it could be extended to
> interface all the Gromacs libraries with Python.
> 
> Where is my point? While I don't think inserting Python-related stuff
> directly into Gromacs source code would be a good idea, a kind of
> "official Python interface for Gromacs" developed at the same time as
> Gromacs would great because:
> - This would be a way to reflect Gromacs API changes into the interface
> more or less seamlessly.
> - "Modularizing the analysis tools" and "making the analysis library a
> true callable library" (cf. roadmap) could also be done.
> - One project would be more visible than a few ones.
> - Python is cool!
> 
> What do you think?
> 
> Sébastien
> 
> --
> 
> Sébastien Buchoux, MC
> UMR 6022 - Génie Enzymatique et Cellulaire / Enzyme and Cell
> Engineering Université Picardie Jules Verne (UPJV)
> 33, rue Saint Leu, 80000 Amiens, France
> tel: +33(0)3 22 82 74 73 - email: sebastien.buchoux[at]u-picardie.fr
> 
> 
> -- 
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.