[Top][All Lists]

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

Re: [h5md-user] H5MD developer's guide

From: Pierre de Buyl
Subject: Re: [h5md-user] H5MD developer's guide
Date: Thu, 26 Sep 2013 10:33:51 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Hi Konrad,

On Tue, Sep 24, 2013 at 10:54:51AM +0200, Konrad Hinsen wrote:
> I propose that we write, in addition to the H5MD specification, a
> developer's guide that explains how best to do specific tasks related
> to trajectories. The motivation is twofold: (1) archive the parts of
> the exchanges on this list that are likely to be of use to others
> later, and (2) discover omissions and inconsistencies in the
> specification by considering how the specification gets applied in
> practice. The ideal form for this would be a Wiki, but I don't know
> if that's an option on nongnu.org.

>From experience, wikis very often get outdated. An additional section could 
be added to nongnu.org/h5md even though it is a bit more cumbersome to manage.
nongnu.org does not offer wikis.

Are there other alternatives to a wiki or to the single repository we have

> As a case in point, we have the current discussion about the box
> information. It started with a question of mine which resulted from my
> attempts to write a program that reads positions and box shape
> information at matching time steps. The current state of this
> discussion has shown that
>  1) There is no agreement on how box information should be stored, in
>     particular if priority should be given to simplicity of storage (a
>     single box group per trajectory) or to efficiency of access (a box
>     group per position trajectory at matching steps).
>  2) A reasonable and useful restriction, monotonicity of step and time
>     arrays, is not written down in the specification.
> This shows that thinking about doing certain things is definitely
> useful.
> Here's a first list of standard tasks that should be considered:
> - Creating a new trajectory, providing various amounts of
>   time-invariant data.
> - Appending a step to the trajectory, providing data for various
>   quantities.
> - Reading positions for a subsystem sequentially, with matching box
>   information.
> - Reading a specified subset of trajectory data (positions,
>   observables ...)  at a specific step number.
> - Reading the positions for a (small) subset of the system for all
>   times, with matching time labels and box information.

In a very pragmatic way, I consider that providing H5MD implementations (in
Python and Fortran, from my side) is a more efficient way of communicating this.
The source code allows one to gather information on these practicalities.

Of course, knowing H5MD quite well I may not realize very well what information
another scientist willing to use H5MD would need.


reply via email to

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