Handle solver_params.xml

[merijn]

Currently Ocean, CoupledModel and Topo independently load solver_params.xml. The problem with this situation is that Ocean's parameters are split over two (well, three, see discussion of THCM in #64) parameter lists. Initially I was going to make the solver params a sublist of the Ocean parameters so that CoupledModel and Topo could just query them from the underlying model. This doesn't work directly, since CoupledModel and Topo would inherit the default parameter values of Ocean which don't match their current default solver parameters.

The alternative solution is to duplicate the current solver_params.xml contents to the parameter lists of Ocean, CoupledModel, and Topo, but this only makes sense if the values don't have to be kept in sync across these.

[Sbte]

I suggest actual parameter lists are only loaded from the main files, and then indeed combined into one with sublists.

Ocean, CoupledModel and Topo should only use a solver when being run as "main" problem. So when CoupledModel is used, Ocean does not use its solver (as far as I know). So no need for synchronization or duplication.

[merijn]

@Sbte I ran into an issue where test_topo lists several "Topo" parameters for the solver, but those don't seem to actually ever get passed to the solver? That doesn't seem right...

[Sbte]

What do you mean exactly? The ones I found get passed to the solver in topo/Topo.H

[merijn]

Ah! I was just looking at the Ocean part of things, I forgot that solver_params.xml also gets used by other parts of the code.

[Sbte]

Well, since you're implementing it with sublists now, you can make it a Topo -> Solver sublist, and get rid of the "Topo " part of the parameter name. That looks like a much nicer way of doing it.

[merijn]

Yeah, I'll do that and have both Topo and Ocean read the same solver_params.xml (since they're currently the same), if someone ever needs a different config they just need to read in a different file for Topo in the test/code.

[Sbte]

I'm already getting excited about the huge number of lines that you can remove in the near future.

[Sbte]

Mostly fixed by 9bec0eb, but still has to be fixed in CoupledModel.