MOOSE Newsletter (April 2026)

MFEM Backend improvements

• Removal of MFEMGeneralUserObject means MFEM systems are no longer built on top of a general user object. MFEM systems are now instead queried like first-class systems through TheWarehouse. Additionally, "execute" objects, like MFEM auxiliary kernels, postprocessors, vectorpostprocessors, and sub-mesh transfers, sub-class from MFEMExecutedObject, which inherits from DependencyResolverInterface. MFEMExecutedObjects are consequently automatically dependency sorted before execution, such that an auxiliary kernel may depend on a postprocessor which itself depends on a different auxiliary kernel which depends on a different postprocessor. This is a dependency chain which has never been supported previously in MOOSE. This dependency chain is made possible by the fact that each execute object performs its own element loops (if required). This is also being done within the ongoing libMesh/Kokkos development, such that we may see arbitrary dependency resolution with the libMesh finite element backend in oncoming months when using MOOSE-Kokkos objects. This arbitrary dependency resolution removes the need for parameters such as execution_order_group within user objects. (idaholab/moose#32701)

• Solves using SuperLU_DIST now respect the user's compute device request, whereas before they would invariantly use the GPU if SuperLU_DIST had been compiled with support for GPUs. (idaholab/moose#32702)

• Non-linear support for both steady and transient problems is now a reality. MFEMKernel and MFEMIntegratedBC have both been extended to add a new member function, createNLIntegrator(), which developers can use to bind their custom-built domain or boundary mfem::NonlinearFormIntegrators, respectively. (idaholab/moose#32256)

• The user can now request shape evaluation transfers for an arbitrary number of variables across libMesh- and MFEM-backed MultiApps. Source and target variables can be defined on different meshes, and if the transfer is between two MFEM-backed MultiApps, there is also support for vector and complex variables. For a full list of supported features, check the docs for the new MultiApp{MFEM,MFEMTolibMesh,libMeshToMFEM}ShapeEvaluationTransfer family of classes. (idaholab/moose#32315)

• Corrected an issue in the formulation of the transient mixed heat conduction problem and in its mesh's nodeset numbering. (idaholab/moose#32494)

• Dropped the --copy-dt-needed-entries linker flag, for better compatibility with the LLVM linker (LLD) used, e.g., by the ROCm toolchain. (idaholab/moose#32769)

• Fixed a number of instances where the main mesh was being retrieved instead of the (sub)mesh pertaining to the variable being acted upon, and improved the performance of time-dependent problems by updating the equation system and variable solution vectors more judiciously. (idaholab/moose#32543)

Kokkos Backend Improvements

A big design change that affects all Kokkos-MOOSE objects was made: every hook method of objects is now defined as a template function with respect to the derived object type. For example:

template <typename Derived>
KOKKOS_FUNCTION Real computeQpResidual(const unsigned int i,
                                       const unsigned int qp,
                                       AssemblyDatum & datum) const;

This is to ease the static polymorphism implementation for users. Even though the hook method is defined in a base class, users can safely cast this pointer to their derived type and call derived class methods using the template argument, like:

static_cast<const Derived *>(this)->foo();

Consequently, the shim methods (e.g., computeQpResidualShim) that were originally intended to serve this purpose were removed.

Other improvements include:

• Material properties can now have different constant_on options on different subdomains. For example, a material property can be defined with constant_on = ELEMENT on subdomain A and constant_on = SUBDOMAIN on subdomain B. However, boundary-restricted material properties should still have the same option across the domain.

• Dimension limit of Array (up to 5 dimensions), JaggedArray (up to 3 inner and outer dimensions), and MaterialProperty (up to 4 dimensions) was removed by leveraging variadic templates. They can now have arbitrary dimensions.

• The datum.reinit() function was removed. Calling it for each quadrature point in a quadrature loop is no longer required.

• Basic parsed function support was added, and KokkosParsedFunction, KokkosParsedMaterial, and KokkosParsedAux are now available. However, using other functions in a parsed function is currently not supported for GPUs due to the limitation of virtual dispatches on GPUs. Parsed objects can facilitate the rapid prototyping of simulations using simple function definitions directly in the input file. Known applications of these parsed objects include field postprocessing, direct input of an analytical shape (for example, a cosine axial power profile) and simple linear models for material properties.

• The Kokkos version of VectorPostprocessors and Reporters are now available.

• Different registration paths for user objects and reducers were unified, and all the UserObjects and their derivatives (Postprocessors, VectorPostprocessors and Reporters) are now registered with registerKokkosUserObject. Making an object to be a reducer is achieved by defining reducer hook methods instead of user object hook methods. See this page for details.

• Incompatibility of UserObjectInterface with Kokkos-MOOSE user objects was fixed.

• Kernels and IntegratedBCs can exploit additional parallelism over local degrees of freedom (DOFs) by setting the num_local_threads parameter, which can improve performance. The optimal number of threads is problem-dependent but is generally recommended to be a divisor of the number of DOFs per element.

• IntegratedBCValue is now provided for optimizing integrated boundary conditions where the residual is of the form , i.e. the test function can be factored out. This is the equivalent of KernelValue for integrated boundary conditions and has the same interface.

Added NaN/Inf Debug Option

In some architectures (notably MacOS), floating point exceptions, like those produced by NaNs or Infs, do not get thrown, even in devel and dbg compile modes. A new option for devel and dbg modes, Debug/error_on_residual_nan=true, can now be used for these situations, which will throw an error upon any NaN or Inf value entering the nonlinear residual and provide the name of the residual object so that users can troubleshoot the source of the bad value.

Added MOOSE User Short Workshop Slides

The MOOSE User Short Workshop slides have been made available. This workshop is approximately 4 hours in length and focuses on the fundamentals of using a MOOSE application.

1D spline in 3D space meshing capabilities

The BSplineCurveGenerator was added to MOOSE to create meshes of edge elements following a 1D spline. The B-Spline accepts starting and ending locations and directions, to be able to connect 1D meshes with a smooth connection.

Reporter point sources

The point sources treatment in ReporterPointSource was improved to better handle points in very close proximity. The tolerance parameter can be used to decide whether to merge close sources or keep them separate.

Tensor material properties from other properties

The RankTwoTensorFromComponentProperties was added to form tensor material properties from other material properties. This facilitates the creation of fully anisotropic diffusion coefficients.

Eigenvalue solve object

The Eigenvalue executioner was modified to rely on an eigen-problem solve object. This lets application developers create new executioners that leverage the solve objects to solve eigenvalue problems as part of workflows that include additional solution steps.

Renumbering elements based on subdomains

The RenumberBySubdomainGenerator was added to renumber (change their ID) elements and their nodes in the mesh based on the subdomain appartenance of the elements. This enables element and node-based loops in MOOSE to change subdomains, and reinit on the new subdomain, as little as possible. This is an optimization that has been observed to reduce computational costs up to 10% in a specific case.

Linear finite volume boundary conditions

Linear finite volume boundary conditions can now be controlled using the Controls system.

Linear finite volume boundary conditions now include sidedness detection to be able to easily evaluate functors and variables on either side of the boundary. For example in conjugate heat transfer problems, the fluid and solid domain may lie on different sides of the boundary, and thus the fluid and solid temperatures should be evaluated on the appropriate side.

Transfers improvements

The MultiAppGeneralFieldFunctorTransfer was added to be able to transfer evaluations of any functor onto a target mesh. This transfer includes both interpolation and extrapolation features, to be able to provide transferred values even when the target mesh extends beyond the source mesh. The extrapolation behavior for this new transfer is selected using the "extrapolation_behavior" parameter.

Additionally, all MultiAppGeneralFieldTransfer-derived classes can now specify the "post_transfer_extrapolation" parameter to activate an additional extrapolation step performed at the end of the transfer after all values have been transfered. The extrapolation values are computed on the target mesh from the previously transferred valid values nearest to an extrapolation point.

Heat Transfer module

The following improvements have been made to view factors:

• Added "normalization_method" parameter to allow choosing between the default (Lagrange multiplier) view factor normalization method and an inverse row sum method.

• Added SpecifiedViewFactor for user-specified view factors (deprecates ConstantViewFactorSurfaceRadiation)

• Allowed ViewFactorVectorPostprocessor to work with ViewFactorBase objects directly.

The KokkosHeatConductionTimeDerivative was added to be able to solve transient heat conduction problems with Kokkos-MOOSE.

Reactor module

The ControlDrumMaterial was added to define material properties for the various drum segments (absorber, clad, background, etc), be able to evaluate at runtime in which segment a quadrature point lies, and return the appropriate property.

Deletion methods were added to the Constructive Solid Geometry support, to prepare for the merging of various cells and universities when creating assemblies from multiple cells.

Navier Stokes module

PIMPLE can now be used with the conjugate heat transfer capabilities. This combination has not been validated unlike the use of SIMPLE with conjugate heat transfer which has been studied in OpenPronghorn.

Thermal hydraulics module

The HSCoupler2D3D now supports the application of a symmetry factor when the 3D domain mesh only covers an angular sector of the true 3D structure geometry.

2026.04.13_0185b8b Update

• In serial runs, treat PARALLEL and GHOSTED PetscVectors with underlying serial Vec types, for greater efficiency, especially on GPU.

• Automatic generation of C0Polyhedron midnode whenever necessary to enable a non-degenerate internal tetrahedralization.

• Option to skip interior_parent() calculation during mesh preparation

• Minor fixes for compiler warnings

• Minor UI improvements for mesh calculator app

• Correctly set has_interior_parent_ptrs if skipping interior parents

• Patch PetscSolverException for PETSc 3.25

moose-build 2026.04.21 [mpich,openmpi]

• Transition moose-mpi package to moose-build, which contains just the compiler stack

• For Mac at runtime: require SDK 26.2, 15.5, 15.4, 15.2, 14.5, 14.2, or 13.3 to be stored in /opt, /opt/conda-sdks/ or ~/sdks - Needed due to incompatibility with current Conda compilers on Mac and SDK 26.4

• Use -ld_classic on mac instead of -ld64 to remove deprecation warning

• Add <PREFIX>/share/moose-mpi/scripts/get_mac_sdk.sh script for downloading an appropriate version of the Mac SDK

• Use pinning from conda/conda_build_config.yaml

moose-pprof 2026.03.01_a15ffb7 build_0

• Update pprof 71be6bf...a15ffb7

• Simplify build, using just go

moose-wasp 2025.09.19_02960f1 build_6

• Simplify package, separating combined build with pyhit

• Simplify build environment, using compilers from {{ compiler() }}

• Pin from conda/conda_build_config.yaml

• Use ninja build

• Use host requirements where possible

moose-pyhit 2026.04.21 build_0

• New package, separate from wasp build

• Simplify build environment, using compilers from {{ compiler() }}

• Pin from conda/conda_build_config.yaml

moose-seacas 2025.10.14 build_3

• Simplify build environment, using compilers from {{ compiler() }}

• Pin from conda/conda_build_config.yaml

• Use build environment from conda where most possible

moose-tools 2026.04.21

• Use pins from conda/conda_build_config.yaml

moose-petsc 3.24.6 [mpich,openmpi]_0

• Update petsc v3.24.5..v3.24.6

• Use pinnings from conda/conda_build_config.yaml

• Remove dependency on moose-mpi

• Use compilers from {{ compiler() }} functions

moose-libmesh-vtk 9.6.1 [mpich,openmpi]_0

• Update VTK to 9.6.1

• Use pinnings from conda/conda_build_config.yaml

• Remove dependency on moose-mpi

• Use compilers from {{ compiler() }} functions

moose-libmesh 2026.04.13_0185b8b [mpich,openmpi]_0

• Use updated VTK from moose-libmesh-vtk 9.6.1_0

• Use updated PETSc from moose-petsc 3.24.6_0

• Update libmesh 3463d95...0185b8b

• Use pinnings from conda/conda_build_config.yaml

• Remove dependency on moose-mpi

• Use compilers from {{ compiler() }} functions

moose-dev 2026.04.21 [mpich,openmpi]

• Remove dependency on moose-mpi, obtaining compilers from moose-build instead

• Use rebuilt wasp from moose-wasp 2025.09.19_02960f1 build_6

• Use updated PETSc from moose-petsc 3.24.6 [mpich,openmpi]_0

• Use updated VTK from moose-libmesh-vtk 9.6.1 [mpich,openmpi]_0

• Use updated libMesh from moose-libmesh 2026.04.13_0185b8b [mpich,openmpi]_0

moose-mpi:2026.04.21

• Update base containers

• Update Intel OneAPI to 2025.3.3 for intel variant

• Update mpich to 5.0.1 for all variants except intel and rocky9

• Only source custom profile /.singularity.d/moose_bashrc once

moose-petsc:3.24.6_0

• Use updated moose-mpi:2026.04.21 container as base

• Update petsc v3.24.5..v3.24.6

moose-libmesh:2026.04.13_0185b8b_0

• Use updated moose-petsc:3.24.5_1 container as base

• Update VTK to 9.6.1

• Update libmesh 3463d95...0185b8b

moose-dev:2026.04.21

• Use updated moose-libmesh:2026.04.13_0185b8b_0 container as base

• Update code-server to 4.115.0

• Update gperftools for profiling build to 2.18.1

• Update go for gperftools build to 1.26.1

• Update miniforge to 26.1.1-3

• Update pytorch to 2.11.0

• Update mfem fa89c5e...64ef39b

• Update conduit ad86e31...8543892

• Have code-server-start source the custom bash profile in /.singularity.d/moose_bashrc if it exists