New classes to take functionality out of MeshSeq(s) / new ways to pass data around

[jwallwork23]

Problems

• The MeshSeq class and its subclasses have become monster classes! A significant amount of functionality lives on them and this is not at all intuitive from the name(s).
• We are perhaps expecting a little too much from the user regarding how data is extracted from user/application code (see comment from @stephankramer in Initialise fields outside of get_solver #179).

Prompts for discussion

@ddundo has already suggested introducing a class for representing fields, which I think makes sense.

1. What other ideas to people have for new classes to move functionality to for clarity?
2. Are there other considerations about how data is being passed around / how we expect the user to do this?

cc @acse-ej321

[ddundo]

I think it would make sense to start by thinking about GoalOrientedMeshSeq.indicate_errors and how we can improve communication to it. At the moment this dictates setting up many things across goalie that we otherwise wouldn't do: passing lagged solutions to steady problems, introducing MeshSeq.time, etc.

So I think that coming up with a good way for indicate_errors to communicate with get_solver (which is user-provided) should be priority.

[ddundo]

Specifically, in the bubble shear demo in #137 the background velocity is updated inside get_solver. This works just fine if we do not call indicate_errors. But if we do, there is a problem because we need to recompute those velocities inside get_form. That's when the idea to introduce MeshSeq.time came up, so that indicate_errors could pass the current simulation time to get_form.

At the moment, indicate_errors first calls solve_adjoint on both not-enriched and enriched mesh sequences before doing anything else. Maybe we could instead do it simultaneously, subinterval by subinterval. So we solve_adjoint on subinterval N, get the error indicators, and only then we clear the tape and move on to the N-1th subinterval. We then need to find a way to extract the background velocity (i.e. all prognostic fields that we don't solve for) in a way that is hidden from the user. I have some ideas of how to do that, but maybe the best way would be to extract it from tape, if possible?

Update: decided on the approach, see #73

[ddundo]

To make it easier to discuss, I made this table to group up current MeshSeq functionality. Will update it as we go :)

Mesh-related	Field-related	Solver-related
count_elements	solutions	_outputs_consistent
count_vertices	_function_spaces_consistent	fixed_point_iteration
check_element_count_convergence	_update_function_spaces	get_checkpoints
_transfer	function_spaces	solve_forward
set_meshes	initial_condition

[ddundo]

So I think that we don't need AdjointMeshSeq and GoalOrientedMeshSeq if we use MeshSeq just for mesh-related stuff.