[Top][All Lists]

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

Re: [h5md-user] tentative of synthesis: parameters, box size, particle n

From: Pierre de Buyl
Subject: Re: [h5md-user] tentative of synthesis: parameters, box size, particle number
Date: Tue, 4 Oct 2011 22:10:43 +0200

Le 15 sept. 2011 à 21:28, Konrad Hinsen a écrit :
> On 14 sept. 11, at 09:39, Pierre de Buyl wrote:
>> 2. box size
>>   - The offset should be given, each in their "H5MD containter" with step 
>> and time.
>>   - How different is what we do with respect to, for instance, PDB or 
>> gromacs ?
>>      see the manual of gromacs, chapter 3, §3.1 and §3.2 at 
>> http://www.gromacs.org/ second news item or direct link 
>> ftp://ftp.gromacs.org/pub/manual/manual-4.5.4.pdf
>>     pdb http://www.wwpdb.org/documentation/format33/sect8.html
> I don't know about Gromacs, but all about PDB. It's a format for storing 
> crystal conformations, so they follow crystallography conventions. It's also 
> a format for single conformations, so time dependence is not an issue.
> The size of the unit cell is given by the three edge lengths (a, b, c, in 
> Angstrom), and the shape by three angles (alpha, beta, gamma, in degrees). 
> The first lattice vector points along the x axis, the second lies in the x-y 
> plane. Symmetry is specified by the name of the symmetry group, which implies 
> a set of symmetry transformations and constraints on the unit cell shape, but 
> those are supposed to be known (tabulated), so they are not stored explicitly.
> The PDB conventions are not very practical for simulations. Simulation 
> programs need the lattice vectors, not their lenghts and angles. The use of 
> named symmetry groups isn't practical either, unless we want all simulation 
> programs to incorporate the tables published by the IUCr (International Union 
> of Crystallographers).

Does anyone see a limitation to use the scheme proposed by Felix ?
  \-- offset
    \-- value [var][d] e.g., (-L_x/2, -L_y/2, -L_z/2)
    \-- time [var]
    \-- step [var]
  \-- edges
    \-- value [var][d][d] e.g., ((L_x, 0, 0), (0, L_y, 0), (0, 0, L_z))
    \-- time [var]
    \-- step [var]
The more elaborate scheme seems overkill.
We could think of setting an attribute to the "box" group that would indicate 
the type of box information.
  +-- kind = [ cubic | triclinic ]
  +-- time_dependent = [ 0 | 1 ]

Then, future revision could easily adapt it by adding box types.

>>   - I am not in favour of storing in fractional coordinates, for my data at 
>> least. How would that work ?
> It's possible, not but practical. I don't see any advantage. Fractional 
> coordinates are good for symmetry operations because that makes them time 
> independent in all practically relevant situations. Most MD simulations don't 
> need symmetry operations anyway.
Ok, this is set then.

>>   - If I understood correctly, the latest suggestion is to store, for each 
>> time frame, a set of transformations and a shift ?
> No, only once for the whole trajectory.

>> Thanks for your various suggestions, and sorry if it looks like I'm not 
>> understanding everything. I am not familiar myself with non-cubic boxes, 
>> understand that they are very useful in many situations, and at the same 
>> time would like to keep "H5MD 0.1" simple enough.
> Non-cubic is a must for macromolecules. Cuboid is the minimal requirement, 
> but many simulations also need non-orthogonal boxes.
Triclinic seems to be a requirement. Is more required ?


Pierre de Buyl
Chemical Physics Theory Group - University of Toronto
Physique des Systèmes Complexes et Mécanique Statistique - Université Libre de 
web: http://homepages.ulb.ac.be/~pdebuyl/
Tel: +1-416-946-0047

reply via email to

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