Adaptation of existing python to allow reading of XYZ files in conjunction with 
a PDB or PSF file.

The KDTree module does not compile with the Intel Compiler v9.0 and python
2.3. Using gcc seems to work, though. (r125) 

Purpose of code changes on this branch:
The docs lay out a draft for the Trajectory API. This should guide us in
the future when implementing additional readers/writers for other formats.
For the new Gromacs XTC/TRR formats I tried to adhere to the API. The PDB
and CRD formats need to be checked.

When reviewing my code changes, please focus on:
 * Do the Methods and Attributes cover our common use cases?
 * Anything else that should be defined?
 * Do we need a "API version" attribute?

To reproduce this memory problem (note that the severity of the problem will of 
course relate to total system memory on your machine):

1. Set up a full unit test:

>>>import MDAnalysis.tests
>>>MDAnalysis.tests.test(verbose=3, label='full')

2. Check for memory usage during the check for fixed issue 34 (as in the last 
line from the snippet of my log below):

test_rewind_xdrtrj (MDAnalysis.tests.test_coordinates.TestTRRReader) ... ok
test_slice_xdrtrj (MDAnalysis.tests.test_coordinates.TestTRRReader) ... ok
Check for fixed Issue 34 ... 

This will probably only be possible if total system memory is actually a 
problem on your system and the test 'stalls' for this check.

I checked memory usage after the system slowed down substantially with:

top -u bioc1009 | head -15 

and found that 0.9845 of system memory was being used (i.e., my system was 
virtually unusable during this portion of the unit test, and did not improve 
over several minutes).

from MDAnalysis import Universe
u = Universe(pdb, xtc) 
PO4 = u.AtomSelect("name PO4")
resPO4 = u.Atomselect( "byres  PO4")

## However there is no way of selecting properties from another predefined ## 
AtomGroup to use in the Atomselect command.

## Normally this wouldn't be a problem by combining the two - i.e.

resPO4 = u.AtomSelect("byres name PO4")

## However I am using LeafletFinder which returns two AtomGroups
## containing the PO4 atoms in each leaflet. I then want to select 
## the residues from the universe corresponding to the residues from each 
## AtomGroup...

L = MDAnalysis.analysis.leaflet.LeafletFinder(u,"name PO4") 
L.atoms(0)  ### Atomgroup containing PO4 atoms in leaflet 0 
L.atoms(1)  ### Atomgroup containing PO4 atoms in leaflet 1
res0 = u.Atomselect( "byres  L.atoms(0)" )

### Is there a way that Atomgroups can be defined and referenced for use
### within the AtomSelect command. This would also be useful for selecting
### between universes - i.e. selections in one universe based on an
### AtomGroup in another.

GROWriter can only write orthorhombic boxes.

See comments 
http://code.google.com/p/mdanalysis/source/browse/trunk/MDAnalysis/coordinates/G
RO.py?spec=svn405&r=405#171

Possibly solve by adding a general method/managed attribute 'native_dimensions' 
to the trajectory API, which converts standard MDAnalysis unitcells back to the 
native form.

What steps will reproduce the problem?
1. Initialize Universe
2. Initialize an XTCWriter instance
3. Try to write to the file using XTCWriter.write_next_timestep(ts)

There are two problems here. Firstly, there seems to be a simple code error in 
line 365 of MDAnalysis/coordinates/xdrfile/core.py:

  self.xdrfile = libxdrfile.xdr_open(filename, 'w')

xdr_open needs to be changed to xdrfile_open. Presumably xdr_open was an older 
function which is now deprecated. Couldn't find any other examples of the code 
attempting to call xdr_open, so I don't think there should be any other 
problems caused by that.
(I haven't sorted my svn commit issues yet so haven't made the change myself...)

Second problem is with units conversion. The XTCWriter.units is set to None, 
rather than being set to the correct units. I can get writing to work correctly 
if I set XTCWriter.units manually after initializing the XTCWriter instance, 
i.e.

  XTCWriter.units={'length': 'nm', 'time': 'ps'}

I think this is supposed to happen within the XTCWriter code, but something has 
gone wrong somewhere.

We should have nice documentation, both from within ipython/python and as a
online reference.

