[Top][All Lists]

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

Re: [h5md-user] box and observables

From: Peter Colberg
Subject: Re: [h5md-user] box and observables
Date: Tue, 24 Sep 2013 12:51:15 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Sep 24, 2013 at 06:13:06PM +0200, Konrad Hinsen wrote:
> In the following, I limit myself to the "particles" group, which is
> where my immediate needs are. Even that part is far from clear to me.
>  > Let’s consider the implementation for a second. Whether box is
>  > replicated to multiple locations or not, a writer would probably
>  > implement a single function that appends the box information at the
>  > current time to the box group, which is invoked by particle and
>  > observables modules that rely on the box information.
> What about a writer that writes two different subsystems at different
> sampling intervals? With a single box group, that requires a lot of
> coordination.

The box writer function needs to know about the step/time of the
system anyway, no? So the box writer already knows how to avoid
appending the box information twice for the same step/time.

> Next, the reader: if there is a single box group but differently
> sampled positions for different subsystems, reading the box
> information is a lot of work and slow.

Well, this is the essence of the step/time scheme.

I added a section [1] on the use of the step/time datasets, which
refers to the binary search, upon which the step/time scheme relies.
This is the basic building block for any H5MD program.

[1] http://h5md.nongnu.org/implementation.html

> So looking at this purely from the point of view of writing and
> reading positions, a box group per subsystem is highly desirable.

For that specific case, yes, that would be desirable.

For the case of all data that depends on the box for interpretation,
the replicated box groups complicate the matter, while providing no
benefit, as a step/time lookup is needed anyway.


reply via email to

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