When is the next release ?

[mboisson]

Last release of LibMesh is 1.5 years old, and there has been a lot of development. I have projects that depend on specific commits, but that is not appropriate to install on a large cluster (we want specific versions instead).

[jwpeterson]

Not sure what @roystgnr prefers, but IMO we could start a release branch now. I was doing somewhat regular releases for a while there, but it wasn't clear that anyone was actually using them... as far as I know most big projects are doing some form of a git submodule for libmesh at this time, and updating it as needed.

[mboisson]

Speaking as a package manager/software install for large HPC clusters, we very much prefer having releases (with sane versioning schemes) than having commit hashes and having to make up our own release scheme. All software on HPC cluster is installed through modules, and having a sane versioning scheme with actual releases makes it a lot simpler for everyone.

[roystgnr]

It would be a good time to start a release branch, IMHO.

[ostueker]

Any idea when we might see a new release?

I see there's now a branch_v1.7.2 but no release has been tagged at https://github.com/libMesh/libmesh/releases

Is branch_v1.7.2 still work-in-progress or does 8cc62e9 represent an un-tagged 1.7.2 release?

Edit: Okay, I see that there is actually a 1.7.2 tag, but no release was made on GitHub. Could you please create a release and upload a complete tar-ball that contains the code from the submodules, just like it was done for 1.7.1?

[jwpeterson]

There was an issue with the 1.7.2 tag where the version number was not incremented correctly before the tag was created. So, there won't be a 1.7.2 release tarball, but we can make a 1.7.3 release tarball. Note, though, that not much has been changed since 1.7.1 was tagged, although a lot of time has gone by.

After discussing things a bit with @roystgnr, our plan is to tag a 1.8.0 release and create tarballs once we get a passing devel -> master merge here.

[jwpeterson]

Would you mind trying out one of the 1.7.3 release tarballs here? As I mentioned before, it won't be hugely different from 1.7.1, but if there's something wrong with the files, it would be good to know before we start in on the 1.8.x series.

[ostueker]

Thanks for the 1.7.3 release.

When I try to build it, it fails because it can't find the exodus_config.h:

In file included from src/ex_create_par.c:126:
./include/exodusII.h:18:10: fatal error: exodus_config.h: No such file or directory
   18 | #include "exodus_config.h"
      |          ^~~~~~~~~~~~~~~~~
compilation terminated.

and sure enough, I find several *_config.h files but the one for exodus is missing:

$ find /tmp/stuekero/avx2/libMesh/1.7.3/foss-2023a -name "*_config.h"
/tmp/stuekero/avx2/libMesh/1.7.3/foss-2023a/libmesh-1.7.3/contrib/metaphysicl/src/utilities/include/metaphysicl/metaphysicl_config.h
/tmp/stuekero/avx2/libMesh/1.7.3/foss-2023a/libmesh-1.7.3/contrib/laspack/laspack_config.h
/tmp/stuekero/avx2/libMesh/1.7.3/foss-2023a/libmesh-1.7.3/contrib/timpi/src/utilities/include/timpi/timpi_config.h
/tmp/stuekero/avx2/libMesh/1.7.3/foss-2023a/libmesh-1.7.3/include/libmesh/libmesh_config.h
/tmp/stuekero/avx2/libMesh/1.7.3/foss-2023a/libmesh-1.7.3/include/libmesh_config.h

Nothing in the output of "./configure" that would explain this. Full configure line:

./configure --prefix=/home/stuekero/.local/easybuild/software/2023/x86-64-v3/MPI/gcc12/openmpi4/libmesh/1.7.3  \
  --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu CXX=mpic++ CC=mpicc --enable-curl \
  --disable-strict-lgpl  --enable-parmesh --enable-distmesh --enable-xdr --enable-hdf5 \
  --with-hdf5=$EBROOTHDF5  --with-eigen-include=$EBROOTEIGEN/include  \
  --with-glpk-include=$EBROOTGENTOO/include --with-glpk-lib=$EBROOTGENTOO/lib64  \
  --with-nlopt-include=$EBROOTNLOPT/include --with-nlopt-lib=$EBROOTNLOPT/lib  \
  --with-curl-include=$EBROOTGENTOO/include/curl --with-curl-lib=$EBROOTGENTOO/lib  \
  --with-tbb=$EBROOTTBB/tbb

