On Fri, 31 Oct 2014, Tim Jenness wrote:
> As many of you know, I've recently been working on a "brand new" implementation of HDS with this new version (version 5) based on top of
> HDF5 rather than be an evolution of the existing HDS library.
>
> I've got an almost complete implementation of the HDS API using HDF5 and you can find that at https://github.com/Starlink/hds-v5 -- it
> should build and pass tests although it does require some Starlink libraries installed because I was too lazy to reimplement stuff from ONE
> and recalculate bad values from PRM (and CNF is needed so that the pointers created by the library can be used in Fortran code).
Must be some missing commits. I played around and got all the various
HDS/HDF libraries to build, but PCS will not build reporting:
libhds.so: error: undefined reference to 'datGet1W_v4'
libhds.so: error: undefined reference to 'datGet1W_v5'
libhds.so: error: undefined reference to 'datGet1UW_v4'
libhds.so: error: undefined reference to 'datGet1UW_v5'
libhds.so: error: undefined reference to 'hdsFind_v4'
libhds.so: error: undefined reference to 'hdsFind_v5'
Don't see the source files for these. hdsClose_v4 was also missing but
that was just a missing include so the re-define was lost.
Cheers,
Peter.
> Meanwhile, on a branch, I've completely reorganzied the HDS library itself such that there libhds is a thin wrapper library that forwards
> calls on to either the old HDS library (libhds_v4) or the new library (libhds_v5) and handles copying of structures between the two if you
> just so happen to be wanting to move some data from files of different versions. The Fortran wrapper is still in libhdsf and is no
> different to what it was previously.
>
> As an aside, HDS locators now work differently in Fortran. I needed to guarantee that the locator buffer in Fortran was the same regardless
> of v4 or v5 so locators are no longer memcpy-d into the buffer and copied out again (which results in new pointers). Instead I print the
> pointer address to the buffer and then read the pointer address back out when going the other way. I'm sure there is a more efficient way
> of doing it (like simply copying the 8 bytes of the pointer directly into the first 8 bytes of the buffer...) The size of the HDS structs
> now varies a lot depending on which version you are using as now all the state is stored in the v5 locator whereas in v4 the locator is a
> little stub to massive internals.
>
> I've now got to the point where stuff is actually working. It's amazing how much of the core infrastructure code in Starlink exercises all
> the little wrinkles of the HDS library. Even hdstrace was a pain when I realised that it calls datSlice on a vectorized locator, and don't
> get me started on ARY which can call datSlice for all the contents of a vectorized locator (which I ignore). Anyhow, I have managed to
> take some JCMT raw data, make a map with SMURF and display it. That seems like a good start so if anyone is interested they can check out
> the hdsv5 branch and give it a try. Note that you may want to set ADAM_USER as any new files will be created in HDF5 format and you won't
> be able to read them when you switch to an older Starlink. All new files are created in v5 format and hdstools hcopy can be used to convert
> data.
>
> v5 files seem to be slightly larger than native HDS files but if you run h5repack on them they do shrink.
>
> PS Regarding version numbers: the HDS library was at v5 and seemed to be implementing v4 file format. HDSv5 therefore refers to the file
> format and not the version number of the HDS library itself (which is now at v6).
>
> --
> Tim Jenness
>
>
--
Peter W. Draper, http://astro.dur.ac.uk/~pdraper
|