Re: [h5md-user] box and observables

[Felix Höfling]

Am 25.09.2013, 09:20 Uhr, schrieb Felix Höfling <address@hidden>:

> Am 24.09.2013, 18:57 Uhr, schrieb Peter Colberg  
> <address@hidden>:
>
> > On Tue, Sep 24, 2013 at 12:51:15PM -0400, Peter Colberg wrote:
> > > > So looking at this purely from the point of view of writing and
> > > > reading positions, a box group per subsystem is highly desirable.
> > >
> > > For that specific case, yes, that would be desirable.
> >
> > A different aspect to consider:
> >
> > Suppose I wish to display the combined particle positions of two or
> > more subsystems in a visualization program. If each subsystem has its
> > own box copy, which box group does the reader read, and which box
> > groups are discarded? Does the reader need to verify that the box
> > information of all groups coincides?
> >
> > As long as we can agree on a single physical box per H5MD root,
> > agreeing on a single box group to represent this data also avoids
> > this ambiguity.
> >
> > Peter
>
> If different subsystems are combined, the box information within the  
> respective subgroup is used to unfold the particle positions. That is:  
> all (relevant) box groups are read. The reader does not need to bother  
> whether the box datasets differ or not. I think this is very natural and  
> simple, but I might overlook something.
>
> This is also a situation where the box offset comes into play: the two  
> subgroups could in principle use very different boxes, and the offset  
> allows the reconstruction of the particle positions in a global  
> coordinate frame.
>
> Olaf, what is your experience with such a situation? How would the VMD  
> plugin handle it?
>
> Felix

To avoid confusion, let me add that the current draft has only a single  
box in the observables group. My proposed change was to simply move global  
observables (including the box) to a subgroup "global" such that there are  
only subgroups at the "observables" level.

Replicating the box in the various observables subgroups would be a  
different issue (which appears to be discussed partly in this thread).

Felix