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 ;) ), 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. 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 <[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 > > -- 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: [email protected] _______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
