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 (69d99e0), 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.

[ostueker]

The exodus_config.h error is gone with 1.7.4.
The configure and compilation runs through but easybuild still fails in the "make check" stage but I hadn't had the time yet to find out why (no clues in the output of make check).

[jwpeterson]

I tested running make check with the 1.7.4 tarball locally with HDF enabled, and I got several errors from the unit testing stage:

1) test: MeshInputTest::testExodusCopyNodalSolutionDistributed (E) 
uncaught exception of type std::exception (or derived).
- Error creating ExodusII/Nemesis mesh file.


2) test: MeshInputTest::testExodusCopyElementSolutionDistributed (E) 
uncaught exception of type std::exception (or derived).
- Error creating ExodusII/Nemesis mesh file.


3) test: MeshInputTest::testExodusCopyNodalSolutionReplicated (E) 
uncaught exception of type std::exception (or derived).
- Error creating ExodusII/Nemesis mesh file.

...

and 23 others, all errors come from the call to ExodusII_IO_Helper::create(). So far, I have not figured out what causes this, but I did confirm that a build with Exodus v5.22 and HDF disabled passes make check. It would be helpful if you could confirm whether you see the same output from make check.

Thanks,
John

[ostueker]

I'm currently in the "make check" phase for my build of libmesh-1.7.5, but haven't reached the ExodusII tests yet.

When two days ago I first noticed the crashes (compiling with HDF5 1.10.11) I looked through the make check logs and didn't see any failing tests.

[jwpeterson]

I recompiled in dbg mode, reran the failing tests, and this time, I got more useful information, it looks like there is some issue with the way that we have configured NetCDF on the 1.7.x branch that prevents it from writing "netcdf-4" format files, which I believe is what we try to do when HDF is enabled:

Exodus Library Warning/Error: [ex__handle_mode]
    EXODUS: ERROR: File format specified as netcdf-4, but the NetCDF library being used was not configured to enable this format


Exodus Library Warning/Error: [ex_create_int]
    ERROR: file create failed for dist_with_nodal_soln.e in NETCDF4 mode.
    This library does not support netcdf-4 files.
    NetCDF: Invalid argument
Error creating ExodusII/Nemesis mesh file.