piecewise-definition of coefficients on subdomains

Consider a Laplace equation with variable coefficient, ∇⋅ (k ∇ u) = 0, with k piecewise-constant on ‘regions’ or ‘subdomains’; e.g. steady conduction of heat between two blocks of different thermal conductivity (with no thermal contact resistance).

I think that such problems could also be done with mortar methods (which I see from ex04 are implemented, at least for two-dimensional problems, via InterfaceMesh1D); however, monolithic approaches can be convenient too. The issue here is to assign different values to k depending on which submesh an element belongs to, e.g. as defined in Gmsh as Physical Surface (in two dimensions). Should k be defined with ElementTriP0? And then populated using the cell_data returned by pygmsh.generate_mesh or the .cell_data attribute of the meshio.Mesh returned by meshio.read—I don’t think skfem.mesh.from_meshio currently does this, it only looks for tags on facets, e.g. for mixed boundary conditions.

[kinnala]

Sure, I’ve been actually planning to write a short article on the adaptive finite element solution of problems where we have multiple subdomains with different diffusion coefficients. It might be interesting to compare the standard adaptive approach and adaptive Nitsche coupling: Nitsche might end up in better accuracy with less DOF’s in some specific cases.

My PhD thesis (https://aaltodoc.aalto.fi/handle/123456789/31486) was heavily based on the use of MeshInterface1d but I’m still not happy with the interface, especially when having more than two subdomains. I’ve been planning to address this problem at some point.

[kinnala]

Yes, I can see why one would like to have all data outputted by meshio accessible.

I propose that we create a single attribute Mesh.external or Mesh.ext which contains all the field data, cell data, etc. of the respective meshio object (e.g. Mesh.ext.cell_data) and where the word external or ext emphasizes that we aim not to document its contents within scikit-fem since it might depend on the format.

Still, I will probably at some point improve the wrapper from_meshio to create Submesh-objects from subdomains since I find them to be convenient regarding my future plans. I’ll probably move the gmsh-specific parts of from_meshio into a separate method at some point.