Changing the meaning of Face in 1d/2d problems?

[lijas]

Currently in Ferrite, we make a distinction regarding the meaning of "Face" in different dimensions. In 1D problems, a face represents a vertex/point; in 2D, it represents an edge/line; and in 3D, it represents a face/surface. I believe this feature has been quite beneficial as it allows us to write dimension-independent code using FaceIndex, getfaceset, etc., for both 2D and 3D problems. However, one drawback is that it is trickier to handle embedded element/shells/beams, as seen in the dof-handler where we have a bunch of if-statements for embedded elements, for example. Additionally, it seems a bit odd to refer to a vertex as a "face" in 1D interpolations :-P

I think It might be worth change the meaning of "face" to always represent a surface (and "edges" to always represent lines). I think this change would improve the codebase. One drawback of this approach however, is that users would need to modify calls to getfaceset for 1D/2D problems and use getvertexset/getedgeset instead, which is quite breaking, so I dont know if the change i worth it.

[termi-official]

Not sure if we should approach fixing embedded elements like this. It feels like a hotfix again. The problem with the "if-else" blocks does not go away with this approach, you just move code around. I would rather vote for an actual dimension-independent interface.

[lijas]

Hmm I played around with it a bit in a branch (this branch if you want to take a look) and it seemed work pretty nicely. How would the "actual dimension-independent interface" look like (roughly speaking)? :)

[termi-official]

I think we can just add queries by dimension like for example dof_interior_indices(entity_dim::Int, entity_index::Int, ...). But then I am not sure what the performance impact might be. Or something similar to boundaryfunction might also be possible.

[lijas]

Ok, that might work aswell.

I dont think my suggestion would be a hot-fix though. I read about it in this paper by Anders Logg, and a think deal ii uses this implementation as well. (The paper also suggests a grid/mesh data-structure for distributed meshes if you are interested :) )

[PetrKryslUCSD]

I read about it in this paper by Anders Logg, and a think deal ii uses this implementation as well.

The data structure in that paper is a bit inconsistent (sometimes it creates one to many relationships by implied connections). Viz https://github.com/PetrKryslUCSD/MeshCore.jl

[KnutAM]

Done in #789 and #914