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

[Felix Höfling]

Am 09.05.2014, 16:05 Uhr, schrieb Pierre de Buyl
<address@hidden>:

> 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.
It is not clear what a "time step" is, maybe we should rephrase as
"simulation step". Floating-point numbers shall not tested for equality,
see my response to Peter.

> 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.
The data refer to different steps (not times), so everything is fine.

> > 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".
Testing floating-point numbers on equality is ill-defined itself. Our spec
implies that this would be possible.

> 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
In the mean-time I found a workaround for my "use case", but the deeper
problem remains. Hence I'm still in favour of correcting the spec.

Best,

Felix