Re: [h5md-user] fields of observable group

[Konrad Hinsen]

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
---------------------------------------------------------------------