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