InteriorBasis?

[nschloe]

When I first saw skfem.InteriorBasis, I got a little confused because I thought it doesn't take into account the dofs on the boundary. If I understand correctly, the name is just to set it apart from FacetBasis (which if I understand correctly only means the boundary facets, right?). If this is true, I would suggest to rename InteriorBasis. How about ElementBasis or just Basis? FacetBasis could then be SurfaceBasis or BoundaryBasis or something like that.

[kinnala]

InteriorBasis caches the values of the basis functions at quadrature points inside the elements. ExteriorFacetBasis is similar for boundary facets and InteriorFacetBasis is for interior facets. FacetBasis is basically shorthand for ExteriorFacetBasis. Basis is the base class for all of these.

[kinnala]

ElementBasis sounds like something related to skfem.element.Element but the other suggestions are fine.

[kinnala]

How about

• Basis -> AbstractBasis
• InteriorBasis -> Basis
• ExteriorFacetBasis -> BoundaryBasis
• InteriorFacetBasis leave as such?
• MortarBasis leave as such?

The base class is never initialized so I think this should be possible to do in a backwards-compatible manner.

[nschloe]

The base class is never initialized so I think this should be possible to do in a backwards-compatible manner.

Indeed, one could simply provide a few aliases for the classes via

Basis  = InteriorBasis

etc. In the long run, the misleading/ambiguous names should probably go, like InteriorBasis. That's not urgent of course.

I don't know all bases in skfem, but your listing above, I'd say ExteriorFacetBasis could also stay as it's unambiguous. The BoundaryBasis alias is appreciated though. I don't see FacetBasis in the list.

Perhaps we can come up with something better for the current InteriorBasis too. Basis is perhaps a little too broad, after all they're all bases.

[gdmcbain]

Perhaps we can come up with something better for the current InteriorBasis too. Basis is perhaps a little too broad, after all they're all bases.

DomainBasis?

[nschloe]

In meshing, the highest-dimension entities are usually called cells, and one below facet (for tetrahedral meshes, those are triangles, for triangle meshes those are edges). I would hence suggest the following names:

• Basis -> AbstractBasis or Basis
• InteriorBasis -> CellBasis
• ExteriorFacetBasis -> BoundaryFacetBasis
• InteriorFacetBasis leave as such
• MortarBasis leave as such

[kinnala]

In meshing, the highest-dimension entities are usually called cells, and one below facet (for tetrahedral meshes, those are triangles, for triangle meshes those are edges). I would hence suggest the following names:

• Basis -> AbstractBasis or Basis
• InteriorBasis -> CellBasis
• ExteriorFacetBasis -> BoundaryFacetBasis
• InteriorFacetBasis leave as such
• MortarBasis leave as such

I think these are good.

Furthermore, I think we should leave the shorthand FacetBasis for BoundaryFacetBasis because that's what you usually mean by "facet basis" unless you specifically talk about things like discontinuous Galerkin methods or a posteriori error estimators.

[kinnala]

I just wonder if InteriorFacetBasis should be JumpBasis because that's what you usually use it for: calculating jumps of fields from one element to another.

[nschloe]

Furthermore, I think we should leave the shorthand FacetBasis for BoundaryFacetBasis because that's what you usually mean by "facet basis" unless you specifically talk about things like discontinuous Galerkin methods or a posteriori error estimators.

I agree.

I just wonder if InteriorFacetBasis should be JumpBasis because that's what you usually use it for: calculating jumps of fields from one element to another.

Not sure. There are other instances where interior facets are useful, for example transition conditions from one medium to another. I'm always for naming things what they are, not what they are used for.

[kinnala]

@gdmcbain any comments before I merge #652 ?

[gdmcbain]

I was wondering whether there might be any exotic elements that would not be well-described by CellBasis but I lack expertise. If you don't think so, then I don't have any other objections to the change. I didn't really have a problem with InteriorBasis myself but perhaps I was just used to it.

[gdmcbain]

I see, yes, I just reread Nico's original comment about 'interior' implying the exclusion if the boundary. Yes, that's fair enough.

