dune-grid issueshttps://gitlab.dune-project.org/core/dune-grid/-/issues2023-10-02T15:41:54Zhttps://gitlab.dune-project.org/core/dune-grid/-/issues/181GridFactory should export element permutation2023-10-02T15:41:54ZSimon PraetoriusGridFactory should export element permutation### Summary
When creating a grid using a grid factory, the element numbering put into the factory is not necessarily the numbering ending up in the created grid, e.g. `ALUGrid` performs some renumbering - I think to guarantee that the gr...### Summary
When creating a grid using a grid factory, the element numbering put into the factory is not necessarily the numbering ending up in the created grid, e.g. `ALUGrid` performs some renumbering - I think to guarantee that the grid can always be refined by bisection afterwards. This renumbering is not directly exported but is required for some applications, e.g., when we also have stored a finite element basis associated to the local vertices, or a geometry mapping. While we have the `insertionIndex` of elements and vertices we can compute the element permutation afterwards, but one always has to think about this again how to do it without comparing coordinates.
1. Is there an easy way to extract this permutation that I am simply not aware of?
2. Would this be a useful interface extension of the `GridFactory` or better a utility next to it?https://gitlab.dune-project.org/core/dune-grid/-/issues/45Move hasBoundaryIntersections to GridView2017-08-30T15:52:35ZMartin NolteMove hasBoundaryIntersections to GridViewCurrently, having intersections with the boundary is a property of an entity. On the other hand, handling intersections between neighboring entities or between entities and the boundary has be delegated to the GridView. This leads to the...Currently, having intersections with the boundary is a property of an entity. On the other hand, handling intersections between neighboring entities or between entities and the boundary has be delegated to the GridView. This leads to the following type of code snipped:
```
for( const auto &entity : elements( gridView ) )
{
if( entity.hasBoundaryIntersections() )
for( const auto &intersection : intersections( gridView, entity ) )
{
if( !intersection.boundary() )
continue;
// do something here
}
}
```
There are two problems with this approach:
- Effectively, this forces the entity to know about the boundary of the domain, e.g., by knowing the grid. This is somewhat counterintuitive.
- The grid might perform an intersection loop to implement `hasBoundaryIntersections`, just to save a loop over all intersections. This is a waste of performance.
To remedy these issues, I suggest to introduce a method
```
bool GridView::mightHaveBoundaryIntersections( const Entity & ) const
```
which returns false if and only if the entity does not have an intersection with the boundary on that grid view. Always returning `true` is a conforming implementation.
As a side effect, this also allows to write a grid view which introduces internal boundaries without wrapping the Entity and, hence, nearly all classes of the grid interface.https://gitlab.dune-project.org/core/dune-grid/-/issues/29Method idSet::subId is not forwarded for arbitrary codimension2017-08-30T15:52:35ZMartin NolteMethod idSet::subId is not forwarded for arbitrary codimensionCurrently, there is an asymmetry in the inferface for index sets and id sets: IndexSet::subIndex may be implemented for entities of arbitrary codimension, while the IdSet interface only forwards subId codim-0 entities.
Unfortunately, si...Currently, there is an asymmetry in the inferface for index sets and id sets: IndexSet::subIndex may be implemented for entities of arbitrary codimension, while the IdSet interface only forwards subId codim-0 entities.
Unfortunately, simply adding the corresponding subId method the usual way will break grid implementations (they would have to implement subId< cc > instead of subId). Therefore, this issue is related to #28.https://gitlab.dune-project.org/core/dune-grid/-/issues/28Strange signatures for IndexSet and IdSet methods taking an entity2017-08-30T15:52:35ZMartin NolteStrange signatures for IndexSet and IdSet methods taking an entityIndexSet and IdSet have implement (nearly) all methods taking an entity twice, e.g.,
```
Index index ( const Entity &entity ) const
{
return index< Entity::codimension >( entity );
}
template< int cc >
Index index ( const type...IndexSet and IdSet have implement (nearly) all methods taking an entity twice, e.g.,
```
Index index ( const Entity &entity ) const
{
return index< Entity::codimension >( entity );
}
template< int cc >
Index index ( const typename GridImp::template Codim< cc >::Entity &entity ) const
{
return asImp().index< cc >( entity );
}
```
The implementation then only implements the method `index< cc >`. This has the downside, that the implementation has to use IndexSet::index to provide the first version, if not casted down to the interface.
As far as I know, the purpose of this technique is to ensure the type `Entity` coinsides with `typename GridImp::template Codim< cc >::Entity`. Today, this could also be done by an SFINAE:
```
template< class Entity , std::enable_if_t< std::is_same< Entity, typename GridImp::template Codim< Entity::codimension >::Entity >::value, int > = 0 >
Index index ( const Entity &entity ) const
{
asImp().index( entity );
}
```
This way, the interface would still protect the method `index` from being called with a wrong entity type.
I propose to use the SFINAE version, here. However, this will break implementations, unless we use another SFINAE trick to detect the implementation (and use proper deprecation).