could also be cleaner to set the system_names here and not make it private. I have not made up my mind!
Either way it's messy to be sending parameters like this in my opinion

gonna be substantial merge conflicts for me 😢

why not store these separately and avoid the dynamic cast in FEProblemSolve?

Is that preferred? Is the dynamic cast a worse problem than having to double up any loop acting on the list of systems?

You could just move the convergence object ahead of the problem

I saw someone on discussion get a test failure there. I think this test is brittle

Yes it's because @joshuahansel must have done a git sed to change the name and then didn't change the order here

I don't like this data member. If this can be true, then this class is not truly a MultiSystemSolveObject. I think either this data member needs to go away or FEProblemSolve should not inherit from MultiSystemSolveObject

Ok that's fair. I did not need this, until I tried to get the optimization module tests to pass. It uses two solve objects m, one for each system.

I have a different solution you might like more.

If we had a class dedicated to multisystem solves then this could be a reference. Trying to retro-fit FEProblemSolve as a multi-system solve really is feeling like a poor fit.

On a different note, I do not know if there are segregated solve options that do not fit in a fixed-point class of algorithms? In which case there may not be a need for this _fp_ denotion

The problem is that there is no dedicated solve object syntax.

So what you are asking means duplicating the executioners instead, adding a MultiSystemSteady and a MiltiSystemTrnsient. This PR makes it work without doing that

This also takes it down the path of objects like IterationAdaptiveDT where we just keep bolting on pieces instead of having a modular system. What I am asking is that we have syntax for solve objects, e.g. executors

Maybe @joshuahansel wants to work with @loganharbour to finish executors? He knocked down convergence objects

Feels more like they knocked me down 😁 I'd be happy to try to help with executors, but Sockeye deadlines demand my attention for at least two months.

I see executors as removing the executioner/solve object separation. This separation is not that natural and performed inconsistently.

This also takes it down the path of objects like IterationAdaptiveDT where we just keep bolting on pieces instead of having a modular system.

No I don't think that s a great analogy because I don't see how you would implement multi-system without the lines I added. I am replacing a single system object with a multi system solve object, not adding multi system as an option to single-system.

I think in a world of executors and not this current solve object paradigm, it would be quite easy to implement multisystem. You just have a MultiSystem executor which logically would have some kind of convergence object that works naturally with multisystem. Additionally the MultiSystem or MultiXXX executor would have a parameter that takes a vector of other executors to execute. Some of these may be SingleSystem executors, for whom such a vector parameter would not make sense and for whom a multi-system or multi-executor convergence object also doesn't make sense. A MultiXXX object is fundamentally different thatn a SingleXXX object because the MultiXXX object immediately introduces the possibility of iteration. I think there should be clear distinction between objects with MultiXXX functionality and SingleXXX functionality because the parameter set is logically much more complex for the former.

I think in a world of executors and not this current solve object paradigm, it would be quite easy to implement multisystem. You just have a MultiSystem executor which logically would have some kind of convergence object that works naturally with multisystem

Agree

Additionally the MultiSystem or MultiXXX executor would have a parameter that takes a vector of other executors to execute. Some of these may be SingleSystem executors, for whom such a vector parameter would not make sense and for whom a multi-system or multi-executor convergence object also doesn't make sense

Agree

A MultiXXX object is fundamentally different thatn a SingleXXX object because the MultiXXX object immediately introduces the possibility of iteration. I think there should be clear distinction between objects with MultiXXX functionality and SingleXXX functionality because the parameter set is logically much more complex for the former.

Agree for executors. And for solveObjects I am moving FEProblemSolve from a singleXXX to a MultiXXX, and the parameters are adapted to be vectors.

@lindsayad Seems like a good design at first glance - are you requesting that executors be finished before this PR? Or just discussing future refactoring?

If you don't have the convergence object and have multisystem could you iterate forever? I think that if you have multisystem, the convergence object should be a required parameter

See the constructor, it is required

I think in a world of executors and not this current solve object paradigm, it would be quite easy to implement multisystem. You just have a MultiSystem executor which logically would have some kind of convergence object that works naturally with multisystem. Additionally the MultiSystem or MultiXXX executor would have a parameter that takes a vector of other executors to execute. Some of these may be SingleSystem executors, for whom such a vector parameter would not make sense and for whom a multi-system or multi-executor convergence object also doesn't make sense. A MultiXXX object is fundamentally different thatn a SingleXXX object because the MultiXXX object immediately introduces the possibility of iteration. I think there should be clear distinction between objects with MultiXXX functionality and SingleXXX functionality because the parameter set is logically much more complex for the former.