[Top][All Lists]

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

Re: [h5md-user] Conventions/Modules

From: Konrad Hinsen
Subject: Re: [h5md-user] Conventions/Modules
Date: Mon, 23 Sep 2013 16:03:43 +0200

Felix Höfling writes:

 > As I recall our discussion, we planned to implement the modules simply as  
 > additional root groups. So the presence of a certain root group (e.g.,  
 > "lattice_boltzmann" for solvent data) would indicate the use of the  
 > respective module. An additional listing in h5md/modules would be  
 > redundant.
 > Konrad's concept of conventions is a bit different if I understand it  
 > correctly. The use of a certain convention changes the interpretation of  
 > the "core" data, e.g., in the particles group, or even extends the data  
 > structures by additional mandatory fields. In such a case,  
 > "h5md/conventions" would be helpful to interpret the data. It makes a  
 > promise on what fields the reader can expect.

Having worked on such a module/convention/whatever, I have a better
idea now of what it implies. In my specific case, it's both additional
data (which lives in a specific group next to "h5md" and additional
constraints on the data items in the generic H5MD part. The
interpretation of the core data is never changed, however, so a
program expecting "plain" H5MD would not have to know about the
additional data or the additional constraints.

The constraints are of the type "observables must have a unit
attribute, which must adhere to a specific format" or "every subgroup
under 'particles' must be defined by a data item with the same name in
the 'mosaic' group".

I think it is useful to have a list of modules in "h5md". First of
all, it provides a single place to store module information (name,
version number, maybe more in the future) in a standard layout. Second,
it makes a clear distinction between an extension to H5MD and some
data that sits next to "H5MD" by accident (or even mistake). Third,
it is the most economic approach for modules that do not need any
additional storage, i.e. a module that specifies unit formats.

Konrad Hinsen
Centre de Biophysique Moléculaire, CNRS Orléans
Synchrotron Soleil - Division Expériences
Saint Aubin - BP 48
91192 Gif sur Yvette Cedex, France
Tel. +33-1 69 35 97 15
E-Mail: research AT khinsen DOT fastmail DOT net
ORCID: http://orcid.org/0000-0003-0330-9428
Twitter: @khinsen

reply via email to

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