ex04 broken without InterfaceMesh1D

[gdmcbain]

Following 078fd379cc550976ab6264feed6a44767de48afc for #195, `python docs/examples/ex04.py

NameError: name 'InterfaceMesh1D' is not defined

[kinnala]

Either I delete the example or recreate the logic of matching facets in InterfaceMesh1D for this specific example only. Thanks, I'll think about it. I also add this to the test suite if it will remain.

[kinnala]

I've started again to work with these mortar methods so I'll probably create better support at some point. I'd like to also cover 3D cases but it's going to be much trickier to match elements over the interface.

[gdmcbain]

Is the conforming special case (in which the facets are shared across the interface) a stepping stone to the general case? The monolithic handling of multiple subdomains is well established in the examples but I imagine that the same problems could be solved better on the same meshes with a segregated technique, connected by Nitsche conditions on the common facets? The generalization of that to three dimensions seems straightforward but I would have no idea even where to begin with a general nonconforming nonplanar interface.

[kinnala]

It could be thought as such. But one must be careful to not make any assumptions that are not true in the general case. Obviously matching the facing elements should be much easier in this case. In the general case you create sort of "union mesh" consisting of the elements of both sides. Sometimes this "union mesh" might contain really nontrivial polygonal shapes (not necessarily triangles for tetrahedral domains). These nontrivial polygons must be further splitted into triangles for numerical integration.

[gdmcbain]

nontrivial polygonal shapes (not necessarily triangles for tetrahedral domains). These nontrivial polygons must be further splitted into triangles for numerical integration.

Ah yes, I hadn't thought of that (whereas along an interfacial line in two dimensions the intersections of lineal segments are still always lineal segments), but it's obvious, yes.

What about the special case of a planar interface? In the general curved case (even in two dimensions) I don't even know what would be meant by a union mesh. Is some underlying continuous representation of the geometry of the interface required? So that one knows what surface one is projecting onto?

[kinnala]

In curved case you need to either project one side to another or a smooth parametrized manifold (between the domains) onto which you project both sides. Depends on the use case which works best. I've seen some cool electrical engine discretizations using the latter. Contact mechanics usually relies on the former.

[gdmcbain]

O. K., thanks, that makes sense.

That's a whole new thing then. I don't think there is any smooth geometry in the library thus far?

But one must be careful to not make any assumptions that are not true in the general case.

Indeed.

Actually though I imagine (without having tried it) that it should be possible to handle the conforming case (in two or three dimensions, maybe even also in one?) without modification to the library, just by defining an entry in the Mesh.boundaries attribute along the interface and then a FacetBasis there and treating the subdomains separately as in ex26. So that might not get in the way of a future implementation for curved nonconformal interfaces. I'm not working on conjugate heat transfer right at the moment but will doubtless return to it sooner or later and will probably look at segregrated versus monolithic solution (with conformal interface) then. I might also get to fluid–solid interaction one day.