vanderwb
commented
2 years ago Hmm... which version of WRF complains without HDF5 set? For my 4.4 builds, WRF correctly picks up on the RPATH'd HDF5 from its linking in of the libs from netCDF. In any case, I'm happy to add the extra variable to the HDF5 module.
On (2) - this again wasn't an issue for my WRFV4.4 build but perhaps it's a problem for older versions that require explicit linking to HDF5? In any case, it doesn't seem to be a HDF5/1.12.2 thing as my builds of that on Cheyenne have both libs. If I had to guess, I suspect that it's a difference between the autotools build (which I used) and the cmake build (which Spack uses), but that will require some testing.
In any case, I'm not sure if there's an easy fix for (2) so I'm hoping that we can figure out why RPATH'ing from netCDF isn't sufficient here.
Two things I noticed building WRF. 1) On cheyenne when we had hdf5 bundled w/ the NetCDF installs, for WRF builds it was sufficient to set the NETCDF variable for the WRF build system. Now we need to also set an HDF5 variable, which we may want to do in the HDF5 modules for WRF users as a convenience. For my WRF build I had to
export HDF5=/glade/u/apps/gust/22.08/spack/opt/spack/hdf5/1.12.2/oneapi/2022.1.0/cray-mpich/8.1.18/23yn2f3/
which seems like a bit much to put on users
2) On cheyenne there is at least one library that has multiple names with the only difference being underscores. WRF expects to find libhdf5hl_fortran.so. On cheyenne libhdf5hl_fortran.so and libhdf5_hl_fortran.so both exist, but the spack builds on gust only generates libhdf5_hl_fortran.so, and WRF wants the other one. Not sure if this is an HDF5 build setting.