Re: [h5md-user] Strings again / parallel issue

[Felix Höfling]

Am 06.02.2014, 15:59 Uhr, schrieb Pierre de Buyl
<address@hidden>:

> On Thu, Feb 06, 2014 at 09:39:47AM -0500, Peter Colberg wrote:
> > On Thu, Feb 06, 2014 at 10:11:36AM +0100, Felix Höfling wrote:
> > > Saying Goodbye to mandating VL String is a good idea! But why forcing  
> > the
> > > string to be of fixed-length now? Why don't we let the user decide,
> > > depending on the situation? I think we had good reasons earlier to use
> > > variable length strings. And we might soon encounter a case where
> > > variable-length strings would be preferred.
> >
> > With variable-length strings, the caller needs to pass or receive an
> > array with pointers to character strings; with fixed-length strings,
> > an array of characters. The former is negligibly easier than the
> > latter in C, but significantly harder in Fortran (and requires
> > iso_c_binding); thus the preference for fixed-length strings.
>
> Actually, I have the feeling that variable-length "whatever" in HDF5  
> should be
> used only when there is no choice (i.e. data for which you have  
> significant
> variations in the size of each element).
>
> This comes from:
> 1. the fact that the vl-string attribute routine is missing in Fortran  
> 90.
> 2. h5py's documentation
> http://docs.h5py.org/en/latest/strings.html#compatibility
> 3. VL is reported not to work in parallel settings in the HDF5 FAQ
>
> So making the choice may actually prevent us from shooting ourselves in  
> the foot
> :-)
>
> P

I agree with you. The parallel context is an important reality for H5MD
applications. Not being able to read some data from the file in such a
situation would be a no-go. I had assumed that any valid HDF5 file can
always be read.

So let's stick to truly Atomic types only, i.e. fixed-length strings
everywhere. The HDF5 library is really confusing here by pretending that
VL strings are atomic.

Felix