Use proper mixins in concrete models

[vlipovac]

Closes #1260

Proposed changes

Models contained in porepy, excluding base models in porepy.models, use now proper mixins for

• geometry
• BC
• Variables and equations (not affected by changes in this PR, listing for completeness)

to eliminate circular paths in the inheritance tree of PorePy models.

Circular paths which I could not break up are the following two:

1. DataSavingMixin : Though all base models inherit from DataSavingMixin, models in tests and porepy.examples usually need VerificationDataSaving which inherits from DataSaving. To break those circular paths (if desired), the simplest solution would be to have all base models inherit from VerificationDataSaving instead of DataSaving. Then the individual verification setups can be turned into proper mixins. Please comment if you wish to do so in this PR.
2. Solution strategies: Currently affected are concrete models with custom IC and a verification setup including an exact solution, where both are included in the model set-up. There are also more complex cases like Biot-mechanics and Poro-mechanics where the design of solution strategies needs more thinking. My suggestion is to skip this for now and wait at least before the issue with VerificationDataSaving is resolved, and the abstraction of InitialConditionMixin from CF Merger #3: Compositional Flow models #1236 is included.

Types of changes

The changes here aim to form the inheritance trees of porepy models into star-like graphs, to a degree possible considering above notes.

Example: Mandel Biot (sorry for the messy graphs, the rendering engine is hard to configure)

Before:

After:

Optimal in theory (with "mixin" denoting a proper mixin):

Breaking change, since model components are now turned into proper mixins and do not work on their own (which was the case in some tests for custom geometries)

• Minor change (e.g., dependency bumps, broken links).
• Bugfix (non-breaking change which fixes an issue).
• New feature (non-breaking change which adds functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as expected).
• Testing (contribution related to testing of existing or new functionality).
• Documentation (contribution related to adding, improving, or fixing documentation).
• Maintenance (e.g., improve logic and performance, remove obsolete code).
• Other:

Checklist

Put an x in the boxes that apply or explain briefly why the box is not relevant.

• The documentation is up-to-date.
• Static typing is included in the update.
• This PR does not duplicate existing functionality.
• The update is covered by the test suite (including tests added in the PR).
• If new skipped tests have been introduced in this PR, pytest was run with the --run-skipped flag.

[IvarStefansson]

Looks very good to me. One substantial comment, we can discuss in person if necessary. Also, let's run all tests for good measure. Withholding approval to remind us of that.

[IvarStefansson]

Great work. If you're confident about the one comment I made, please feel free to merge.

[vlipovac]

@IvarStefansson I requested another review, due to some changes which should be inspected closer.
F.e., the Biot model had some intermediate parent classes for constitutive laws and something denoted as solution strategy.

Upon closer inspection, the code could be simplified, as well as the inheritance tree of the Terzaghi and Mandel models.

The main insight I gained from this (and from looking into the intermediate "solution strategies" for various benchmarks and manu models) is that they are not actual solution strategies in the original sense. They just add some stuff and like exact solutions, initial conditions and some model assertions. Most of it does not deserve the status of a solution strategy, but should maybe in the future be shifted to the actual model class, since it is only valid and used there (in short: exact solution, model assumptions, are currently declared as "solution strategy" mixins, but the code would be cleaner and simpler if those things are with the actual model class).

[IvarStefansson]

Some relatively minor questions.