TRR/XTC writer does not include timestep or time information for frames

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run the attached script with adk_oplsaa.pdb and adk_oplsaa.xtc in current 
directory.
2. Run gmxcheck (part of gromacs tools) on either resulting trajectory (ca.xtc 
or ca.trr).

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

One would expect to see timestamps and timestep information in the gmxcheck 
output. As it stands, it would seem that no time information is written to 
either TRR or XTC trajectory files, even with explicit use of the keywords 
intended for doing this.

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

0.7.6 development branch

Please provide any additional information below.

Original issue reported on code.google.com by dot...@gmail.com on 26 Aug 2013 at 9:22

Attachments:

• ca_trajectory.py

[GoogleCodeExporter]

David, you are right.

At the moment you would need to manually add the frame information to the 
Timestep object that you pass to the write() method. 

Arguably, the Writer should be doing this. It would be good to have this 
fixed...

Note that this also applies to the XTC writer.

Original comment by orbeckst on 28 Oct 2013 at 5:19

• Changed title: TRR/XTC writer does not include timestep or time information for frames
• Changed state: Accepted

[GoogleCodeExporter]

Hi, 
I can take a look into this.
So far I've also seen the TRR writer writes way too much (it includes the zeros 
for the empty forces/velocities) but fixing that will probably require a bigger 
overhaul (see issue 162) than just taking care of the time.

Original comment by manuel.n...@gmail.com on 15 Jan 2014 at 4:39

[GoogleCodeExporter]

Ok, the issue is that the Writer will try to use time information from the 
Timesteps you create, and those default to zero. The delta time is only used if 
there is no time attribute of the Timestep, but even then the time assignment 
fails because delta is multiplied by the frame number from the Timestep (which 
also default to zero).

I changed a bit the default behavior of the Writer: if it is initialized with a 
delta value, it will use it together with start, step, and the written frame 
counter to output the time at each frame. Otherwise it'll try to use the time 
from the Timestep. Failing to find it it assigns a default delta of 1ns. I add 
this in order not to break code that relied on the old behavior, although 
results will now differ slightly since each frame will have increasing time 
tags instead of having always t=0.

I'll push my fix and you guys let me know what you think.

Original comment by manuel.n...@gmail.com on 15 Jan 2014 at 6:37

[GoogleCodeExporter]

Your approach sounds fine to me; I don't believe a lot of code relies on the 
old behavior.

Add a warning to the docs and a note to CHANGELOG.

Original comment by orbeckst on 15 Jan 2014 at 6:47

[GoogleCodeExporter]

Original comment by manuel.n...@gmail.com on 15 Jan 2014 at 9:04

• Changed state: Fixed