[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 09:57:44 +0200
User-agent: Opera Mail/12.16 (Linux)

Am 08.05.2014, 20:54 Uhr, schrieb Peter Colberg <address@hidden>:

Hi Felix,

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.

The “time” dataset constraint has been mentioned before:


I think it is good to have the implied uniqueness of the time values.

Could you provide insight why one stores the velocities both before
and after a rescaling? I consider the rescaling part of the MD step
and store the velocities after the rescaling.

If the user wants to examine/store the situation before and after any time-neutral operation, there is a need for a non-unique (but non-decreasing) time dataset. This happens for example if several simulation runs are combined where a manipulation (e.g., velocity rescaling) takes place inbetween. Perhaps the rescaling is not the best example, another one are chemical reactions, which change the state of the system and may be assumed to take place instantaneously.

(Of course, one may always redefine the step to include such things, but then all previous steps without the manipulation are different from the last one.)

Would this change entail an issue I have overlooked?

Dropping the uniqueness is backwards-incompatible with readers.

It does actually not break backwards compatibility as the difference is relevant only for equality comparisons of floating-point numbers, which is strictly discouraged. Thus I think the slightly relaxed condition would make H5MD a bit more flexible.



reply via email to

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