Open questions regarding bases for non-affine equivalent families

When implementing global bases for non-affine (e.g. Hermite-like) finite elements, several additional questions and problems arise, that need to be taken care or:

• What is the precise semantics of the functions passed to local interpolate() methods? Is is (A) just a differentiable function defined on the reference element or (B) a local function whose derivatives are given in global coordinates? (This is the topic of #76 (closed)). (We agreed on (B) in a meeting.)
• Caching of local basis evaluations can lead to significant speedup e.g. during assembly. However, plain caching will in general not work for Hermite-type bases, because the basis functions depend on the grid element. This leads to two problems:
  • We need an interface that provides the assembler with the information if caching across different elements is OK. This should roughly correspond to an isAffineFamiliy flag.
  • Even for non-affine families, there is often a significant bit of information that could be cached, however, this is in general an implementation detail of the local basis. E.g. for cubic Hermite elements, you only have to do minor modifications to the evaluations of some reference functions. Evaluating those is most of the work and independent of the element and thus cacheable. A possible interface could be to add two functions localBasis.preComputeFunction(const Domain&, CacheableIntermediateValue&) and localBasis.evaluateFunction(const CacheableIntermediateValue&, std::vector<Range>&), where CacheableValueData is an implementation-depended exported type containing all cacheable intermediate data for evaluating at x that is persistent across elements.
  • The same problem and possible solutions apply to families with range transformations or multiple variants like e.g. Raviart-Thomas.
• Implementing Hermite-like finite elements with respect to text book interpolation conditions leads to basis functions with h-dependent scaling and thus badly scaled matrices. E.g. the condition number of the mass matrix associated with classic cubic Hermite triangles behaves like O(h^{-2}). This can be avoided by rescaling with an effective h that needs to be computed in advance for each entity. Since this is not specific to a certain basis, having a general mechanism would be nice. (The current implementation of rescaling in the existing Hermite-type bases sees to be fine.)