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?
Anton,
Currently HDF5 does't support attributes for a field in a compound datatype.
You may try to use a committed datatype that corresponds to your C structure and store an attribute(s) for the datatype. Then all datasets that use the same committed datatype will have the same associated units. Unfortunately the application should know the association between attributes and fields in the compound datatype.
Elena
···
On Mar 16, 2010, at 5:56 PM, Anton Kulchitsky wrote:
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?_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
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
{"field2", "km/s", "long explanatory field 2", 24.3}
This is simple and quite powerful, IMO.
···
Data: {"field1", "kg", "long explanatory field 1", 1.2},
--
Francesc Alted
Anton,
Currently HDF5 does't support attributes for a field in a compound datatype.
True. But, we just submitted an NSF proposal that would add this feature. (So, I hope it gets funded 
Quincey
···
On Mar 16, 2010, at 10:43 PM, Elena Pourmal wrote:
You may try to use a committed datatype that corresponds to your C structure and store an attribute(s) for the datatype. Then all datasets that use the same committed datatype will have the same associated units. Unfortunately the application should know the association between attributes and fields in the compound datatype.
Elena
On Mar 16, 2010, at 5:56 PM, Anton Kulchitsky wrote:
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?_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
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.
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
Attribute: x {1}
Type: shared-1:800 native double
Location: 1:1224
Links: 2
Type: shared-1:1224 struct {
"t" +0 native double
"x" +8 native double
} 16 bytes
h5experiment.c (1.51 KB)
test.h5 (2.3 KB)
···
Data: 0
Data: 0
On Thu, 18 Mar 2010 11:40:10 -0500, Anton Kulchitsky <kulchitsky@arsc.edu> 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.
Hdf-forum@hdfgroup.org
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
A Thursday 18 March 2010 17:40:10 Anton Kulchitsky escrigué:
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.
I see, metainformation that complements other metainformation (in this case
the data type). Oh well
···
--
Francesc Alted
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 bytesOn Thu, 18 Mar 2010 11:40:10 -0500, Anton Kulchitsky <kulchitsky@arsc.edu> 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.
Hdf-forum@hdfgroup.org
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.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
--
There is no place like $HOME
Anton Kulchitsky, PhD
HPC Specialist
University of Alaska Fairbanks,
Arctic Region Supercomputing Center
West Ridge Research Building
909 Koyukuk Drive, Suite 105
PO Box 756020 Fairbanks, AK 99775-6020
Tel. (907)450-8689 Fax. (907)450-8603
E-mail: kulchitsky@arsc.edu
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 <kulchitsky@arsc.edu> 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 bytesOn Thu, 18 Mar 2010 11:40:10 -0500, Anton Kulchitsky <kulchitsky@arsc.edu> 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.
Hdf-forum@hdfgroup.org
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.
Hdf-forum@hdfgroup.org
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
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 <kulchitsky@arsc.edu> 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 bytesOn Thu, 18 Mar 2010 11:40:10 -0500, Anton Kulchitsky <kulchitsky@arsc.edu> 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.
Hdf-forum@hdfgroup.org
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.
Hdf-forum@hdfgroup.org
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.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
--
There is no place like $HOME
Anton Kulchitsky, PhD
HPC Specialist
University of Alaska Fairbanks,
Arctic Region Supercomputing Center
West Ridge Research Building
909 Koyukuk Drive, Suite 105
PO Box 756020 Fairbanks, AK 99775-6020
Tel. (907)450-8689 Fax. (907)450-8603
E-mail: kulchitsky@arsc.edu
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 <kulchitsky@arsc.edu> wrote:
Werner,
Sorry, I missed the attached file and program! They are very helpful. By
the way, I learned about transient datatypes.
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 <kulchitsky@arsc.edu> 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 bytesOn Thu, 18 Mar 2010 11:40:10 -0500, Anton Kulchitsky <kulchitsky@arsc.edu> 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.
Hdf-forum@hdfgroup.org
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.
Hdf-forum@hdfgroup.org
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.
Hdf-forum@hdfgroup.org
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
Werner,
thank you very much for your detailed answer. It is even clearer
now.
main purpose of that program of course is inspiration
And it achieved the goal. I learned H5Tcommit command
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.
That is what I feel a little bit complicated. I am not sure that for a
casual user of data it would be easy to understand what is going
on.
If that NSF proposal is funded that Quincey mentioned (cross fingers and go
lobbying at NSF
to the compound data type members. It should be similar to the current solution,
but a bit simpler and more natural.
I crossed my fingers :). HDF5 now is the best option for scientific data
I/O and exchange, imho. I used to NetCDF and used it for many
years. However, it has too many limitations compare to HDF5 and some
other problems too.
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
Right, I think that is what Francesc Alted was writing.
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
Every such attribute might have the same name for all datasets, for
example "Units" or "Description". That is also (implicitly) Francesc
Alted said, I believe.
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.
That is the problem. I mentioned that in my reply to him. Indeed, what
we want is the attribute to the datatype fields, not to the dataset in
this particular case. Your suggestion does not have this problem.
Anton
···
Werner
On Thu, 18 Mar 2010 17:46:46 -0500, Anton Kulchitsky <kulchitsky@arsc.edu> wrote:
Werner,
Sorry, I missed the attached file and program! They are very helpful. By
the way, I learned about transient datatypes.
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 <kulchitsky@arsc.edu> 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 bytesOn Thu, 18 Mar 2010 11:40:10 -0500, Anton Kulchitsky <kulchitsky@arsc.edu> 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.
Hdf-forum@hdfgroup.org
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.
Hdf-forum@hdfgroup.org
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.
Hdf-forum@hdfgroup.org
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.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
--
There is no place like $HOME
Anton Kulchitsky, PhD
HPC Specialist
University of Alaska Fairbanks,
Arctic Region Supercomputing Center
West Ridge Research Building
909 Koyukuk Drive, Suite 105
PO Box 756020 Fairbanks, AK 99775-6020
Tel. (907)450-8689 Fax. (907)450-8603
E-mail: kulchitsky@arsc.edu
Anton,
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.That is what I feel a little bit complicated. I am not sure that for a
casual user of data it would be easy to understand what is going
on.
It's a workaround, and would need to be documented for a casual user, though
one could possibly figure it out with some effort without documentation.
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 viaEvery such attribute might have the same name for all datasets, for
example "Units" or "Description". That is also (implicitly) Francesc
Alted said, I believe.
Problem is you need to introduce a convention on how this attribute needs to
be named. If some call it "Units", other "Description", or even just "units",
you become incompatible.
Going via the named datatypes, you're basically convention-independent and
keyword-free. Except when it comes down to the units itself, where you have
the option of calling them "metres", "meters", "m", "Meters", "Metres", "meter"
etc. etc...
Werner
···
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.That is the problem. I mentioned that in my reply to him. Indeed, what
we want is the attribute to the datatype fields, not to the dataset in
this particular case. Your suggestion does not have this problem.Anton
Werner
On Thu, 18 Mar 2010 17:46:46 -0500, Anton Kulchitsky <kulchitsky@arsc.edu> wrote:
Werner,
Sorry, I missed the attached file and program! They are very helpful. By
the way, I learned about transient datatypes.
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 <kulchitsky@arsc.edu> 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 bytesOn Thu, 18 Mar 2010 11:40:10 -0500, Anton Kulchitsky <kulchitsky@arsc.edu> 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.
Hdf-forum@hdfgroup.org
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.
Hdf-forum@hdfgroup.org
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.
Hdf-forum@hdfgroup.org
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.
Hdf-forum@hdfgroup.org
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
Werner,
I think we totally agree that it is an unfortunate "workaround" and we
need attributes for the fields. NSF guys, can you hear us?
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.That is what I feel a little bit complicated. I am not sure that for a
casual user of data it would be easy to understand what is going
on.It's a workaround, and would need to be documented for a casual user, though
one could possibly figure it out with some effort without
documentation.
You are saying about documentation for the user and I do not think it is
an option. HDF5 is self-documenting format, nuff said!
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 viaEvery such attribute might have the same name for all datasets, for
example "Units" or "Description". That is also (implicitly) Francesc
Alted said, I believe.Problem is you need to introduce a convention on how this attribute needs to
be named. If some call it "Units", other "Description", or even just "units",
you become incompatible.
It should not be a problem for my task of distributing the computed
data. There is only one model and many users. In this case, nobody
confused, I think.
Going via the named datatypes, you're basically convention-independent and
keyword-free. Except when it comes down to the units itself, where you have
the option of calling them "metres", "meters", "m", "Meters", "Metres", "meter"
etc. etc...
Aha! The same problem then. We do need attributes for the fields!
Anton
···
Werner
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.That is the problem. I mentioned that in my reply to him. Indeed, what
we want is the attribute to the datatype fields, not to the dataset in
this particular case. Your suggestion does not have this problem.Anton
Werner
On Thu, 18 Mar 2010 17:46:46 -0500, Anton Kulchitsky <kulchitsky@arsc.edu> wrote:
Werner,
Sorry, I missed the attached file and program! They are very helpful. By
the way, I learned about transient datatypes.
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 <kulchitsky@arsc.edu> 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 bytesOn Thu, 18 Mar 2010 11:40:10 -0500, Anton Kulchitsky <kulchitsky@arsc.edu> 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.
Hdf-forum@hdfgroup.org
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.
Hdf-forum@hdfgroup.org
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.
Hdf-forum@hdfgroup.org
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.
Hdf-forum@hdfgroup.org
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.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
--
There is no place like $HOME
Anton Kulchitsky, PhD
HPC Specialist
University of Alaska Fairbanks,
Arctic Region Supercomputing Center
West Ridge Research Building
909 Koyukuk Drive, Suite 105
PO Box 756020 Fairbanks, AK 99775-6020
Tel. (907)450-8689 Fax. (907)450-8603
E-mail: kulchitsky@arsc.edu
Elena,
thank you very much! Good idea. I might use it later.
At the moment I decided to use the simplest decision: I use a C string
attribute to the whole dataset with the list of all fields and units. It
is not very nice but satisfies the requirement of self describing data.
Anton
Quincey,
that would be great. However, it can be a problem for hdfview
developers. I personally do not know how they are going to show that
attributes in the current model 
Anton