Libmesh update 20250205

[roystgnr]

Update libMesh submodule:

• Bug fix: normals vectors at the sides of edge elements in 3D, which were previously hard-coded to return (-1,0,0) and (1,0,0) at points 0 and 1 respectively (the correct solution only for x-axis-aligned edges), are now correctly calculated for all edges in 2D/3D. Compatibility with this fix required a corresponding fix in one MOOSE application; developers of any applications not in MOOSE CI who use non-x-axis-aligned edge elements may wish to test their codes for result changes with this update.
• Bug fix: H(curl) and H(div) element calculations are now correct on 2D elements embedded in 3D space and not parallel to the xy plane.
• Bug fix: Some TIMPI communications of "packed-range" data (data with variable-size data types), when given enough input data (typically ~4MB by default) to split between multiple buffers and given an output iterator that requires correct incrementation, were not correctly preserving that iterator from one buffer to the next. This has been fixed.
• Command line option --mpi-thread-type to manually choose between "single", "funneled", "serialized", and "multiple" MPI initialization threading options. Initialization still defaults to "funneled" (for maximum compatibility with older MPI implementations), but users of slate/strumpack may need to specify "multiple" for compatibility with those packages.
• PetscMatrix support for hash-table-based matrices with newer PETSc versions. This will allow MOOSE much more flexibility in problems (e.g. contact) where a priori determination of matrix sparsity patterns is difficult.
• Fixes for HYPRE_SetMemoryLocation in more complicated (e.g. field split) configurations
• Removed contrib/boost, which was a version incompatible with C++17. libMesh codes (including MOOSE) which require boost now must have an external boost installation to use.
• Support for and compiler flag selection for configuring libMesh with newer Intel compilers
• MeshTools::n_connected_components() function to count the number of connected components in a mesh
• Added operator[] for DenseVector. This is more consistent with other vector/map container types, and enables more compatibility with generic templated algorithms.
• PetscMatrix::frobenius_norm() method, and refactoring of other norm calculations
• Improvements and more options in calculator app
• Improvements and bug fixes in reduced-basis code
• New grad(div()) problem example code with Raviart-Thomas elements
• Support for "packing" for Cap'n'Proto users
• Bug fix in FParser optimized JIT output
• Bug fix for corrupt time stamps in Exodus outputs with a single time step
• Bug fixes in programmatic setting of PETSc preconditioners
• Workarounds for older PETSc error-checking macros are now removed; raw PETSc code should use LibmeshPetscCall for error checking.
• General cleanup in autoconf (./configure source) code
• General refactoring in FEInterface

Edit: a force push also adds:

• Fix for a multithreading error in applications where multiple threads are encountering elements with negative mapping Jacobians
• Preconditioning option, to scale new raw degrees of freedom, when importing mesh constraint rows from a sparse matrix. This can greatly improve solver robustness on such constrained systems.
• New transient_ex3 example application demonstrating a explicit DG/FV formulation of the 2D advection equation

[moosebuild]

Job Documentation, step Docs: sync website on 70fce7b wanted to post the following:

View the site here

This comment will be updated on new commits.

[moosebuild]

Job Coverage, step Generate coverage on 70fce7b wanted to post the following:

Framework coverage

	e6f742	#29817 70fce7
	Total	Total	+/-	New
Rate	85.26%	85.27%	+0.01%	-
Hits	108548	108567	+19	0
Misses	18773	18754	-19	0

Diff coverage report

Full coverage report

Modules coverage

Coverage did not change

Full coverage reports

Reports

• framework
• chemical_reactions
• combined
• contact
• electromagnetics
• external_petsc_solver
• fluid_properties
• fsi
• functional_expansion_tools
• geochemistry
• heat_transfer
• level_set
• misc
• navier_stokes
• optimization
• peridynamics
• phase_field
• porous_flow
• ray_tracing
• rdg
• reactor
• richards
• scalar_transport
• solid_mechanics
• solid_properties
• stochastic_tools
• thermal_hydraulics
• xfem

This comment will be updated on new commits.

[lindsayad]

It looks like I may need to go through some apps and fix up the PETSc macros

[lindsayad]

• Griffin patch: https://github.inl.gov/ncrc/griffin/pull/2327
• Subchannel patch: https://github.inl.gov/ncrc/subchannel/pull/351

[lindsayad]

I think that when https://github.inl.gov/ncrc/pronghorn/pull/1292 and idaholab/virtual_test_bed#520 are merged, then pronghorn devel (which currently has a subchannel module update that fixes the libmesh petsc call macros) can go to master, and then I believe we'll be all set to go for invalidating the failing app tests

[moosebuild]

Job Documentation internal apps on 9622db6 : invalidated by @lindsayad

[moosebuild]

Job Internal app tests on 9622db6 : invalidated by @lindsayad

[lindsayad]

relap-7 and sockeye should be fixed now thanks to @joshuahansel. Looks like we need a rebase here

[roystgnr]

I'll do the rebase in a sec.

[roystgnr]

Well, I'll rebase the newsletter, anyway; simpler to just redo the other commits.

[lindsayad]

I added the other targets. Looks like we need another rebase

[milljm]

neat... you'll be one of the first to follow: https://github.com/idaholab/moose/wiki/Updating-packages

[lindsayad]

Anyway we can wait to get libMesh/libmesh#4091 in here?

[moosebuild]

Job Precheck, step Versioner verify on 70fce7b wanted to post the following:

Versioner templates

Found 16 templates, 0 failed

Versioner versions

Found 10 packages, 2 changed, 0 failed

package	status	hash	to hash	version	to version
libmesh	CHANGE OK	b8b3d69	dabc922	2024.12.02=mpich_1	2025.02.25=mpich_0
moose-dev	CHANGE OK	834b239	fcaa73c	2025.02.27=mpich	2025.03.03=mpich

[milljm]

bump looks good to me! 👍

[lindsayad]

I don't understand why the openmpi tests are taking so long. Can we just merge this bad boy?

[roystgnr]

2 crashes with stack traces in PetscInitialize, one timeout just starting a test.

My vote is for "just merge this bad boy" - I could make a long list of all the things I could have theoretically broken with the dozen odd major changes in this update, but "PetscInitialize, but only with OpenMPI" would not be on it.

It's disappointing to see OpenMPI so flaky, though. Way back when I used to switch between OpenMPI and MPICH frequently, well, neither of them was perfect, but OpenMPI was always the more reliable of the two.

[lindsayad]

I would still like to remove the openmpi target, at least on PRs. The sum of time developers have spent wondering about false positives has to at least be on the order of hours at this point

[lindsayad]

I don't think I've seen a PR test green without invalidation in months and openmpi is usually the culprit

[roystgnr]

I like the OpenMPI target as a "sanity check" for weird MPI-looking failures in MPICH, but it really should be going yellow on failure, not red.

What's the verdict for this case, though? Merge despite OpenMPI, or invalidate and cross our fingers?

[roystgnr]

Ah, wait, never mind, we're still branch locked.