Hi,<div><br></div><div>I personally don't believe that (web-)forums help the discussions over archived mailing lists. But I think it is important to have a good subject for the mail-thread to be able to find a thread later. Ideally we would have a summary/conclusion of important email-threads on the wiki, but I'm doubtful that we find someone volunteering to write those summaries.</div>
<div><br></div><div>I suggested a while ago to have a monthly teleconference to have a monthly opportunity to hear the status of various parts of the code and to discuss problems and ideas. I think it might also increase collaboration and participation. In case we want to do this I'm happy to organize it (e.g. find the best time and date).</div>
<div><br></div><div>Roland</div><div><br></div><div><br><div class="gmail_quote">On Thu, Sep 9, 2010 at 7:54 AM, Shirts, Michael (mrs5pt) <span dir="ltr"><<a href="mailto:mrs5pt@eservices.virginia.edu">mrs5pt@eservices.virginia.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">So, great discussion! This brings one thought to mind:<br>
<br>
How can we improve the discussion to better convert the expertise and<br>
person-hours into better code -- especially going beyond the developers who<br>
are in Sweden and can communicate face-to-face easily?<br>
<br>
Gromacs is becoming such a widely used tool -- and widely modified -- tool.<br>
Are there changes in the web tools that we can make -- ways that these sorts<br>
of conversations can be documented on the wiki in a better form, or that we<br>
can use forums to better use all the ideas and effort, and not duplicate<br>
effort?<br>
<div class="im"><br>
Best,<br>
~~~~~~~~~~~~<br>
Michael Shirts<br>
Assistant Professor<br>
Department of Chemical Engineering<br>
University of Virginia<br>
<a href="mailto:michael.shirts@virginia.edu">michael.shirts@virginia.edu</a><br>
(434)-243-1821<br>
<br>
<br>
</div>> From: Sébastien Buchoux <<a href="mailto:sebastien.buchoux@u-picardie.fr">sebastien.buchoux@u-picardie.fr</a>><br>
> Reply-To: Discussion list for GROMACS development <<a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a>><br>
> Date: Thu, 9 Sep 2010 07:13:33 -0400<br>
<div class="im">> To: "<a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a>" <<a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a>><br>
</div><div class="im">> Subject: Re: [gmx-developers] Python interface for Gromacs<br>
><br>
</div><div><div></div><div class="h5">> Hi,<br>
><br>
> On 09/09/2010 08:38 AM, David van der Spoel wrote:<br>
>> People in the Lindahl group are working on parallellizing analysis<br>
>> tools because they are quickly becoming the bottleneck. We run<br>
>> simulations of large systems on hundreds of processors, and due to<br>
>> checkpointing this can be done largely unattended. Analysis can take a<br>
>> lot of effort, both hardware (CPU, Disk) and organisational. I think<br>
>> the prime advantage of a scripting languagae like Python could be<br>
>> organisational.<br>
><br>
> From my experience, Python is too slow to really make analysis tools<br>
> (or any heavy computational work) on its own. But it can use C/C++ libs<br>
> like a charm... hence a Python interface! :)<br>
><br>
>> @portability: I have tried compiling numpy a few times on mac & linux<br>
>> without success. As long as numpy is not in the main python<br>
>> distribution it will not be useful...<br>
><br>
> Numpy compilation can indeed be... troublesome. but I don't think it is<br>
> mandatory.<br>
> From my experience, Numpy is great for pure Python programming so it<br>
> would be useful for a 100% Python analysis tool. But with the use of C<br>
> to do the hard work, the advantage a Numpy is pretty slim and I think<br>
> that new Python types defined within a C extension are more efficient<br>
> since they allow Python users to access C objects directly (given the<br>
> use of a descent interface).<br>
> This is specially true when dealing with already written C objects that<br>
> are very different from C numarrays (i.e. they would need to be<br>
> "translated" to Numpy arrays prior to use any of the Numpy routines).<br>
> IMHO, the #1 priority of Numpy is much more to ease life of pure Python<br>
> programmers than to be useful to C extension programmers.<br>
><br>
> Sébastien<br>
><br>
><br>
> --<br>
> Sébastien Buchoux, MC<br>
> UMR 6022 - Génie Enzymatique et Cellulaire / Enzyme and Cell Engineering<br>
> Université Picardie Jules Verne (UPJV)<br>
> 33, rue Saint Leu, 80000 Amiens, France<br>
> tel: +33(0)3 22 82 74 73 - email: sebastien.buchoux[at]<a href="http://u-picardie.fr" target="_blank">u-picardie.fr</a><br>
><br>
> Pourquoi pas de pièces jointes Word? / Why no Word attachments?<br>
> <a href="http://www.gnu.org/philosophy/no-word-attachments.html" target="_blank">http://www.gnu.org/philosophy/no-word-attachments.html</a><br>
><br>
><br>
> --<br>
> gmx-developers mailing list<br>
> <a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>
> <a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
> Please don't post (un)subscribe requests to the list. Use the<br>
> www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br>
<br>
--<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the<br>
www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov">cmb.ornl.gov</a><br>865-241-1537, ORNL PO BOX 2008 MS6309<br>
</div>