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

[Pierre de Buyl]

On Thu, Feb 06, 2014 at 10:11:36AM +0100, Felix Höfling wrote:
> Am 06.02.2014, 05:14 Uhr, schrieb Peter Colberg
> <address@hidden>:
> 
> >Hi Pierre,
> >
> >On Wed, Feb 05, 2014 at 02:03:57PM +0100, Pierre de Buyl wrote:
> >>On the Fortran examples page on the HDF5 website [1] there is simply no
> >>variable-length string attribute code :-/
> >
> >There is an example…

For vl-string attribute? strings are handled differently w.r.t. other vl
datatypes. I received an example for a vl-string attribute on the hdf-forum
mailing list yesterday but it requires Fortran 2003. Anyway, I isn't supposed to
work in parallel.

http://mail.lists.hdfgroup.org/pipermail/hdf-forum_lists.hdfgroup.org/2014-February/007530.html

> >Be sure to hold a safety blanket before opening this:
> >
> >http://www.hdfgroup.org/ftp/HDF5/examples/examples-by-api/hdf5-examples/1_8/FORTRAN/H5T/h5ex_t_vlenatt_F03.f90
> >
> >I updated the H5MD specification to mandate fixed-length string
> >datatypes.

Thanks for the update.

> Hi Peter,
> 
> 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.
> 
> I found it a bit confusing whether a variable-length string is of Atomic
> type H5T_STRING or Composite type H5T_VLEN. Here is what I learned:
> 
> The HDF5 API and the file treat vlen strings as H5T_STRING (check output
> of h5dump). Internally, the library converts it to H5T_VLEN (see line 3789
> in H5T.c, version 1.8.11), but this is fully opaque to the user.
> 
> Writing is easy (for a scalar string, not for arrays): use
> H5T_{C,FORTRAN}_S1 as predefined type and call H5Tset_size with
> H5T_VARIABLE (or -1) instead of the actual string size. The same for
> reading, just use H5T_*_S1, but don't set its size and don't allocate
> space for the result buffer.
> 
> So I'm in favour of giving full freedom to the user what string type to
> choose.

Given the unexpected disappointment on VL strings, I must say that I don't know
what to think anymore. I actually didn't implement VL strings in my Fortran code
(this was 'too recent' in a way for my use) and the addition of parallel
programming issues just comes on top of that.

Anyone with relevant experience is welcome to comment.   

Pierre