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

[Pierre de Buyl]

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".

Regards,

Pierre