Make text adjustments, remove PETSc update section.

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

@@ -10,7 +10,7 @@ was added, which computes the convection heat flux from a solid surface to a flu
 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
@@ -29,14 +29,15 @@ 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.
+"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
+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
@@ -52,11 +53,10 @@ is expensive, because we could have avoided this redundant residual evaluation e
 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`.
+   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 keeps the legacy behavior by default, and will print out a warning message at the beginning
-   of each simulation. The warning says
+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
@@ -67,12 +67,12 @@ is expensive, because we could have avoided this redundant residual evaluation e
 
 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
+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 so 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 often times sufficient.
+`execute_on` flags of those objects is oftentimes sufficient.
 
 ## libMesh-level Changes
 
@@ -93,12 +93,10 @@ execute_on  flags of those objects is often times sufficient.
   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 parameters in PETSc.
-- The [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 the [RenameBoundaryGenerator.md]
+  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].