transfer_to_memory doesn't copy dynamics dimension information

[kain88-de]

Expected behaviour

If I load a trajectory from an NPT simulation into memory I would expect that the memory reader also copies the dimension information for every frame

Actual behaviour

Only the information from the first frame is used.

[orbeckst]

I consider this a bug and because ts.dimensions is a top level attribute of Timestep it should also be copied.

However, it raises the question if the MemoryReader should also be aware of other per-timestep information – aren't we storing these data nowadays in a ts.data dict?

[kain88-de]

The data dict is reader specific. I'm OK if that isn't copied. But other available top level attributes should be copied if available.

[jbarnoud]

Do we have an equivalent of Reader.timeseries for the box shape? Fixing this is not difficult, but I have to iterate through the trajectory even when the faster timeseries is available.

[kain88-de]

We don't have an equivalent. But libdcd reader does return it as well. I wouldn't mind adding a method that can also read the box information for all frames and returns them as an array. We should think if we want to add this to timeseries though to avoid iterating several times over a possibly large trajectory.

[orbeckst]

I don't think we have but we should. Ideally you'd also get the additional time step information such as lambda or the more complicated stuff in some other formats such as trz (or tng?). Basically, it would be good to start with a data structure that allows some flexibility depending on available per frame data. E.g. a dataframe like array with named fields. We could start with a slow Python implementation in the base class and upgrade readers as we go along. Ideally you'd want to do coordinates and other timestep data together, of course.

…

-- Oliver Beckstein email: [email protected]

Am Jul 16, 2017 um 09:47 schrieb Max Linke ***@***.***>: We don't have an equivalent. But libdcd reader does return it as well. I wouldn't mind adding a method that can also read the box information for all frames and returns them as an array. We should think if we want to add this to timeseries though to avoid iterating several times over a possibly large trajectory. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[jbarnoud]

If libdcd has it, then it would make sense to expose it. Not much of a priority, but convenient at least in that context.

[kain88-de]

Btw xarray sounds like the right package for a data format that such a universal time series should return.

[orbeckst]

@jbarnoud if you fix this issue then we will have dealt with all defect for 0.17 issues.

EDIT: use future perfect tense when you legitimately can!

[orbeckst]

I'd really like this one to work... but it looks as if the chances for this getting fixed in 0.17.0 are slim. It is a bug fix so this can always go into a 0.17.x.

Feeback from anyone working on this issue would be welcome.