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

[Pierre de Buyl]

Le 15 sept. 2011 à 18:09, Felix Höfling a écrit :
> 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).

Well, "observables" is, in my view, all that changes during the simulation, 
which is the case of the box size. The box volume, for instance, is a proper 
physical observable.

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

A file should always, in my opinion, contain the observables group.
I go on after point 3.

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

It was my understanding (see my message of yesterday) that coordinates are 
stored in cartesian coordinates and that the symmetry transformations would 
allow one to define transformations of the cell itself. So that for display, 
you need to apply any transformation to the particles, which would be quite 
heavy on the reader side.

>> 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).
Well, I hope H5MD will be able, at some point, to store
    - MD simulations. reasonable expectation :-)
    - Experimentally relevant structures (crystallography data, for instance) 
so that one can put it into a simulation program.
    - "Only" the observables: Sometimes, I don't need the full trajectory. So I 
want to copy the H5MD file without the trajectory group. I still keep, thanks 
to the observables group, info on energy conservation, center of mass motion 
for selected colloidal compounds, chemical kinetics, box size, ...
    - Other kind of simulations, for instance lattice or kinetic simulations. 
In the former, trajectory (or a newly-named group) would contain the state of 
the lattice sites while in the latter, you may store only distributions (space 
dependent, position dependent or dependent on both).

As the trajectory group will, in general, take the most disk space, I don't see 
why we should always keep h5md, parameters and observables.

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