We will use [http://sphinx.pocoo.org/ sphinx] and
[http://docutils.sf.net/rst.html restructured text] (which works well and
allows one to produce very nice online documentation).

Tasks:
  * The current doc strings need to be converted to
[http://sphinx.pocoo.org/rest.html spinx reST]; orbeckst already started
doing this. See, for example, the XTC/TRR code.
  * Set up a sphinx build in doc/sphinx.
  * Generate documentation.

The trajectory data take up ~20 MiB and don't change between releases. They 
should become a 
separate package that could automatically be downloaded via easy_install 
requirements for ''tests''.

XTCReader class to read a Gromacs xtc trajectory.

What steps will reproduce the problem?
1. u = universe('some.psf', 'some.dcd')
2. ts = u.dcd.timeseries(u.P) # P is the protein segmentid
3. The above step gives the error: "Atom number is not an integer" The full
output is below.

What is the expected output? What do you see instead?

/usr/local/lib/python2.6/dist-packages/MDAnalysis/coordinates/DCD.pyc in
timeseries(self, asel, start, stop, skip, format)
    230         # from trajectory file instead of an entire timestep

    231         # XXX needs to be implemented

--> 232         return self._read_timeseries(atom_numbers, start, stop,
skip, format)
    233     def correl(self, timeseries, start=0, stop=-1, skip=1):
    234         ''' Populate a TimeseriesCollection object with timeseries
computed from the trajectory



What version of the product are you using? On what operating system?

Linux, Ubuntu, 9.04, 
Version: MDAnalysis-0.6.0-rc1.tar.gz
Build using standard lapack library


Please provide any additional information below.

u.P.indices() returns a list of Numpy.int64
u.dcd.timestep function checks whether indices are Python integer.

see proposed change of the roles of trunk and branches in the SVN
repository as detailed under DevelopmentWorkflow

It would be nice if the selectAtoms parser did not require white space around 
parentheses.

What steps will reproduce the problem?

u = Universe(PSF,DCD)
W = Writer('foo.pdb')
W.write(u.trajectory.ts)


What is the expected output? What do you see instead?

The Trajectory API Specification currently says that this should work but 
instead I get

--> 343         u = selection.universe
    344         if frame is not None:
    345             u.trajectory[frame]  # advance to frame

AttributeError: 'Universe' object has no attribute 'universe'

The way it is implemented at the moment it cannot work because FrameWriter also 
need atom type information that is not in the Timestep but only accessible via 
a universe.

Either change API definition before 0.7.0 is released or somehow hack around 
– maybe add Universe to Timestep??

What steps will reproduce the problem?
1. u = Universe(psf,dcd) # creates u.PROTEIN, u.WATER
2. u.PROTEIN.selectAtoms('resname PRO')

What is the expected output? What do you see instead?
No AtomGroup is returned but an exception is raised:
 Exception: Must pass in an AtomGroup or Universe to the Selection

Why does the check 
 > MDAnalysis/Selection.py(37)apply()
     36         if not (isinstance(group, Universe) or
isinstance(group,AtomGroup)):
fail? Segment is derived from AtomGroup, albeit via ResidueGroup.

What steps will reproduce the problem?
1. u = MDAnalysis.Universe(psf,dcd) # psf contains segments PROTEIN and WATER
2. u.PROTEIN.coordinate()

What is the expected output? 

  A numpy array of coordinates.

What do you see instead?

 Stack trace below:

/Users/oliver/Biop/Library/python-lib/MDAnalysis/AtomGroup.py in
coordinates(self, ts)
    204         if ts == None:
    205             ts = self.atoms[0].universe.coord
--> 206         return numpy.array(ts[self.indices()], copy=True)
    207     def bfactors(self):
    208         return self.atoms[0].universe.bfactors[self.indices()]

/Users/oliver/Biop/Library/python-lib/MDAnalysis/DCD.py in
__getitem__(self, atoms)
     48         elif type(atoms) == slice or type(atoms) == numpy.ndarray:
     49             return self._pos[atoms]
---> 50         else: raise TypeError
     51     def __len__(self):
     52         return self.numatoms


The problem appears to be that self.indices() returns
 <AtomGroup with 0 atoms>
even though it should be a list of integers.

When running in the debugger I can also not access 
 self._cached_indices


If I do a manual selection,

 p = u.selectAtoms('segid PROTEIN')
 p.coordinates()

everything works as expected and I get the array.

What steps will reproduce the problem?
 python setup.py install --prefix=$HOME/tmp/mydir
(on Mac OS X 10.4.11 + fink/unstable)

What is the expected output? What do you see instead?
 Should install completely under ~/tmp/mydir. It does so for most of the
package it also tries to access the system-wide directory:
 running install_data
 creating /sw/lib/python2.4/site-packages/MDAnalysis
 error: could not create '/sw/lib/python2.4/site-packages/MDAnalysis':
Permission denied

need to transfer local SVN to google SVN, preferrably without loosing the
history. See http://code.google.com/support/bin/answer.py?answer=56673

In order to work seamlessly with Gromacs it should be possible to use the
Gromacs binary [http://wiki.gromacs.org/index.php/.tpr_File tpr] file as
the basis of the topology.

What steps will reproduce the problem?
1. selectAtoms(".....") with a condition where no atoms are present


What is the expected output? What do you see instead?

Exception: No atoms defined for AtomGroup

I just want to be able to select a group of atoms without having this
Exception popup and stop my job

Failed to load Universe(../../AdK_lig/psf/open_adp.psf,co001_adp_mg_co.dcd)
Exception exceptions.AttributeError: '_dcd_C_ptr is not an attribute' in <bound 
method DCDReader.__del__ of < DCDReader 'co001_adp_mg_co.dcd' with 0 frames of 
0 atoms (0 fixed) >> ignored
Segmentation fault

A fast GRO file reader is desirable for better interoperability with Gromacs 
http://www.gromacs.org.

File format: http://manual.gromacs.org/current/online/gro.html

A GRO file writer would be nice, too.

It would be really need if we could do
 ag = universe.selection("name CA")
 some_ca = ag[[0, 2,10,22]]
and get a new AtomGroup only containing the Atoms corresponding to indices 0, 
2, 10, and 22.

Right now one needs to do 
 some_ca = AtomGroup([ag[i] for i in [0,2,10,22])

The following should be fixed:

/home/oliver/.local/lib/python2.5/site-packages/MDAnalysis-0.6.1_alpha-py2.5-lin
ux-x86_64.egg/MDAnalysis/KDTree/CKDTree.py:69:
DeprecationWarning: PyArray_FromDims: use PyArray_SimpleNew.
  def get_indices(*args): return _CKDTree.KDTree_get_indices(*args)
/home/oliver/.local/lib/python2.5/site-packages/MDAnalysis-0.6.1_alpha-py2.5-lin
ux-x86_64.egg/MDAnalysis/KDTree/CKDTree.py:69:
DeprecationWarning: PyArray_FromDimsAndDataAndDescr: use PyArray_NewFromDescr.
  def get_indices(*args): return _CKDTree.KDTree_get_indices(*args)

I've used linalg.svd to produce the principal axes of an alpha helix. These are 
different to that produced by principleAxes().

output from principleAxes() [in red in attached figure]

[-0.67825811 -0.20538766 -0.70553656] [-0.51792553 -0.54748404  0.657278  ] 
[-0.5212668   0.81121954  0.26495998]

output from linalg.avd [in blue in figure]

[ 0.67825812  0.5179255   0.52126682] [-0.20538768 -0.54748404  0.81121951] 
[-0.70553654  0.657278    0.26495996]

I have mapped (10x) these vectors back onto the centre of Geometry (only C 
atoms used) in VMD. A snapshot is attached. As you can clearly see svd does a 
good job of finding the helical axis. 

If you look closely at the coordinates they seem to be transposed i.e. the 
first eigenvector from svd is just the first coordinate from each of the 
principleAxes() and the second eigenvector is the second etc.

I'm not sure where this has happened. I've had a look at the src but am not yet 
good enough in python to be sure and this error seemed like one that a 
developer could fix in a trice (prob whilst slapping a forehead).

my python code:

# define the helix
sel = u.selectAtoms(" ( name CA or name C ) and protein and resid 169:190 ")
selCoords = sel.coordinates()
selCentre = sel.centerOfGeometry()
e1, e2, e3 = sel.principleAxes()
uu, dd, vv = linalg.svd(selCoords - selCentre)
v0h = vv[0]/linalg.norm(vv[0])
v2h = vv[2]/linalg.norm(vv[2])
v1h = vv[1]/linalg.norm(vv[1])
print e1,e2,e3
print v0h,v1h, v2h

excerpt from my MDAnalysis source:

    def momentOfInertia(self):
        # Convert to local coordinates
        recenteredpos = self.coordinates() - self.centerOfMass()
        masses = self.masses()
        values = zip(masses, recenteredpos)
        # Create the inertia tensor
        # m_i = mass of atom i
        # (x_i, y_i, z_i) = pos of atom i
        # Ixx = sum(m_i*(y_i^2+z_i^2)); Iyy = sum(m_i*(x_i^2+z_i^2)); Izz = sum(m_i*(x_i^2+y_i^2))
        # Ixy = Iyx = -1*sum(m_i*x_i*y_i)
        # Ixz = Izx = -1*sum(m_i*x_i*z_i)
        # Iyz = Izy = -1*sum(m_i*y_i*z_i)
        Ixx = reduce(lambda t,a: t+a[0]*(a[1][1]*a[1][1]+a[1][2]*a[1][2]), values, 0.)
        Iyy = reduce(lambda t,a: t+a[0]*(a[1][0]*a[1][0]+a[1][2]*a[1][2]), values, 0.)
        Izz = reduce(lambda t,a: t+a[0]*(a[1][0]*a[1][0]+a[1][1]*a[1][1]), values, 0.)
        Ixy = Iyx = -1*reduce(lambda t,a: t+a[0]*a[1][0]*a[1][1], values, 0.)
        Ixz = Izx = -1*reduce(lambda t,a: t+a[0]*a[1][0]*a[1][2], values, 0.)
        Iyz = Izy = -1*reduce(lambda t,a: t+a[0]*a[1][1]*a[1][2], values, 0.)
        return numpy.array([[Ixx, Ixy, Ixz],[Iyx, Iyy, Iyz],[Izx, Izy, Izz]])
    def principleAxes(self):
        from numpy.linalg import eig
        eigenval, eigenvec = eig(self.momentOfInertia())
        # Sort
        indices = numpy.argsort(eigenval)
        return eigenvec[:,indices] 

What steps will reproduce the problem?
1. import MDAnalysis; from MDAnalysis.tests.datafiles import *; u = 
MDAnalysis.Universe(PSF,DCD)
2. print(u.s4AKE.CYS)   # produces a <Residue? object
3. <Residue 'CYS', 77>
4. print(u.s4AKE.MET)
5. <ResidueGroup [<Residue 'MET', 1>, <Residue 'MET', 21>, <Residue 'MET', 34>, 
<Residue 'MET', 53>, <Residue 'MET', 96>, <Residue 'MET', 174>]>

What is the expected output? What do you see instead?
u.s4AKE.CYS should be a ResidueGroup with a single member; otherwise scripts 
have to separately test what kind of object is returned; eg u.s4AKE.CYS[3] 
returns the 3rd Atom whereas u.s4AKE.MET[3] returns the 3rd Residue!

Arguably, this is bug because it really defies expectation.

What steps will reproduce the problem?
1. import MDAnalysis
2. from MDAnalysis.tests.datafiles import PSF,DCD
3. u = MDAnalysis.Universe(PSF,DCD)
4. u.trajectory.dcd_header()

What is the expected output? What do you see instead?
Should produce a sensible dict of values.

In [27]: u.trajectory.dcd_header()
---------------------------------------------------------------------------
error                                     Traceback (most recent call last)

/Volumes/Data/oliver/Biop/Projects/FABP/I-FABP/1IFC/GMX/WT/analysis/<ipython 
console>
in <module>()

/Volumes/Data/oliver/Biop/Library/python/mdanalysis/MDAnalysis/coordinates/DCD.p
y
in dcd_header(self)
    161         import warnings
    162         warnings.warn('dcd_header is not part of the trajectory API
and will be renamed to _dcd_header',
--> 163                       DeprecationWarning)
    164         self._dcd_header()
    165     def _dcd_header(self):

error: unpack requires a string argument of length 80

What steps will reproduce the problem?
 from MDAnalysis import Universe
 u = Universe(psf,dcd)
 w_ok = u.selectAtoms('name OH2 and around 4.0 protein') # select solvation
shell
 water = u.selectAtoms('name OH2')
 w_bad = water.selectAtoms('around 4.0 protein')

What is the expected output? 
 w_ok == w_bad 
 --> True

What do you see instead?
 w_ok == w_bad
 --> False
(In fact, w_bad == []) 

What steps will reproduce the problem?
1. u = Universe('foo.pdb')
2. u.dimensions()

What is the expected output? What do you see instead?

Should give the unitcell data from pdb but just get [0,0,0,0,0,0]

What version of the product are you using? On what operating system?

I am using MDAnalysis-0.6.3 on Mac OS X 10.5.8


Please provide any additional information below.

In CHARMM it is possible to read in multiple dcd files (dynamc.doc).  This is 
advantageous because the dcd files can get very large ( mine are 7GB for each 
2ns of simulation).  It is often quite impractical to combine all of these 
trajectory files into 1 large file, so it would be nice if MDAnalysis could 
accept multiple dcd filenames to read sequentially for analysis.

Thanks!

Daniel
[email protected]

What steps will reproduce the problem?
1. u = Universe(pdbfile)
2. u._psf['_bond']
   --> KeyError: '_bond'

What is the expected output? What do you see instead?

Should get the bonds list; this is also necessary for the 'byres' selection
keyword.

What steps will reproduce the problem?
1. from MDAnalysis import *; from MDAnalysis.tests.datafiles import *
2. c = Universe(GRO,XTC)
3. c.trajectory.ts.dimensions

What is the expected output? What do you see instead?

Should be:

array([ 80.01700592,  80.01700592,  80.01700592,  90.        ,
        59.99999237,  59.99999237], dtype=float32)

e.g. cf PDB:

adk_oplsaa.pdb:CRYST1   80.017   80.017   80.017  60.00  60.00  90.00 P 1       
    1

But instead we get:

array([ 89.46173096,  89.46173096,  56.58056259,  78.46302795,
        63.43494034,  63.43494034], dtype=float32)

What steps will reproduce the problem?

 import MDAnalysis,MDAnalysis.distances
 universe = MDAnalysis.Universe('x.psf','x.dcd')

 solvent = universe.selectAtoms('name OH2')
 protein = universe.selectAtoms('protein and not name H*')

 s_coor = solvent.coordinates()
 p_coor = protein.coordinates()

 d = MDAnalysis.distances.distance_array(s_coor,p_coor)

The distance matrix is wrong (compared to, say, what one sees in VMD).

If one uses the workaround of copying the arrays then the results make sense:

 s_coor = solvent.coordinates().copy()
 p_coor = protein.coordinates().copy()

According to Naveen the problem was that the distance_array() C function
assumes contiguous arrays. However, until rev 74, AtomGroups.coordinates()
would return an non-contigious array. This was fixed in rev 75. See
http://code.google.com/p/mdanalysis/source/diff?old=63&r=75&format=unidiff&path=
%2Ftrunk%2Fpython%2FAtomGroup.py

However, it's not clear if this really solved the problem. Some evidence
says this is not so.

We need a decent test case and then look at this carefully again.





What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. u = MDAnalysis.Universe('closed_final.psf', 'op45.dcd')
2. u.dimensions

What is the expected output? What do you see instead?

Should give unit cell information but actually throws exception

 TypeError: dimensions() takes no arguments (1 given)

What steps will reproduce the problem?
1. easy_install
http://mdanalysis.googlecode.com/files/MDAnalysis-0.6.0-rc1.tar.gz

What is the expected output? What do you see instead?
It should build cleanly.
However, pyrex fails to find the c_numpy.pxd include file
 /tmp/easy_install-HX_L4r/MDAnalysis-0.6.0-rc1/src/dcd/_dcdtest.pyx:2:8:
'c_numpy.pxd' not found
and compilation eventually fails.

Please use labels and text to provide additional information.

At the moment we only manually check if the release builds (Mac OS X and
Linux) and if the top level module imports cleanly. We should really have a
proper test suite, perhaps with small example input files, to automatically
test a release.

It would be great if someone would work on this. For a start it would be
good to collect scenario cases, i.e. which functions need to be tested and
how. Add comments to this issue or in the wiki.

It would be good to have a topology builder, similar to VMD's psfgen plugin
http://www.ks.uiuc.edu/Research/vmd/plugins/psfgen/ . For a start it only
needs to generate a minimal psf from a pdb.

I think we could use the Charmm FF topology files because they are freely
available from Alex MacKerell's page
http://mackerell.umaryland.edu/CHARMM_ff_params.html

The distance selections are currently broken in the 'stable' release. You
cannot do the following

  u = Universe(psf,dcd)
  w_shell = u.selectAtoms('name OH2 and around 4.0 protein')

This either crashes or gives non-sensical results. (The same is true for
the POINT operator.)

adj =  (MDAnalysis.distances.distance_array(coord,coord,box=box) < self.cutoff)
ValueError: dimensions too large.


Probably a better way to handle large systems (N > 100,000) is to either use a 
sparse matrix 
representation or build the graph structure (e.g. a dict) directly.

In either case, one needs to write new code to do that. Maybe someone wants to 
write a 

    contact_matrix(coord, cutoff, returntype="numpy", box=None)

function where returntype selects a "numpy" (standard numpy.array) or "dict" or 
"sparse" 
reprensentation. The function should return a square matrix with 1 for any 
distances < cutoff 
(and 0 otherwise).

(Btw the current discussion refers to 
http://code.google.com/p/mdanalysis/source/browse/trunk/MDAnalysis/analysis/leaf
let.py .)

[deleted issue]

What steps will reproduce the problem?
1. using an Ubuntu system
2. python setup.py build

What is the output? 
running build
running build_py
running build_ext
building 'KDTree._CKDTree' extension
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2
-Wall -Wstrict-prototypes -fPIC

compile options: '-g -I/usr/lib/python2.5/site-packages/numpy/core/include
-I/usr/include/python2.5 -c'
gcc: src/KDTree/KDTree.cpp
gcc: error trying to exec 'cc1plus': execvp: No such file or directory
gcc: error trying to exec 'cc1plus': execvp: No such file or directory
error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2
-Wall -Wstrict-prototypes -fPIC -g
-I/usr/lib/python2.5/site-packages/numpy/core/include
-I/usr/include/python2.5 -c src/KDTree/KDTree.cpp -o
build/temp.linux-i686-2.5/src/KDTree/KDTree.o" failed with exit status 1


Please use labels and text to provide additional information.

SOLUTION:
* check your compilers
* for my case i needed to do:
    sudo apt-get install g++

What steps will reproduce the problem?
1. u = Universe(PSF,DCD)
2. u.s4AKE.write('4ake.crd')


What is the expected output? What do you see instead?

Should write file. Instead fails with 'NoDataError: No atom in residue MET with 
name resid'

The paths to link against fast libraries on Linux such as Intel MKL are
currently hard coded in setup.py:
   fast_numeric_include = ['/opt/intel/cmkl/10.0.5.025/include']
    fast_numeric_link = ["-L/opt/intel/cmkl/10.0.5.025/lib/em64t",
"-lmkl_lapack","-lmkl","-lguide"]
This is not appropriate for a general install, especially on Linux.

Need to find out how to put this into setup.cfg.

u = MDAnalysis.Universe('bilayer.gro')
MDAnalysis.analysis.contact_matrix(u.atoms.coordinates() , returntype='sparse')

This sparse matrix method was added as a fix for large systems, where a full N 
x N numpy array would be too large. This was required for the leaflet.py 
analysis script. The method works, but is very slow - takes a few hours for a 
30,000 lipid membrane. Currently it is pure Python code, so re-writing in pyrex 
should make it a lot faster. However, my C coding is pretty rusty and I would 
need to work out how to implement a sparse matrix in C, so it might be a little 
while before that happens. Let me know if you would like it sorted more 
urgently.

What steps will reproduce the problem?
1.  W = MDAnalysis.Writer('foo.dcd')

What is the expected output? What do you see instead?

Should get a writer.


/sansom/gfio/oliver/Library/i386-apple-darwin9.8.0/lib/python2.6/MDAnalysis-0.7.
0_rc1-py2.6-macosx-10.5-i386.egg/MDAnalysis/coordinates/DCD.pyc in 
__init__(self, filename, numatoms, start, step, delta, remarks, convert_units)
     38         self.dcdfilename = filename  # backward compatibility
     39         if convert_units is None:
---> 40             convert_units = 
MDAnalysis.core.flags['convert_gromacs_lengths']
     41         self.convert_units = convert_units    # convert length and time to base units on the fly?
     42         self.numatoms = numatoms

NameError: global name 'MDAnalysis' is not defined

What steps will reproduce the problem?
1. a dcd file containing coordinates of two time steps
2. executing following codes 
==========================================
    psf = "all.psf"
    dcdfile = "ggvlvndd1.dcd" 
    universe = Universe(psf,dcdfile)
    collection.clear()

collection.addTimeseries(Timeseries.CenterOfMass(universe.selectAtoms("name
C* and segid X")))
    collection.compute(universe.dcd,start=0,stop=1)
    print collection[0].shape, collection[0],
==========================================

What is the expected output? What do you see instead?

result :
[[-13.50472442   0.        ]
 [ 28.06302269   0.        ]
 [-16.7179693    0.        ]]

expected result is :
 [[-14.0426321, -13.50472546]  
  [ 27.06080437, 28.06302071 ]
  [-18.63012695, -16.71796989]]

What version of the product are you using? On what operating system?
v.0.5.1 

Please provide any additional information below.

What steps will reproduce the problem?
1. build MDAnalysis but do not link to MKL lapack (i.e. in setup.py leave
empty fast_numeric_include = [] and fast_numeric_link = [])
2. import MDAnalysis

What is the expected output? What do you see instead?
It should import but instead an ImportError is raised:

  ImportError: MDAnalysis/core/rms_fitting.so: undefined symbol: dsyev_

The problem is that the rms_fitting.so extension was not linked to any
linear algebra library. Neither the setup.py script nor the MDAnalysis
library itself checks for that case.

CRD (CHARMM coordinates) can be written but not read. We require a 

* CRDReader that reads coordinates
* CRDParser that constructs a primitive topology from a CRD file alone.

Not having this functionality is inconvenient (some tests break) and confusing 
to users who expect a certain symmetry (PDB and GRO formats can both be read 
and written).

import MDAnalysis fails to import (python 2.5):

/Library/Python/2.5/site-packages/MDAnalysis-0.6.4-py2.5-macosx-10.5-i386.egg/MD
Analysis/coordinates/PDB.py:221: 
Warning: 'with' will become a reserved keyword in Python 2.6
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File 
"/Library/Python/2.5/site-packages/MDAnalysis-0.6.4-py2.5-macosx-10.5-i386.egg/M
DAnalysis/__init__.py",
line 142, in <module>
    from coordinates.core import get_writer_for
  File 
"/Library/Python/2.5/site-packages/MDAnalysis-0.6.4-py2.5-macosx-10.5-i386.egg/M
DAnalysis/coordinates/__init__.py", 
line 290, in <module>
    import PDB, DCD, CRD, XTC, TRR, GRO, XYZ
  File 
"/Library/Python/2.5/site-packages/MDAnalysis-0.6.4-py2.5-macosx-10.5-i386.egg/M
DAnalysis/coordinates/PDB.py", 
line 221
    with util.openany(filename, 'r') as pdbfile:
            ^
SyntaxError: invalid syntax

To reproduce this problem:

1. Run a full set of unit tests with the latest install of Biopython (version 
1.55):

>>>import MDAnalysis.tests
>>>MDAnalysis.tests.test(verbose=3, label='full') 

While the expected output would be a successful unit test without major 
warnings, there are several log reports of problems with a specific component 
of the new version of Biopython.

There are two main 'error reports' in the unit test output, one for 
TestPDBReader and the other for TestPDBReaderBig (each repeated several times 
for different atoms):

a) test_coordinates (MDAnalysis.tests.test_coordinates.TestPDBReader) ... 
/sansom/sc2/bioc1009/.local/lib/python2.6/site-packages/biopython-1.55-py2.6-lin
ux-i686.egg/Bio/PDB/Atom.py:71: PDBConstructionWarning: Atom object (name=N) 
without element
  PDBConstructionWarning)

b) test_coordinates (MDAnalysis.tests.test_coordinates.TestPDBReaderBig) ... 
/sansom/sc2/bioc1009/.local/lib/python2.6/site-packages/biopython-1.55-py2.6-lin
ux-i686.egg/Bio/PDB/Atom.py:71: PDBConstructionWarning: Atom object (name=H1) 
without element
  PDBConstructionWarning)

There is also a large amount of output looking like this:
N --> ?
HT1 --> ?
HT2 --> ?
HT3 --> ?
CA --> ?
HA --> ?

(See the attached logfile for the merged and complete stdout and stderr streams 
resulting from the unit test)