[gmx-developers] Python interface for Gromacs

[Shirts, Michael (mrs5pt)]

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
effort? 

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