Move all FIAT-like element classes to FIAT

[Miklós Homolya]

Discussion started in this thread, I summarise the main points here.

Considering all of FFC, FIAT and TSFC, the current situation about "finite elements" residing in form compilers is somewhat chaotic:

• Both FFC and FIAT have an EnrichedElement. FFC uses its own, TSFC uses the one from FIAT.
• Both FFC and TSFC have a MixedElement. Both using their own, however, due to form splitting, coefficient splitting and finat.TensorFiniteElement, Firedrake never actually uses the TSFC MixedElement, so the TSFC copy is only there for the sake of FEniCS.
• FFC has a QuadratureElement. FInAT has a smarter QuadratureElement which shall be satisfactory for Firedrake in virtually all cases. (Unless someone wants to "enrich" quadrature elements with other elements.) Because FEniCS does not practice form splitting and coefficient splitting, there many more cases in FEniCS when TSFC needs a FIAT-like QuadratureElement which TSFC sneakily imports from FFC.

While it is true that FFC finite elements do not have all the functionality that FIAT elements traditionally had, this is less of an issue since the FiniteElement/CiarletElement split in FIAT, which officially introduced a thinner interface for finite elements (FiniteElement), while retaining the old, richer interface as CiarletElement for elements that actually implement those features.

Moving all FIAT-like elements to FIAT would allow to simplify these convoluted relationships.

[Miklós Homolya]

Both FFC and FIAT have an EnrichedElement. FFC uses its own, TSFC uses the one from FIAT.

Same applies to RestrictedElement.

[Miklós Homolya]

Note to self: 42b50e0 causes divergence between the FFC and the FIAT version of EnrichedElement. Some FFC code relies on the dual functions being None, while FIAT TensorProductElement assumes non-None dual functions.

[Jan Blechta]

There is an interface. Just need to interpret it accordingly in FFC, i.e. any duals which are not orthogonal (hence they are arbitrary) are not wanted in FFC. (Sorry for doing the None hack before, I was expecting it more temporary problem before.)

class FiniteElement(object):
    """Class implementing a basic abstraction template for general
    finite element families. Finite elements which inherit from
    this class are non-nodal unless they are CiarletElement subclasses.
    """

    @staticmethod
    def is_nodal():
        """True if primal and dual bases are orthogonal. If false,
        dual basis is not implemented or is undefined.

        Subclasses may not necessarily be nodal, unless it is a CiarletElement.
        """
        return False

Also note that FFC EnrichedElement is more general, it takes any number of sub-elements.

[Miklós Homolya]

Thanks, that is a good approach for reconciliation.

Also note that FFC EnrichedElement is more general, it takes any number of sub-elements.

I will merge that then somehow.

[Miklós Homolya]

If I rely on is_nodal(), then things change on MixedElements, since currently those nodes that come from EnrichedElements are None, while the other nodes are real. Even if I defined a custom is_nodal() function for MixedElement, it could either enable all nodes or none.

[Jan Blechta]

I guess(!) none is ok in that case. What is a part of the nodes useful for? You don't do an interpolation without all nodes.

[Jan Blechta]

This is incorrect. Element either is nodal when psi_j (phi_i) = delta_ij or is not otherwise. Here it is obviously the second case. And we don't want arbitrary nodes in FFC.

So go ahead and make mixed of non-nodal enriched non-nodal.

[Miklós Homolya]

Thanks, I will be confident changing the reference data then.

[Miklós Homolya]

Implemented by pull request #66.