Re: [h5md-user] Case of 1D systems

[Peter Colberg]

On Tue, Aug 16, 2011 at 07:53:30PM +0200, Felix Höfling wrote:
> In NumPy, it doesn't make a difference, I think you wouldn't even
> have to provide the index as it is now (except for beautification of
> the output). But think about an analysis tool written in C++ (or
> Fortran?), there it would cause a lot more troubles.
> 
> If we want to "allow" for this exception in H5MD, then both variants
> have to be supported by a proper H5MD reader. This is taken for
> granted in NumPy, but not necessarily in other languages. In
> general, I feel that exceptions and alternatives make things more
> difficult to maintain in the end.

I agree that a reader would have to support 1-dimensional datasets
both with and without the “extra” dimension, which would mean more
work for every author of a H5MD-compliant trajectory reader.

> @Peter: I must be missing something here. In HALMD, we would
> instantiate the templates with dimension=1 resulting in
> vector<fixed_vector<double, 1> >
> Otherwise, we would have to make use of type traits in a more
> consistent manner.

What I meant to say is that if HALMD were a 1D-only package, and we
were using vector<double> for particle coordinate arrays, our current
H5MD writer would not add the extra dimension. But you are of course
correct, if we supported 1D in addition to 2D/3D, we would use
fixed_vector. Anyway, this is off topic on this list ;-).


So I made up my mind and would vote for a consistent data format that
mandates “position/samples” to be of dimensions (variable × N × D),
regardless of whether D is equal to 1, or greater. This adds only
little burden onto the author of a 1D simulation package, and spares
every author of a H5MD evaluation script a major headache.

Peter