Re: [h5md-user] [h5md-commit] [SCM] UNNAMED PROJECT branch, master, updated. c234149781bfa9f5dc81aa139038e7dc6689b64d

[Pierre de Buyl]

On Fri, May 31, 2013 at 03:35:13PM +0200, Felix Höfling wrote:
> Am 31.05.2013, 13:01 Uhr, schrieb Pierre de Buyl
> <address@hidden>:
> 
> >On Wed, May 29, 2013 at 03:01:57PM +0200, Felix Höfling wrote:
> >>Am 29.05.2013, 13:48 Uhr, schrieb Pierre de Buyl
> >><address@hidden>:
> >>
> >>>I would like to make the "particles" attribute optional. It is
> >>>useless in many
> >>>cases.
> >>
> >  - A quantity associated with a thermostat, such as a program for the
> >    temperature.
> >  - State of a PRNG. This is in my opinion a very valid usecase.
> >If a code uses
> >    H5MD, it should be able to store a maximum amount of data in
> >the H5MD file.
> >    As the state of a PRNG depends of the time and can be used for
> >    checkpointing, it is very well suited for the observables group.
> >  - Data about simulated or measured actuators or probes.
> >
> >Sticking a mandatory "particles" attribute makes no sense for
> >those usecases. As
> >the need for it is frequent I still think that it should be a
> >reserved and
> >optional attribute name.
> >
> 
> Thanks for providing these examples. The /observables group is
> intended for physical observables that are averages over a (sub)set
> of particles. And the primary target of H5MD are molecular
> simulations. Let me respond to your examples:
> 
> Thermostat variables should be stored inside /trajectory since the
> time evolution of each degree of freedom is resolved. Things like
> the thermostat energy, however, deserve a place in /observables.
> Here, the number of degrees of freedom may replace the particle
> number.
> 
> Experimental data of a different kind (e.g., the time series read
> from a voltmetre indicating a cantilever position) may go to a
> different root group. Alternatively, the user is free to set the
> "particle" number (or number of d.o.f.) to 1.
> 
> For the state of a PRNG, I would prefer to store it inside
> /parameters as it heavily depends on the simulation program.
> 
> Does this answer your objections?
> 

Hi,

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.
http://homepages.ulb.ac.be/~pdebuyl/code/f90h5md.html
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
too).

Sorry for the long email 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 :-)

Cheers,

Pierre