Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #1048 +/- ##
==========================================
- Coverage 89.33% 86.76% -2.57%
==========================================
Files 213 234 +21
Lines 27532 29205 +1673
==========================================
+ Hits 24595 25339 +744
- Misses 2937 3866 +929
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
src/ReferenceFEs/ReferenceFEs.jl
Outdated
| export nedelec | ||
| export bezier | ||
| export modalC0 | ||
| export cr |
Contributor
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() ?
Contributor
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".
Member
Author
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.
Member
Author
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.
- fix @inbounds propagation to prevent bound checks - fix getindex in performence mode
fixing precomputation performences and a typo
removed generated function and stored indices in the basis
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.
Cf added tests that wouldn't pass before.
I was initially reluctant to implement this for non scalar valued bases, but then I realized that `MonomialBasis` always implemented `get_orders` for tensor-valued bases, so I updated the doc in function.
…p.jl into moment-based-reffes
[moment-based-reffes] Geometric decomposition on n-cubes, choice of poly basis in Lagrangian and Serendipity FES
- Enable chosing the term of component-wise tensor product polynomial bases - Fixed allocation issue in derivatives evaluations - Generalized their derivatives to basis with tensor-type value having dependent components - enabled return_type to work on linear-combination of PolynomialBasis
following Santi's review
following Santi's review
[Moment based reffes] Improve CompWiseTensorPolyBasis and fix perf regression, minor renamings
It should now work for any MultiValue type (previously broken for SkewSymTensorValue).
- homogenized the content of former face_dofs field of GenericRefFE accross all elements, by putting face_own_dofs inside, which most element did. - face_dofs is now computed on demand, but are (almost?) never used in practice
PolynomialBasis used to do type pyracy of Arrays' return_type, the signature return_type(::PolynomialBasis) is now deprecated in favor of `value_type(::PolynomialBasis)`.
Implemented `vcat` on tuple of `Dof` vectors such that: `evaluate(vcat(dofs...), φ) == vcat( (evaluate(dof, φ) for dof in dofs)...)`
Generalized `representatives_of_componentbasis_dual`, to any given basis of a subspace of span(component_basis(V)). Usefull to compute a dual basis to a tensor-product space of tensors when at least one has dependant components Improved the docs of `component_basis`, `representatives_of_componentbasis_dual` and `representatives_of_basis_dual`.
Moment dof bases now accept a `operator` argument, the operator is broadcasted over the fields before evaluating the moment. This is useful to implement e.g. directional derivative dofs.
[Moment based reffes] small TensorValues and Polynomials improvements, MomentDofBasis generalization to differential operators
- Added HighOrderTensorValue{S,T,N,L} <: MultiValue{S,T,N,L} wrapping a
SArray of arbitrary order.
- Replaced the concrete implementation of ThirdOrderTensorValue with an
alias to HighOrderTensorValue{Tuple{D1,D2,D3},T,3,L}
- implemented generic outer product, inner product, dot product and
double dot product for tensor of arbitrary order, via the
contraced_product method
- fixed the component naming for order 2 & 3 tensors
[Moment based reffes] Generalized MultiValue types and product operation to arbitrary order
I earlier introduced this dynamic dispatch when removing the polynomial
order `K` from the abstract type `PolynomialBasis{D,V,K}`, because
knowing K at compile time is necessary for Bernstein based bases
But it was very inelegant. Instead, I added again `K` in the type
parameters of the basis that want to statically know it at compile time
(Bernstein based basis), and refactor _get_static_parameters into
_get_parameters.
It now returns K::Int for bases that don't need to know K at compile
time, and ::Val(K) for Bernstein bases. As a consequence, all evaluation
methods are not both type stable and statically inferable from the basis
type, all dynamic dispatches are eliminated.
[Moment based reffes] Merge master and minor Polynomials optimization
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.