The current way of treating equations, parameters and numerics on different subdomains can be made much more flexible:
We need a cleaner way to define discrete equations, and assign different equations on different subdomains
Parameters are currently limited to keywords 'flow', 'transport' and 'mechanics'. The user should be free to specify whatever needed.
Spatial discretizations can in general be different on different subdomains; the only requirement should to have a discrete interface law that is compatible with the discretization on both sides. This is most relevant for elliptic equations, for which we have several discretizations and the best understanding of what constitutes a stable interface discretization.
These changes will be implemented gradually over the next weeks and months. The changes will only to a limited degree break the backwards compatibility of the high-level solver classes (elliptic.py etc.). Deeper in the code, the changes will be significant.
The current way of treating equations, parameters and numerics on different subdomains can be made much more flexible:
These changes will be implemented gradually over the next weeks and months. The changes will only to a limited degree break the backwards compatibility of the high-level solver classes (elliptic.py etc.). Deeper in the code, the changes will be significant.