Non Isoparametric Elements

[jacobmerson]

I am opening this issue so that we have a place to discuss how we should handle non-isoparametric elements in MeshFields.

• review how nonisoparametric coordinates are handled in MFEM
• review how nonisoparametric coordinates are handled in PUMI
• review how nonisoparametric coordinates are handled in DEALII
• make list of common geometry types we need to support

[jacobmerson]

// geometry mapping = FieldElement over the coord field with its own shape + map
template <typename FieldElem, typename GeomElem = FieldElem>
struct MappedElement {
  FieldElem field;
  GeomElem  geom;      // isoparametric: geom == field
  auto getValue(ent, xi)     const { return field.getValue(ent, xi); }
  auto getJacobians(...)     const { return geom.getJacobians(...); }  // ONE implementation
};

A claude idea. I don't hate it.

[jacobmerson]

For MFEM they have a ElementTransformation base class see: https://github.com/mfem/mfem/blob/a7dbea190fb3e71324ab1e1b9521b1cfcfe97e63/fem/eltrans.hpp#L27

The IsoParametricTransformation inherits from the ElementTransformation

[jacobmerson]

Kirby paper discussing transforming finite elements. It looks like it has some explanation about why the Bell element (which is the reduced quintic we implemented) cannot utilize the standard reference element. They propose an alternative mapping strategy that may be worth investigating.

https://www.numdam.org/item/10.5802/smai-jcm.33.pdf

[jacobmerson]

Went through Kirby paper in some additional detail. I think we can take care of what’s needed for a wide range of elements by just adding an additional policy to that class I suggested for the PushForward and PullBack to the reference element. Kirby does this trick where he does those mapping in a larger space than the Bell/reduced quintic elements, but easy enough to encode in those policies. That design should also work for HDiv/Hcurl

[jacobmerson]

I was thinking about naming and I think PushForward/PullBack although they match to Kirby, they are not going to make much sense to anyone that doesn't have experience with differential geometry. Something closer to ToReferenceElement and ToPhysicalField as the policy names might be more clear.