[Top][All Lists]

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

Re: [h5md-user] [h5md-commit] [SCM] master, updated. c234149781bfa9f5dc8

From: Pierre de Buyl
Subject: Re: [h5md-user] [h5md-commit] [SCM] master, updated. c234149781bfa9f5dc81aa139038e7dc6689b64d
Date: Thu, 20 Jun 2013 14:24:02 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Hi Felix,

See below.

On Wed, Jun 12, 2013 at 06:11:38PM +0200, Felix Höfling wrote:
> I see your point. It is worth keeping the value/step/time structure intact.
> The attribute could be moved up one level to, e.g.,
> /observables/group1, and there it is either an attribute (fixed in
> time) or a time-dependent dataset simply named "count" or "number".
> Making it optional would be possible, but I don't favour it. The
> question then is how /trajectory and /observables differ at all and
> why the two groups need to be distinguished and specified.

Before going further, I have a point for this (traj vs obs) that I did not make
in my previous messages that helps me to make the distinction:

/trajectory : time dependent data with storage of order N
/observables: time dependent data with storage of order 1

> Independently of that we need to specify how a H5MD reader behaves
> if optional data are missing.
> On the long run, I have also other root groups in mind, e.g.,
> /structure for pair correlation functions (depend on distance) or
> static structure factors (depend on wavevector) and /dynamics for
> mean-square displacement (depends on lag time), intermediate
> scattering functions (depends on wavevector and lag time) etc. Of
> course we may leave it to the user, how such quantities are stored
> but what is then the added value of H5MD if there is no consenus
> about the content of the data groups, about naming conventions etc.?
> In my understanding, the root groups are useful for grouping
> different substructures. Of course, data forming a time series are
> always stored as value/step/time triples.

I have also plans for other data in mind. And the goal of H5MD is indeed to
bring consensus on what goes in the file. For H5MD 1.0 we have already a strong
set of features and capability that we should now push as "public".



reply via email to

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