[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [h5md-user] tentative of synthesis: parameters, box size, particle n
Re: [h5md-user] tentative of synthesis: parameters, box size, particle number
Thu, 15 Sep 2011 18:09:59 +0200
Opera Mail/11.51 (Linux)
Am 14.09.2011, 09:39 Uhr, schrieb Pierre de Buyl
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).
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 "/
- In my opinion, time-dependent information should not be in
"parameters" but in "observables".
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
see the manual of gromacs, chapter 3, §3.1 and §3.2 at
http://www.gromacs.org/ second news item or direct link
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
I agree, that's why I would like to move it to the parameters group.
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.
- 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 ?
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.
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).
3. particle numbers
- I prefer the option where the data is in a single dataset [:]
- 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.
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.