|
From: | Felix Höfling |
Subject: | Re: [h5md-user] Case of 1D systems |
Date: | Tue, 16 Aug 2011 19:53:30 +0200 |
User-agent: | Opera Mail/11.50 (Linux) |
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
[Prev in Thread] | Current Thread | [Next in Thread] |