Replace UFL elements with Basix elements in tests (work in progress)

[mscroggs]

Using Basix's UFL wrapper, Basix elements can be created directly rather than going via UFL. Once this is complete, finiteelementbase.py will be the only file in ufl/finiteelemnt that DOLFINx uses, and new elements could be added to FEniCSx by changing Basix (and only Basix).

Issues encountered while working on this: FEniCS/basix#600

In #2301, the same was done for functions in the Python layer but not tests.

[jorgensd]

Im not too enthusiastic with this change. It now looks more complicated to create an element. Additionally, if we go ahead with this, it has to be propagated to the C++ interface (I.e. the python files).

At least we need to find a nicer namespace than basix.ufl_wrapper as it is significantly more complicated than ufl.

[mscroggs]

It now looks more complicated to create an element.

It shouldn't look more complicated once done right. (It's not there yet. I've opened this early as we're discussing UFL development tomorrow and I wanted this to be easier to find.) In any case, things only need to change when UFL elements are created directly (ie tests where family and degree are passed into FunctionSpace have not changed).

At least we need to find a nicer namespace than basix.ufl_wrapper as it is significantly more complicated than ufl.

Agreed. Maybe import basix.ufl_wrapper as bufl should be standard but with a better choice than bufl

[mscroggs]

~Just realised that I didn't update the C++ tests and the demos. Reverting this to a draft while I sort these out~ done

[garth-wells]

I know these are Basix questions, but

• Could basix.ufl_wrapper be basix.ufl? The former is a bit long and ugly
• Do all the functions need to be prefixed with ‘create’? Does seem to add anything. We have attempted to remove this style elsewhere. ‘create’ is C-like when one might expect a corresponding ‘destroy’ function.

[mscroggs]

* Could `basix.ufl_wrapper` be `basix.ufl`? The former is a bit long and ugly

As the ufl_wrapper imports ufl, I was worried this might create a circular import. If it works, it's definitely what we should call it. I'll test this...

[garth-wells]

* Could `basix.ufl_wrapper` be `basix.ufl`? The former is a bit long and ugly

As the ufl_wrapper imports ufl, I was worried this might create a circular import. If it works, it's definitely what we should call it. I'll test this...

If it doesn't work or is confusing, maybe something like uflw?

[jorgensd]

* Could `basix.ufl_wrapper` be `basix.ufl`? The former is a bit long and ugly

As the ufl_wrapper imports ufl, I was worried this might create a circular import. If it works, it's definitely what we should call it. I'll test this...

If it doesn't work or is confusing, maybe something like uflw?

We could follow how we did with dolfinx.io.gmshio, ie basix.uflio

[mscroggs]

basix.ufl works (we're not running from in the Basix dir, so import doesn't see the file in there unless you ask to import basix,ufl).

I think it's not confusing as in the examples, we always either import basix.ufl or from basix.ufl import ... and never from basix import ufl

[mscroggs]

• Do all the functions need to be prefixed with ‘create’? Does seem to add anything. We have attempted to remove this style elsewhere. ‘create’ is C-like when one might expect a corresponding ‘destroy’ function.

I've ~renamed~ combined the functions to ~finite_element, vector_element and tensor_element~ element (see https://github.com/FEniCS/basix/pull/655)