-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixes build and tests when not using hdf5
#1504
Conversation
hdf5
hdf5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for this fix, @kennyweiss .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks good to me.
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 |
@@ -1220,7 +1220,7 @@ void MFEMSidreDataCollection::Save(const std::string& filename, | |||
// Root file support only available in hdf5. | |||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
hdf5
scr
onzlib
I 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-
hdf5
configs require aconduit
withouthdf5
(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: