Boundary Elements vs. Internal Surfaces

[mlstowell]

This is a topic we would like to resolve in the MFEM 5.0 release because it may demand changes to some existing codes.

This grew out of issue #2640 but I believe similar issues have come up in the past.

Currently the mfem::Mesh class contains a data object called boundary which is an array of Element pointers. These are "boundary elements" which have their own set of "boundary attributes" which can be used for extracting subsets of degrees of freedom or for restricting bilinear or linear forms or for other uses. One other use is in GLVis where these "boundary elements" are used to easily display the outer surface of a 3D mesh.

The term "boundary" is used loosely in the mfem::Mesh class. There is no requirement that the "boundary elements" include all elements which are on the surface of the domain. There is also no requirement that all elements in the set of "boundary elements" be on the surface of the domain e.g. some boundary elements can be interior faces. The only requirement may be that the dimension of the "boundary elements" must be one less than the dimension of the domain e.g. 3D meshes can only have 2D elements in their boundary.

This loose definition adds a certain flexibility but it also creates confusion.

Periodic meshes add a complication because they typically contain internal surfaces which might be natural to view as part of the boundary although technically they are not boundary surfaces.

We would like to continue to offer flexibility to our users while avoiding confusion wherever possible.

[mlstowell]

One possible solution is to create another data structure in mfem::Mesh to contain Element pointers to a set of interior faces and reserve mfem::Mesh::boundary for those faces which truly are on the boundary i.e. faces with exactly one neighboring element.

Pros

• During mesh finalization we could traverse the boundary and verify that each face has exactly one neighboring element.
• DG methods would no longer need to avoid interior faces while looping over boundary elements.
• GLVis could display internal surfaces as well as boundary surfaces which would improve visualization of periodic meshes in 3D.
• User documentation would be clearer and perhaps conform better to people's expectations.

Cons:

• This would require us to replicate some functions which might be needed for both interior and boundary elements e.g. FiniteElementSpace::GetBdrElementDofs.
• (feel free to add other possible negative consequences)

[mlstowell]

Other solutions have been proposed by @tzanio and @v-dobrev but I hesitate to summarize them myself for fear of sounding biased.

I have also noticed @acfisher, @jandrej, and @pazner comment on these matters so I'll tag them here to help the interested parties find this discussion.

[pazner]

Thanks for starting this discussion @mlstowell.

I think the main issue is linguistic, stemming from the following:

• We support boundaries and internal surfaces, but call both of them "boundaries". This is confusing.

This leads to confusion, not only among users, but also in the code. For example, "boundary face integrators" operate only on domain boundaries, and skip internal surfaces, whereas "boundary integrators" operate on both domain boundaries and internal surfaces. There is nothing in the names of these objects that would suggest that they work this way (and I don't think it's even mentioned in the documentation).

In terms of suggestions, I think:

• Ideally, we want an easy way for users to distinguish between domain boundaries and internal surfaces (without requiring them to properly tag their mesh files).
• When dealing with periodic geometries, it often makes sense to keep the periodic surfaces around. But we really want to add them as internal surfaces (for visualization and perhaps computing integrals) rather than boundaries (for BCs).

I think if we can be a little bit better at separating these two cases we can mostly resolve this issue.
Perhaps we can just add some convenience functions for identifying and marking boundaries and internal surfaces. Maybe we can associate some metadata with each face (either stored or computed) that will tell you if it is a domain boundary, internal surface, or periodic surface.

Maybe by default boundary integrators will skip internal surfaces, unless you specifically request them using their attribute. Additionally, functions like GetBoundaryTrueDofs should return only boundary DOFs and not internal surface DOFs.

[YohannDudouit]

I think we should also mention the "GLVis" boundary faces, these "boundary" faces have for sole purpose to make it convenient
for GLVis to render periodic meshes, unfortunately they also appear as boundary faces in MFEM which can lead to hard to track issues because some faces appear as "boundary" when they truly are not.