[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: Felix Höfling
Subject: Re: [h5md-user] tentative of synthesis: parameters, box size, particle number
Date: Thu, 15 Sep 2011 18:09:59 +0200
User-agent: Opera Mail/11.51 (Linux)

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,

reply via email to

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