[gmx-developers] Python interface for Gromacs

Shirts, Michael (mrs5pt) mrs5pt at eservices.virginia.edu
Thu Sep 9 13:54:14 CEST 2010

So, great discussion!  This brings one thought to mind:

How can we improve the discussion to better convert the expertise and
person-hours into better code -- especially going beyond the developers who
are in Sweden and can communicate face-to-face easily?

Gromacs is becoming such a widely used tool -- and widely modified -- tool.
Are there changes in the web tools that we can make -- ways that these sorts
of conversations can be documented on the wiki in a better form, or that we
can use forums to better use all the ideas and effort, and not duplicate

Michael Shirts
Assistant Professor
Department of Chemical Engineering
University of Virginia
michael.shirts at virginia.edu

> From: Sébastien Buchoux <sebastien.buchoux at u-picardie.fr>
> Reply-To: Discussion list for GROMACS development <gmx-developers at gromacs.org>
> Date: Thu, 9 Sep 2010 07:13:33 -0400
> To: "gmx-developers at gromacs.org" <gmx-developers at gromacs.org>
> Subject: Re: [gmx-developers] Python interface for Gromacs
> Hi,
> On 09/09/2010 08:38 AM, David van der Spoel wrote:
>> 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.
>  From my experience, Python is too slow to really make analysis tools
> (or any heavy computational work) on its own. But it can use C/C++ libs
> like a charm... hence a Python interface! :)
>> @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...
> Numpy compilation can indeed be... troublesome. but I don't think it is
> mandatory.
>  From my experience, Numpy is great for pure Python programming so it
> would be useful for a 100% Python analysis tool. But with the use of C
> to do the hard work, the advantage a Numpy is pretty slim and I think
> that new Python types defined within a C extension are more efficient
> since they allow Python users to access C objects directly (given the
> use of a descent interface).
> This is specially true when dealing with already written C objects that
> are very different from C numarrays (i.e. they would need to be
> "translated" to Numpy arrays prior to use any of the Numpy routines).
> IMHO, the #1 priority of Numpy is much more to ease life of pure Python
> programmers than to be useful to C extension programmers.
> 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
> Pourquoi pas de pièces jointes Word? / Why no Word attachments?
> http://www.gnu.org/philosophy/no-word-attachments.html
> -- 
> 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.

More information about the gromacs.org_gmx-developers mailing list