Skip to content

WIP: Feature/add dynamic grid function spaces

Santiago Ospina De Los Ríos requested to merge copasi/dune-pdelab:feature/add-dynamic-grid-function-spaces into master

What does this MR do?

Adds dynamic power grid function spaces including all types of possible orderings. The main reason to have this features is to have run-time number of components in multicomponent settings. There are inumerable cases where this is a must-have if code has to be released. Perhaps the most remarkable one is the case where two level tree (power space of a power space) have to be changed (e.g. child nodes refer to components of a speces in a domain while parent node refers to the domain where these speces live). For such cases, compiling is not an option due to the combinatorial explition of possibilities.

  • Notice that with dynamic I refer to dynamic storage of them, defined at construction of the space. Afterwards, the space is immutable as its static counterparts.

  • Orderings work exacly the same as for the static power node

  • Regarding performance, there is two places in the critical path where I had to change anything at all. That is in the entity blocked ordering and in the local function space cache. In the two cases the only change was to use std::vector instead of std::array when a dynamic node was used. Apart of that, no change from the algorithmic point of view.

  • This MR is only functional with the branch feature/add-dynamic-power-nodes on the copasi/dune-typetree fork which adds the dynamic power node infrastructure for this.

  • This MR is for only discussion (WIP) until staging/dune-typetree!55 (closed) is accepted.

  • To discuss: Do we actually need static grid function power spaces at all? From my perspective, the pdelab machinary does not care at all and I don't see the point on maitaining the two of them (other than backwards compatibility). The only point where I see where static information is needed is on the local operators, but these cases mostly depend on the grid dimension (e.g. vector spaces) or other user provided information (e.g. number of components in a solution).

Is there something that needs to be double checked?

  • Are these tests enough?

Can this MR be accepted?

Related issues

staging/dune-typetree!55 (closed)

Edited by Santiago Ospina De Los Ríos

Merge request reports