Anton,
main purpose of that program of course is inspiration ;)
From your initial question, it sounded as if you would like attributes
to a compound data type. This is what the program is doing. Unfortunately
there are limitations in HDF5, you cannot add attributes to transient types,
only to committed types (i.e. named datatypes that are bound to a file).
Also, the components of a compound data type will not inherit the properties
of a named datatype and its attributes, which would be the most elegant
solution.
But you can have attributes with the same names as compound members, and these
attributes may be named datatypes with attributes. That is what this program
is doing.
If that NSF proposal is funded that Quincey mentioned (cross fingers and go
lobbying at NSF ;) ), then it will be possible to add such attributes directly
to the compound data type members. It should be similar to the current solution,
but a bit simpler and more natural.
Or did you just want to add an attribute that was of compound data type to
a dataset? That is of course even simpler, but then you would need to add this
attribute explicitly to each dataset, and you need to invent some name for this
attribute, which might eventually need to some name space conflicts. Going via
named datatypes ensures that all datasets of the same type also have the same
units, independent if the datasets might have any more attributes or none.
Werner
On Thu, 18 Mar 2010 17:46:46 -0500, Anton Kulchitsky <[email protected]>
wrote:
Werner,
Sorry, I missed the attached file and program! They are very helpful. By
the way, I learned about transient datatypes. :) Your solution seems to
me a bit more complicated than creating a compound attribute. However,
it is a matter of taste and maybe it is because I did not used to
transient datatypes.
Anton
Anton,
there are no groups in this file. It only contains as single data set of five
elements which is build from a compound datatype of type struct { double t,x; }.
This compound datatype has two attributes, called "t" which is of type "seconds"
and another attribute "x" which is of type "meter"; both "seconds" and "meter"
are of type "double".
I'm more used to h5ls, but the hdf5 file was attached, so you can give h5dump
a try on it (I don't have h5dump installed here at the moment for 1.8).
For the given scenario, to find the units of a dataset's compound member,
you would need to look at an attribute of the same name as the compound member,
and this one would be of the type of the respective unit. In the example below
the value of this attribute is zero, it's not really used, but it could e.g.
have some scaling value, for instance 1000 to tell that the x-values of this
dataset is given in kilometres.
Werner
On Thu, 18 Mar 2010 13:30:15 -0500, Anton Kulchitsky <[email protected]>
wrote:
Werner,
I did not understand exactly what is this. Does it mean creating some
additional groups with names of units and making links to the data?
I worry it is too complicated especially for those who never saw the
data before and needs just take a quick look into the file they received?
Maybe I missed the point. Maybe h5dump would show more details?
Anton
Anton,
would something like the following do? HDF5 file and source code attached.
It's not as elegant as the forthcoming method to have attributes directly
at the compound type's members, but is some kind of workaround with the
existing methods.
Werner
h5ls -rvd test.h5
Opened "test.h5" with sec2 driver.
/ Group
Location: 1:96
Links: 1
/data Dataset {5/5}
Location: 1:1504
Links: 1
Storage: 80 logical bytes, 80 allocated bytes, 100.00% utilization
Type: shared-1:1224 struct {
"t" +0 native double
"x" +8 native double
} 16 bytes
Data:
(0) {1, 2}, {3, 4}, {1, 4}, {1, 5}, {5, 0}
/meter Type
Location: 1:800
Links: 2
Type: shared-1:800 native double
/seconds Type
Location: 1:1176
Links: 2
Type: shared-1:1176 native double
/spatiotemporal Type
Attribute: t {1}
Type: shared-1:1176 native double
Data: 0
Attribute: x {1}
Type: shared-1:800 native double
Data: 0
Location: 1:1224
Links: 2
Type: shared-1:1224 struct {
"t" +0 native double
"x" +8 native double
} 16 bytes
On Thu, 18 Mar 2010 11:40:10 -0500, Anton Kulchitsky <[email protected]>
wrote:
Francesc,
I think this is a really nice and elegant solution. Honestly, I am still
thinking of attributes as of simple strings. Now I see the advantage to
use other types. Thank you!
I see just another problem with this though. Actually, what I really
want is attributes for the types, not the data! When attributes are
associated with data, this compound attribute need to be written every
time when I write data of this type. However, what I really need for
compound type are attributes of the type. Indeed, once fields are
described there is no need to repeat this every time I write the data
into a file.
Anton
A Tuesday 16 March 2010 23:56:38 Anton Kulchitsky escrigué:
I would like to specify physical units and long names for every field of
a compound object. I have an array of particles. Each particle is
specified as a C structure with many fields associated with it. I would
like to have an attribute for every field. However, when I create a
compound object, I am not able to specify an attribute for a
field. I am wondering if anyone has similar problem?
An elegant solution for this would be to write a compound type attribute, with
the first field specifying the field to be described and the others with
complementary info. For example, if you have a table with two fields, one
possibility is to describe it with a `descr` attribute like:
Attribute: descr {2}
Type: struct {
"fieldname" +0 10-byte null-terminated ASCII
string
"unit" +10 10-byte null-terminated ASCII
string
"expl" +20 60-byte null-terminated ASCII
string
"scale" +80 native double
} 88 bytes
Data: {"field1", "kg", "long explanatory field 1", 1.2},
{"field2", "km/s", "long explanatory field 2", 24.3}
This is simple and quite powerful, IMO.
_______________________________________________
Hdf-forum is for HDF software users discussion.
[email protected]
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
--
___________________________________________________________________________
Dr. Werner Benger Visualization Research
Laboratory for Creative Arts and Technology (LCAT)
Center for Computation & Technology at Louisiana State University (CCT/LSU)
211 Johnston Hall, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362
_______________________________________________
Hdf-forum is for HDF software users discussion.
[email protected]
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
--
___________________________________________________________________________
Dr. Werner Benger Visualization Research
Laboratory for Creative Arts and Technology (LCAT)
Center for Computation & Technology at Louisiana State University (CCT/LSU)
211 Johnston Hall, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362
_______________________________________________
Hdf-forum is for HDF software users discussion.
[email protected]
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
--
___________________________________________________________________________
Dr. Werner Benger Visualization Research
Laboratory for Creative Arts and Technology (LCAT)
Center for Computation & Technology at Louisiana State University (CCT/LSU)
211 Johnston Hall, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362
_______________________________________________
Hdf-forum is for HDF software users discussion.
[email protected]
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
