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

[Pierre de Buyl]

Hi Olaf,

On Fri, Jan 10, 2014 at 04:21:52PM +0100, Olaf Lenz wrote:
> 2014/1/10 Pierre de Buyl <address@hidden>:
> > For those components where `boundary` is set to "none", any value of
> >
> > > `edges` or `image` must be silently ignored.
> >
> > Any value of `image` then. Edges only play a role if 'image' is different
> > from
> > zero.
> 
> 
> No! That is exactly *not* true. It makes perfect sense to specify periodic
> boundary conditions, an edge, but no image! This is exactly the case when
> you use what I call absolute coordinates, where the positions may be
> outside the box.

Please forgive me, what I wrote was not clear. I only intended to write that
'edges' was not used to compute the position (i.e. $R_{ik} = r_{ik}$ as opposed
to $R_{ik} = r_{ik} + L_k a_{ik}$).

Actually, if you want the 'in-box' position you have:
R_{ik} = r_{ik} modulo L_k

> To clarify, let me try to make some examples of possible cases, all of
> which do make sense! I am now specifying only one dimension and a single
> particle with a position x=20.3. In the periodic case, the edge is 10.0.
> 
> *Case 1: Open boundaries*
> 
>   boundary = "none"
>   position[0] = 20.3
> 
> In this case, any value of 'edge' or 'image' has to be ignored.
> 
> *Case 2: Periodic boundaries, with folded positions and image specification*
> 
>   boundary = "periodic"
>   edge[0] = 10.0
>   position[0] = 0.3
>   image[0] = 2
> 
> This is probably the standard case that most people think of.
> 
> *Case 3: Periodic boundaries, with absolute positions and without image*
> 
>   boundary = "periodic"
>   edge[0] = 10.0
>   position[0] = 20.3
> 
> This case also makes sense when a software never explicitly computes the
> image the particle is in.
> 
> *Case 4: Periodic boundaries, with folded positions that may lie outside
> the primary image ("mixed")*
> 
>   boundary = "periodic"
>   edge[0] = 10.0
>   position[0] = 10.3
>   image[0] = 1
> 
> This case might look weird, but it does make perfect sense in some
> simulation packages.

Thanks for providing these examples. They all make sense to me, even Case 4!

Best,

Pierre