h5md-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Felix Höfling
Subject: Re: [h5md-user] fix remaining imprecisions - particle position
Date: Wed, 08 Jan 2014 17:07:17 +0100
User-agent: Opera Mail/12.16 (Linux)

Am 08.01.2014, 15:58 Uhr, schrieb Olaf Lenz <address@hidden>:

Hi all!

Happy New Year!

In some cases it makes sense to store the particle coordinates in absolute coordinates in a periodic system even when they are outside the primary box
(for example when tracking the MSD of the particle). In that case 'image'
would not be defined.
Also, it might make sense to store coordinates outside the primary box even when 'image' is used (for example, it is common practice that particles can
walk out of the box up to skin/2 before the image is updated for
performance reasons.

To make that clear, I propose to change the last paragraph (starting with
"For instance...") with the following paragraph:

If the component $d$ of `box/boundary` is set to "none" (see below) and `image` is set, the value of the corresponding component $d$ of `image` has
to be silently ignored. If the component $d$ of `box/boundary` is set to
"periodic", this does neither mean that the element `image` has to exist
nor that the position has to be within the primary box. The component $d$
of the absolute position of particle $i$ is then computed as $R_{id} =
r_{id}  + L_d a_{id}$, where $\vec r_i$ is taken from `position`, $\vec
a_i$ is taken from `image`, and $\vec L$ from `box/edges`.

Furthermore, I would propose to extend the paragraph "Simulation box" ->
"boundary" as follows:

  For those components where `boundary` is set to "none", any value of
`edges` or `offset` must be silently ignored.

Finally, I am still wondering about the meaning of the `offset` field,
given that we give no guarantees on the limits of the positions. What could
anybody do with this value?

Olaf


Thanks a lot for the feedback! I have updated the spec according to your
suggestions. The requirements on the position data are pretty weak, but as
this seems to be common practice it makes no sense to be more stringent in
the output file.

Would it make sense to add a "skin depth" to the box which states how much
the positions may deviate at most from the primary box? Then also the
offset field would make sense again.

Felix



reply via email to

[Prev in Thread] Current Thread [Next in Thread]