DUNE PDELab (git)

Map between DOFIndex and ContainerIndex. More...

Classes

class  Dune::PDELab::ChunkedBlockOrdering< Ordering >
 Ordering that permutes top-level ContainerIndex entries. More...
 
class  Dune::PDELab::GridViewOrdering< LocalOrdering >
 Transforms a local ordering (entity-wise order) into a global ordering. More...
 
class  Dune::PDELab::LeafGridViewOrdering< LocalOrdering >
 Gridview ordering for leaf spaces. More...
 
class  Dune::PDELab::LeafOrderingBase< LocalOrdering >
 Generic infrastructure for orderings for leaf spaces. More...
 
class  Dune::PDELab::CompositeLexicographicOrdering< DI, CI, Children >
 Interface for merging index spaces. More...
 
class  Dune::PDELab::LocalOrderingBase< ES, DI, CI >
 Entity-wise orderings. More...
 
class  Dune::PDELab::PermutedOrdering< Ordering >
 Ordering that permutes top-level ContainerIndex entries. More...
 
class  Dune::PDELab::SubOrdering< BaseOrdering_, TreePath >
 A view on a subtree of a multi-component ordering. More...
 
struct  Dune::PDELab::MergeMode
 Index merging algorithm for global orderings. More...
 
struct  Dune::PDELab::DummyDOFIndexIterator
 Dummy iterator type over DOF indices. More...
 
struct  Dune::PDELab::SizeProviderAdapter< Size, ContainerIndex_, OriginOrder >
 Adapter to create a size provider from an ordering. More...
 

Enumerations

enum class  Dune::PDELab::MultiIndexOrder { MultiIndexOrder::Inner2Outer , MultiIndexOrder::Outer2Inner }
 Information about order semantics on multi-indices. More...
 

Functions

template<class Ordering >
 Dune::PDELab::SizeProviderAdapter (const std::shared_ptr< const Ordering > &ordering) -> SizeProviderAdapter< typename Ordering::Traits::SizeType, typename Ordering::Traits::ContainerIndex, Ordering::Traits::ContainerIndexOrder >
 template deduction guide for orderings
 

Detailed Description

Map between DOFIndex and ContainerIndex.

Overview

The main purpose of the ordering library is to provide mappings from DOFIndex to ContainerIndex.

  • The DOFIndex represents a unique Degree of Freedom index in the Grid Function Space Tree (See DOFIndex documentation).
  • The ContainerIndex is a MultiIndex that encodes the access to a backend container. The ordering library is in charge of providing such indices. In a nested container (e.g. BlockVector<FieldVector<double,2>>) each index in the MultiIndex will determine the accessor on each of the depths of the container going from inner container to outer container (e.g. the MultiIndex {1,10} in a nested vector vec is accessed with vec[10][1]).

Ordering Tree

A final ordering is a type tree that is very similar to the Grid Function Space Tree. The ordering tree has the same structure but may have additional intermediate nodes. However, a main difference is that intermediate nodes are added in order to account for additional node transformations to the ContainerIndex.

Tree example:

Power GFS node --> * * |\ |\ | \ * * <– Additional intermediate node e.g. GV ordering nodes | \ | \ Leaf GFS node --> * * * * <– e.g. Local ordering nodes

Possible intermediate nodes:

  • Grid View Ordering node
  • Chunked Ordering node
  • Permuted Ordering node

Ordering Node

The main task of an ordering node is to modify or add the last index of a partially constructed ContainerIndex based on a part of a DOFIndex.

  • Container indices are built left to right. That is, starting from inner to outer container indices. This implies that to construct one container index out of a DOFIndex, the ordering tree should be traversed from a leaf node towards the root node.
  • Blocked: When a node orders a new block in the container, it appends a value to the container index. Typically, the appended value is the index of the DOFIndex that is being processed.
  • Non-Blocked: In this case the node modifies the last value of the container index. In other words, it needs to put the last modified index into the context of the a bigger tree strucutre. Typically, this is done by adding an offset according to a merging strategy.
### Local Ordering Tree

The local ordering is a special kind of ordering tree where all
ContainerIndex for a given entity index are ordered consecutively
starting at index `0`. Notice that it is an ordering itself and also
work as described above, but because their indexation starts at `0`,
they are placed at the bottom of the tree so that other ordering nodes
can merge them in a meaningful way.

### Grid View Ordering Node

This kind of node holds **one** local ordering tree as a child and puts the
local ordering ContainerIndex in context of all the entities in an entity
set. Typically, this node keeps a list of offsets for each entity index.
This offset is added or appendend to the last index of the ContainerIndex
created by the local ordering.

## Size of sub-blocks

The ContainerIndex is meant to access a container. However, in an arbitrarily
nested container, every sub-block container may have a different size
necessary to store every possible ContainerIndex from the ordering. To solve
this, the ordering root node offers a `size(ContainerIdex)` method that
gives a size for every possible container.

In particular, it computes the size required for a given suffix of a
ContainerIndex. We say that the container index is a complete
MultiIndex path to the container and that a suffix is a partial
MultiIndex refering to the outer containers of a system of nested
containers (e.g. vector of vectors).

For example, posible suffixes to the container index `{1,4,10}` are
`{}`, `{10}`, and  `{4,10}`, and each of these suffixes will
yield different sizes that are big enough to accommodate all possible
sub-suffixes. Following the example above, the sizes should be at least
11, 5, and 2. The `size(ContainerIndex)` method also accepts full container
index (i.e. full MultiIndex `{1,4,10}`), but since containers are not
expected to be blocked further down, it returns 0.

In dune-function terms, the root ordering node will act as a size provider.
However, notice that order of the `SizePrefix` has the same semantics as the
`ContainerIndex` and need to be reversed when used with dune-functions
algorithms. See SizeProviderAdapter for more details on this.

### Computation of sizes

The comuptation of sizes should be thought as an inverse of the
ContainerIndex transformation. For a ContainerIndex suffix, it traverses
the tree top to bottom. Since the ContainerIndex encodes the ordering path
to an leaf node by either adding an offset or by appending a tree path, the
calculation on each node consumes the last index of the suffix in
the same way as it was created, and tries to find an offset range where
such index is contained. Once this range is found, the tree path down the
tree may be reconstrcted or the size of the offset range may be returned if
all indices where consumed.

@see SizeProviderAdapter
@see MultiIndex
@see DOFIndex

Enumeration Type Documentation

◆ MultiIndexOrder

enum class Dune::PDELab::MultiIndexOrder
strong

Information about order semantics on multi-indices.

Enumerator
Inner2Outer 

indices are ordered from inner to outer container: {inner,...,outer}

Outer2Inner 

indices are ordered from outer to inner container: {outer,...,inner}

Creative Commons License   |  Legal Statements / Impressum  |  Hosted by TU Dresden  |  generated with Hugo v0.111.3 (Nov 12, 23:30, 2024)