Remove legacy Solver API

[ZedThree]

Remove the following Solver methods:

• Solver::setRHS
• Solver::setPrecon
• Solver::setJacobian
• Solver::setSplitOperator

and the following free functions:

• bout_solve
• bout_run
• bout_constrain
• physics_run
• physics_init

bin/bout-v5-physics-model-upgrader.py can now fix all of the above.

Do we also want to remove Physics::bout_solve/constrain? Currently this just calls Solver::add/constrain. One could imagine removing or hiding the PhysicsModel::solver member, which would make keeping the bout_solve/constrain methods appealing.

(includes the bug fix in #2283)

[github-actions]

clang-tidy made some suggestions

[github-actions]

warning: Value stored to status is never read [clang-analyzer-deadcode.DeadStores]

status = model->runConvective(t);
    ^
src/solver/solver.cxx:1239:5: note: Value stored to 'status' is never read

[johnomotani]

I've never used the PhysicsModel::bout_solve() methods. I do think it'd be nicer to have only one interface for doing a thing (unless there's a good reason to have more), i.e. either remove PhysicsModel::bout_solve(), etc., or make the solver object private and require using PhysicsModel methods. The second option seems nice in many ways, but would require copying quite a lot of the Solver API into PhysicsModel methods, which seems like a maintenance headache so at the moment I think my vote is to keep solver accessible directly and remove PhysicsModel::bout_solve(), etc.

[johnomotani]

bout-v5-physics-model-upgrader.py was too much for me to get my head around, so I skipped that, but everything else looks good to me.

[ZedThree]

Grepping the models in examples, it looks like the Solver methods used are:

• solver->add
• solver->addMonitor
• solver->addTimestepMonitor
• solver->constraint
• solver->constraints

which is not terribly many. bout_solve and bout_constrain already cover add and constraint.

I think I will them for now, maybe we can have a bit of a discussion about the direction to go in at the BUG meeting.

[bendudson]

I agree this is a good idea, and having one way to do things is definitely a good idea. I would like to think about what changes we might like to make in future, so that we don't have to change interface again soon.
I would like to see a solver interface which didn't have Solver holding pointers to PhysicsModel fields. Eventually Solver could pass fields to the physics model as some kind of set/vector/map of fields; maybe an Options tree. Would the interface we chose now be compatible with this?

[ZedThree]

I think either interface, via Solver methods or PhysicsModel methods, would work with that. If we went with a PhysicsModel we could hide the solver instance which is appealing.

Picking an interface can wait for another PR when we've thought about it a bit more.