MOOSE Newsletter (April 2024)

Added convection functor material

The functor material (AD)ConvectionHeatFluxFunctorMaterial was added, which computes the convection heat flux from a solid surface to a fluid. This object takes the heat transfer coefficient, solid temperature, and fluid temperature as functor parameters.

WebServerControl added

A new Controls System object, the WebServerControl, was added to the framework that allows for external control of a MOOSE-based simulation. It works by starting a web-server that exposes a REST API that any external application or script can access in order to control the execution of MOOSE. The current capabilities are intended to be used by external "controllers" - typically those built using AI/ML in Python/MATLAB/etc.

The web server is controlled by an accompanying Python utility, MooseControl.

New time stepper based on target number of fixed point iterations

The time stepper FixedPointIterationAdaptiveDT was added, which can be used in applications that have MultiApps to adjust the time step size based on the number of fixed point iterations of the last time step, relative to a target number of fixed point iterations.

New initial residual evaluation behavior

New initial residual evaluation behavior was introduced that may require a re-gold of affected applications. The original issue dates back to #10464. When we solve a nonlinear problem, we need some form of relative convergence check based on some definition of "reference residual". Intuitively, we should use the residual from the 0th nonlinear iteration as the reference residual. However, there are objects that can potentially modify the solution vector (and hence the residual) before the 0th nonlinear iteration, such as preset BCs, predictors, constraints, etc. As a result, whether to use the residual before or after executing those "solution-modifying objects" (SMOs) as the reference residual becomes debatable.

Prior to pull request #23472, we relied on a parameter in the Executioner block called compute_initial_residual_before_preset_bcs to control which residual to use as the reference residual in the relative convergence checks, and that parameter defaults to false. That means if you don't recall ever setting this parameter to true, you have been using the post-SMO residual (the 0th nonlinear iteration residual) as the reference residual.

Everything is reasonable so far, except that we always perform a residual evaluation before executing SMOs even if we don't use it as the reference residual in relative convergence checks. This is not ideal when the residual evaluation is expensive, because we could have avoided this redundant residual evaluation entirely. PR #23472 addresses this issue and introduces a few changes:

1. compute_initial_residual_before_preset_bcs is deprecated in favor of use_pre_SMO_residual. They have semantically the same meaning.

2. On the application level, a new parameter is introduced called use_legacy_initial_residual_evaluation_behavior. This parameter defaults to true and can be modified in *App.C. When set to true, we fall back to the legacy behavior where a possibly unnecessary residual evaluation is always performed prior to executing SMOs before the 0th nonlinear iteration. When use_pre_SMO_residual is set to false, we completely skip that unnecessary residual evaluation.

3. All the MOOSE modules have migrated to the new behavior, i.e. use_legacy_initial_residual_evaluation_behavior = false.

4. MOOSE-based applications keep the legacy behavior by default, and will print out a warning message at the beginning of each simulation. The warning states:

This application uses the legacy initial residual evaluation behavior. The legacy behavior performs an often times redundant residual evaluation before the solution modifying objects are executed prior to the initial (0th nonlinear iteration) residual evaluation. The new behavior skips that redundant residual evaluation unless the parameter Executioner/use_pre_smo_residual is set to true. To remove this message and enable the new behavior, set the parameter 'use_legacy_initial_residual_evaluation_behavior' to false in *App.C. Some tests that rely on the side effects of the legacy behavior may fail/diff and should be re-golded.

In principle, migrating from the legacy behavior to the new behavior should not introduce differences in regression tests. However, in practice, some objects and tests rely on "side effects" from the redundant residual evaluation at the beginning of each time step, and those tests should be fixed and/or re-golded. Several such tests were encountered while migrating the MOOSE modules. The most common cause of regression is that in some tests, certain AuxKernels or UserObjects are executed on LINEAR (when residual is evaluated), and those objects initialize or modify some internal stateful data. When migrating to the new behavior, the pre-SMO residual evaluation is skipped, and, thus, some internal stateful data might not be in the correct state upon access. The fix is fairly simple – adding TIMESTEP_BEGIN to the execute_on flags of those objects is oftentimes sufficient.

2024.04.23 Update

• Improved TriangulatorInterface compatibility with quadratic elements in boundary and hole meshes, including adjusting triangulation elements to match curved boundaries. This feature is not yet compatible with mid-triangulation boundary refinement.

• Added scaling options to Empirical Interpolation Method in Reduced-Basis code, handling for cases with linearly dependent data, and update plotting.

• Fixed bugs in visualization output of Lagrange data on Tri7, in DirichletBoundary application on nodesets generated from sidesets, and in FEMContext quadrature selection for cases where the first variable of a system is higher-order than any of the variables being queried by the context. This last fix prevents excessive numbers of quadrature points from being used in some MOOSE GeneralField transfer operations.