[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Felix Höfling
Subject: Re: [h5md-user] increasing order of "time" dataset
Date: Fri, 09 May 2014 16:41:16 +0200
User-agent: Opera Mail/12.16 (Linux)

Am 09.05.2014, 16:05 Uhr, schrieb Pierre de Buyl


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.



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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]