Implement interpolation for quadrature elements

[mscroggs]

Requires FEniCS/ffcx#634.

Resolves #1546.

Progress towards #2872

[jorgensd]

Looks good to me!

Should we maybe add an x-fail test for the case where one uses multiple quadrature elements (with different schemes) in the same code?

[chrisrichardson]

I am a bit confused by the complexity of it - it seems to be adding more generated code (which we generally try to avoid) to pass data from basix via ffcx back to dolfinx. Is this avoidable?

[mscroggs]

I am a bit confused by the complexity of it - it seems to be adding more generated code (which we generally try to avoid) to pass data from basix via ffcx back to dolfinx. Is this avoidable?

Writing the quadrature rules into the generated code is definitely necessary.

We could avoid writing the map type into generated code if we make the assumption that elements with custom quadrature always use an identity pullback. This feels dangerous though.

The key issue is that quadrature elements are only defined in Python, so we need to write what we need into the generated code so that C++ can get hold of it

[jorgensd]

We could avoid writing the map type into generated code if we make the assumption that elements with custom quadrature always use an identity pullback. This feels dangerous though.

I'm not sure it is dangerous. QuadratureElements isn't really a finite element (as discussed earlier), and is a way of representing data at points. Having a pull back != identity on point data seems strange.

[mscroggs]

We could avoid writing the map type into generated code if we make the assumption that elements with custom quadrature always use an identity pullback. This feels dangerous though.

I'm not sure it is dangerous. QuadratureElements isn't really a finite element (as discussed earlier), and is a way of representing data at points. Having a pull back != identity on point data seems strange.

The danger I'm worried about it that we're not checking if it's a quadrature element, we're checking if there's a custom quadrature rule. If at some point in the future we decided to implement (eg) a Nedelec-style element that has a custom quadrature rule (for whatever reason), this would lead to odd behaviour.

[mscroggs]

We could avoid writing the map type into generated code if we make the assumption that elements with custom quadrature always use an identity pullback. This feels dangerous though.

I'm not sure it is dangerous. QuadratureElements isn't really a finite element (as discussed earlier), and is a way of representing data at points. Having a pull back != identity on point data seems strange.

The danger I'm worried about it that we're not checking if it's a quadrature element, we're checking if there's a custom quadrature rule. If at some point in the future we decided to implement (eg) a Nedelec-style element that has a custom quadrature rule (for whatever reason), this would lead to odd behaviour.

I've changed it to check whether the element is a quadrature element directly, so no longer any need to worry about possible other future uses of custom quadrature

[jorgensd]

Could we merge this?