Re: [h5md-user] particle number

[Pierre de Buyl]

Hi Felix,

On Fri, Feb 01, 2013 at 03:50:40PM +0100, Felix Höfling wrote:
> Am 25.01.2013, 20:19 Uhr, schrieb Pierre de Buyl
> <address@hidden>:
> >On Fri, Jan 25, 2013 at 04:10:49PM +0100, Felix Höfling wrote:
> >>1) The space dimension shall be stored in /parameters+dimension (as
> >>integer attribute).
> >>
> >>In principle, it can be deduced from the size of the box offset, but
> >>this appears pretty cumbersome. Apart from handiness, the box may be
> >>found either in observables or in trajectory, requiring a
> >>distinction of cases—just to obtain the space dimension.
> >
> >This seems reasonable enough :-)
> >
> 
> I've included the space dimension in the draft. Since I can't push
> to git://git.savannah.nongnu.org/h5md.git (why?) I have attached the
> patch.

I checked your patch. Wouldn't it be easier to make "dimension" a dataset
instead of an attribute? It is an important parameter so I don't feel like it
should be made less visible.

Just nitpicking anyway, if you prefer attribute I'll commit anyway.

Here's the URL I have in my .git/config:
address@hidden:/srv/git/h5md.git
git:// is read-only. address@hidden uses ssh and savannah uses ssh-key login.

(First use of "git am", it is not that complex to use).

> >>2) If data are present only in /observables, the number of particles
> >>can not be inferred. My suggestion is to supplement each observable
> >>group with an attribute indicating the number of particles that lead
> >>to this specific average. (So far, all macroscopic observables
> >>result from an average over particles.) Thereby, also partial
> >>observables of particle subgroups are handled correctly. The
> >>attribute may be attached either to the top groups ('all', 'A', and
> >>so on), or to individual data groups like 'total_energy'.
> >
> >I have mixed feelings about this one. For the moment (this does
> >not mean that
> >this should be the final solution, btw) I run multispecies
> >simulations. The
> >number of particles is in /observables/solvent_N and is a
> >[:,N_species] dataset.
> >In all generality, the number of particles depends on time and on
> >the species.
> >The variety of situations makes me think that this should not go
> >into the first
> >published version (FPV).
> >
> >>I believe that both attributes are of sufficient generality to
> >>deserve a place in H5MD, and I will add them if there are no urgent
> >>objections.
> >>
> >>BTW, what is missing as well is an (optional) error field (=standard
> >>deviation) for the observables. What do you think?
> >
> >Is this critical for the FPV?
> >
> 
> I see that we're running in a similar trouble as with the
> static/fluctuating box size. Nevertheless, I think storing the
> particle number of averaged quantities is an essential feature, two
> examples:
> 
> Example 1: given two subset of particles, the total potential energy
> per particle can not be computed from the subgroups unless the
> particle number is known.
> 
> Example 2: computing simple response coefficients like the specific
> heat from energy fluctuations requires the particle number.
> 
> The crucial point is to add the possibility to convert a per
> particle quantity in a total quantity. If the particle group
> contains a mixture (as in your case, and also in some of my
> simulations), the _total_ number of particles is stored.
> (Information about the fluctutating composition of the mixture may
> go in a seperate observable.)
> 
> My suggestion is to store the particle number either in an attribute
> attached to the observable if it is fixed in time or in a dataset
> next to value/time/step if it fluctuating. The naming may be
> "number", "particle_number", or simply "count".

"count" is more generic. It could be simpler to parse if it remains a dataset
either way. An attribute is not really necessary as "all that jazz" is enclosed
in a group anyway. 

observables
 \-- obs_1
      \-- step [var]
      \-- time [var]
      \-- value [var] (or [var,d1,d2,...]
      \-- count SCALAR


observables
 \-- obs_1
      \-- step [var]
      \-- time [var]
      \-- value [var]
      \-- count [var]

> What do you think?

OK, just check what you think of the attribute/dataset issue.

Best,

Pierre

> PS: Your replies to the mailing list are often only CC to the list,
> is this by intention? Opera's mail client doesn't recognise such
> mails as belonging to the discussion in the list.

No idea why it behaves like this. For this list, I have to add the address or
hit "reply-all" whereas for other lists I just just hit "reply" and don't even 
look
further.