h5md-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Felix Höfling
Subject: Re: [h5md-user] Strings again / parallel issue
Date: Thu, 06 Feb 2014 10:11:36 +0100
User-agent: Opera Mail/12.16 (Linux)

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…

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.

Peter


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.

Cheers,

Felix



reply via email to

[Prev in Thread] Current Thread [Next in Thread]