Framework for working with analytical solutions to model problems

[keileg]

Background

The set of functional tests provides setups for working with manufactured solutions. Central components of a typical workflow are

1. Define an analytical solution to a given model problem. Derive the right hand side by passing the solution through the governing equations (heavily relying on sympy. For an example, see here
2. Evaluate the right hand side so that it can be fed into the relevant PorePy model. This typically requires a wrapper and an evaluation step.
3. Evaluate the analytical solution (primary and secondary variables) at cells and faces for error computation.
4. Define a data structure for specifying and storing quantities of interest, see here and here

NOTE: There may be other relevant points that I have missed.

Problem statement

The current formulation requires a lot of tailoring for each model problem, and only partly facilitates sharing of common functionality. For an illustration, see the extension between 2d and 3d, and towards more (complex physics)[https://github.com/pmgbergen/porepy/blob/develop/tests/functional/setups/manu_thermoporomech_nofrac_2d.py].
Also, there is a lot of almost duplication of code, see examples here and from here and below. Taken together, this makes for code that is too long, too complex, and difficult to extend, as is well illustrated by the THM setup in 2d and 3d

Room for improvements

Suggested ideas:

1. Build a library for working with analytical expressions (e.g., define the stress function once). It should be possible both to get a common implementation for 2d and 3d and, hopefully, shared functionality between related physics (conservation of momentum is common, but the definition of the stress will change).
2. Unify the data storage. I have sketches of how this can be done, though these are most easily shared in other channels.
3. Simplify the implementation for evalutation of source terms and primary/secondary variables.

There is surely room for a point 4. here.

[IvarStefansson]

Minor comment: I suspect we should not have results (and possibly others) as class variables, since these are not supposed to be shared among objects.

[IvarStefansson]

Currently, the convergence analysis is invoked by the following steps:

1. Instantiate the Class: Create an instance of the ConvergenceAnalysis class by providing the required parameters such as the model class, model parameters, number of refinement levels, spatial refinement rate, and temporal refinement rate.
2. Run Analysis: Use the run_analysis method to perform the convergence analysis. This method runs a batch of simulations with successively refined mesh sizes and/or time steps and collects the results during call to save_data_time_step(). The stored results attribute is an extended dataclass (e.g. MandelSaveData) with whatever data is needed. This is a crucial and unclear contract for the between ConvergenceAnalysis class and the model it operates on. A lot of the heavy lifting is delegated to collect_data(), which is implemented ad hoc in the SaveData class.
3. Export Errors: After running the simulations, use the export_errors_to_txt method to export the errors into a text file. This method takes the list of results from the run_analysis method and writes the errors into a specified text file.
4. Compute Order of Convergence: Use the order_of_convergence method to compute the observed order of convergence for a given set of variables. This method performs a linear regression on the log-transformed errors and mesh sizes/time steps to estimate the convergence rate.