[Top][All Lists]

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

Re: [h5md-user] [h5md-commit] [SCM] master, updated. c234149781bfa9f5dc8

From: Felix Höfling
Subject: Re: [h5md-user] [h5md-commit] [SCM] master, updated. c234149781bfa9f5dc81aa139038e7dc6689b64d
Date: Wed, 12 Jun 2013 18:11:38 +0200
User-agent: Opera Mail/12.15 (Linux)

Am 01.06.2013, 21:49 Uhr, schrieb Pierre de Buyl <address@hidden>:


I think that, as you mention yourself at the end, at some point it becomes a question of choice. My choice, up to now, is to put all time dependent data in /observables except for the trajectory (that is, datasets that contain one item per particle) with the lengthily discussed issue of the box specification. By
the way, I have not yet reviewed the latest commit that duplicates (If I
understood correclty) the box information which would lead to duplicate data.

If "particles" is kept optional, this provides a good and interesting flexibility to /observables (even for future unknown yet cases). If not, it means that I
have to select manually which time-dependent data goes where.

For an idea of "my side" of H5MD, you may want to have a look at my Fortran implementation. Basically, I have routines that handle all "parameters" as time-independent data and all "observables" as time-dependent data and this is
very easy to use and manage.
By this I do not mean in any way that we should do it the "f90h5md" way else it
would not be very interesting as a collaborative project :-)
But I would like to point here that making "particles" mandatory kills part of what makes H5MD easy for me. It was indeed easier to write and generate more than 2500 lines of Fortran code than writing data manually. But H5MD should remain flexible with respect to the users (and developers, who are indeed users

Sorry for the long email "Pierre de Buyl" <address@hidden>for so little, but I want H5MD to remain a comfort of
use and the solution I want to use for all my molecular data :-)



Hi Pierre,

I see your point. It is worth keeping the value/step/time structure intact.

The attribute could be moved up one level to, e.g., /observables/group1, and there it is either an attribute (fixed in time) or a time-dependent dataset simply named "count" or "number".

Making it optional would be possible, but I don't favour it. The question then is how /trajectory and /observables differ at all and why the two groups need to be distinguished and specified.

Independently of that we need to specify how a H5MD reader behaves if optional data are missing.

On the long run, I have also other root groups in mind, e.g., /structure for pair correlation functions (depend on distance) or static structure factors (depend on wavevector) and /dynamics for mean-square displacement (depends on lag time), intermediate scattering functions (depends on wavevector and lag time) etc. Of course we may leave it to the user, how such quantities are stored but what is then the added value of H5MD if there is no consenus about the content of the data groups, about naming conventions etc.? In my understanding, the root groups are useful for grouping different substructures. Of course, data forming a time series are always stored as value/step/time triples.



reply via email to

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