Hi Pierre,
Am 12.09.2012, 09:52 Uhr, schrieb Pierre de Buyl
<address@hidden>:
>Hi Felix,
>
>On Mon, Sep 10, 2012 at 09:14:55AM +0200, Felix Höfling wrote:
>
>>I thought about the box again since I feel not really
>>comfortable with the
>>current specification. I find it a bit awkward that the
>>observables group
>>must be present if a file contains trajectory data only.
>>Further, the box
>>information is only needed in conjuction with position data. If only
>>velocities are stored (for some reason), the box is not needed. And
the
>>maybe strongest point last: for time-dependent boxes, there shall be a
>>simple way to retrieve the corresponding box size for a given
>>entry in the
>>position time series. (Currently, the box may be stored at different
>>intervals than the positions).
>>
>>My suggestion is to link the box much tighter to the position data.
The
>>box group in observables may still be present and can be realised by
>>appropriate hard links. The following suggestion ensures that
>>the box data
>>are available within each position group consistently using the
>>same time
>>grid as the position data:
>>
>>trajectory
>> \-- group1
>...
>>
>>One open point: how can we efficiently store the information for a
fixed
>>box size (which is a pretty widespread case)? If the edges and offset
>>datasets contain always the same entries, they may pack well, but they
>>have to be unpacked for accessing any data point. An alternative
>>would be
>>to indicate the non-changing box size transparently, e.g., by an
>>additional attribute and different dataset extents (with fixed size).
>>
>>trajectory
>> \-- group1
>> | \-- position
>> | | \-- value
>> | | \-- step
>> | | \-- time
>> | \-- box
>> | +-- type
>> | \-- edges [D][D]
>> | \-- offset [D]
>>
>>(Note that the extents of edges depend on the box type, either [D]
>>or [D][D].)
>
>I prefer to turn your suggestion around, if you don't mind: keep
>the data in
>observables, with the option to link from the trajectory groups if
>needed.
>
>The thing that I think you would like to avoid is to carry
>"observables" even
>though all you want is a trajectory (with box information indeed).
>On the other
>hand, if one wants to find the box information, it is in
>"/trajectory/groupname/..." where "groupname" depends on the
>file... Even if the
>data is linked, this seems more cumbersome to me. The
>specification of several
>boxes seems to me to be a more of an exceptional event.
>
My suggestions is less cumbersome than you describe. The box is
mostly relevant for the interpretation of position data, and then
all information is contained in "/trajectory/group/position" without
resorting to a different root group. The position data is
exceptional in this respect due to the typically used periodic
boundaries.
If the box information itself is needed, I agree. It should not be
deduced from some trajectory group. Therefore I suggested to keep it
in observables as it is. But not every information needs to be
stored. If the box is not in observables, a H5MD reader refuses
retrieving it from the file (although it could by looking up some
strange trajectory group).