What is the most recent version of HDF5 that you have tested with libMesh? Before trying 1.7.3 I've created my own tarball of 1.7.2 by doing a recursive clone of the branch_v1.7.2, deleting the .git and then tar-ing it up. But when using our current default version of HDF5 (1.14.2) I got errors when running make check:

tst_h_files4.c: In function op_func:
tst_h_files4.c:54:43: error: const union <anonymous> has no member named address
   54 |    if ((id = H5Oopen_by_addr(g_id, info->u.address)) < 0) ERR;
      |                                           ^
In file included from /cvmfs/soft.computecanada.ca/easybuild/software/2023/x86-64-v3/MPI/gcc12/openmpi4/hdf5-mpi/1.14.2/include/H5public.h:31,
                 from /cvmfs/soft.computecanada.ca/easybuild/software/2023/x86-64-v3/MPI/gcc12/openmpi4/hdf5-mpi/1.14.2/include/hdf5.h:21,
                 from tst_h_files4.c:11:
tst_h_files4.c: In function main:
/cvmfs/soft.computecanada.ca/easybuild/software/2023/x86-64-v3/MPI/gcc12/openmpi4/hdf5-mpi/1.14.2/include/H5version.h:934:30: error: too few arguments to function H5Oget_info_by_idx3
  934 |   #define H5Oget_info_by_idx H5Oget_info_by_idx3
      |                              ^~~~~~~~~~~~~~~~~~~
tst_h_files4.c:189:14: note: in expansion of macro H5Oget_info_by_idx
  189 |          if (H5Oget_info_by_idx(grpid, ".", H5_INDEX_CRT_ORDER, H5_ITER_INC,
      |              ^~~~~~~~~~~~~~~~~~
In file included from /cvmfs/soft.computecanada.ca/easybuild/software/2023/x86-64-v3/MPI/gcc12/openmpi4/hdf5-mpi/1.14.2/include/H5Apublic.h:21,
                 from /cvmfs/soft.computecanada.ca/easybuild/software/2023/x86-64-v3/MPI/gcc12/openmpi4/hdf5-mpi/1.14.2/include/hdf5.h:22:
/cvmfs/soft.computecanada.ca/easybuild/software/2023/x86-64-v3/MPI/gcc12/openmpi4/hdf5-mpi/1.14.2/include/H5Opublic.h:599:15: note: declared here
  599 | H5_DLL herr_t H5Oget_info_by_idx3(hid_t loc_id, const char *group_name, H5_index_t idx_type,
      |               ^~~~~~~~~~~~~~~~~~~
make[4]: *** [Makefile:703: tst_h_files4.o] Error 1

These went away when I replaced it with hdf5/1.10.11.

I would like to avoid having to install another version of HDF5 because users can't have two different hdf5 modules (versions) loaded at the same time and there are so many other modules that depend on HDF5 (and are using our default version).

[jwpeterson]

When I try to build it, it fails because it can't find the exodus_config.h:

And this doesn't happen when you try building the 1.7.1 tar archive? Nothing has changed with our bundled Exodus between releases 1.7.1 and 1.7.3, so I don't know why it would work for one but not the other. I found an exodus_config.h file in our source tree (./contrib/exodusii/v8.11/exodus/sierra/exodus_config.h) but it doesn't contain anything important (just a bunch of defines inside #if 0 blocks) so a quick workaround might be to comment out the inclusion in exodusII.h

What is the most recent version of HDF5 that you have tested with libMesh?

I'm using HDF 1.10.0 myself.

But when using our current default version of HDF5 (1.14.2) I got errors when running make check

Those errors are coming from the bundled NetCDF sources, which are on v4.9.2. So, in order to use newer HDF5 versions, we'd first have to update our internal NetCDF to something newer.

[jwpeterson]

OK, I confirmed that I get the same error as you regarding the exodus_config.h file not being found while trying to build from the 1.7.3 release tarball. We figured out that our internal make distcheck testing does not enable HDF5, and is only testing the Exodus v5.22 code path, so we never realized there was an issue with building v8.11 from the release tarball.

We'll look into a fix for this and create a new release if/when we find one.

[jwpeterson]

We realized there was already a fix for this issue on master (69d99e04cdec4cda1e2115cc4aa3e05881fda316), it just needed to be cherry-picked to the 1.7.x release branch. I have now done that and created the new tarballs here, would you mind giving that a try? Unfortunately I don't think we can fix the "does not work with recent HDF" issue on this old release branch, and likely not on 1.8.x either since we are trying to tag that very soon, but we'll try and keep it on the radar for future releases.