Fix minor doco error in NonlinearSystem.md; Add a news entry on the n…

…ew initial residual evaluation behavior

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

@@ -27,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
+
+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 rely 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 set to false, we completely skip that unnecessary residual evaluation
+   when `use_pre_SMO_residual = false`.
+3. All the MOOSE modules have migrated to the new behavior, i.e. `use_legacy_initial_residual_evaluation_bahavior = false`.
+4. MOOSE-based applications keeps the legacy behavior by default, and will print out a warning message at the beginning
+   of each simulation. The warning says
+
+> 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. I've encountered several such tests
+while migrating all 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 so 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 often times sufficient.
+
 ## libMesh-level Changes
 
 ### `2024.04.23` Update