[Top][All Lists]

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

Re: [h5md-user] Minor revisions before H5MD v1.0

From: Felix Höfling
Subject: Re: [h5md-user] Minor revisions before H5MD v1.0
Date: Mon, 06 May 2013 16:02:52 +0200
User-agent: Opera Mail/12.15 (Linux)

Am 03.05.2013, 18:37 Uhr, schrieb Peter Colberg

On Fri, May 03, 2013 at 12:32:32PM -0400, Peter Colberg wrote:
The observables currently defined in the specification do not require
a dimension attribute for interpretation. For your custom needs, use,
e.g., a program parameter "parameters/dimension".

By the way, I recall that it was your proposal to move the box group
from observables to trajectory/<subgroup>. Please do not reason that
the observables group is now lacking the spatial dimension…


The box group has always been optional, Pierre agreed with me that it
should be mandatory along with each trajectory group. This did not solve
the problem that it is still optional in the /observables group. Maybe it
should become mandatory there as well?

It is not true that the interpretation of, e.g., the observable
"potential_energy" does not require the space dimension. It is for example
needed when analysing the fluctuations to compute the specific heat. (See
Allan & Tildesley, Chapter 2.5) But other quantitites may need the volume
as well, and so it would be consequent to

1) either make /observables/box mandatory if /observables is present,

2) or permit the interpretation of flucutations only if the optional group
/observables/box is present (otherwise the reader considers the H5MD file
as incomplete for the desired purpose and fails)

In both cases, there appears the same issue with a fluctuating box as for
the trajectory: the sampling intervals of the box and the various
observables may differ, rendering the box information essentially useless
for these observables. The solution would be to attach the box (possibly
via hard link) to each data group in /observables. But this appears to be
a pretty weird, I admit.

The pragmatic and maybe best solution would be variant 2) with the
constraint that the sampling times of the box and the observable shall


reply via email to

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