Re: [h5md-user] fix remaining imprecisions - particle position

[Pierre de Buyl]

Hi all,

On Fri, Jan 10, 2014 at 12:15:10PM +0100, Felix Höfling wrote:
> Am 10.01.2014, 11:14 Uhr, schrieb Konrad Hinsen
> <address@hidden>:
> 
> >Felix Höfling writes:
> >
> 
> > > Originally, `offset` together with `edges` was meant to provide
> >the range
> > > of folded particle positions. As of Olaf's pointing at the box
> >skin, this
> > > use has become meaningless. As nobody is using `offset` AFAIK,
> >we may drop
> > > it in favour of `minimum` and `maximum` which provide a
> >guarantee on the
> > > range of particle positions. What do you think?
> >
> >Sounds good in principle, but again the devil is in the details.
> >
> >1) Having both "minimum" and "maximum" is redundant, as the difference
> >   must be "edge".
> >
> It's not fully redundant as Olaf pointed out, because the difference may
> exceed the edge length by a skin width.
> 
> >2) Any such specification should be optional, for trajectories that
> >   don't make any promises.
> >
> Of course. I think the minimum/maximum fields would best go to the
> particles/.../position group, not in the box.
> 
> >3) In simulation of small-molecule liquids, it is common to apply
> >   periodic boundary conditions to the centers of mass of the molecules,
> >   rather than to individual atoms. The guarantee on the positions thus
> >   applies to something else than the stored coordinates.
> >
> >   It's OK with me to say that no minimum/maximum should be specified
> >   in this situation, but I think it's worth saying so explicitly to
> >   avoid misunderstandings.
> >
> Sounds like a similar situation as with the skin due to lazy updates of
> the image vectors. I suggest to skip the minimum/maximum fields in this
> case, or to specify a (not necessarily tight) bounding box of actual atom
> positions.
> 
> I have removed the offset from the box specification and have added a
> suggestion for minimum/maximum, which I called bounding_box. (Since a
> minimum value would have to be taken by any of the positions, strictly
> speaking.)

I am very reluctant to include bounding_box:
- There seems to be very little motivation to use it.
- It is in the spec but not used by anyone.
- It is not in direct relation to a physical quantity.
- Currently, it is written as valid for all times, which makes it less
  appealing.
- If I were to use the information, I would check myself anyway in my code. This
  view seems shared by Olaf [1].

With respect to "offset", my view is that it serves to define the absolute
boundaries of the box [2]. It is not "essential" as the edges is sufficient to
define the physical properties of the box it is a a physical quantity
nonetheless. Pragmatically, I use it to define my simulation box (i.e.
xmin,ymin,zmin in my software).

I understand that this use might not seems interesting to others and we can drop
it (as in the current state of the repository).

In the absence of protests, I'll remove bounding_box.

I wanted to react to offset/bounding_box, I'll take a look now at the
interpretation of "image" :-)

Best,

Pierre

[1] http://thread.gmane.org/gmane.science.simulation.h5md.user/500/focus=524
[2] http://thread.gmane.org/gmane.science.simulation.h5md.user/309/focus=458