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

[Felix Höfling]

Am 16.08.2011, 19:34 Uhr, schrieb Peter Colberg  
<address@hidden>:

> Hi Felix, hi Pierre,
>
> On Tue, Aug 16, 2011 at 10:44:35AM -0400, Pierre de Buyl wrote:
> > Hi Felix,
> >
> > One of the reasons I am asking this is that in my current
> > implementation, the H5MD routines automatically take into account
> > the kind and shape of the data that is sent to them.
> > What happens is that it ends up being easier to work without the
> > last dimension, then. I need to add it "by hand" for now.
> >
> > If the same situation happens in other implementations, it becomes
> > easier to drop the last dimension, else not.
> > As for the analysis, I usually do it in Python where it would quite
> > easy to handle the flexibility.
>
> I second that.
>
> In HALMD we would have the same issue: 1-dimensional coordinates stored
> in a vector<double> would be written with one dimension less than
> multi-dimensional coordinates in a vector<fixed_vector<double, N> >.
>
> Peter

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.

@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.

Felix


--
Dr. Felix Höfling
Max Planck Institute for Intelligent Systems
(formerly Max Planck Institute for Metals Research)
Heisenbergstr. 3
70569 Stuttgart
Germany

Phone:  +49 711 689 1938
Fax:    +49 711 689 1922