Fixes build and tests when not using hdf5#1504
Conversation
hdf5hdf5
Arlie-Capps
left a comment
There was a problem hiding this comment.
Thank you for this fix, @kennyweiss .
Specifically, `sidre::Group::loadExternalData` is only implemented for the `sidre_hdf5` protocol.
This is apparently necessary, but was masked by hdf5's dependency on zlib. It was masked by build axom with scr, but without hdf5.
This was required for an Axom config with `scr` but without `hdf5` since it didn't get the `zlib` that `hdf5` normally sets up.
f8a659c to
0acdfca
Compare
…ailable * `Load(<cycle>)` is currently hard-coded for the `sidre_hdf5` protocol, so add a SLIC_ERROR to give an indication of why this won't currently work * `Save()` had an MPI hang for non-`sidre_hdf5` protocols related to using spio to `write()` on only the root rank. Since `write` is a collective operation, we need to use `Group::save()` instead.
|
Note: My original spack config didn't include |
| else | ||
| { | ||
| writer.write(blueprint_indicies_grp, 1, file_path + ".root", protocol); | ||
| blueprint_indicies_grp->save(file_path + ".root", protocol); |
There was a problem hiding this comment.
@nselliott -- This call to writer.write() from only the root rank was hanging since writer.write() is collective.
Switching it to directly use Group::save() resolved the issue.
| << axom::fmt::format("\n\tfile_base: '{}'", file_base) | ||
| << axom::fmt::format("\n\ttest_file_base: '{}'", test_file_base)); |
There was a problem hiding this comment.
@nselliott -- I updated this log statement to show the filenames
| # zlib | ||
| if(AXOM_USE_ZLIB) | ||
| set(AXOM_ZLIB_DIR "@ZLIB_DIR@") | ||
| if(NOT ZLIB_DIR) | ||
| set(ZLIB_DIR ${AXOM_ZLIB_DIR}) | ||
| endif() | ||
| if(ZLIB_DIR) | ||
| set(ZLIB_ROOT ${ZLIB_DIR}) | ||
| endif() | ||
| find_package(ZLIB REQUIRED) | ||
| endif() |
| virtual void Load(int cycle_ = 0) | ||
| { | ||
| #ifndef AXOM_USE_HDF5 | ||
| SLIC_ERROR( | ||
| "MFEMSidreDataCollection::Load(<cycle>) is only implemented for the " | ||
| "'sidre_hdf5' protocol"); | ||
| #endif |
There was a problem hiding this comment.
It was somewhat surprising that the MFEMSidreDataCollection::load(<cycle>) didn't support protocols other than sidre_hdf5. (Although the doxygen already noted this).
I added this error message so it's easier for people to see why this doesn't work. I don't think it would be too difficult to make this work with other protocols, but I also am not aware of any need/desire for this at the moment, so I'm planning to leave this as is.
Summary
hdf5scronzlibI noted in #1480 that Axom supports configurations without
hdf5. We don't currently have CI for this, and when I configured the code withouthdf5, I found several tests that did not work. This branch fixes them.Since non-
hdf5configs require aconduitwithouthdf5(i.e. a new library set), I'm not sure that we need a CI that tests this -- it might be enough to just manually run the code and fix it every so often. Perhaps we should have a manually run github-action that does this, similar to our manual Windows TPL build?Details:
I configured the code with a host-config generated by running the following uberenv command: