Skip to content
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

Merged
merged 11 commits into from
Mar 5, 2025

Conversation

kennyweiss
Copy link
Member

@kennyweiss kennyweiss commented Feb 19, 2025

Summary

  • This PR is a bugfix
  • It fixes the build and tests in configurations without hdf5
  • I also discovered and fixed an unknown dependency for scr on zlib

I noted in #1480 that Axom supports configurations without hdf5. We don't currently have CI for this, and when I configured the code without hdf5, I found several tests that did not work. This branch fixes them.

Since non-hdf5 configs require a conduit without hdf5 (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:

> ./scripts/uberenv/uberenv.py --spec "%[email protected]+devtools~hdf5+c2c+mfem+scr+profiling  ^conduit~hdf5"

@kennyweiss kennyweiss added App Integration Issues related to integration with applications Testing Issues related to testing Axom Build system Issues related to Axom's build system maintenance Issues related to code maintenance labels Feb 19, 2025
@kennyweiss kennyweiss self-assigned this Feb 19, 2025
@kennyweiss kennyweiss changed the title Fixes build and test when not using hdf5 Fixes build and tests when not using hdf5 Feb 19, 2025
Copy link

@Arlie-Capps Arlie-Capps left a 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 .

Copy link
Member

@BradWhitlock BradWhitlock left a 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.
@kennyweiss kennyweiss force-pushed the bugfix/kweiss/optional-hdf5 branch from f8a659c to 0acdfca Compare March 5, 2025 02:34
…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.
@kennyweiss
Copy link
Member Author

Note: My original spack config didn't include mfem and there were some additional cases that needed to be handled when we have mfem but not hdf5. I fixed these including an MPI hang in how we were using spio from sidre::MFEMSidreDataCollection for protocols other than sidre_hdf5.

@@ -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);
Copy link
Member Author

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.

Comment on lines +185 to +186
<< axom::fmt::format("\n\tfile_base: '{}'", file_base)
<< axom::fmt::format("\n\ttest_file_base: '{}'", test_file_base));
Copy link
Member Author

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

Comment on lines +164 to +174
# 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()
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@white238 -- thanks for your suggestion about importing zlib. I adapted the conduit example (thanks @cyrush!) and verified that we can now run the using-with-blt example w/ Axom's exports.

Comment on lines 473 to +479
virtual void Load(int cycle_ = 0)
{
#ifndef AXOM_USE_HDF5
SLIC_ERROR(
"MFEMSidreDataCollection::Load(<cycle>) is only implemented for the "
"'sidre_hdf5' protocol");
#endif
Copy link
Member Author

@kennyweiss kennyweiss Mar 5, 2025

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.

@kennyweiss kennyweiss merged commit 0b734d6 into develop Mar 5, 2025
13 checks passed
@kennyweiss kennyweiss deleted the bugfix/kweiss/optional-hdf5 branch March 5, 2025 20:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
App Integration Issues related to integration with applications Build system Issues related to Axom's build system maintenance Issues related to code maintenance Testing Issues related to testing Axom
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants