dune-functions merge requestshttps://gitlab.dune-project.org/staging/dune-functions/-/merge_requests2019-05-31T14:03:39Zhttps://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/189WIP: Generalize backend conversion functions.2019-05-31T14:03:39ZMax Kahntmax.kahnt@fu-berlin.deWIP: Generalize backend conversion functions.Collect the local helper lambdas as proper free functions.
Make them understand vectors that are wrapped in shared_ptr.
This adds typeutilities for `shared_ptr` which is the main reason why this MR is tagged as WIP.Collect the local helper lambdas as proper free functions.
Make them understand vectors that are wrapped in shared_ptr.
This adds typeutilities for `shared_ptr` which is the main reason why this MR is tagged as WIP.https://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/187Avoid copying GridViewFunctions passed as references.2018-12-11T09:20:00ZMax Kahntmax.kahnt@fu-berlin.deAvoid copying GridViewFunctions passed as references.This avoids creating copies for GridViewFunctions passed as references.This avoids creating copies for GridViewFunctions passed as references.https://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/181WIP: Make geometry type handling more flexible2018-12-21T12:48:36ZCarsten Gräsergraeser@math.fau.deWIP: Make geometry type handling more flexibleThis implements three features: `StaticGeometryType`, `LagrangeFiniteElementCache`, and `GeometryTypeProviders`. Together they allow to avoid the polymorphic local finite element interface if either the grid only supports a single geomet...This implements three features: `StaticGeometryType`, `LagrangeFiniteElementCache`, and `GeometryTypeProviders`. Together they allow to avoid the polymorphic local finite element interface if either the grid only supports a single geometry type, or if you explicitly know that it only contains a single geometry type.
### `StaticGeometryType`
This encodes all the information of a `GeometryType` as template
parameters. Some remarks on the implementation:
* This may be a solution for using geometry types a template paremters
and is thus a candidate for dune-geometry
* All methods in `Dune::GeometryTypes::` have analogues in
`Dune::Functions::StaticGeometryTypes::` and additional template
aliases for parametrized types. Hence you can e.g. use Simplex<dim>.
* There is `LocalHybridGeometryTypeIndex` which works like `LocalGeometryTypeIndex`
but supports `GeometryType` and `StaticGeometryType`.
* Some topologyIds are different: If you want to overload for specific
`StaticGeometryType`s, you must be sure that the same geometry type
leads to the same type. Hence topologyIds are normalize to have 0
in the first bit.
* One may consider using `uniqueTopologyId = (topologyId >> 1)` as
template parameter instead to get rid of the nasty non-uniqueness.
### `LagrangeFiniteElementCache`
This works like `PQkFiniteElementCache` in dune-localfunctions
but also allows to obtain raw fe-implemenations without polymorphic
wrapper if the geometry type is provided statically as `StaticGeometryType`.
This allows to seamlessly switch between the polymorphic and non-polymorphic
version by using `GeometryType` or `StaticGeometryType`.
### `GeometryTypeProviders`
These allow to map an entity to its geometry type. Depending on the
selected provider and grid view, this is encoded as `GeometryType` or
`StaticGeometryType`. There are several implementations:
* `MixedGeometryTypeProvider` will always act like a mixed element
grid and simply forward the dynamic `GeometryType`. You'd normally
not want to use this one.
* `AutoGeometryTypeProvider` will use a `StaticGeometryType` if the grid
satisfies `hasSingleGeometryType()`. Otherwise `GeometryType` is used.
This is the default choise which should work always.
* `SimplexGeometryTypeProvider` and `CubeGeometryTypeProvider` will
always provide the corresponding `StaticGeometryType`. This can be used
to avoid the costly polymorphic interface if your grid supports mixed
elements, but you know, that there are only simplices or cubes.https://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/128WIP: Implement PersistentGridView2021-09-21T15:41:35ZCarsten Gräsergraeser@math.fau.deWIP: Implement PersistentGridViewThis caches any accessed index lazily. The grid
view only implements indices but no iteration
because this is not needed for the intended use:
Create a persistent version of a basis that
survives grid modifications in order to inter...This caches any accessed index lazily. The grid
view only implements indices but no iteration
because this is not needed for the intended use:
Create a persistent version of a basis that
survives grid modifications in order to interpolate
solutions to a refined grid. Notice that this approach
is non-intrusive, i.e. the bases don't have to be adjusted,
but simply work, on the `PersistentGridView`, as long as they
only rely on the provided feature set.https://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/101Dynamic order DG basis2018-07-04T21:24:33ZLasse Hinrichsen-Bischofflh1887@mi.fu-berlin.deDynamic order DG basisThis is an implementation of a Discontinous Galerkin (DG) basis that supports (element-wise) varying local finite elements. In particular, one can set the local polynomial degree at runtime.
Currently, this is only fully implemented for ...This is an implementation of a Discontinous Galerkin (DG) basis that supports (element-wise) varying local finite elements. In particular, one can set the local polynomial degree at runtime.
Currently, this is only fully implemented for a Qk basis, but most parts should be interchangeable:
- The `DynamicDGPreBasis` is quite universal, one has to modify the `Node`
- The `DynamicOrderNode` takes a `Cache` template parameter. This cache gives local FE which are asked for _by order_.
- The `DynamicOrderLocalFiniteElementCache` implements such a cache taking another `Factory` which produces the actual finite element (so if you want different elements, say, e.g., Gauss-Lobatto, you only need to provide a suitable factory and change the template parameter)
If you need a more general `Node` (e.g. to deal with varying geometries (which are assumed to be uniform in the `DynamicOrderNode`)), you'd have to implement a node similar to the given one. However, I can't make the Node type a template parameter of the `DynamicDGPreBasis` (which would be cleaner) as the nodes needs also a `TreePath` template argument itself which I do not know beforehand. However, aside from the hardcoded `Node` type (and the form of its constructor), the pre-basis does not make any further Qk-specific assumptions as far as I can see.
I haven't tested this too broadly, yet (before this, I used another implementation which made more assumptions), so comments and tests are highly appreciated. Also, if things can be done better or differently, I'm open for comments.
Cosmetic things I see that maybe should be discussed:
- the whole `DynamicFooBar` class naming scheme
- code spread through three different header