[gdmcbain]

Hmm, I'm still a little hesitant. As well as generally wishing to minimize changes in the API , if I remember my finite element theory correctly, aren't all finite element functions really only defined in the interior, despite possibly having degrees of freedom nominally located on the boundary? Aren't the values on the boundary derived from trace theorems? Obviously i'm pretty sketchy on the details here so if CellBasis makes more sense to you two then i'm hapoy to go along with it.

[nschloe]

The problem with the term "interior" is that in finite-elements, when you say "interior", one immediately thinks about the interior of the domain, as opposed to the boundary of the domain. That's why I suggested a renaming. Trace spaces etc. didn't play a role here. I still like the name CellBasis because it's a basis associated with the cells.

Just for fun, a little refresher on trace spaces: When you talk about traces, you're thinking about an important property of finite element functions, namely that they don't need to be continuously differentiable in the classical sense. (The typical finite element function you first encouter are contiuous "hats" with non-differentiable "kinks".) That doesn't matter though, because they only need to be differentiable in a Sobolov-sense, namely with integrals around. And with integrals, sets of measure 0 don't play any role, so assigning values at any point or line is meaningless. That's where traces come in, because in real life, the actual values are important and you associate the traces with the "real" values. Traces really are a way of assigning "true" values to points or lines or any 0-measure set to Lebesgue functions. In short, traces are the mathematical construct that give values at points or lines some meaning when the actual mathematical context says they are meaningless.

[gdmcbain]

Thanks.

I wonder whether there are two different senses of ‘interior’ that are getting confused here. One is the topological interior of the domain on which a continuous variational problem (e.g. boundary value problem for a partial differential equation) is posed, with the interior of the domain being identical to the domain itself since domains are defined as open connected subsets of (e.g. Euclidean) space and I assume we're only interested in domains that are regular open sets in this very sense: identical to the interior of their closure. An example of this usage might be (Braess 2001 Finite Elements, 2nd edn, §1.1):

Moreover, u and v are infinitely often differentiable in the interior of Ω

The other is the concept of the discrete interior degrees of freedom, as in (Ern & Guermond 2004 Theory and Practice of Finite Elements, §8.4.1)

To distinguish the interior degrees of freedom from those associated with the Dirichlet data, …

I don't think these are the same. It's the first that was referred to by InteriorBasis and the second by

https://github.com/kinnala/scikit-fem/blob/3369c040005c90e7edd925694620c8bfd1048286/docs/examples/ex25.py#L46

or by the I for ‘interior’ as opposed to the D for ‘Dirichlet’ in

https://github.com/kinnala/scikit-fem/blob/d8107f92a0e09e3d89b0f8b129185084e94abd8a/skfem/utils.py#L304-L309

[kinnala]

Some of my ideas.

• What is Basis object?

A collection of finite element basis function values (and optionally gradients, second derivatives), evaluated at quadrature points.

• What about InteriorBasis or FacetBasis?

Quadrature points are associated with either elements/cells or facets. "Associated with" means that the quadrature points are used to integrate over elements/cells or over facets.

• InteriorBasis has quadrature points associated with elements/cells. In most cases these quadrature points are, in fact, interior to the mesh/domain (not touching the boundary or any interior facets) because this is preferred, e.g., when having discontinuous material fields. But this is not a hard requirement.
• FacetBasis (that is, ExteriorFacetBasis) has quadrature points associated with boundary facets.
• ExteriorFacetBasis is obviously a bad name: exterior is outside of the domain which is not the case. Hence, rename to BoundaryFacetBasis.
• ElementBasis or CellBasis are fine, but "element" has kind of dual meaning ("elements" of the mesh vs. "finite element" which refers to the combination of reference domain, polynomial order and degrees-of-freedom). Because we already have skfem.element.Element, I thought also that ElementBasis can be confusing.
• Therefore, CellBasis remains.

[kinnala]

I'm also not against renaming InteriorBasis to CellBasis and adding a new alias Basis->CellBasis because CellBasis is what you usually want to use.

[gdmcbain]

O. K.