h5md-user
[Top][All Lists]
Advanced

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

Re: [h5md-user] box and observables


From: Felix Höfling
Subject: Re: [h5md-user] box and observables
Date: Wed, 25 Sep 2013 12:25:43 +0200
User-agent: Opera Mail/12.15 (Linux)

Am 25.09.2013, 11:42 Uhr, schrieb Konrad Hinsen <address@hidden>:

Peter Colberg writes:

 > > Next, the reader: if there is a single box group but differently
 > > sampled positions for different subsystems, reading the box
 > > information is a lot of work and slow.
 >
 > Well, this is the essence of the step/time scheme.
 >
 > I added a section [1] on the use of the step/time datasets, which
 > refers to the binary search, upon which the step/time scheme relies.
 > This is the basic building block for any H5MD program.
 >
 > [1] http://h5md.nongnu.org/implementation.html

So the idea is that we have only a single box information for the
whole trajectory, right? My impression is that Felix still disagrees.

In that case, the following sentence must be removed from the
specification:

  A specific requirement for box groups inside particles is that the
  step and time datasets exactly match those of the corresponding
  position groups, which may be accomplished by hard-linking the
  datasets.

This sentence is the essence of a really long discussion and we all agreed on that. I'm convinced that this solution serves modularity and simplicity w.r.t. reading and writing H5MD.

If left in, this indirectly implies that all position data must be
sampled on the same time grid.

Each subgroup may be sampled at different time grids. Only the sampling of position and box within the same group must be the same (velocity or species might be sampled differently).

The note about hard-linking is to be understood as an implementation hint for the case that the sampling intervals of the box in different subgroups coincide. Maybe the spec is not precise enough here.

 > For the case of all data that depends on the box for interpretation,
 > the replicated box groups complicate the matter, while providing no
 > benefit, as a step/time lookup is needed anyway.

I agree that if there is only a single set of box information per
trajectory, then it would be best to have it once in a single place.

Konrad.

In the current version, the observables tree contains a single (mandatory) box group at a defined location. A source of confusion may be the phrase "may be stored in appropriate subgroups similarly to the particles tree". It was not meant to imply anything about the box group.

It is my hope that we come to a conclusion on the box soon. Let me recall that we have already the status of a release candidate and are about to finalise version 1.

Felix



reply via email to

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