[gmx-developers] Python interface for Gromacs

[Sébastien Buchoux]

Hi,

On 09/09/2010 12:22 AM, 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.
>    

I probably didn't make myself clear enough: my point is really not to 
inject Python code into Gromacs but to make use of the potential of 
Python directly to work with C libs to write a wrapper related but 
independent (i.e. different dev branch). This would involved virtually 
no Python-related code in the main Gromacs distribution. All the 
Python-related C code would be in the Python wrapping distribution. I 
may send a proof of concept to illustrate this if you want.


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

The example of Python wrapping I mentioned in my previous email was 
related to the dev of an analysis tool so I totally agree with this point.
Actually, I started this tool using 100% Python but it was painfully 
slow when playing with big systems. So I started to think about using 
machinery from Gromacs... and discovered that it was much more 
straightforward that I thought in the first place (and that it didn't 
require any hacks in the Gromacs source code).


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

I think this is the only place in the core of Gromacs where Python could 
really be useful (and efficient).

> 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.
>    
This would be cool! But even 10 years from now I don't see Python being 
efficient enough (in terms of speed of execution) to be involved with 
such a high percentage in any computational ogre such as Gromacs... I 
hope I am wrong though!

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