Comment on revision rbebea4a817b18ea7004703d50ee13559f737d57b in mdanalysis

[mdana...@googlecode.com]

Comment by orbeckst:

Score: Positive

General Comment:
Hi Jan,

nice of you to add a DMS reader. Looking good but see comments in the code.

Don't forget to add a note to CHANGELOG and update the table of formats in
the docs (coordinates/__init__.py
http://packages.python.org/MDAnalysis/documentation_pages/coordinates/init.html#id1
and topology/__init__.py
http://packages.python.org/MDAnalysis/documentation_pages/topology/init.html).

-- Oli

Line-by-line comments:

File: /package/MDAnalysis/topology/DMSParser.py
(rbebea4a817b18ea7004703d50ee13559f737d57b)
===============================================================================

Line 25: import numpy, sqlite3, collections
-------------------------------------------------------------------------------
collections.OrderedDict is not in Python 2.5 and 2.6 so you have to add a
workaround because MDAnalysis is supposed to be compatible with Python 2.5.

Please get odict.py (e.g. from GromacsWrapper, can't remember the original
source from the top of my head... see
http://orbeckst.github.com/GromacsWrapper/README.html) and add it as
util/odict.py. Then do something like

try:
from collections import OrderedDict
except ImportError:
from MDAnalysis.util.odict import odict as OrderedDict

Or use http://pypi.python.org/pypi/odict; we could make it a dependency in
setup.py if we can't find collections.OrderedDict.


File: /package/MDAnalysis/topology/core.py
(rbebea4a817b18ea7004703d50ee13559f737d57b)
===============================================================================

Line 87: return math.sqrt((bond[0]**2)+(bond[1]**2)+(bond[2]**2))
-------------------------------------------------------------------------------
I know that this is not your code but while you are at it could ypu get rid
of math and use proper NumPy? We even already have
http://packages.python.org/MDAnalysis/documentation_pages/core/util.html#MDAnalysis.core.util.norm

For more information:
https://code.google.com/p/mdanalysis/source/detail?r=bebea4a817b18ea7004703d50ee13559f737d57b

[Andy Somogyi]

What is the advantage to still supporting python 2.5?, 2.6 has been
around for at least 5 years or so, and 2.6 is a req for matplotlib
anyway.

Sent from my iPad

On Jan 29, 2013, at 11:21 PM, "mdana...@googlecode.com"

> --
> You received this message because you are subscribed to the Google Groups "MDnalysis-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mdnalysis-dev...@googlegroups.com.
> To post to this group, send email to mdnalys...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Oliver Beckstein]

Hi folks,

Andy brought up the question if MDAnalysis should really continue to try to support Python 2.5:

On 29 Jan, 2013, at 21:39, Andy Somogyi wrote:

> What is the advantage to still supporting python 2.5?, 2.6 has been around for at least 5 years or so, and 2.6 is a req for matplotlib anyway.

Have any of the developers got an opinion?

I know we would have liked to be 2.4 compatible (so that one can run even on ancient clusters) but that was too complicated so I think since around 0.7 it's been 2.5.

What are the advantages of keeping or dropping support for 2.5?

Note that if the next release is 0.8 then that would be a good time to do some clean up including dropping support for older python versions.

I'd like to hear opinions. Once we have a better picture and if we decide to drop 2.5 then we can poll the users list and see how big or small of an uproar this creates.

Oli

--
Oliver Beckstein * orbe...@gmx.net
skype: orbeckst * orbe...@gmail.com

[Sébastien Buchoux]

Hi,

On Tuesday 29 January 2013 23:25:41 Oliver Beckstein wrote:
> Andy brought up the question if MDAnalysis should really continue to try to
> support Python 2.5:
> On 29 Jan, 2013, at 21:39, Andy Somogyi wrote:
> > What is the advantage to still supporting python 2.5?, 2.6 has been around
> > for at least 5 years or so, and 2.6 is a req for matplotlib anyway.
> Have any of the developers got an opinion?

I am with Andy on this one.
I think that most of the users also use matplotlib or other tools that require
2.6 or higher. I hardly see the point of supporting 2.5.

> I know we would have liked to be 2.4 compatible (so that one can run even on
> ancient clusters) but that was too complicated so I think since around 0.7
> it's been 2.5.

I see the point. Yet, since MDAnalysis is not parallelized, I see no advantage
about using it on a cluster for analysis and nobody (sane) build their systems
directly on their clusters since most of the clusters are used via batch jobs.

> What are the advantages of keeping or dropping support for 2.5?

Dropping support 2.5 will ease a future migration to python 3.0: python 2.6
and higher incorporate feature and syntax from python 3.0.
(See: http://docs.python.org/2/whatsnew/2.6.html)

> Note that if the next release is 0.8 then that would be a good time to do
> some clean up including dropping support for older python versions.

+1 clean ups are always a good things! :)

> I'd like to hear opinions. Once we have a better picture and if we decide to
> drop 2.5 then we can poll the users list and see how big or small of an
> uproar this creates.

Agree with that too.

Séb

[Andy Somogyi]

That is a valid point about older clusters. However, our clusters are
so worthlessly configured (some even have gcc downgraded to 2.9??), I
don't even bother with the system software, I install everything into
a group/local dir, and prepend the env vars.

Sent from my iPad

[Sébastien Buchoux]

On Wednesday 30 January 2013 01:56:08 Andy Somogyi wrote:
> That is a valid point about older clusters. However, our clusters are
> so worthlessly configured (some even have gcc downgraded to 2.9??), I
> don't even bother with the system software, I install everything into
> a group/local dir, and prepend the env vars.

Just to satisfy my curiosity Andy,
For what reasons do you need MDAnalysis directly on your clusters?

[Andy Somogyi]

On Jan 30, 2013, at 5:25 AM, "Sébastien Buchoux"

<sebastie...@gmail.com> wrote:

> Just to satisfy my curiosity Andy,
> For what reasons do you need MDAnalysis directly on your clusters?

Mdanalysis is actually one of the core parts of a coarse grained
dynamics system I'm writing. Idea is that it gathers statistics from
an ensemble of short md trajectories, identifies collective variables,
advects the collective modes, these define a global deformation of a
molecule,then runs an ensemble of md again on the deformed structure,
then repeat for n coarse grained time steps.

Python is ok because 99% of the time is spent in md.

[Jan Domanski]

Being the super-conservative player that I am, I'll change to a python 2.5 compatible way of doing this. The effort and extra lines of code here are minimal – maybe somewhere out there there is a customer, (khm, user) who for some reason that I cannot conceive NEEDS python 2.5 compatibility.

Let's change back to the python2.6 formulation, if that'll be settled (i'm neutral to that change).

Jan

[Oliver Beckstein]

Hi,

We are discussing if we should drop support for Python 2.5 from MDAnalysis. Python 2.5 is several years out of date. Significant improvements have been made both to the Python language core (e.g. with statements by default) and the standard library (e.g. collections) that, when used, result in cleaner code.

To summarize the discussion so far:

1) Dropping Python 2.5 support is not likely to inconvenience many users.
- MDAnalysis is believed to be typically used on local workstations with recent version of numpy/scipy/matplotlib and (due to matplotlib) with Python >= 2.6
- If MDAnalysis is used in different functionality (e,g. as part of a control/monitor simulation framework) on a cluster then one typically has to build one's own Python software stack as per-installed Python software is generally outdated/incomplete.

2) Dropping support 2.5 will ease a future migration to python 3.0: python 2.6 and higher incorporate feature and syntax from python 3.0. (See: http://docs.python.org/2/whatsnew/2.6.html)

3) An upcoming 0.8 release would be the ideal time to drop support.

4) Dropping support will allow some code-cleanup and getting rid of some legacy code constructs, overall (hopefully) resulting in cleaner and more robust code.


The opinion so far appear to be in favour of dropping support.

Do you have anything to add from a developer's point of view?

If, in a week's time, there's consensus on dropping Python 2.5 then I'll send a similar email to the users list and ask for opinions there.

Thanks,
Oliver

p.s.: It was great to meet up at Biophysics!