Core Modules issueshttps://gitlab.dune-project.org/groups/core/-/issues2017-04-07T14:32:14Zhttps://gitlab.dune-project.org/core/dune-grid/-/issues/22In UGGrid: EntitySeed of Entities with codim=1 not possible2017-04-07T14:32:14ZSimon PraetoriusIn UGGrid: EntitySeed of Entities with codim=1 not possibleUsing UGGrid, a simple code that attempts to extract entity-seeds for sub-entities of elements, fails to compile:
```c++
UGGrid<2> grid(...); // initialize grid
for (auto const& e : edges(grid.leafGridView())) {
auto s = e.seed();
...Using UGGrid, a simple code that attempts to extract entity-seeds for sub-entities of elements, fails to compile:
```c++
UGGrid<2> grid(...); // initialize grid
for (auto const& e : edges(grid.leafGridView())) {
auto s = e.seed();
}
```
Error message (in g++-5.4):
```
uggridentity.hh:301:57: error: no matching function for call to 'EntitySeed<const UGGrid<2>, UGGridEntitySeed<1, const UGGrid<2> > >::EntitySeed(const UGEdgeEntity<2, const UGGrid<2> >&)
```
The problem lies in the class hierarchy of `UGGridEntity` and `UGEdgeEntity`, i.e.
```c++
template<class GridImp>
class UGGridEntity<1,2,GridImp> : public UGEdgeEntity<2,GridImp> {...}
```
and an `UGGridEntitySeed` that expects an `UGGridEntity`:
```c++
template<int codim, class GridImp>
class UGGridEntitySeed
{
UGGridEntitySeed(const UGGridEntity<codim, GridImp::dimension, GridImp>& entity) {...}
};
```
Maybe a solution could be to replace the class hierarchy by something like a typedef:
```c++
template<int codim, int dim, class GridImp>
class UGGridEntityDefault {...};
template<int dim, class GridImp>
class UGEdgeEntity {...};
namespace aux {
template<int codim, int dim, class GridImp>
struct UGGridEntity {
using type = UGGridEntityDefault<codim,dim,GridImp>;
};
template<class GridImp>
struct UGGridEntity<1,2,GridImp> {
using type = UGEdgeEntity<2,GridImp>;
};
} // end namespace aux
template<int codim, int dim, class GridImp>
using UGGridEntity = typename aux::UGGridEntity<codim, dim, GridImp>::type;
```
(but I do not seed possible implications of such a change)https://gitlab.dune-project.org/core/dune-grid/-/issues/23Common interface for grid-readers2021-07-04T11:25:08ZSimon PraetoriusCommon interface for grid-readersWhen comparing the various file-readers for different grids, e.g. albertareader, gmshreader, starcdreader, amirameshreader, ..., I've noticed that every reader has a different api, different methods to call, with different signatures. So...When comparing the various file-readers for different grids, e.g. albertareader, gmshreader, starcdreader, amirameshreader, ..., I've noticed that every reader has a different api, different methods to call, with different signatures. Sometimes this makes sense (e.g. if a reader provides additional data to be extracted from the grid), sometimes it is just irritating and not necessary, e.g.
```c++
void AlbertaReader::readGrid(const std::string& fileName, Dune::GridFactory<Grid>& factory);
static Grid* StartCDReader::read(const std::string& fileName, bool=true);
static Grid* GmshReader::read(const std::string& fileName, bool=true, bool=true);
static void GmshReader::read(Dune::GridFactory<Grid>& factory, const std::string& fileName, bool=true, bool=true);
static Grid* AmiraMeshReader::read(const std::string& filename);
static void AmiraMeshReader::read(Grid& grid, const std::string& filename);
```
`AlbertaReader` has a non-static method and expects a filename and a factory, whereas all other mentioned readers provide static methods and work with a filename alone (creating a factory internally). `GmshReader` provides a read method, that takes a factory, but compared to `AlbertaReader` the arguments are exchanged. In `AmiraMeshReader` instead of a factory, the grid itself must be passed to the method. And finally in `AlbertaReader` the method has a different name than all the other readers.
I propose to *define* a common interface that all readers should implement, but is allowed to be extended:
```c++
static Grid* Reader::read(const std::string& fileName, bool verbose = true);
static void Reader::read(Dune::GridFactory<Grid>& factory, const std::string& fileName, bool verbose = true);
```
Maybe the `verbose` parameter can be removed in the common interface.
All the readers above can easily be modified to conform with this common interface.https://gitlab.dune-project.org/core/dune-istl/-/issues/21Unexpected behaviour of BCRSMatrix implict buildmode2017-09-22T04:19:36ZCarsten Gräsergraeser@math.fau.deUnexpected behaviour of BCRSMatrix implict buildmodeThe behaviour of the implicit build mode is in several ways unexpected and does not fit its documentation:
* (a) In contrast to the documentation, the allocated overflow area is not used while filling the matrix in favour of a separate `...The behaviour of the implicit build mode is in several ways unexpected and does not fit its documentation:
* (a) In contrast to the documentation, the allocated overflow area is not used while filling the matrix in favour of a separate `std::map`.
* (b) The allocated overflow area does always contain `4*avg` more entries than expected.
* (c) The given `avg` value is not really related to average row sizes. If you give the exact average, `compres()` may fail if the overflow size is zero.
* (d) The allocated overflow area is in fact used to balance the mismatch between the given `avg` value and rows having more entries than this.
* (e) `compress()` may fail depending on the row order: The following will fail for `row=0` but succeed for `row=5`
```cpp
using M = Dune::BCRSMatrix<Dune::FieldMatrix<double,1,1>>;
M m(6, 6, 1, 0.0, M::implicit);
for(std::size_t i=0; i<6; ++i)
m.entry(row,i) = i;
m.compress();
```
Explanation for this behaviour: When allocating storage, this is partitioned into the overflow area followed by `avg` reserved entries per row.
When more than `avg` entries are used in a row, they are stored in an additional `std::map`. On `compress()` all entries are shifted forward towards the first
free position, inserting intermediate entries from the overflow map when necessary. This explains, why early rows cannot have more than `avg`+`overflow`
entries, while later ones may consume remaining space left by preceding less populated rows.
Due to (a) there is a possible fix for several of those problems. Before compressing forward with insertion of overflow entries, one can compress backwards
without this insertion. This would solve (c)-(e) at the price of an additional shifting operation. Even more, this would allow to compute the number of non-zeros in the
first sweep and than allocate new storage if the overflow was to small instead of throwing an exception and letting the user assemble all entries again with a hopefully better guess.https://gitlab.dune-project.org/core/dune-istl/-/issues/22Allocator template parameter of classes without memory management2018-05-16T08:58:47ZCarsten Gräsergraeser@math.fau.deAllocator template parameter of classes without memory managementSeveral classes in bvector.hh and basearray.hh have an allocator template parameter but don't do any memory management. This is true for
`base_array_unmanaged`, `base_array_window`, `compressed_base_array_unmanaged`, `block_vector_unma...Several classes in bvector.hh and basearray.hh have an allocator template parameter but don't do any memory management. This is true for
`base_array_unmanaged`, `base_array_window`, `compressed_base_array_unmanaged`, `block_vector_unmanaged`, `BlockVectorWindow`, `compressed_block_vector_unmanaged`, `CompressedBlockVectorWindow`.https://gitlab.dune-project.org/core/dune-grid/-/issues/24Remove method index<cc> and subIndex<cc> from IndexSet2018-01-15T15:13:10ZMartin NolteRemove method index<cc> and subIndex<cc> from IndexSetThe index set currently provides the index and subIndex methods twice:
template< class Entity >
Index index ( const Entity &e ) const
template< int codim >
Index index ( const typename Grid::template Codim< codim >::Entity &e ) const
...The index set currently provides the index and subIndex methods twice:
template< class Entity >
Index index ( const Entity &e ) const
template< int codim >
Index index ( const typename Grid::template Codim< codim >::Entity &e ) const
Of course, both methods do the same thing. The second version simply checks the type of entity. We have better checks for this now, e.g.:
template< class Entity, std::enable_if_t< std::is_same< Entity, typename Grid::template Codim< Entity::codimension >::Entity >::value, int > = 0>
Index index ( const Entity &e ) const
I think dropping the second form (maybe in favor of the third) would clarify the interface for the user.https://gitlab.dune-project.org/core/dune-common/-/issues/42DUNE 2.5 release2017-05-25T21:04:49ZAnsgar Burchardtansgar.burchardt@tu-dresden.deDUNE 2.5 releaseOliver and me propose to do a 2.5 release of DUNE before the end of the year to have a recent version of DUNE in the next Debian release.
Also for other users, we believe a new release makes it easier to support both the last stable rel...Oliver and me propose to do a 2.5 release of DUNE before the end of the year to have a recent version of DUNE in the next Debian release.
Also for other users, we believe a new release makes it easier to support both the last stable release and the current master of DUNE in external modules as the build system changed significantly since 2.4.
The release will be managed by @ansgar and @oliver.sander.
Our current rough plan is to create a release branch mid-October and plan for a first release candidate early November.
If required, this will be followed by a second release candidate mid-November.
The final release will then take place either mid-November or early-December (in case of two release candidates).
All issues and merge requests that should be included in DUNE 2.5 should be assigned to the "DUNE 2.5.0" milestone (once this is setup).
However, we will not delay the release if there are minor issues that are not dealt with in time.
We plan to also release the module in staging at the same time.DUNE 2.5.0https://gitlab.dune-project.org/core/dune-geometry/-/issues/9Redesign of quadrature rules2021-07-12T20:49:35ZSimon PraetoriusRedesign of quadrature rulesCurrently there are some different ways where and how quadrature rules are defined and implemented. We have 1d rules, generated by *Maxima* scripts `xxx.mac` from analytic multi-precision expressions, using a template for the `InitHelper...Currently there are some different ways where and how quadrature rules are defined and implemented. We have 1d rules, generated by *Maxima* scripts `xxx.mac` from analytic multi-precision expressions, using a template for the `InitHelper` class, provided in two ways, values as double and values as string. We have simplex quadrature rules, provided as double values and manually listed in the `SimplexQuadratureRule` up to *low* order. And there are tensor-product rules constructed from lower dimensional rules, e.g. a tensor-product of 1d rules for all dimensions. These can be transformed to other geometries than cubes, resulting in very expensive rules (many points).
This is the current status. I propose a redesign of these rules: First of all, except for the 1d rules (and correspondingly the tensor-product rules based on these 1d rules) all rules must be provided as tabulated values of coordinates and quadrature weights. It is really difficult to write down analytic expressions for higher order rules on arbitrary geometry elements. Every few years a research group therefor publishes a new set of rules for a specific geometry, that may be better in the sense of symmetry of complexity, compared to older rules.
- To extend our quadrature rules frequently it would be nice to have a way to generate an implementation directly from **tabulated values**
- Providing **high precision** rules in text format allows to generate rules for any data type (up to the printed precision)
- There are tools available to extend the precision of quadrature rules (preserving symmetry constraints), based on tabulated values.
Thus, I propose to add a "library" of tabulated quadrature rules for all our geometry types and a converter (similar to the one implemented in the Maxima script for 1d) that **generates rules in a uniform way**. Additionally I propose to implement the rules using a **string representation of the values** and a string-to-float converter, like `std::stringstream` to generate the concrete values on construction of the quadrature rule. Rules are implemented as singleton, thus a construction takes place only one and the additional performance consts are negligible.
The tabulated values should be given in a defined format, e.g.
```
# optional comment lines, to add reference to the publications where the rules were found
dim order
x0 y0 z0 weight0
x1 y1 z1 weight1
```
(see a set of rules in `utility/rules`) 1d rules can be generated using the Maxima-Script as before, but saved in this tabulated format instead of generating c++ code directly.
I have already implemented a generator, based on *Mako* python templates (see `utility/make_rules.py`, but it can simply be implemented in any language. The main difficulty is, that every publication provides values in a different format, for a different reference geometry, in barycentric coordinates or local coordinates, or .... Thatwhy I have additionally implemented a conversion script to read values given from a publication for one reference element and transform it to the Dune reference element and coordinate format.
This is a follow up issue of issue #6 . See the merge request !27.
## Update
### Discussion from Dune Developer Meeting 2017
- all agree that the proposed changes are nice, as long as Simon does the changes
- the MR should be split up into smaller parts
- it is still up for discussion, which intermediate format one should use
- it is a good idea to only use string representations and generate instances of float like data from this string representation
- in a future version it should be possible to honor further properties of a quadrature rule
### Workflow
- [x] Cleanup of quadrature rules (see !138)
- [ ] Return coefficients by cast from string representation (see !175)
- [ ] Tabulation of quadrature rules
It was discussed whether to provide the tabulation in a way that other libraries can benefit from.
**Suggestion:** I create a new dune module `dune-quadrature` that is responsible for the tabulation of quadrature rules and provides generator functions to produce C++ source files that can be included in `dune-geometry` directly.https://gitlab.dune-project.org/core/dune-grid/-/issues/25UGGrid does not implement subIndex method for entities other than elements2018-01-15T15:13:10ZOliver Sanderoliver.sander@tu-dresden.deUGGrid does not implement subIndex method for entities other than elementsThis makes the tightened tests from !87 (and its improved version !89) fail.This makes the tightened tests from !87 (and its improved version !89) fail.DUNE 2.5.0Oliver Sanderoliver.sander@tu-dresden.deOliver Sanderoliver.sander@tu-dresden.dehttps://gitlab.dune-project.org/core/dune-common/-/issues/43äser2017-05-25T21:04:49ZCarsten Gräsergraeser@math.fau.deäserhttps://gitlab.dune-project.org/core/dune-grid/-/issues/26Introduce `hasEntityIterator` capability2017-10-31T10:59:54ZCarsten Gräsergraeser@math.fau.deIntroduce `hasEntityIterator` capabilityAt the DUNE Developer Meeting 2013 it was decided to implement a capability `hasEntityIterator`. This still needs to be implemented
Reference: http://users.dune-project.org/projects/dev-meeting-2013/wiki/Protocol#SubEntity-of-all-co-dim...At the DUNE Developer Meeting 2013 it was decided to implement a capability `hasEntityIterator`. This still needs to be implemented
Reference: http://users.dune-project.org/projects/dev-meeting-2013/wiki/Protocol#SubEntity-of-all-co-dimensionsDUNE 3.0.0https://gitlab.dune-project.org/core/dune-common/-/issues/44Hybrid::switchCases is not tested2023-02-01T11:04:05ZOliver Sanderoliver.sander@tu-dresden.deHybrid::switchCases is not testedThere is no unit test for Hybrid::switchCases. It would be nice to have it, to show people how to use it.There is no unit test for Hybrid::switchCases. It would be nice to have it, to show people how to use it.Carsten Gräsergraeser@math.fau.deCarsten Gräsergraeser@math.fau.de2017-11-24https://gitlab.dune-project.org/core/dune-common/-/issues/45ifElse cannot (always) contain a 'return' statement2024-02-22T15:29:37ZOliver Sanderoliver.sander@tu-dresden.deifElse cannot (always) contain a 'return' statementThe following code snippet fails to compile
bool foo = true;
Hybrid::ifElse(foo, [&](auto id)
{
return 0;
});
Reason: this is turned into a run-time if-then-else construct, with else clause being an empty lambda [...The following code snippet fails to compile
bool foo = true;
Hybrid::ifElse(foo, [&](auto id)
{
return 0;
});
Reason: this is turned into a run-time if-then-else construct, with else clause being an empty lambda [&}(auto id){}
(in hybridutilitites.hh:356. There, the if-branch returns int, and the else-branch returns void, and the compiler
doesn't like it.
I think this can be fixed by having a separate implementation of ifElse-without-an-else-clause.https://gitlab.dune-project.org/core/dune-common/-/issues/46Race condition in Dune::Singleton::instance()2017-05-25T21:04:49ZJö Fahlkejorrit@jorrit.deRace condition in Dune::Singleton::instance()In https://gitlab.dune-project.org/flyspray/FS/issues/1718#note_20700 @carsten.graeser asks whether `Dune::Singleton` is thread-safe. So I had a look, and it is not thread-safe.
From [singleton.hh](dune/common/singleton.hh)
```c++
...In https://gitlab.dune-project.org/flyspray/FS/issues/1718#note_20700 @carsten.graeser asks whether `Dune::Singleton` is thread-safe. So I had a look, and it is not thread-safe.
From [singleton.hh](dune/common/singleton.hh)
```c++
DUNE_EXPORT static T& instance()
{
/* Smartpointer to the instance. */
static std::unique_ptr<T> instance_;
if(instance_.get() == 0)
instance_ = std::unique_ptr<T>(new T());
return *instance_;
}
```
There is a chance for two threads to enter `instance()` concurrently. Then there is a reader-writer-race between one thread's `instance_.get()` and the other thread's `instance = ...`, and a writer-writer race between both threads' `instance = ...` if this is the first time the instance method was called.
A better way to achieve the same thing is:
```c++
DUNE_EXPORT static T& instance()
{
static T instance_;
return instance_;
}
```
In this case the compiler ensures that the constructor for the `instance_` variable is called only once. If multiple threads enter `instance()` concurrently, one of them will invoke the constructor, while the others will wait. If the constructor throws, one of the waiting threads will retry it, until one of them succeeds. Once the constructor succeeds, the compiler will mark the variable as initialized and any threads still waiting (and any later invocation of `instance()` will skip the constructor call. The effect is as if the constructor call is wrapped in a `std::call_once()`, with the `once_flag` argument automatically supplied by the compiler.
If the constructor of `T` is simple enough, the compiler may even be able to do static initialization, and skip the synchronization needed for the implicit call_once altogether.https://gitlab.dune-project.org/core/dune-grid/-/issues/27Edges in parallel UG are broken2022-12-14T07:21:51ZCarsten Gräsergraeser@math.fau.deEdges in parallel UG are brokenWhen compiled in parallel mode the edges in a parallel dune-uggrid are broken. More specifically: In a 3d grid obtained from successive local refinement of a simplex the leaf grid contains edges that have a non-trivial intersection. E.g....When compiled in parallel mode the edges in a parallel dune-uggrid are broken. More specifically: In a 3d grid obtained from successive local refinement of a simplex the leaf grid contains edges that have a non-trivial intersection. E.g. they intersect in a point that is neither a vertex of one or the other edge. When compiled in sequential mode this does not happen. Moreover, the number of total edges is larger in parallel mode while the number of elements, faces, and vertices is the same. One can also observe, that the centers of the elements are different.
The attached example demonstrates the issue: [uggrid-failure.cc](/uploads/201efaeb424959aba738377a0c248683/uggrid-failure.cc) . It works nicely when dune is set to sequential mode and the edge count is different.
I was unsure if this should be files here or for dune-uggrid. Since I have a vague memory that UG does not provide edges by itself and that they are implemented in the dune bindings I picked dune-grid.DUNE 2.7.0https://gitlab.dune-project.org/core/dune-istl/-/issues/23Performance of `compressed_base_array_unmanaged::operator[]`2017-09-22T04:19:36ZTobias MalkmusPerformance of `compressed_base_array_unmanaged::operator[]`In one of my applications the operator[] access to the array entries takes up to 5 % of total run-time.
If i comment the index check out i gain this 5% run-time improvement.
I would suggest the two options:
1) use preprocessor dir...In one of my applications the operator[] access to the array entries takes up to 5 % of total run-time.
If i comment the index check out i gain this 5% run-time improvement.
I would suggest the two options:
1) use preprocessor directives to (de-)activate the checks:
```
if (lb == j+n || *lb != i)
DUNE_THROW(ISTLError,"index "<<i<<" not in compressed array");
```
2) implement `at(size_type i)` which includes the index checks and operator[] returns without checking.
The first option seems to be a little more 'dune-istl' like and less invasive, while the second one is similar to the behavior of a `std::vector`.https://gitlab.dune-project.org/core/dune-common/-/issues/47Almost everyhing is convertible into a `DenseMatrix`2017-05-25T21:04:49ZTobias MalkmusAlmost everyhing is convertible into a `DenseMatrix`I figured out that `std::is_convertible< ..., DenseMatrix< ... > >::value` is true for huge range of types.
See also the attached test: [fmatrix.cc](/uploads/03d7c889d4c5391dc4c3a2e8ab181b91/fmatrix.cc)I figured out that `std::is_convertible< ..., DenseMatrix< ... > >::value` is true for huge range of types.
See also the attached test: [fmatrix.cc](/uploads/03d7c889d4c5391dc4c3a2e8ab181b91/fmatrix.cc)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).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/30test-ug does not build with clang, due to Hybrid::ifElse weirdness2017-04-07T14:32:04ZOliver Sanderoliver.sander@tu-dresden.detest-ug does not build with clang, due to Hybrid::ifElse weirdnesstest-ug builds fine with gcc. However, if fails to build with both clang-3.6 and clang-3.8.
Here's how far I got: in uggridindexsets.hh:75 there is a code block
Hybrid::ifElse(Std::bool_constant<cc==0>(), [&](auto id)
...test-ug builds fine with gcc. However, if fails to build with both clang-3.6 and clang-3.8.
Here's how far I got: in uggridindexsets.hh:75 there is a code block
Hybrid::ifElse(Std::bool_constant<cc==0>(), [&](auto id)
{
[...]
result = UG_NS<dim>::levelIndex(UG_NS<dim>::GetEdge(UG_NS<dim>::Corner(grid_->getRealImplementation(e).getTarget(), // ***
UGGridRenumberer<dim>::verticesDUNEtoUG(a,e.type())),
UG_NS<dim>::Corner(grid_->getRealImplementation(e).getTarget(),
UGGridRenumberer<dim>::verticesDUNEtoUG(b,e.type()))));
}
});
The cc==0 condition is static, therefore this code should really only be instantiated when cc==0. However, clang barfs at the line *** when the case cc==1 is tested. I attach the error message below.
@carsten.graeser , as you wrote the Hybrid::ifElse, could you please have a look? Thanks!
In file included from /home/sander/dune/dune-grid/dune/grid/test/test-ug.cc:14:
In file included from /home/sander/dune/dune-grid/dune/grid/uggrid.hh:125:
/home/sander/dune/dune-grid/dune/grid/uggrid/uggridindexsets.hh:86:84: error: cannot initialize a parameter of
type 'const UG_NS<2>::Element *' (aka 'const UG::D2::element *') with an rvalue of type 'typename
UG_NS<2>::Entity<codim>::T *' (aka 'UG::D2::edge *')
...grid_->getRealImplementation(e).getTarget(),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/sander/dune/dune-grid/dune/grid/common/indexidset.hh:178:31: note: in instantiation of function template
specialization 'Dune::UGGridLevelIndexSet<const Dune::UGGrid<2> >::subIndex<1>' requested here
return asImp().template subIndex< cc >( e, i, codim );
The error by itself is okay when cc==1, that is why a static if is used.DUNE 2.5.0https://gitlab.dune-project.org/core/dune-grid/-/issues/31Add periodic tests for yaspgrid2017-08-30T15:52:35ZChristian EngwerAdd periodic tests for yaspgridWe merged !3, but Dominik suggested to add additional tests for periodic yaspgrid. These are currently in the code, but not enable, as something (please ask @dominic) still needs to be cleaned up.We merged !3, but Dominik suggested to add additional tests for periodic yaspgrid. These are currently in the code, but not enable, as something (please ask @dominic) still needs to be cleaned up.