[gmx-developers] Python interface for Gromacs

[David van der Spoel]

On 2010-09-09 00.22, Shirts, Michael (mrs5pt) wrote:
> 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!

People in the Lindahl group are working on parallellizing analysis tools 
because they are quickly becoming the bottleneck. We run simulations of 
large systems on hundreds of processors, and due to checkpointing this 
can be done largely unattended. Analysis can take a lot of effort, both 
hardware (CPU, Disk) and organisational. I think the prime advantage of 
a scripting languagae like Python could be organisational.

@portability: I have tried compiling numpy a few times on mac & linux 
without success. As long as numpy is not in the main python distribution 
it will not be useful...
Let the flamewars begin.

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


-- 
David van der Spoel, Ph.D., Professor of Biology
Dept. of Cell & Molec. Biol., Uppsala University.
Box 596, 75124 Uppsala, Sweden. Phone:	+46184714205.
spoel at xray.bmc.uu.se    http://folding.bmc.uu.se