Contract nonlinear solvers code

[MFraters]

Talking about nonlinear solvers in #1276, I thought I was a good idea to discuss something I am planning to do for the Newton solver. Because there is a lot of code duplication and divergence over time between the nonlinear solvers with the current approach of defining a separate iterated IMPES and iterated Stokes (and maybe also Stokes only?) I am planning to have only one case for the Newton solver and in there have different options, such as solve temperature, solve composition, iterate temperature and composition, or a separate iterate temperature and iterate composition.

I would like to know what you think of this idea, and if this could also be useful for the Picard type of nonlinear solvers?

[tjhei]

I played with an idea a while ago but I stopped working on it because I know it would make your task of merging much harder.

The idea is the following: The solver strategy is a list of plugins that are executed one after each other. The standard IMPES scheme could be written as "set strategy = extrapolate, temperature, stokes, composition". Then one can add additional solvers like "Newton Stokes" or "Newton Stokes/Temperature", "Picard Stokes", etc.. Of course we can define shortcuts like "IMPES" or "Stokes only" that would expand to a longer sequence and make it easier for the user.

The beauty of this is that one can easily do fancy things like "solve temperature once, then do 5 picard steps for Stokes, then do Newton for Stokes". This could also include particle advection at different times depending on your needs.

Does that make sense?

[MFraters]

Hey Timo, That does make sense, although I would have some questions about some details, especially for iterative methods. But to me it seems that it would indeed be better to first merge the newton solver (the IMPES version) and after that worry about implementing this.

[gassmoeller]

Mostly addressed by #2162.

[jdannberg]

Alright, so I think the only thing that is left to fix this issue would be to read in the solver schemes not as one given name for a solver scheme, but as different keywords, so that users could mix and match (similarly to how you can mix and match formulations if you want to do that), as it is discussed in #2162. This would be backwards compatible. For example, for IMPES, one could split the string at the comma, and then read in the option for the advection solver scheme (single) and the Stokes solver scheme (single). In the code, this could look like

if (advection_scheme == single)
      {
        assemble_and_solve_temperature();
        assemble_and_solve_composition();
      }

if (stokes_scheme == single)
      assemble_and_solve_stokes();

In this way, adding new custom solver schemes would be easier.