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.