interfacial coupling and discontinuities

[gdmcbain]

This picks up an idea from #865 discussed by @gdmcbain relating techniques for Dirichlet conditions to

techniques for imposing interfacial conditions (continuity or otherwise of potential and flux)

and @gatling-nrl who noted that this was

maybe irrelevant to this PR, but I'm extremely interested in this topic. might be a good general discussion to start. i'm trying to embed skfem in an impedance tomography problem, and assumptions about the electrode interface is pretty significant to the found solutions.

Here we go then. What kind of interfacial conditions arise? So it's other than continuity of potential and continuity of normal component of flux? I can well imagine an electrical analogue of thermal contact resistance. The general idea is that there is a thin layer between the two subdomains that has macroscopic significance (e.g. resistance) but is so thin compared to the rest of the geometry that meshing with n-dimensional cells it would be problematic. The remedy is to insert (n − 1)-dimensional interfacial elements and couple the two neighbouring subdomains through them.

Do any of the model problems in my 2012 slides cover the physics of interest? If so, I still have some of my FreeFem++ scripts and now that we have orientating facet-bases in hand (#831, &c., I think), it should be possible to start translating them to scikit-fem. There I used two separate meshes, sharing a part of their boundaries; in scikit-fem, it should be possible to use two subdomains of a single mesh, as begun in ex26.

The other line of work to build on here comes from the preceding part of the first quote, in which the techniques for imposing interfacial conditions were related to analogous techniques for imposing Dirichlet conditions; they're discussed in #753. A Dirichlet condition is like half an interfacial condition in which what is on the other side is completely known.

[kinnala]

MortarFacetBasis/MortarMapping handles nonmatching meshes in 2D. It's just not very good implementation.

[kinnala]

I could make a simple Poisson interface example if you want.

[gdmcbain]

Ah, I'm sure you've got plenty to do and it would be a good exercise for me to work it out myself. I can't say when I'll get to that though and @gatling-nrl may be interested in something sooner.

There is also the simple test for me to look at to begin with.

scikit-fem/tests/test_basis.py

Line 362 in b24b078

def test_mortar_basis(m1, m2, lenright):

Unless it's already obvious that it's not a good idea to try adapting it from handling nonmatching meshes to handling matching matches (in particular matching because they're adjacent parts of the same mesh as in ex26, #865, &c.).

[kinnala]

MortarMapping splits all nonmatching facets into smaller pieces for integration (supermesh). Creating this is somewhat slow so I wouldn't create it for fun. There is a Fortran library (libsupermesh) which does this for also higher dimensional cases. I know Firedrake is using it internally but I'm not aware of a nice wrapper for Python.

[gdmcbain]

Nah, I think the immediate interest is in interfaces across matching meshes. So I guess we'll work with the vanilla FacetBasis (currently aliasing to the possibly somewhat misnamed BoundaryFacetBasis) and leave MortarFacetBasis aside as a specialized subclass. Thanks.

[kinnala]

Matching mesh should work equally well using Mortar*.

However, I'd think those cases as using a single mesh, add them together and use InteriorFacetBasis.

However, now I see that there is an issue with orienting the trace and the normals while MortarFacetBasis does it consistently. Thanks, I'll try to address this also in #865 et al.

[gatling-nrl]

So there are actually two "interface" problems I'm facing.

The general idea is that there is a thin layer between the two subdomains that has macroscopic significance (e.g. resistance) but is so thin compared to the rest of the geometry that meshing with n-dimensional cells it would be problematic.

Yes, exactly. In the impedance tomography problem, there is in general assumed to be a "contact impedance" on each electrode. The starting point is to assume a perfectly conducting electrode with a known, uniform, finite conductivity between the electrode and the medium. Of course all of these can be relaxed to make the problem as hard as you want. Prior to this discussion I had intended to brute force my way by just meshing the contact impedance area and giving that region a value for conductivity. But your post in #864 made me consider that there might be more elegant / accurate / efficient / general solutions. In any case, the physical result of this is the voltage you put on the electrode is not the voltage seen by the medium.

Do any of the model problems in my 2012 slides cover the physics of interest?

I only skimmed them yet, but yes, that looks like electrode contact impedance problem. You've given me a lot of reading to do this weekend :)

The second "interface" problem concerns "sigma" (del dot sigma * del u). sigma is the actual unknown in my problem, which is very ill-conditioned. Imagine having 5 electrodes, which could have at most 20 measurements. Well even a 10x10 grid for piecewise constant sigma is already a very rank-deficient problem. For even 200x200 pixel images (which most people would consider quite poor resolution in nearly any domain) there's no way to compensate with "more electrodes".

The main area of my work right now is smart ways to partition the domain for sigma... the idea being to maximize the use of the limited information in the measurements. Maximize is a lofty goal though, so at present I am merely showing I can do better than uniform area pixels. Anyway, the point of all that is that the mesh on which I solve Laplace equation cannot be the same mesh that I use to partition the space for sigma. Specifically, the mesh for sigma must be coarser than the one for Laplace, and in general won't share any of the same nodes/facets. For now, I am just keeping sigma as data on the side and projecting it into a P0 basis on the Laplace equation mesh. I hadn't thought of the word "interface" for this problem until reading @kinnala's comments in this discussion. I will look more into the Mortar basis for this.

@gatling-nrl may be interested in something sooner.

#851 meets all of my immediate needs. I haven't checked if #865 works, but I have a paper I need to finish and I'll just pause at #851 until that's done (2-3 weeks, I hope!).