meeting2017.md

@@ -17,14 +17,15 @@ IWR Heidelberg
    CG: What about using `Dune::TupleVector` for this?
  1. [X] CG: Batch access to indices in `LocalIndexSet` #12 
  1. [X] CG: Review naming of `Basis`, `NodeFactory`, `NodeFactoryBuilder`, ... #13 
- 1. [ ] CE: Non-affine FE
- 1. [ ] CE: topology and constraints (higher-order FE, H-div, etc.)
+ 1. [X] OS: Simplify the dune-localfunctions virtual interface now that the evaluate method
+   is gone.
+ 1. [X] CE: Non-affine FE (H2-conforming spaces, etc.)
+ 1. [X] CE: topology and orientation ("Twist", H-div-conforming spaces, etc.)
+ 1. [ ] CE: constraints (p-adaptive FE, hanging nodes, etc.)
  1. [ ] CE: Paper
  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?
- 1. [ ] OS: Simplify the dune-localfunctions virtual interface now that the evaluate method
-   is gone.
  1. [ ] CG: What do we need for adaptivity?
 
 ## Protocol
@@ -44,7 +45,7 @@ IWR Heidelberg
   * Add an interface to obtain a linear basis transformation for each node. This allows, e.g., to flip basis functions (normal flip for RT), to permute basis functions or, in general, to transform to another local basis (Hermite elements). This should be exported as a matrix wrt the local basis function numbering in the node. Using special matrix types allows to express simple cases efficiently.
   * Add an interface to obtain a "global" finite element which already contains the range space transformation and the element geometry transformation of the domain. It should not contain the basis transformation, because this can be done more efficiently outside.
   * Possible problems: Implementing the interpolation into the global space using only the local basis transformations may not lead to the expected natural interpolation for
-the corresponding FE-space, e.g., in case of Hermite-elements. Since this problem results from the fact that we must extend the interpolation functionals to a larger space, this cannot be solved only based on the transformation without providing additional information.
+the corresponding FE-space, e.g., in case of Hermite-elements. Since this problem results from the fact that we must extend the interpolation functionals to a larger space, this cannot be solved only based on the transformation without providing additional information. This also holds true for certain definitions of the RT family, where the DOFs are defined via moments.
 
 ### TypeTree
 * Add a method `treePath(...)` that does the same as `hybridTreePath()`