Merge pull request #27490 from cticenhour/april-news

Make April 2024 news public

framework/doc/content/source/systems/NonlinearSystem.md

@@ -61,7 +61,8 @@ a solution to the system of nonlinear equations is found. Therefore, after each
 we need to check if the current guess is "close enough" to being a solution.
 
 There are two primary convergence criteria, and the nonlinear system is said to be converged
-if _either_ of the two is satisfied:
+if *either* of the two is satisfied:
+
 1. Absolute convergence: The norm of the residual evaluated at the current guess is below
    a certain tolerance, i.e. $\lVert \vec{r} \rVert \leq \mathrm{atol}$ where $\mathrm{atol}$
    is the absolute tolerance. This tolerance is specified via the `nl_abs_tol` parameter in the
@@ -74,6 +75,7 @@ if _either_ of the two is satisfied:
    [`Executioner`](Executioner.md) block.
 
 MOOSE supports several definitions of the reference residual:
+
 - Initial residual: The residual evaluated at the 0-th nonlinear iteration. To select this definition,
   set `use_pre_SMO_residual = false` in the [`Executioner`](Executioner.md) block.
 - Pre-SMO residual: The residual evaluated before any solution-modifying object is executed, and

modules/doc/content/newsletter/2024/2024_04.md

@@ -1,29 +1,24 @@
 # MOOSE Newsletter (April 2024)
 
-!alert! construction title=In Progress
-This MOOSE Newsletter edition is in progress. Please check back in May 2024
-for a complete description of all MOOSE changes.
-!alert-end!
-
 ## MOOSE Improvements
 
 ### Added convection functor material
 
 The [functor material](/FunctorMaterials/index.md)
 [(AD)ConvectionHeatFluxFunctorMaterial](/functormaterials/ConvectionHeatFluxFunctorMaterial.md)
-was added, which computes the convection heat flux from a solid surface to a fluid,
-taking the heat transfer coefficient, solid temperature, and fluid temperature
-as [functor](/Functors/index.md) parameters.
+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](/Functors/index.md) parameters.
 
-### WebServerControl
+### WebServerControl added
 
 A new [/Controls/index.md] object, the [/WebServerControl.md], 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](https://www.redhat.com/en/topics/api/what-is-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.
+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, the [MooseControl/index.md].
+The web server is controlled by an accompanying Python utility, [MooseControl/index.md].
 
 ### New time stepper based on target number of fixed point iterations
 
@@ -32,6 +27,53 @@ in applications that have [MultiApps](syntax/MultiApps/index.md) 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](https://github.com/idaholab/moose/issues/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](https://github.com/idaholab/moose/pull/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](https://github.com/idaholab/moose/pull/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_bahavior`.
+   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_bahavior = 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_bahavior' 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.
+
 ## libMesh-level Changes
 
 ### `2024.04.23` Update
@@ -51,6 +93,10 @@ step, relative to a target number of fixed point iterations.
   quadrature points from being used in some MOOSE GeneralField
   transfer operations.
 
-## PETSc-level Changes
-
 ## Bug Fixes and Minor Enhancements
+
+- Class user documentation was added to the Navier Stokes finite element non-AD incompressible flow (INSFE)
+  boundary conditions as well as the chemical reactions actions.
+- Valid MOOSE command line parameters no longer trigger "unused command line parameter" warnings from PETSc.
+- [MultiAppVectorPostprocessorTransfer.md] can now be used with multiple processes in any child application.
+- Integer-overflow of user-specified boundary ids now triggers an error in [RenameBoundaryGenerator.md].

modules/doc/content/newsletter/2024/2024_05.md

@@ -0,0 +1,14 @@
+# MOOSE Newsletter (May 2024)
+
+!alert! construction title=In Progress
+This MOOSE Newsletter edition is in progress. Please check back in June 2024
+for a complete description of all MOOSE changes.
+!alert-end!
+
+## MOOSE Improvements
+
+## libMesh-level Changes
+
+## PETSc-level Changes
+
+## Bug Fixes and Minor Enhancements

modules/doc/content/newsletter/index.md

@@ -6,6 +6,7 @@ monthly to the [MOOSE discussion forum](contact_us.md) as well as provided below
 
 ## 2024
 
+- [April, 2024](2024_04.md)
 - [March, 2024](2024_03.md)
 - [February, 2024](2024_02.md)
 - [January, 2024](2024_01.md)

modules/doc/content/training/index.md

@@ -4,13 +4,15 @@
 Upcoming MOOSE related training in chronological order:
 !style-end!
 
-- [ART/NEAMS M&S Molten Salt Reactors @PHYSOR24 (2024 April 21)](more_detail/PHYSOR_MS_2024_04_21.md)
-- [ART/NEAMS M&S Pebble Bed Reactors @PHYSOR24 (2024 April 21)](more_detail/PHYSOR_PB_2024_04_21.md)
 - [MOOSE Framework Fundamentals (2024 June 4-6, Idaho Falls)](more_detail/MOOSE_2024_06_04-06_IF.md)
 - [MOOSE Framework Fundamentals (2024 October 15-17, University of Illinois Urbana-Champaign)](more_detail/MOOSE_2024_10_15-17_UIUC.md)
 
 Past Training:
 
+- ART/NEAMS M&S Molten Salt Reactors @PHYSOR24 (2024 April 21)
+
+- ART/NEAMS M&S Pebble Bed Reactors @PHYSOR24 (2024 April 21)
+
 - MOOSE Framework Fundamentals (2024 April 2-4, Oregon State University)
 
 - MOOSE Solid Mechanics Workshop (2024 March 11-12, Duke University)