thanks for the elaboration of the differences between OpenEXR half vs. half library. I can actually switch to the half library, it does sound like the better choice and makes code independent of OpenEXR, which indeed is a bit antiquated with respect to the evolving C++ standards. Just it works well, and why change a running system. It’s also interesting to compare HDF5 and OpenEXR; basically HDF5 does all that OpenEXR is still working on to achieve, but they have a few more features, such as multithreaded I/O, that HDF5 does not yet have and that the OpenEXR community insists on.
I might have run over Hinnant’s C++ extensions for date management some time before, it’s indeed some lack in C++ to only consider time but not date. But probably for supporting it, we should wait (as awful as waiting is) for it to be part of the C++ standard, as it’s still evolving and getting there sooner or later. They recently added support for UTC vs GPS time in C++20, which is a non-trivial conversion, and actually important for us to have. For example, when investigating flight trajectories a difference of 18 seconds (UTC vs. GPS) accounts to 500m difference, which leads to significant errors in geospatial data analysis.
One more thought about implementing I/O support for complex numbers: If you read HDF5 files, then it shouldn’t matter how it was written, whether it was written by “some” C++ library, or by FORTRAN, or any other programming language. So I would prefer to have the file-data layout to be as independent of existing C++ libraries as possible, and ideally just being based and inspired by the mathematical properties of a data type. It would be great if complex numbers are written in HDF5 such to fit automatically in a bigger context, even if the C++ standard implementation of complex numbers only supports the 2D case.
Complex numbers also raise the issue of multiple representations of the same quantity: A complex number can be given in Cartesian representation (x,y) as well as in polar representation (r,phi). Those are of course different numerical values and even different units, but mathematically it’s still the same number, only different numerical representations of the same. So that raises the question if maybe via HDF5, or some HDF5 filters, some automatic data conversion between representations can be - or should be - supported? Conversion from (x,y) to (y,x) is already intrinsically possible, provided a complex data type is stored as compound data type.
It also touches the issue of specifying physical quantities. So far it seems CGNS has the most elaborated schemed for physical quantities in HDF5, but it looks quite engineered and not necessarily as elegantly systematic as it could be. At some point, physical quantity support will also come to C++, the time support is only a first step. For HDF5 itself, it was too much of a “hot topic” yet to be supported there as part of the library, but interest on that certainly persists.
And sure, we can open a different discussion on the topic of time, tensor etc. .