[Top][All Lists]

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

[h5md-user] observables: per particle averages or total sums

From: Felix Höfling
Subject: [h5md-user] observables: per particle averages or total sums
Date: Mon, 07 Oct 2013 11:21:32 +0200
User-agent: Opera Mail/12.15 (Linux)

Am 04.10.2013, 21:33 Uhr, schrieb Pierre de Buyl


Due to the traffic, I didn't perceive a change here.

The observables are stated to be "per particle". I'd like to revert that. There
are situations where this is just not appropriate.

For instance, in MPCD simulations the interaction energy represents energy in the interfacial region for which there is no clear definition of the number of


Hi Pierre,

Such a constraint on the observables would be a bit too much, indeed. The
spec was not meant to be restrictive in this direction. The phrase "per
particle" was merely added as explanation for the standardised
identifiers, e.g., to say what is meant by "kinetic_energy". Some
considerations how to make it more flexible and still meaningful:

The file format should not enforce users to store the average instead of
the total sum, although I think it is good practice to use the average
(smaller values with a sensible normalisation and smaller round-off
errors). In your application, you could store the average along with the
varying number of particles that contributed to the average.

The data group has to be verbose about whether the average or the total
sum is stored, otherwise the information cannot be interpreted properly.

1) Very long group names like "kinetic_energy_per_particle" appear weird.

2) Making the "particles" attribute/dataset mandatory for averages
(serving as indicator) is too restrictive as well.

3) We could add an attribute "average" which is either "true" or "false",
or an attribute "type" ...

I have no definite solution for this yet. Maybe a kind of attribute would
be the best choice.

In addition to that, it would be useful to have an optional string
attribute "description" (for all data groups) which can be as precise as
the user needs/wants it to be. Such a field, of course, could not be
parsed automatically (with reasonable effort), but should make things
clear for a scientifically educated human. It could serve, e.g., as
display name for H5MD readers, by now a generic reader has to translate
the group name by replacing "_" by " ".



reply via email to

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