Update Silo and HDF5

[markcmiller86]

Description

• Updates Silo to 4.12.0 and CMake
• Updates HDF5 to 2.0 and CMake
• Patches build of Xdmf 2.1.1 for HF5-2.0
• Fixes a few HDF5 plugins for HDF5-2.0
• Patches and or adjusts bv_xxx.sh for some HDF5 dependent TPLs

Type of change

• Bug fix~~
• New feature~~
• Documentation update~~
• Other~~

How Has This Been Tested?

Reminders:

• Please follow the style guidelines of this project.
• Please perform a self-review of your code before submitting a PR and asking others to review it.
• Please assign reviewers (see VisIt's PR procedures for more information).

Checklist:

• I have commented my code where applicable.~~
• I have updated the release notes.~~
• I have made corresponding changes to the documentation.~~
• I have added debugging support to my changes.~~
• I have added tests that prove my fix is effective or that my feature works.~~
• I have confirmed new and existing unit tests pass locally with my changes.~~
• I have added new baselines for any new tests to the repo.~~
• I have NOT made any changes to protocol or public interfaces in an RC branch.~~

[cyrush]

So far looks great! I recommend we create a ticket that lists plugins that still need to use old HDF5 APIs via defines.

[biagas]

I see ZLIB support here, but not SZIP.
SZIP is still listed in bv_hdf5_depends_on and in bv_hdf5_host_profile. If an external szip is no longer needed for building hdf5 it should be removed.

[markcmiller86]

Great point. I am inclined to remove the SZIP requirements here. Its never used...well, I can't say I know that for certain. Its an educated guess though that I believe with 95% confidence.

Does removing SZIP mean we wouldn't be able to visualize SZIP compressed data files? Yes and no. Yes, not without the user having to manage HDF5 external plugins...which is pretty easy. No, as long as the user has an SZIP plugin installed somewhere and they set HDF5_PLUGIN_PATH in their env. variables. Then, it should pretty much happen automagically. Thoughts?

[biagas]

Thoughts?

From me, none, I don't understand all the implications. I have only been following the build_visit settings as best as possible for builds of TP libs on Windows, so I needed to know if this was still a requirement.

[cyrush]

I think it is unlikely that a user will understand they have an szip file and be able to create the lib and set up the env vars.

That said, if these files are very rare -- I am open to dropping support. Mark do you know if LLNL sim codes used szip in the past?

[markcmiller86]

Almost certainly no. For most of its life szip was inconveniently licensed. Truly open source alternatives for it have emerged only recently say within the last few years. It was closely associated with the hdf5 library however because I think NASA had a lot of initial interest in it. And they were a big early user and sponsor of hdf5. My understanding is it excels mostly at integer or integer like data and not floating point data. So my belief is that no llnl SIM codes have ever used it. That said it may be worth checking with Kathryn Mohror to ask if she is aware of ever having encountered it in some of their work on SCR.

…

On Mon, Dec 8, 2025, 1:24 PM Cyrus Harrison ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In src/tools/dev/scripts/bv_support/bv_hdf5.sh <#20752 (comment)>: > if [[ "$DO_ZLIB" == "yes" ]]; then info "Configuring HDF5 with ZLib support." - cf_zlib="--with-zlib=\"${VISITDIR}/zlib/${ZLIB_VERSION}/${VISITARCH}\"" + cmk_opts="${cmk_opts} \ I think it is unlikely that a user will understand they have an szip file and be able to create the lib and set up the env vars. That said, if these files are very rare -- I am open to dropping support. Mark do you know if LLNL sim codes used szip? — Reply to this email directly, view it on GitHub <#20752 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABLUUZD2QSA5W6OL6GAOGE34AXT7ZAVCNFSM6AAAAACOL3TFYOVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTKNJUGEZDCMRVGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[markcmiller86]

I was trying to build Xdmf against the one, parallel HDF5-2.0 I have installed and that fails, even after my patches for HDF5-2.0. Why? It fails because including hdf5.h in Xdmf sources causes a #include <mpi.h> and bv_xdfm.py ordinarily doesn't deal with building Xdmf against a parallel HDF5. Xdmf's CMake logic is very, very old. It is not using find_package() for HDF5 and so doesn't prime itself properly when building against a parallel-enabled HDF5.

There are a few options for situations like this...

• Simply adjust bv_hdf5.sh to install both hdf5 and hdf5_mpi as before (which was the plan last week and my intention if I keep hitting issues like this).
• There is a swizzle on the above I've at least tested with Xdmf and that is to arrange for H5_HAVE_PARALLEL to be #undef'd in HDF5 headers when building a serial lib like Xdmf against HDF5. This seems to work!
• When building for parallel, inject -I/path/to/mpi/headers into Xdmf CMAKE_CXX_FLAGS
  • Note: Xdmf 2.1.1 does have some MPI functionality in it but it is related to their network-distributed global memory (NDGM) and unrelated to our needs for simple Xdmf I/O.

[markcmiller86]

To get Xdmf library to add -I/path/to/mpi/includes when HDF5 library it is using is parallel enabled, I added some logic to use CMake to probe the HDF5 installation. That seems to work.

[markcmiller86]

Ok, netcdf requires more love because it a) assumes hid_t is an int and in HDF5-2.0 that type was changed to int64_t and it has the same H5Oget_info...() issues seen in other libs.

I suspect HDF5-2.0 has a bug in the API mapping macros for H5Oget_info... methods. I've submitted an inquiry to The HDF Group about it. Its popping up in a lot of places due to a missing arg when compiling against 2.0.

[biagas]

You might try Netcdf 4.5.0. That's what I've been using on Windows (for ease of building). I had no issues with the VisIt using this version, nor with building it against HDF5 2.0 in my test builds this week.

[markcmiller86]

You might try Netcdf 4.5.0. That's what I've been using on Windows (for ease of building). I had no issues with the VisIt using this version, nor with building it against HDF5 2.0 in my test builds this week.

So, the set of patches needed for netcdf-4.1.1 (now ~15 years old) with HDF5-2.0 is getting larger and more complex. I am close to having it working but I kinda like @biagas suggestion. @cyrush do you have strong opinions?

[cyrush]

@markcmiller86 I think we should try the new version, would be good to remove ancient patches and have same code used on windows as linux if possible.

[markcmiller86]

So, I was 4 patches in and apparently 2 patches away from a successful netcdf-4.1.1 build with HDF5-2.0. So, I've currently got that in this PR. I will revisit the issue before taking out of draft mode. But, for time being, I think its working now.

[markcmiller86]

I added logic to silo plugin to provide a little more info about the file (and plugin) software versions...