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 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. >> > > 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 <[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 >>> >>> >> > > > -- > ___________________________________________________________________________ > 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
