Expose basix::FiniteElement

[nate-sime]

Exposure of the basix::FiniteElement underlying dolfinx::fem::FiniteElement is very useful for code building on top of dolfinx. Futhermore a number of methods in dolfinx::fem::FiniteElement needlessly wrap the basix::FiniteElement. Here we simplify the interface.

[garth-wells]

The idea behind the original design was to hide the Basix implementation, for example to allow a user to hand-code an element. We've probably had some leakage over time, but is it still reasonable to try and hide the implementation?

A benefit of wrapping parts of the Basix interface is that we can more easily evolve Basix and DOLFINx independently. Some changes in Basix are planned to remove xtensor.

[nate-sime]

It seems that most natural way to creating a custom element is to use basix itself as demonstrated here. I can add back the wrapping methods for those who wish to inherit dolfinx::fem::FiniteElement. Whichever philosophy is decided, having access to the underlying basix::FiniteElement is highly desirable.

[jorgensd]

It seems that most natural way to creating a custom element is to use basix itself as demonstrated here. I can add back the wrapping methods for those who wish to inherit dolfinx::fem::FiniteElement. Whichever philosophy is decided, having access to the underlying basix::FiniteElement is highly desirable.

I agree with Nate that custom elements now are naturally supported through Basix. We also added the function space constructor that takes in a Basix element, and then create the dolfinx finite element.

There are many cases where one would like to access functions we haven’t exposed, such as degree and tabulate_shape, that would simplify codes relying on DOLFINx in C++.

[IgorBaratta]

I also think it's a good idea to expose the basix element, although the wrapping methods provide more freedom for Basix. Otherwise, a change in basix interface would reflect in dolfinx API.

[jorgensd]

I also think it's a good idea to expose the basix element, although the wrapping methods provide more freedom for Basix. Otherwise, a change in basix interface would reflect in dolfinx API.

We could keep the wrappers, but also expose the underlying element such that one can use the other functions (that are not used in the DOLFINx API).

[garth-wells]

Yes, we could expose the Basix element. I'm not sure if this should be via a pointer or a reference given that not all FiniteElement objects have a Basix element.

I do think we should keep the wrapper functions for a few reasons:

1. Wrapper makes the coupling between DOLFINx and Basix less tight, which is good
2. It's annoying if one has to dig through the Basix documentation for finite element functionality
3. Not all FiniteElements have a Basix element, and we may want. to handle some of these cases

[mscroggs]

This looks good to me, as the only methods being taken out of the DOLFINx FiniteElement are those that are rarely used and just called Basix anyway

[nate-sime]

Also related: #2139, #2055, #2221.

[nate-sime]

I've reverted to the previous dolfinx interface. If we're happy with this can I merge?