Moment based reffes #1048
Moment based reffes #1048
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1048 +/- ##
==========================================
- Coverage 89.35% 86.01% -3.35%
==========================================
Files 197 212 +15
Lines 23916 24577 +661
==========================================
- Hits 21370 21139 -231
- Misses 2546 3438 +892 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Moment based reffes: refactoring and extension of Gridap.Polynomials
| @@ -197,6 +196,7 @@ export bdm | |||
| export nedelec | |||
| export bezier | |||
| export modalC0 | |||
| export cr | |||
There was a problem hiding this comment.
shouldn't we name Crouziex-Raviart reffename: crouziex_raviart = CrouziexRaviart() for clarity and consistency with raviart_thomas = RaviartThomas() ?
There was a problem hiding this comment.
In the literature, people just refer to it as "cr" just like "bdm". I would suggest that we should name "raviart_thomas" as "RT" instead, which is how people refer to it in the literature and probably modify "cr" to "CR" and "bdm" to "BDM".
There was a problem hiding this comment.
I prefer longer names. CR, RT, ... could mean anything. If you start abbreviating you end up with fortran77 codes...
If a user doesn't know that CR means Crouziex-Raviart, maybe they should not be using it.
There was a problem hiding this comment.
Also: If you don't know what Raviart-Thomas is, you can google it. Going the other direction is not as easy.
and 1D Monomial basis optimization
de Casteljau indices and iteration needed to be computed and unrolled at compile time
To really optimise this, the tuple of orders should be added in the type parameters of the UniformPolyBases and CompWiseTensorPolyBases, in order to avoid creating the Val(Kd) at runtime and associated runtime dispatch into _evaluate_1d! (but this seems overkill for most usages)
renamed _ps_filter and _qs_filter to _ph_filter and _qh_filter respectively, "h" for Homogeneous.
A dof basis \Sigma is a set of dofs \sigma, and a dof is in
V* = {\sigma: V -> R}, not in V** = { p: V* -> R}.
Removed the maximum order K from template parameters of PolynomialBasis to simplify the type signature, added the corresponding field to all concrete subtypes, passed the order by Val to [...]_nd! functions to avoid allocations and runtime dispatch in them (at each evaluation point) added _get_static_parameters(::PolynomialBasis) to let each basis choose their static parameter (Val(K), nothing, others...)
unfortunately _evaluate_nd! and friend do not specialize properly when unpacking a tuple of Val in evaluate! The parameters could also be put in cache, but then return_cache is not independant of the polynomial order anymore (currently it is thanks to _setsize! in evaluate!)
…o moment-based-reffes
Fixed test coverage, fixed singular simplex detection, simplified bernstein_term_id, updated NEWS.md.
Moment based reffes - Implementation of scalar Bernstein basis in barycentric coordinates.
So we've been having a look at the current implementation of Raviart-Thomas and Nedelec. It has become clear that the current implementation
Moreover, there has been interest lately in implementing more types of moment-based discretisations like Crouzeix-Raviart.
We believe the best way to solve all these issues at once is to create some extendable machinery to easily create moment-based FEs.
TODOs:
New RefFEs:
Other: Polynomial bases
The solution to the first issue requires extending Jacobi-type polynomial bases. Although it could be done blindly, I think we could try to merge a lot of code together. In the future we might want to have even more basis of polynomials, which would require a lot of copied code.