[gmx-developers] Python interface for Gromacs

[jhaas at gwdg.de]

Hi all,

> I was aware of pymacs but I wanted something which is pythonic from the
> interface.
YAA - Yet Another Approach:

I am using the boost.python libraries for python export (on a C++ project
though,) and despite some complexity in the error messages usage is
straightforward:

void export_SuperPose()
{
  class_<SuperpositionResult>("SuperpositionResult", init<>())
    .def_readwrite("Rmsd",
                   &SuperpositionResult::rmsd)
    .def_readwrite("Transformation",
               &SuperpositionResult::transformation)
  ;
  def("IterativeSuperposition", &IterativeSuperposition);

> Also I wanted something which doesn't generate any dependencies and doesn't
> add any complexity to the makefile.
That is a very good point, though I never used ctypes, at a first glance
your code looks straightforward.
I assume the difference is that ctypes calls functions from a library and
swig/boost.python approaches allow access to global variables, ie allowing
to construct a python shell for gmx as such?
But since there is no real gmx session, but rather scripts connecting
different gmx programs, there seems nothing one cannot achieve by using
ctypes.
are there any cross-platform issues? it seems to run smoothly on OS X,
linux and windows systems...

>This is why I chose to use ctypes.
>
> How many functions did you wrap with swig? Would it really be much more
work
> to do it with ctypes? Can you upload you lib somewhere so we can take a
look
> at the interface? The problem with the libs, I have seen so far which have
> been wrapped with swig, is that they keep the C interface. I think you only
> have half the advantage of using python if the interface is still C-like.
I
one definitely should be able to do the usual python iterating through
lists (and list comprehension) without needing to write an explicit export
function

cheers Juergen
> think reading a trajectory has to work the same way as you read any other
> file in python. Thus I made sure this works:
>
> from xdrfile import *
> x=xdrfile("test.xtc")
> for f in x: #f frame
>     print f.x
>
> the same way e.g. reading pdb should work as
> p=pdb("some.pdb")
> for a in p: #a atom
>    print a.x,a.y,a.z,a.type,a.beta
>
> The wrapper now also autodetects trr and numpy (if numpy is installed the
> coordinates are a Numpy array). Still it is very small.
> latest version: https://cmb.ornl.gov/Members/z8g/xdr.tgz/at_download/file
>
> I think it would be great to have also wrapper for the analysis library and
> for reading other files. But I wouldn't like to have a SWIG interface with
> is not pythonic.
>
> We certainly don't want to have depencies of Gromacs on Python. You can't
> run python everywhere. But I think it would be good to have a CVS
repository
> for a python wrapper of the other Gromacs libs (and python tools) so
that it
> is possible to collabrate.
>I asked whether the xdr python wrapper can be
> added to the xdrlib because it only reads trajectories and thus fits
best in
> that repository. Also by keeping it seperate to the rest of Gromacs it is
> possible to use it without installing all of Gromacs.
>
> Roland
>
> On Sat, Mar 28, 2009 at 12:35 AM, nizamov.shawkat at gmail.com <
> nizamov.shawkat at gmail.com> wrote:
>
>> Hi all!
>>
>> It looks like there is a plenty of developers trying to create a Python
>> interface for this or that particular function of Gromacs. There is
>> fairly functional (and stable?) pymacs package. I didn't look much in
>> it, but it goes directly extending Python with manually crafted C
>> wrapper. Others are creating some useful wrappers using ctypes (previous
>> message in the list). Lately I also did some work in this area, but
>> wasn't interested in discussing it before some actual results obtained.
>> But as surprisingly much effort of different researchers got devoted to
>> Pythonic interface, maybe it's time to discuss before reinventing the
>> wheel?
>>
>> Last week I created a single SWIG wrapper around all 3 libraries -
>> libgmx, libmd and libgmxana. As a proof of concept I also successfully
>> (but implemented only partially) ported gmxdump.c to Python using this
>> wrapper. Rewriting gmxdump.c in pure Python was straightforward. I hope,
>> that there will be no large obstacles for using other library routines
>> also. The task of creating wrapper for scripting language is on
>> developers section of Gromacs wiki right after the task of moving
>> analyzing functions to core library (libgmxana). But it is not clear -
>> if scripting interface with Python wrapper is going to be mainline tool
>> for analyzing  data, converting to and from different formats (XML and
>> gnuplot are also mentioned on developers section), setup the simulation,
>> interfacing with user,  etc? That means that in the long term Gromacs
>> will be strictly dependent on Python and its bindings and only a
>> simulation core will remain in pure C and available mostly as a library.
>> Did I get the idea correctly?
>>
>> Practical question is - how can different developers collaborate on such
>> Python wrapper for Gromacs ? I would spend some of my spare time for
>> improving SWIG wrapper (that is already usable) for my own research, but
>> working in a team makes much more sense in the open-source world.
>>
>> WBR
>> Shawkat
>> _______________________________________________
>> gmx-developers mailing list
>> gmx-developers at gromacs.org
>> http://www.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.
>>
>
>
>
> --
> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
> 865-241-1537, ORNL PO BOX 2008 MS6309
>