Skip to content

Issue 107

Afonso Mukai requested to merge issue_107 into master

Created by: martukas

What has changed:

  • Using new docker image, most recent conan packages
  • hdf5 is no longer directly included but through h5cpp, which is provided through conan. No additional CMake magic should be needed. Information on HDF5 capabilities such as MPI and SWMR should be provided through h5cpp. If you need additional flexibility of features, please forward them to us so we can include them in the next release of h5cpp
  • HDFFile and related tests have been refactored to use h5cpp. Very few vestiges of direct H5 C API remain. HDFFile has decreased in size by roughly 30%. A lot more opportunities for refactoring come into view.
  • some related functions have had their signatures changed, for example FileWriterTask::hdf_init
  • all tests pass, except streamer_test, which I am not quite sure how to run correctly
  • exceptions are used in many places where return values were previously used. The new C++11 nested_exception is particularly good for providing a traceback stack. HDF5 error stack is thrown in the same way. You are welcome to use the convenience function std::string print_nested(const std::exception&) to unwrap such an exception for printing to logger or whatnot.
  • explicit closing of H5 handles no longer necessary as h5cpp handles all the resource allocation. Many asserts are also not needed, because in the course of accessing HDF5 resources through h5cpp, many such checks are already in place and will throw exceptions in case of failure.

Outstanding questions:

  • What is the role of groups in this function?:
void HDFFile::init(rapidjson::Value const &nexus_structure,
                  std::vector<StreamHDFInfo> &stream_hdf_info,
                  std::vector<hdf5::node::Group> &groups)

As far as I can tell, groups are only passed in to have their handles released (with some complaining about it). Given that all instances of hid_t are now handled by h5cpp, this may not be necessary? Do we have some other plans for this parameter?

  • In HDFFile::create_hdf_structure there are three Group instances (hdf_this, hdf_next_parent, gid) defined that all eventually point to the same object, with no logic that ever differentiates them in any way. Are they at all needed there or could one variable suffice?

Merge request reports