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

[Felix Höfling]

Am 14.09.2011, 09:39 Uhr, schrieb Pierre de Buyl  
<address@hidden>:

> Hi everyone,
>
> There has been a lot of traffic on the list and I couldn't keep up. I'll  
> try to make a synthesis of my suggestions, remarks and questions.
>
> Please, if possible, keep the discussion in this single thread so as to  
> remain focused on these items.
>
> 1. parameters "subgroups"
>       - I think it is a good idea to devise a few (let us keep it to a  
> minimum) shared parameters and to put program parameters in "/ 
> parameters/program_name".
>       - In my opinion, time-dependent information should not be in  
> "parameters" but in "observables".
The idea behind moving 'particle_number' and 'box' to /parameters was that  
they should become mandatory for a H5MD file, while the /observables group  
is optional. I have encountered several situations where both information  
is essential for the further interpretion of the data, independent of  
where the data come from (trajectory or observables). Of course, they  
could be time-dependent datasets (as we have in both trajectory and  
observables so far).

> 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
Good question, we should look that up.

>      - If we put all of that in "observables" (not parameters), then a  
> H5MD file with only the trajectory group will be useless. Do we agree on  
> that ?
I agree, that's why I would like to move it to the parameters group.

>      - can one on Konrad or Felix synthetize the result?
>      - I am not in favour of storing in fractional coordinates, for my  
> data at least. How would that work ?
>      - Peter, do you have comments ?
>      - If I understood correctly, the latest suggestion is to store, for  
> each time frame, a set of transformations and a shift ? How would it  
> work if I sample very often a reduced set of coordinates (center of mass  
> of a group of particles), I guess I need to have the transforms  
> available at all times ?
No, storing fractional coordinates would be a pain. The idea was merely  
that symmetry transformations applied to a part of the box (e.g. for  
truncated octahedra or other box geometries with internal symmetries) are  
stored in fractional coordinates. Thus, the information has to be given  
only once, even if the box size fluctuates. This is just meant for very  
complicated boxes, for cuboid boxes, nothing changes.

The offset _could_ become part of the first symmetry transformation, which  
would be the identity matrix plus a translation [e.g., (-1/2, -1/2,  
-1/2).] But I would like to avoid a situation where every access to  
particle coordinates requires a transformation (like a shift), even for  
simple situations. Should we allow for the situation that the (relative)  
offset changes with time, e.g. for a box co-moving with an active particle  
(like a swimmer)?

So far, there is an ambiguity of "for each time frame": The trajectory  
coordinates may be written at a different interval than the box extents in  
the case of a fluctuating box. This can cause some troubles in the reader:  
from the index in the trajectory data set, you cannot simply infer the  
index in the box dataset. One would need to find the corresponding box  
entry at the same value of 'step' as in the trajectory dataset.


> 3. particle numbers
>      - I prefer the option where the data is in a single dataset [:] 
> [N_species].
>      - It should be in "observables".
>      - It should not be mandatory, as some simulation/experiments may  
> work with no "particle number" or with a fixed particle number, in this  
> situtation having a time-dependent dataset is overkill.
An MD simulation without particles appears weird to me ... What do you  
mean with that? The time-dependent dataset could contain a single entry  
only, of course, which would be valid for all later times (until the next  
'update' if it exists).


> 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.
I agree, H5MD 0.1 should be simple, but sufficently generic.

Best wishes,
Felix