[Top][All Lists]

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

Re: [h5md-user] Update on H5MD from Stuttgart

From: Pierre de Buyl
Subject: Re: [h5md-user] Update on H5MD from Stuttgart
Date: Mon, 22 Jul 2013 14:17:42 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Sun, Jul 21, 2013 at 09:30:00PM -0400, Peter Colberg wrote:
> On Sun, Jul 21, 2013 at 10:43:03PM +0200, Pierre de Buyl wrote:
> > I pushed modifications and found a surprise issue. 
> > 
> > In the box specification, one stores edges and offset as attributes for time
> > independent boxes. This goes against the new idea that any data is a 
> > dataset or
> > a H5MD group. Still, datasets make sense in "/trajectory" (for species or
> > masses, say) but attributes are more appropriate for a box edges and offset.
> I think this can be resolved without any further changes.
> While I support the new idea to use datasets in place of step/time
> groups for the case where a dataset is time-invariant, it should not
> be applied in a dogmatic sense, e.g., against good implementation
> practice.
> A good practice is to store data significantly smaller than 64 KiB in
> attributes, and larger data in datasets. (HDF5 library version 1.8 or
> later does support attributes larger than 64 KiB [1], but this
> requires special handling.)
> [1] http://www.hdfgroup.org/HDF5/doc/H5.format.html#AttributeMessage
> I suggest to limit the use of attributes to the case where data will
> always be significantly smaller than 64 KiB. This includes the case
> of time-invariant box edges and offset data.

Fortunately, the current wording of this part of H5MD fits well with the update
on time-dependent data but still specifies the distinction between attribute and
dataset for edges and offset. I propose we leave it as is.

> For cases where data could potentially reach or exceed 64 KiB,
> datasets should be used. This includes the case of time-invariant
> trajectory data, which scales with the system size.

This also fits the current H5MD :-) Currently, your proposal does not conflict
at all with the specification but it might be interesting to state somewhere the


reply via email to

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