Describe the proposal
Users have a lot of trouble compiling against a working version of HDF5. However, we only use HDF5 to read the cooling tables. It would be good to avoid it altogether. Some HDF5 versions are also buggy, and we've wasted time working around that.
The upside: we could use ASDF instead. It supports self-describing arrays and unstructured metadata, and there is both a C++ (https://github.com/eschnett/asdf-cxx) and Python implementation (https://github.com/asdf-format/asdf). We can include the C++ implementation as a submodule, like we do already for AMReX, OpenPMD, and yaml-cpp.
The downside: we would have to convert the Grackle HDF5 files to ASDF using a Python script, and then save those tables in our repository.
Describe alternatives you've considered
We could stick with HDF5, or we could use a raw binary format that we implement ourselves (but why do that?)
Additional context
ASDF is used in the astronomical community, and is currently supported by STSci.
This will also require changing perturbations.py to save ASDF files (should be trivial), and then change the code to read in the perturbations in the initial conditions.
Describe the proposal Users have a lot of trouble compiling against a working version of HDF5. However, we only use HDF5 to read the cooling tables. It would be good to avoid it altogether. Some HDF5 versions are also buggy, and we've wasted time working around that.
Describe alternatives you've considered We could stick with HDF5, or we could use a raw binary format that we implement ourselves (but why do that?)
Additional context ASDF is used in the astronomical community, and is currently supported by STSci.