FindHDF5: prefer homebrew, better finding with MPI

Previously, on MacOS Anaconda Python could get in the way of finding an ABI-compatible HDF5. This update looks for Homebrew HDF5 first.

Also, find HDF5 better when only the parallel HDF5 is installed but not specified.

better MPI handling, CMake >= 3.20

For quality and maintenance, CMake >= 3.20 required.

Better handling of MPI for those with HDF5+MPI libraries--we haven't yet enabled the actual HDF5 MPI features but are working on it.

build and find enhancements

• action= r, r+, rw, w, a is all that's allowed --reduce ambiguity this way

FindHDF5 and FindMPI are more robust across platforms.

Use HDF5 library constants instead of explicit integer constants

allow 1d length one read as scalar

A common though suboptimal practice is to write scalars as 1d, length 1. Now these are allowed to be read in h5fortran.

• Fixed excessive, incorrect warnings about auto-closing HDF5 files.
• h5write/h5read: removed "ierr" argument
• Find{HDF5,MPI}: only search gfortran paths if using gfortran
• CI: test in Debug and Release mode to catch more errors in development

enhance scalar rank check

To enhance speed/stability of scalar rank checks, don't bother to check shape as rank alone is a sufficient check for scalars.

read: check scalar rank

1d-7d arrays were already checked for matching shape on read. Inadvertently, we did not check scalars, so if one read an array dataset into a scalar memory variable, segfaults could result.
We did already check 0d..7d on write.

Hence, we add 0d read shape checks (dataset vs. memory variable).

bugfix: internal intent(inout) for read

Fortran intent(out) arguments reallocate allocatable variables, even if they were already allocated. This can cause segfaults on large variables (gigabyte or so), so we change internally to intent(inout). No user program changes are required. This issue affects any Fortran program in general.

• HDF5 autobuild requires CMake >= 3.20. It's generally easy to install a recent CMake, and the performance for auto-building is much better as a result.

• FindHDF5 is enhanced to work with HDF5 library linked with MPI. We don't yet include parallel HDF5 features, but it's being prototyped in a separate repo.

• HDF5 1.12.1 is used for autobuild HDF5. h5fortran continues to work with older HDF5 1.8 and 1.10.

FindHDF5: work with parallel HDF5 or serial

also, add MPI linking to h5fortran if user has parallel HDF5 library.

We haven't enabled MPI parallel HDF5 features in h5fortran yet, but are prototyping over in https://github.com/scivision/hdf5-benchmark/

remove open(status=) parameter, use action instead

The h%open(..., status=) parameter is DEPRECATED and is ignored. Its functionality was duplicated by the h%open(..., action=) parameter.

As before:

• h%open(...) defaults to action='rw', which opens or creates a file.
• action='w' erases an existing file if present.
• action='r+' or action='r' errors if file doesn't exist

bugfix: CMake < 3.20 HDF5 build, Intel compiler performance

• fixed self-build of HDF5 with CMake < 3.20. CMake >= 3.20 still recommended to improve performance of HDF5/ZLIB autobuild.
• now works with Intel oneAPI LLVM NextGen compiler ("icx" "ifx" instead of "icc" "ifort"). As before, continues to work with Intel oneAPI Classic.
• Intel compiler: use "-xHost" for improved runtime speed
• zlib updated from 2.0.4 => 2.0.5
• don't override CMAKE_INSTALL_PREFIX to avoid problems when h5fortran used via CMake FetchContent
• read_scalar: use TKR-distinct procedures instead of select type to improve runtime performance and overall reliability. Likely to do the same for 1d..7d reads in the future.