Re: [h5md-user] increasing order of "time" dataset

[Pierre de Buyl]

Hi,

I start a new subthread to ease the reading (I hope).

On Mon, May 05, 2014 at 05:05:22PM +0200, Felix Höfling wrote:
> I encountered an obstacle with the present specification of the "time"
> dataset of generic H5MD elements. It says "The values of the dataset are
> in monotonically increasing order."
> 
> In specific use cases, it happens that the positions/velocities are
> modified without incrementing time. An example is rescaling of the
> velocities at the end of a run to match a prescribed kinetic energy. In
> the current H5MD spec it is not possible to store the data before and
> after the rescaling as time does not progress. (The step may be
> incremented by convention in such a case.)
> 
> I suggest to relax the condition on the "time" dataset to "non-descreasing
> order". This would not impair binary search strategies in the "time"
> dataset. And time being a floating-point value should not be used to
> uniquely identify a simulation step anyway.

I am not favorable to this change.

The step dataset is present to facilitate the indexing, searching and comparison
of time-dependent data. step "contains the time steps at which the corresponding
data were sampled." (from the spec) and as such it is implied that a value of 
step identifies
uniquely a value of time. This is how I understand the specification.

For someone reading a dataset, a duplicate value of a H5MD element (such a the
velocities) means a possible analysis difficulty (two 'time frames'
corresponding to the same physical time but with an instantaneous
transformation) is a confusing situation.

> Would this change entail an issue I have overlooked?

Beside the practical issues given above, there is a deeper problem: Finding the
state of the system at a given time would result in a ill-defined problem as two
time-frames would be "candidates". 

>From the use-case that you mention, it seems to be motivated by the analysis of
the algorithm "flow". It is a problem that I understand very well :-) But I
don't think that H5MD should reflect that. A possible (not very elegant but
still practical) solution is to store both 'velocity' and
'velocity_before_rescaling' as different H5MD elements.

Best,

Pierre