[Dune-devel] dune-functions meeting and mailing list

[Christian Engwer]

Dear all,

last week we had a small meeting in Aachen to continue with the
discussion of a possible dune-functions module.

We mainly collected experiences with the interfaces discussed in
Münster, sorted out smaller issues and clearified some open
questions. We also started implementing some of the interfaces.

Attached you can find the short protocoll from Aachen.

We decided that for future discussion a dedicated mailing-list would
be helpful. Therefor we now have the dune-functions at dune-project.org
list. We invite all of you to participate in the discussion and you
can subscribe your self at
  http://lists.dune-project.org/mailman/listinfo/dune-functions

Ciao
Christian
-------------- next part --------------
Function Space Bases

- for now only depending on GridView (maybe also for Grids or other entity sets - tbd)
- Global interface minimalistic (only provide enough information for computing container sizes)
- main interface through a LocalView obtained from the global basis
- Prototype implementation for PQ1 and flat global index in dune-functions

LocalView

- LocalView returned by value (can have multiple views at the same time)
- View can be bound to and unbound from elements and provides access to a bound element
- Concrete interaction with a bound view through a nested tree object (name tbd)

LocalView Tree

- Tree represents an element-local tensor product space
- Leafs correspond to a local finite elements from dune-localfunctions
- Tree is implemented using dune-typetree
- Leafs can map leaf-local consecutive indices for shape functions to
  - a unique index with respect to the entire local basis tree, which is consecutive and 0-based
  - a globally unique (for the entire function space) multi-index. The exact semantics and
    properties of this multi-index are not defined yet. There may be multiple classes of multi-indices
    with different properties and complexities.
    A very simple index would be of length 1 and consecutive. In general, indices can be of varying
    length and can contain non-consecutive entries (e.g. for the GeometryTypeIndex).
    At a later stage, those classes will need to be precisely defined to create an interface to container
    backends that will depend on the exact semantics of those classes.
  - There are interfaces to obtain either a single global index or to efficiently populate a container with
    all global indices for the currently bound grid element


Smaller Changes

- GridViewFunction was revised to work with new GridViewFunctionSpaceBasis
- Replace FunctionHandle for derived functions with shared_ptr
- Functions now longer inherit from enable_shared_from_this
- Convenience interfaces by Carsten to convert to / from callables (via std::function)


Open Questions

- Container backends
- Index transformations (for systems / blocking / etc.)
- Avoid interface restrictions w.r.t. features like automatic backend construction (PDELab) or additional
  information like local sparsity structures (Carsten)
- Semantics and properties of canonical multi-index classes
- Constraints
- higher-order derivatives of shape functions for non-affine geometry mappings
- dune-localfunctions: Several smaller issues
- revise global valued interface of dune-localfunctions


Homework

Oli: port additional bases (P^k) from dune-fufem
Christian: functions interface for PDELab
Christian / Steffen: discuss minimum backend interface from PDELab point of view