Draft: Add integration of fenix-basix finite-element library
Add wrapper around the finite-element definition and tabulation library Basix: https://docs.fenicsproject.org/basix/v0.8.0/index.html
Merge request reports
Activity
requested review from @christi
@simon.praetorius thanks for doing this - I was starting to look into this as well but you beat me by a mile.
Edited by Andreas Dedneradded 1 commit
- 508c99ea - Directly extract the data table into the output vectors
added 2 commits
added 1 commit
- 532d2ee2 - Add entity numbering for basix reference elements
added 1 commit
- d2cbec68 - Make basix local and global finite element constructible from pointer to basix object
mentioned in merge request staging/dune-functions!483
The basix library uses
std::spanandstd::mdspanfor passing and returning argument to their functions. This is very nice, since very flexible. In our interface of the local basis, we pass the output parameters asstd::vector<FieldVector<...>>& outorstd::vector<FieldMatrix<...>>& out. What we need is a memory block that can be referenced using a data-handle (e.g. a pointer) to the begin, and a shape (e.g. the row/column sizes of the whole container). Is it allowed to use&out[0][0](and&out[0][0][0]) for the data-handle and{out.size(), dimRange}(and{out.size(), dimRange, dimDomain}) for the shape, or would this be undefined behavior?- dune/localfunctions/basix/utility.hh 0 → 100644
21 case basix::cell::type::point: return GeometryTypes::vertex; 22 case basix::cell::type::interval: return GeometryTypes::line; 23 case basix::cell::type::triangle: return GeometryTypes::triangle; 24 case basix::cell::type::tetrahedron: return GeometryTypes::tetrahedron; 25 case basix::cell::type::quadrilateral: return GeometryTypes::quadrilateral; 26 case basix::cell::type::hexahedron: return GeometryTypes::hexahedron; 27 case basix::cell::type::prism: return GeometryTypes::prism; 28 case basix::cell::type::pyramid: return GeometryTypes::pyramid; 29 default: return GeometryTypes::none(0); 30 } 31 } 32 33 // Map the Dune::GeometryType to cell::type from basix 34 inline basix::cell::type cellType (GeometryType type) 35 { 36 if (type.isVertex()) -
While I have implemented here a local finite-element and a "global" finite-element, I mean by the latter a finite-element transformed to a real geometry. We have discussed in dune-functions that this abstraction does not fit well into dune-localfunctions. One often needs some global information from the grid.
Having another discussion about adding
globalfe would be nice.basixshas methods for this that do not really require too much global information as far as I could understand. Also there are different stages ofglobal fewe could consider;- there is the pushforward/back which is really still quite local
- there is the issue of reordering of basis functions or dofs (twist) or switching signs of dofs (e.g. RT) which are perhaps more problematic to integrate on a local level.
Would it be possible to separate different parts in some way and move at least part of the
globalizationintodune-localfunctions? Of course the resulting object has to make sense in some way - but pushforward/back seems reasonable for example, i.e., alocalfe in physical spaceobject.-
This would probably be a good topic for a developer meeting. Currently we try to sort things out in dune-functions and discuss what can be put into dune-localfunctions and what does not fit there well. There is no module for more global definitions of finite-elements.
In the current implementation I have parametrized the global basis fe with a geometry. It can be bound to such a geometry and one can pass the permutation information in form of the cell_info encoding that basix is using. Unfortunately, I have not yet found a proper definition of this integer, only vague examples. One can look into the dolpinx implementation, though.
The pull_back/push_forward of basis function values can be implemented with this information. The interface in basix for this is not very nice, though. Maybe an infrastructure for this in Dune is better suited. In dune-functions this is partially implemented.
Interestingly, there is the interface description of global-valued finite-elements already in dune-localfunctions, but I have not found a place where this is used.
Edited by Simon Praetorius
