MOOSE Newsletter (July 2025)

MOOSE Improvements

Convergence objects may now be used for steady-state detection

The Convergence system may now be used for steady-state detection in Transient. Use the steady_state_convergence parameter in the Executioner block to specify the name of a Convergence object to use. If not specified, a DefaultSteadyStateConvergence is created internally using the existing steady-state detection parameters in the Executioner.

Convergence objects may now be used for MultiApp fixed point solves

The Convergence system may now be used for termination of MultiApp fixed point solves. Use the multiapp_fixed_point_convergence parameter in the Executioner block to specify the name of a Convergence object to use. If not specified, a DefaultMultiAppFixedPointConvergence is created internally using the existing fixed point parameters in the Executioner.

Also, a new execute_on flag was added for the purpose of executing objects for the purpose of these convergence checks: MULTIAPP_FIXED_POINT_CONVERGENCE, which occurs in each iteration of the MultiApp fixed point loop, immediately prior to the MultiApp fixed point convergence check, after TIMESTEP_END and MultiApps/transfers executing on TIMESTEP_END.

Added on-the-fly option to the Residual post-processor

To support the new fixed point convergence checks capability, a new option was added for the residual_type parameter in Residual: COMPUTE, which recomputes the residual at the time of the post-processor's execution.

HTML-style comments no longer allowed in MooseDocs

After being informally deprecated for several years, HTML-style block comments have been removed from MooseDocs. The currently-supported markdown alternatives for inline and block comments are shown below. For more detailed information about the Comment extension, checkout out the documentation page.

Example 1: Example usage of inline and block MooseDocs comments

!! This is an inline comment

This is regular text.

!!!
This is a block comment.
Multiple lines can exist within them.
!!!

This is regular text.

Support for GPUs in the test harness

Several parameters were added to the MOOSE test harness to specify which device the test harness should use when running the tests. The options are notably useful for testing MFEM and libTorch related capabilities.

Deployment of validation testing capabilities

The MOOSE test harness was expanded to have dedicated Tester classes for validation purposes. The tests run a simulation which generates validation data, possibly using a computing cluster, then execute a validation Python script that automatically computes, checks and stores the validation results.

This capability is intended to provide automated validation reports to applications that deploy it.

Tagging system for linear finite volume

The tagging system, e.g. the ability to compute vectors and matrices everywhere in the domain using kernels and boundary conditions, has been extended to support the linear finite volume discretization.

MOOSE Modules Changes

Thermal Hydraulics Module

  • HeatTransferFromHeatStructure1Phase now allows the user to specify a subset of a heat structure boundary using hs_boundary instead of requiring the entire heat structure boundary, allowing axial sections to have different coupling.

Reactor Module

The PatternedCartesianMeshGenerator can now select an arbitrary boundary ID or name for stitching the elements of the pattern together.

BatchMeshGeneratorAction now supports RealVectorValue parameters for size-3 vectors.

Subchannel Module

The auxkernels and initial conditions for the triangular and quadrilateral lattice have been re-factored to provide energy conservation even with meshes that are not aligned with the heated section axial delineation.

The standard k-epsilon model was implemented for the linear finite volume discretization of the Navier Stokes equation. This two-equation model can be solved using the SIMPLE and PIMPLE segregated solvers. The model includes equilibrium and non-equilibrium wall functions for the turbulent viscosity. It was validated on the channel flow and backward-facing steps ERCOFTAC cases.

Bug Fixes, Minor Changes, and Minor Enhancements

  • When using the "sampling_blocks" parameter of Outputs that allow block-restricted output, the block restriction of variables is now correctly obeyed.

  • Domain user objects now request the re-init of the neighbor quantities (shape functions, volumes, etc.) when being considered on an internal face.

  • The ConvectiveFluxBC now correctly supports distributed mesh.

  • ElementGroupCentroidPositions can now be used with a distributed mesh

  • Redundant GhostingFunctors are no longer added to the mesh.

  • The ElementQualityChecker can now be set to not report a warning when using a metric that does not apply to some elements in the mesh.

  • The SideValueSampler now supports finite volume variables.

  • The Console output header is now saved in the Exodus info.

  • The NodePositions was added to the Positions system to keep track of all nodes in the mesh or in a group of subdomains.

  • The ElementMaxLevelPostProcessor was added to MOOSE to compute the maximum level of h- or p-adaptivity used in the mesh or in a group of subdomains.

  • The UniqueExtraIDMeshGenerator can now have its action be restricted to a group of subdomains.

  • The ExtraIDIntegralVectorPostprocessor can now be used as a SpatialUserObject to transfer quantities that were integrated in groups of elements sharing an extra element ID.

  • The StepUserObject and Step-concept related objects were renamed to now mention AnalysisStep. The following features were added: - Step-end times can now be used to set steps in AnalysisStepUserObject. - The AnalysisStepNumber Postprocessor can output the current step number. - The AnalysisStepUserObject can set sync times for all steps.

  • Application parameters are now stored as const, and should be passed as a const reference to the App and TestApp of your application. Please update your <app name>App.C file accordingly.