Problems reading mdcrd files

[GoogleCodeExporter]

What steps will reproduce the problem?

I have three differing scenarios using the same input and the same system:

SCENARIO 1:
>>> import MDAnalysis as mda
>>> u1=mda.Universe("penta.top","md0.mdcrd")
>>> u1
<Universe with 59 atoms>
>>> u1.trajectory.numframes
101
>>> u1.trajectory.frame
0
>>> u1.trajectory.next()
< Timestep 1 with unit cell dimensions array([ 0.,  0.,  0.,  0.,  0.,  0.], 
dtype=float32) >
...
>>> u1.trajectory.next()
< Timestep 99 with unit cell dimensions array([ 0.,  0.,  0.,  0.,  0.,  0.], 
dtype=float32) >
>>> u1.trajectory.next()
< Timestep 100 with unit cell dimensions array([ 0.,  0.,  0.,  0.,  0.,  0.], 
dtype=float32) >

SCENARIO 2:

>>> import MDAnalysis as mda
>>> u1=mda.Universe("penta.top","md0.mdcrd")
>>> u1.trajectory.frame
1
>>> u1.trajectory.ts
< Timestep 1 with unit cell dimensions array([ 0.,  0.,  0.,  0.,  0.,  0.], 
dtype=float32) >
>>> u1.trajectory.numframes
101
>>> u1.trajectory.rewind()
>>> u1.trajectory.frame
1
>>> u1.trajectory.next()
< Timestep 1 with unit cell dimensions array([ 0.,  0.,  0.,  0.,  0.,  0.], 
dtype=float32) >
>>> u1.trajectory.frame
1

QUESTION: Why did it report the current frame of SCENARIO 2 as 1 instead of 2 
even after performing a next() step?
QUESTION: Is the frames index 0-based or 1-based? Whatever the case, why should 
it behave differently in the same machine with the same conditions?

SCENARIO 3:
>>> 
u2=mda.Universe("/users/ardita/coco12Sept/coco/examples/penta.top","md0.mdcrd")
>>> u2.trajectory.frame
1
>>> u2.trajectory.ts
< Timestep 1 with unit cell dimensions array([ 0.,  0.,  0.,  0.,  0.,  0.], 
dtype=float32) >
>>> u2.trajectory.next()
< Timestep 2 with unit cell dimensions array([ 0.,  0.,  0.,  0.,  0.,  0.], 
dtype=float32) >
>>> u2.trajectory.frame
2
>>> u2.trajectory.next()
< Timestep 3 with unit cell dimensions array([ 0.,  0.,  0.,  0.,  0.,  0.], 
dtype=float32) >
>>> u2.trajectory.frame
3

QUESTION: Why would it now behave differently with respect to "SCENARIO 2" and 
"SCENARIO 3" in the sequence of indexes of the frames?

Summarizing:
1. SCENARIO 1: Position at beginning of trajectory with current frame index 0. 
Forwarding steps changing the current frame index progressively (0, 1, 2, 3 up 
to 100 inclusive).
SCENARIO 2: Position at beginning of trajectory with current frame index 1. 
Forwarding steps changing the current frame index not quite progressively at 
the beginning (1, 1, 2, 3 etc).
SCENARIO 3: Position at beginning of trajectory with current frame index 1. 
Forwarding steps changing the current frame index progressively (1, 2, 3 etc).

2. Moreover, my trajectory file has only got 100 frames and not 101 according 
to AMBER.

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

>>> import MDAnalysis as mda
>>> mda.__version__
'0.8.1'

I have these problems on a system with the following characteristics:
Linux version 3.11.10-100.fc18.x86_64 (mockbuild@bkernel02) (gcc version 4.7.2 
20121109 (Red Hat 4.7.2-8) (GCC) ) #1 SMP Mon Dec 2 20:28:38 UTC 2013

Could anyone please have a look at this? 
Thank you very much.

Kind regards,
Ardita

Original issue reported on code.google.com by ardita.s...@gmail.com on 17 Sep 2014 at 4:59

Attachments:

• md0.mdcrd
• penta.top

[GoogleCodeExporter]

This issue was closed by revision f5834233b704.

Original comment by richardjgowers on 18 Sep 2014 at 8:30

• Changed state: Fixed

[GoogleCodeExporter]

Hi Ardita

There was a couple of things going on here, firstly len(u.trajectory) wasn't 
working properly, 100 frames is correct.

Secondly, when counting frames or iterating the trajectory, the first frame 
wasn't reloaded afterwards, so went to 'frame 0' which is the state before the 
next frame is read.  I think frames are 1 based because most MD programs treat 
& write them that way.

I've pushed a fix to this in the development branch, you can read how to use 
this here:
http://code.google.com/p/mdanalysis/wiki/DevelopmentBranch

Hopefully everything should be fixed for you now.
Richard

Original comment by richardjgowers on 18 Sep 2014 at 8:36