[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [h5md-user] fields of observable group
From: |
Konrad Hinsen |
Subject: |
Re: [h5md-user] fields of observable group |
Date: |
Mon, 5 Sep 2011 11:17:55 +0200 |
On 2 Sep, 2011, at 14:07 , Felix Höfling wrote:
> How should the edges/offset scheme be extended to account for such things
> as a truncated octahedral?
I see two options:
1) Introduce a special case for the truncated octahedral shape, which is
probably the most frequent one. The size of the box is specifed by the edges
just like for a "normal" (parallelepipedic) box. Some additional label says
that it is truncated octahedral box, meaning that the unit cell of the
parallelepipedic system actually contains two copies of the system.
2) Provide a general mechanism for specifying symmetry inside the box. This
would allow the simulation of arbitrary crystals while maintaining their
symmetry. The part of the simulation universe stored explicitly becomes the
asymmetric unit, to which a set of symmetry transforms are applied implicitly
to reconstruct the whole system. The most straightforward way to store the
symmetry information is as a list of symmetry transformations, i.e. one 3x3
rotation matrix plus a translation vector.
In my "molecular system" data model, I have chosen the second approach because
in my field of work (molecular biophysics), crystals are important because
crystallography is the main source for protein structures.
> The offset can be useful if, e. g., different simulation snapshots shall
> be glued together (for creating layered structures of pre-equilibrated
> phases). And it is necessary for the complete description of an
> arbitrarily positioned box in space. Of course, it is redundant for
> particle positions reduced to the periodic box.
Ultimately this comes down to the question of what conditions you want to
impose on the particle coordinates stored in the trajectory. There are various
options:
1) No conditions at all. A particle implicitly stands for all its periodic
images, which are constructed by applying integer multiples of the edge
vectors. There is then no point in storing an offset. This convention makes
life easy for programs generating a trajectory, but requires more work by
programs that read a trajectory. It provides most freedom for pairs of
generators/readers to establish their own conventions, but leaves the
verification of these conventions to the readers.
2) Coordinates are required to be in the interval [offset ... offset+edge[.
Trajectory generating programs must ensure this condition, but have the freedom
of specifying the offset as it suits them. Reading programs gain a bit compared
to 1) but must still handle arbitrary offsets.
3) Coordinates are required to be in an interval defined by the trajectory
format specification, such as [0 ... edge[ or [-edge/2 ... edge/2[. This puts
more constraints on trajectory generators but provides the most guarantees to
readers.
There are also intermediate choices, such as permitting various conventions and
indicating them in metadata.
In biomolecular simulations, the usual convention is 1) because it permits a
useful arrangement for visualization: coordinates can be arranged such that
biologically important molecular assemblies are represented in the way that is
most useful to a biologist. This comes down to having a specific arrangement
for each individual simulation. All programs get a bit more complicated, but
it's the users who gain. However, the same effect can be obtained otherwise,
e.g. by storing an explicit "visualization offset" outside of the trajectory.
Konrad.
--
---------------------------------------------------------------------
Konrad Hinsen
Centre de Biophysique Moléculaire, CNRS Orléans
Synchrotron Soleil - Division Expériences
Saint Aubin - BP 48
91192 Gif sur Yvette Cedex, France
Tel. +33-1 69 35 97 15
E-Mail: research AT khinsen DOT fastmail DOT net
---------------------------------------------------------------------