dune-functions merge requestshttps://gitlab.dune-project.org/staging/dune-functions/-/merge_requests2024-05-28T06:46:13Zhttps://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/476Remove old protocol from the 2014 meeting in Aachen2024-05-28T06:46:13ZOliver Sanderoliver.sander@tu-dresden.deRemove old protocol from the 2014 meeting in AachenThis is just a set of notes, which I think is not of value
to anyone anymore.
@carsten.graeser, @christi ,@simon.praetorius , please approve or disapprove.
If we decide to keep the file I will fix the spelling.This is just a set of notes, which I think is not of value
to anyone anymore.
@carsten.graeser, @christi ,@simon.praetorius , please approve or disapprove.
If we decide to keep the file I will fix the spelling.https://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/475Add SPDX license information2024-05-29T09:02:59ZOliver Sanderoliver.sander@tu-dresden.deAdd SPDX license informationhttps://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/474Draft: [bug][draft] Switch poisson-pq2.py to triangle grid2024-05-03T12:32:29ZCarsten Gräsergraeser@math.fau.deDraft: [bug][draft] Switch poisson-pq2.py to triangle gridThis implements the following changes:
* Add a gmsh coarse grid file consisting of two triangles
on the unit square.
* Load and refine the grid in `poisson-pq2.py`.
* Add some debug output to `poisson-pq2.py`.
When using the ...This implements the following changes:
* Add a gmsh coarse grid file consisting of two triangles
on the unit square.
* Load and refine the grid in `poisson-pq2.py`.
* Add some debug output to `poisson-pq2.py`.
When using the grid, the example fails with a segfault.
This does not come from the assembler, but from the
boundary treatment code that is generated from C++.
Adding debug output reveals that here the basis
provides buggy global indices. In fact even the
number of elements is not correct here.https://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/472add 3d monomial basis2024-06-14T07:11:42ZMaik Porrmannadd 3d monomial basisAdds 3d implementation of the monomialbasis and Hessians for `dim = 1,...,3`.Adds 3d implementation of the monomialbasis and Hessians for `dim = 1,...,3`.https://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/470Add new function class MonomialSet<K,dim,n>2024-04-16T07:05:14ZCarsten Gräsergraeser@math.fau.deAdd new function class MonomialSet<K,dim,n>This implements all `dim`-variate monomials up to order `n`
as components of a vector-valued differentiable functions.
Currently this is only specialized for order `dim=1` and `dim=2`.
The implementation was extracted from the test `Cub...This implements all `dim`-variate monomials up to order `n`
as components of a vector-valued differentiable functions.
Currently this is only specialized for order `dim=1` and `dim=2`.
The implementation was extracted from the test `CubicHermiteBasis` and adjusted to model the differentiable function interface.https://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/468Add a vector factory based on the container descriptors2024-04-12T14:07:46ZSimon PraetoriusAdd a vector factory based on the container descriptors- [ ] Requires https://gitlab.dune-project.org/core/dune-istl/-/merge_requests/563 to be merged before.- [ ] Requires https://gitlab.dune-project.org/core/dune-istl/-/merge_requests/563 to be merged before.https://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/467Draft: Add container descriptor for blocked-interleaved index-merging strategy2024-04-11T16:23:30ZSimon PraetoriusDraft: Add container descriptor for blocked-interleaved index-merging strategyhttps://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/456[python] Use the same default index merging strategies as C++2024-03-04T15:17:22ZOliver Sanderoliver.sander@tu-dresden.de[python] Use the same default index merging strategies as C++Using composite or power nodes in C++ yields blocked multi-indices by default. So far, however, the Python interface used *flat* indices by default. This violates the Principle of Least Surprise, and there this commit changes the Pytho...Using composite or power nodes in C++ yields blocked multi-indices by default. So far, however, the Python interface used *flat* indices by default. This violates the Principle of Least Surprise, and there this commit changes the Python defaults to match those of the C++ interface.
To make the tests pass even with the new defaults, this MR also implements the `size` methods of `DefaultGlobalBasis`.https://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/451[python] Do not export dimRange as a property of function space bases2024-03-04T08:14:00ZOliver Sanderoliver.sander@tu-dresden.de[python] Do not export dimRange as a property of function space basesThe C++ interface doesn't have it, either.The C++ interface doesn't have it, either.https://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/450Draft: Separate the stokes assembling from the definition of the bases2024-03-01T09:05:47ZSimon PraetoriusDraft: Separate the stokes assembling from the definition of the basesIn order to have a uniform implementation of multiple different stable Stokes bases, I want to separate the assembling code from the definition of the basis. This is extracted from !435 that introduces bases with bubble functions to defi...In order to have a uniform implementation of multiple different stable Stokes bases, I want to separate the assembling code from the definition of the basis. This is extracted from !435 that introduces bases with bubble functions to define, for example, a MINI element or a `P2b+P1^disc` basis.
### ToDo
- [ ] Check that the documentation of the Stokes example can be generated properly.https://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/448Draft: Add RangeType deduction for basis trees2024-02-29T12:11:25ZSimon PraetoriusDraft: Add RangeType deduction for basis treeshttps://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/439[draft] Add ElementGeometryGridFunction2024-01-29T14:37:49ZCarsten Gräsergraeser@math.fau.de[draft] Add ElementGeometryGridFunctionThis maps any point `x` to a tuple consisting of
the element, it's geometry, and the local coordinate
of the point.
While this function is not very helpful on its own,
it allows to implement grid functions representing
geometric mesh pr...This maps any point `x` to a tuple consisting of
the element, it's geometry, and the local coordinate
of the point.
While this function is not very helpful on its own,
it allows to implement grid functions representing
geometric mesh properties with very little effort
by composition. E.g. `FaceNormalGridFunction` could
be implemented as
```cpp
auto computeFaceNormal = [](auto arg)
{
const auto& [element, geometry, x] = arg;
auto&& re = Dune::referenceElement(geometry);
// Compute reference normal of closest face to given point
auto face = Dune::Functions::Impl::closestFaceIndex(re, x);
auto localNormal = re.integrationOuterNormal(face);
// Transform reference normal into global unit outer normal using
// covariant Piola transformation
using Range = typename GridView::template Codim<0>::Entity::Geometry::GlobalCoordinate;
auto normal = Range{};
geometry.jacobianInverseTransposed(x).mv(localNormal, normal);
normal /= normal.two_norm();
return normal;
};
auto normal = Dune::Functions::makeComposedGridFunction(computeFaceNormal, Dune::Functions::ElementGeometryGridFunction(gridView));
```
Similarly one could implement element circumference, maximal edge length, ... .https://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/435Draft: Hierarchical Lagrange basis with element bubble function2024-03-20T17:25:09ZSimon PraetoriusDraft: Hierarchical Lagrange basis with element bubble function### Summary
Similar to the HierarchicalLagrangeBasis there is a hierarchical basis with element bubble functions implemented in dune-localfunctions. This MR makes this available to dune-functions and implements the Stokes problem with a ...### Summary
Similar to the HierarchicalLagrangeBasis there is a hierarchical basis with element bubble functions implemented in dune-localfunctions. This MR makes this available to dune-functions and implements the Stokes problem with a combination of P2+B3 for the velocity and discontinuous P1 for the pressure.
### Requirements
- [x] Need https://gitlab.dune-project.org/core/dune-localfunctions/-/merge_requests/257 to be merged beforehttps://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/427Draft: Check whether basis still works after modifying the grid view2024-01-26T09:17:59ZOliver Sanderoliver.sander@tu-dresden.deDraft: Check whether basis still works after modifying the grid viewWhen the grid view has changed, calling Basis::update(gridView)
should make the basis adapt to the new grid view. However, this was
never tested, and several basis implementation indeed do it wrong.
This commit extends the general basis...When the grid view has changed, calling Basis::update(gridView)
should make the basis adapt to the new grid view. However, this was
never tested, and several basis implementation indeed do it wrong.
This commit extends the general basis test for a test for this
updating mechanism.https://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/421Draft: Linear transformed finite elements2024-04-15T13:20:44ZMaik PorrmannDraft: Linear transformed finite elementsThis MR is a draft on how non affine equivalent (or non Piola equivalent) finite elements can be structurally implemented in dune-functions. In particular, it introduces a structure for linear transformed FEs, which require an additional...This MR is a draft on how non affine equivalent (or non Piola equivalent) finite elements can be structurally implemented in dune-functions. In particular, it introduces a structure for linear transformed FEs, which require an additional element dependend transformation of the generic reference FE to provide an - element depended - local FE which is affine (Piola) equivalent to the real FE. All finite element types, where the polynomial space is preserved under the resp. pullback, can in principle be implemented in this manner.
This MR also contains implementations of the cubic Hermite, ~~quadratic Morley, quintic Argyris and cubic Arnold-Winther~~ finite elements on triangles. ~~While the first one can be implemented reasonably well with the GlobalValuedLocalFiniteElement structure, the others profit strongly from caching the transformation and the last one even uses both structures as it is a non Piola equivalent element.~~
The approach follows the theory from [Kirby 2018](https://arxiv.org/abs/1706.09017) and [Kirby 2021](https://arxiv.org/abs/2110.13224).
The previous development happend in a separate [module](https://gitlab.dune-project.org/maik.porrmann/dune-c1elements), which also contains the dune-localfunctions part. ~~This MR depends on the dune-localfunctions [MR](https://gitlab.dune-project.org/core/dune-localfunctions/-/merge_requests/253)~~.
Together these two MRs raise a number of questions, like:
* How to handle interpolation with FEs that involve derivative evaluations as DOFs? See also [dune-function issue](https://gitlab.dune-project.org/staging/dune-functions/-/issues/76)
* How to encode that some finite elements cannot be cached?
* How to collect and pass nonlocal information to `LocalFiniteElements`?
* Are the generic FEs, like in this MR, meaningful in dune-localfunctions or should they be kept together with their transformations?
* How to implement matrix-valued finite elements and what are the precise `LocalFiniteElementTraits`?
* How to ensure a global orientation on a distributed
The following is a copy of the mentioned modules Readme:
This module contains classes for the Hermite (1d-3d), the Morley (2d), the Argyris(2d), and the Arnold-Winther element on simplices. It covers both dune-localfunctions and dune-functions aspects and thus mimics their directory structure. Additionally, the compatibility with the AMDiS module is provided in the `amdis/` directory. All of those finite elements are not affine (Piola) equivalent and thus require an additional transformation when mapped onto the reference element. This approach follows the theory developed by Kirby for the fenicsx/firedrake framework. For this theory, finite elements are grouped by the behavior of their degrees of freedom when pulled back onto the reference element. In short, assuming the polynomial space is preserved under pullback, the physical dofs are either
1. mapped onto the reference dofs. This gives affine (Piola) equivalence and no transformation is necessary.
1. mapped onto dofs whose span equals the span of the reference dofs (as infinite dimensional functionals). Then we have no affine (Piola) equivalence and a linear transformation of the basis functions is necessary. This Transformation is just the transposed of the basis transformation of the dofs. However, we have affine (Piola) interpolation equivalence, which means that we can implement the local interpolation via the inverse of the mentioned basis transformation.
1. mapped onto a set of DOFs, whose span does not equal to the span of reference dofs. So long as we have unisolvence however, the span on the restrictions of the DOFs to the polynomial space is equal to the span of the restrictions of the reference dofs to the reference polynomial space and we can still derive a linear transformation like before. Again, the transformation of the basis functions is just the transposed the transformation of the dof restrictions. In this case however, we have no interpolation equivalence and cannot use the reference dofs to implement a local interpolation that can be used to determine coefficients of the physical finite element.
This behavior is modeled by a class structure `LinearTransformedLocalFiniteElement` similar to the `GlobalValuedLocalFiniteElement` structure, with corresponding classes `LinearTransformedLocalBasis`, etc. It is parametrized with a class that fulfills the `LinearTransformator` interface, which is essentially a objectified transformation class. This interface is defined as follows:
* Like other objects in the dune-functions world, `LinearTransformator` objects need to be bound to an element to be useful.
* The actual transformation is done by a call to the `apply` method. In the current implementation the interface has only one `apply` method, which should be used for shapevalues, gradients and hessians, since a basis transformation is essentially the same for all of those types.
* Since different aspects like orientation and determination of boundary condition dofs require nonlocal information, the structure includes a `ElementInformation` interface, to be implemented by a class exported by the `LinearTransformator`.
* Lastly, the interpolation is handled differently, depending on the type of finite element as described above. For finite elements of type (2), i.e. interpolation equivalent finite elements, the `LinearTransformator` class can implement an `applyInverse` method. The framework then provides a corresponding `LocalInterpolation` class. For finite elements of type (3), the `LinearTransformator` class needs to export a class `GlobalValuedInterpolation`, which can be bound to the `Element` and `ElementInformation` objects and additonally fulfills the `LocalIntepolation` interface.
Extensions of the `LocalFiniteElement` interface for Hermite/Morley/Argyris elements:
* The first three finite elements include derivative degrees of freedom, and so their `LocalIntepolation` classes only work with functions which provide a free `derivative` method. A proposal implementation of dune-functions' `interpolate` method is contained in the module.
* Strongly enforcing boundary conditions requires setting a subset of boundary dofs. Typical routines like the ones in the examples don't consider that. The `LocalCoefficient` classes for the three finite elements thus offer an additional method to question whether a dof is in the respective subset for Dirichlet or Clamped conditions. Discretization modules that want to include this functionality thus have to include them in their corresponding routines.https://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/415[bugfix] A fix interpolate and evaluateJacobian in ReducedCubicHermite^^^2023-02-27T10:07:59ZCarsten Gräsergraeser@math.fau.de[bugfix] A fix interpolate and evaluateJacobian in ReducedCubicHermite^^^https://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/397Draft: Feature/reduced cubic hermite basis2023-08-18T12:48:11ZKlaus BöhnleinDraft: Feature/reduced cubic hermite basisAdd a new basis for reduced cubic hermite Triangles.Add a new basis for reduced cubic hermite Triangles.Klaus BöhnleinKlaus Böhnleinhttps://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/390Draft: Make maxNodeSize a static information if possible2022-12-20T18:17:57ZSimon PraetoriusDraft: Make maxNodeSize a static information if possibleIt might be helpful to have the `maxNodeSize` as static information, e.g., to choose corresponding static data structures. This is not always possible and thus not a requirement, but if possible the function should be `static constexpr`.It might be helpful to have the `maxNodeSize` as static information, e.g., to choose corresponding static data structures. This is not always possible and thus not a requirement, but if possible the function should be `static constexpr`.https://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/378Draft: Introduce c++20 concepts2022-10-21T16:48:49ZSimon PraetoriusDraft: Introduce c++20 concepts(This MR is for experimenting with C++20 concepts and far from ready to be merged)
### Summary
Replace the C++17 concept-workarounds `Dune::Concept::models<...>` by proper c++20 concepts and replace all `enable_if` SFINAE statements by ...(This MR is for experimenting with C++20 concepts and far from ready to be merged)
### Summary
Replace the C++17 concept-workarounds `Dune::Concept::models<...>` by proper c++20 concepts and replace all `enable_if` SFINAE statements by `requires` clauses.
### Discussion
- Tested locally with clang-16. We need a proper toolchain for more recent compilers supporting concepts.
- I don't see any improvement of compile-times by this change in code
- The definition of a basis-tree in terms of concepts is difficult, since we need recursion that is not allowed in concept definitions. Any ideas?https://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/351WIP: Experimental replacement of typetree2022-02-18T09:27:08ZSimon PraetoriusWIP: Experimental replacement of typetree## Summary
This is an experiment to replace the old structures in dune-typetree with a new type-tree implementation more similar to the TreeContainer, i.e., a composition of `std::array`, `std::tuple` and `std::vector`.
See also https:/...## Summary
This is an experiment to replace the old structures in dune-typetree with a new type-tree implementation more similar to the TreeContainer, i.e., a composition of `std::array`, `std::tuple` and `std::vector`.
See also https://gitlab.dune-project.org/staging/dune-typetree/-/merge_requests/111