dune-geometry issueshttps://gitlab.dune-project.org/core/dune-geometry/-/issues2024-01-23T12:20:23Zhttps://gitlab.dune-project.org/core/dune-geometry/-/issues/36Recent "cleanup" breaks code in dune-fem.2024-01-23T12:20:23ZRobert KRecent "cleanup" breaks code in dune-fem.A recent "cleanup" merge !235 breaks code in dune-fem (removal of header include in a MR that says doxygen fixes).
Apparently, a deprecated header is used and there never was any warning that this should not be done anymore. This is ex...A recent "cleanup" merge !235 breaks code in dune-fem (removal of header include in a MR that says doxygen fixes).
Apparently, a deprecated header is used and there never was any warning that this should not be done anymore. This is exactly these cases where the merging person has to have more overview on the code and in general some common sense.https://gitlab.dune-project.org/core/dune-geometry/-/issues/11Add strongly typed dynamic codim and subentity indentifiers2018-01-16T16:11:19ZCarsten Gräsergraeser@math.fau.deAdd strongly typed dynamic codim and subentity indentifiersWe already have `Codim<i>` to statically wrap a codimension into a type because
this makes code much more readable. However, there are several places where a
codimension or a subentity (codimension+index) is specified dynamically
(e.g. i...We already have `Codim<i>` to statically wrap a codimension into a type because
this makes code much more readable. However, there are several places where a
codimension or a subentity (codimension+index) is specified dynamically
(e.g. in `ReferenceElement`, `IndexSet`). All these places suffer from
readability because they use plane indices, e.g. `referenceElement::subEntity(i,j,k,l)`.
Code using this functionality would be much more readable and less error prone,
if we use strong types to encode dynamic codimension or subentity information.
A quick (but functional) prototype is attached, where all functionality is provided by global functions:
[referenceelementutility.hh](/uploads/86b6b4d6d0051243bc01358842ad481f/referenceelementutility.hh)
The prototype also contains a helper that returns a range with the result of `ReferenceElement::subEntity(i,j,k,l)` for fixed `i,j,l` and all suitable `i` (guess what `i` is ;-) ). This is IMHO a big improvement because you normally need the whole range anyway. Being able to ask for individual values gives the false impression of subsubentity consistency of the grid and the reference elements. This misconception leads to many discussions and people continue to ask for this or report (false) bugs.
As an example, marking all boundary vertices using this prototype could be implemented as follows:
```cpp
const auto& indexSet = gridView.indexSet();
for(const auto& element: elements(gridView))
for(const auto& intersection: intersections(gridView, element))
if (intersection.boundary())
for(const auto& vertex: subVertices(referenceElement(element), insideFacet(intersection)))
isBoundary[subIndex(indexSet, element, vertex)] = true;
```