Add multi-system to FEProblemSolve and deploy on Physics syntax

[GiudGiud]

closes #29019

Includes:

• support for setting system names in Physics, which can then be coded to assign the variables to the right systems. There is no matching variables to systems from the input directly. I dont think all options are needed for the main class.
• a reworked FEProblemSolve that includes the fixed point iteration (or once-through loop) using a CV object for each system
• fixes for residual debugging for multi-system
• support for using the dynamic pressure for solving the NS equations. This one is a small change but consequential and I need it for the same project as this.

Next items we need (TODO but not in this PR?)

• Nonlinear convergence for each NL system that don't fight over the EquationSystems parameter (currently an issue)
  This is requiring this PR in libmesh: Add a parameter object on the system, use it in derived classes libMesh/libmesh#4007
• A decent convergence object for multi-system fixed point. Right now if you tried to use the nonlinear residual (like for multiapp iterations), you'd end up with always considering it converged (because you just solved that nonlinear system, but did not recompute the residual after solving the other nonlinear systems)
• Relatedly, an execute_on for multisystem fixed-point convergence checks (needed to update any PP during that convergence check) or for post system1 solve (a la post-Executor style)

For these last two tasks, i think the solutions will be fairly close to what gets used for MultiAppFixedPointConvergence when that gets figured out.

[joshuahansel]

It's looking good!

[moosebuild]

Job Documentation, step Docs: sync website on e8e9ecc wanted to post the following:

View the site here

This comment will be updated on new commits.

[moosebuild]

Job Coverage, step Generate coverage on e8e9ecc wanted to post the following:

Framework coverage

	8a5faa	#29021 e8e9ec
	Total	Total	+/-	New
Rate	85.14%	85.13%	-0.01%	82.14%
Hits	107324	107450	+126	207
Misses	18727	18766	+39	45

Diff coverage report

Full coverage report

Modules coverage

Contact

	8a5faa	#29021 e8e9ec
	Total	Total	+/-	New
Rate	90.41%	90.38%	-0.03%	66.67%
Hits	4957	4959	+2	4
Misses	526	528	+2	2

Diff coverage report

Full coverage report

Heat transfer

	8a5faa	#29021 e8e9ec
	Total	Total	+/-	New
Rate	88.81%	88.81%	+0.00%	100.00%
Hits	4404	4406	+2	2
Misses	555	555	-	0

Diff coverage report

Full coverage report

Navier stokes

	8a5faa	#29021 e8e9ec
	Total	Total	+/-	New
Rate	84.68%	84.78%	+0.10%	96.74%
Hits	17182	17384	+202	356
Misses	3108	3120	+12	12

Diff coverage report

Full coverage report

Optimization

	8a5faa	#29021 e8e9ec
	Total	Total	+/-	New
Rate	88.75%	88.73%	-0.02%	85.71%
Hits	2035	2039	+4	6
Misses	258	259	+1	1

Diff coverage report

Full coverage report

Scalar transport

	8a5faa	#29021 e8e9ec
	Total	Total	+/-	New
Rate	88.86%	88.89%	+0.03%	100.00%
Hits	367	368	+1	1
Misses	46	46	-	0

Diff coverage report

Full coverage report

Full coverage reports

Reports

• framework
• chemical_reactions
• combined
• contact
• electromagnetics
• external_petsc_solver
• fluid_properties
• fsi
• functional_expansion_tools
• geochemistry
• heat_transfer
• level_set
• misc
• navier_stokes
• optimization
• peridynamics
• phase_field
• porous_flow
• ray_tracing
• rdg
• reactor
• richards
• scalar_transport
• solid_mechanics
• solid_properties
• stochastic_tools
• thermal_hydraulics
• xfem

Warnings

• framework new line coverage rate 82.14% is less than the suggested 90.0%
• contact new line coverage rate 66.67% is less than the suggested 90.0%
• optimization new line coverage rate 85.71% is less than the suggested 90.0%

This comment will be updated on new commits.

[GiudGiud]

Got to add doco and fix the odd straggler tests but otherwise ready to get looked at

[lindsayad]

I think this PR should be split into two. Can we change the title to highlight some of the more fundamental additions/changes in this PR? The things I'm concerned about are separate from the Physics classes.

I also do not like that we have hard-coded a certain type of fixed point iteration (for which conceptually we would hope to have something like a FixedPointSolveObject electable from the input file) in a FEProblemSolve object

[grmnptr]

The same issues will come up with this I think:
#28821

Maybe it has an excuse that currently there is no executioner that can run a linear system on its own in the framework.

[GiudGiud]

Can we change the title to highlight some of the more fundamental additions/changes in this PR? The things I'm concerned about are separate from the Physics classes.

Done.

I also do not like that we have hard-coded a certain type of fixed point iteration (for which conceptually we would hope to have something like a FixedPointSolveObject electable from the input file) in a FEProblemSolve object

I have hard coded the most simple one, both conceptually and for a user (no parameters). "Electing it from the input file" is the plan for executors.
If you recall I reached out before transforming FEProblemSolve. I m happy to rework if in the end we dont like that FEProblemSolve took on a multi-system solve (even though conceptually FEProblem does not mean single-system). There are 3 options:

• create 2 new executioners, SteadyMultiSystem and TransientMultiSystem which create a different solve object. Lots of code duplication in that path imo. Lots of refactoring of executioners to limit the code duplication but just the solve objects will be tons of duplication
• what I did (minimal duplication, no extra option)
• modify Steady and Transient so they do NOT always create a FEProblemSolve, but instead there's some options for the solve object, selectable from the input file. So turn this:

Steady::Steady(const InputParameters & parameters)
  : Executioner(parameters),
    _problem(_fe_problem),
    _feproblem_solve(*this),
    _system_time(getParam<Real>("time")),
    _time_step(_problem.timeStep()),
    _time(_problem.time()),
    _output_iteration_number(0)
{
  _fixed_point_solve->setInnerSolve(_feproblem_solve);

into this:

Steady::Steady(const InputParameters & parameters)
  : Executioner(parameters),
    _problem(_fe_problem),
    _system_time(getParam<Real>("time")),
    _time_step(_problem.timeStep()),
    _time(_problem.time()),
    _output_iteration_number(0)
{
if (_using_multi_system)
  _inner_solve = std::make_shared<MultiSystemSolve>(...);
else
  _inner_solve = std::make_shared<FEProblemSolve>(...);

is that preferred? That's the design I used for MultiApp fixed point iterations so I am familiar with it.
I opted against this design because of:

• the duplication of the FEProblemSolve code
• it's not the right design for handling parameters. It worked fine for Secant/Steffensen because they use the same parameters as Picard but we got lucky
• the options to do other algorithms than Picard for multiapp coupling / fixed-point is hardly used and caused some unhappiness and complaints for the executor rework. The deeper we expand into this solve object design, the more complex the code is to re-create as executors. I think what I added here however is quite simple, just a loop
• what I did is all we need for MSFR and all that was needed for SAM too. It is not enough for coding SIMPLE though, but then again on SIMPLE, we are creating new executioners not just new solve objects so until we decide we ONLY want a new solveObject, the effort is not there

Or do you have a 4th option?

[GiudGiud]

@lewisgross1296 this is the PR I mentioned

[grmnptr]

Very nice generalization!

[grmnptr]

Looks good to me, thanks! Failure is unrelated.

I will add the example for non-physics-based multi linear problem in
#28821

[GiudGiud]

Thanks for the reviews! I ll work on linear scalar asap