... | ... | @@ -11,21 +11,21 @@ IWR Heidelberg |
|
|
|
|
|
## Agenda
|
|
|
|
|
|
* CE: Non-affine FE
|
|
|
* CE: topology and constraints (higher-order FE, H-div, etc.)
|
|
|
* CE: Paper
|
|
|
* OS: Can we replace the HybridTreePath class by a more general HybridArray?
|
|
|
1. [ ] CE: Non-affine FE
|
|
|
1. [ ] CE: topology and constraints (higher-order FE, H-div, etc.)
|
|
|
1. [ ] CE: Paper
|
|
|
1. [ ] OS: Can we replace the HybridTreePath class by a more general HybridArray?
|
|
|
Such a HybridArray could then also be used, e.g., to index entries of a
|
|
|
MultitypeBlockVector.
|
|
|
CG: What about using `Dune::TupleVector` for this?
|
|
|
* OS: dune-pdelab contains Lagrange-LocalFiniteElements with run-time order. Given
|
|
|
1. [ ] OS: dune-pdelab contains Lagrange-LocalFiniteElements with run-time order. Given
|
|
|
that we have constexpr nowadays, can we merge this into the compile-time-order
|
|
|
implementation in dune-localfunctions and get both behaviour from a single code?
|
|
|
* OS: Simplify the dune-localfunctions virtual interface now that the evaluate method
|
|
|
1. [ ] OS: Simplify the dune-localfunctions virtual interface now that the evaluate method
|
|
|
is gone.
|
|
|
* CG: Batch access to indices in `LocalIndexSet` #12
|
|
|
* CG: Review naming of `Basis`, `NodeFactory`, `NodeFactoryBuilder`, ... #13
|
|
|
* CG: What do we need for adaptivity?
|
|
|
1. [ ] CG: Batch access to indices in `LocalIndexSet` #12
|
|
|
1. [ ] CG: Review naming of `Basis`, `NodeFactory`, `NodeFactoryBuilder`, ... #13
|
|
|
1. [ ] CG: What do we need for adaptivity?
|
|
|
|
|
|
## Protocol
|
|
|
|
... | ... | |