Core Modules issueshttps://gitlab.dune-project.org/groups/core/-/issues2018-11-16T11:47:54Zhttps://gitlab.dune-project.org/core/dune-istl/-/issues/55Bug: Detecting isolated/dirichlet nodes in AMG2018-11-16T11:47:54ZNils-Arne DreierBug: Detecting isolated/dirichlet nodes in AMGIn the `pre` method of the AMG I found the following code:
[amg.hh](https://gitlab.dune-project.org/core/dune-istl/blob/a932af5ebd807d461fe8b7ac8752d1ef32706a87/dune/istl/paamg/amg.hh#L573)
```c++
for(RowIter row=mat.begin(); row!=mat.e...In the `pre` method of the AMG I found the following code:
[amg.hh](https://gitlab.dune-project.org/core/dune-istl/blob/a932af5ebd807d461fe8b7ac8752d1ef32706a87/dune/istl/paamg/amg.hh#L573)
```c++
for(RowIter row=mat.begin(); row!=mat.end(); ++row) {
bool isDirichlet = true;
bool hasDiagonal = false;
Block diagonal;
for(ColIter col=row->begin(); col!=row->end(); ++col) {
if(row.index()==col.index()) {
diagonal = *col;
hasDiagonal = false;
}else{
if(*col!=zero)
isDirichlet = false;
}
}
if(isDirichlet && hasDiagonal)
diagonal.solve(x[row.index()], b[row.index()]);
}
```
I guess `hasDiagonal` should be set to `true`, if the diagonal entry has been found? Otherwise the last `if` would never match?!https://gitlab.dune-project.org/core/dune-common/-/issues/108Dedication for Elias2017-12-14T10:00:14ZJö Fahlkejorrit@jorrit.deDedication for EliasJust to make sure we don't forget.
See http://lists.dune-project.org/pipermail/dune-devel/2017-October/002291.html. The way the changelogs work now, it should probably go into dune-common's CHANGELOG.md in the top of the 2.6 section.Just to make sure we don't forget.
See http://lists.dune-project.org/pipermail/dune-devel/2017-October/002291.html. The way the changelogs work now, it should probably go into dune-common's CHANGELOG.md in the top of the 2.6 section.DUNE 2.6.0https://gitlab.dune-project.org/core/dune-common/-/issues/97deprecate `Dune::Std::make_unique`2019-07-08T12:59:00ZAnsgar Burchardtansgar.burchardt@tu-dresden.dedeprecate `Dune::Std::make_unique``std::make_unique` is part of C++14. So the DUNE-specific implementation for older compilers could be deprecated (at least for DUNE 2.7).`std::make_unique` is part of C++14. So the DUNE-specific implementation for older compilers could be deprecated (at least for DUNE 2.7).DUNE 2.7.0https://gitlab.dune-project.org/core/dune-common/-/issues/83Clean up our type_traits headers (again)2021-08-18T08:50:19ZSteffen Müthingsteffen.muething@iwr.uni-heidelberg.deClean up our type_traits headers (again)While putting together some of the trickery required for the revised reference elements, I got to take a look at our headers with type traits again and noticed a few things:
- ~~It's unfortunate that `void_t` is in `dune/common/typetrai...While putting together some of the trickery required for the revised reference elements, I got to take a look at our headers with type traits again and noticed a few things:
- ~~It's unfortunate that `void_t` is in `dune/common/typetraits.hh` and not in `dune/common/std/type_traits.hh`. It's also not in `Dune::Std`. Can we still move it?~~ (This isn't really worth it, see !464)
- We have again duplicated a bunch of functionality, with `Dune::AlwaysTrue<T>` vs. `Dune::Std::to_true_type<T>` and the corresponding `false` versions. Should we get rid of one of them?
- [X] \(!393) For 2.5, we added the type trait `Dune::Std::is_callable` along the lines of N4446, but C++17 did instead get `std::is_invocable` and `std::is_invocable_r` (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0604r0.html for the (slightly arcane, but understandable from the EWG point of view) reasoning). This is not just a rename, the committee also changed the syntax by replacing the encoding of the arguments, going from the function-call-like `is_callable<F(Args...),R>` to a more traditional `is_invocable<F,Args...>`. The website listed above gives a good reason for that change. So the question is: What do we do with our implementation? Do we deprecate it and replace it with a fallback implementation of `std::is_invocable`? If we do that, do we also add `std::invoke_result`?
- I don't get `IsInteroperable<T1,T2>` and related `EnableIfInterOperable<T1,T2,U>`. Apart from the naming inconsistency, it checks for a really weird thing:
`is_convertible_v<T1,T2> or is_convertible_v<T2,T1>`. With a quick grep, I could only find it in the iterator facades. And there, it will lead to a compiler error if only one of the two conversions is valid. I'm in favor of deprecating it.
- `is_indexable` can be simplified quite a bit with our improved compiler requirements. I'll take care of that.
- [x] \(!466) The combination of `CamelCase` and `stl_like` syntax is probably here to stay, even though it might be good to use `CamelCase` for our own utilities and `stl_like` for standard library backports.https://gitlab.dune-project.org/core/dune-common/-/issues/61`isfinite`, `isnan`, `isinf`, `isunordered` for vectors2018-06-07T10:28:49ZAnsgar Burchardtansgar.burchardt@tu-dresden.de`isfinite`, `isnan`, `isinf`, `isunordered` for vectorsC++ has `isfinite`, `isnan`, `isinf`, `isunordered`.
It would be nice to have an overload (`Dune::is*`) for `FieldVector` and `BlockVector` which implement the appropriate version for vector types (where all components have to be finite,...C++ has `isfinite`, `isnan`, `isinf`, `isunordered`.
It would be nice to have an overload (`Dune::is*`) for `FieldVector` and `BlockVector` which implement the appropriate version for vector types (where all components have to be finite, any component is nan, ...). (One can use the standard functions on the norm, but having `isfinite(x)` for a vector `x` is nicer in my opinion.)
Ideally they should also work for `FieldVector<std::complex<...>, ...>`; the standard functions don't work for complex numbers either.https://gitlab.dune-project.org/core/dune-grid/-/issues/49Remove the file entitypointer.hh2017-04-07T14:32:03ZOliver Sanderoliver.sander@tu-dresden.deRemove the file entitypointer.hhThe EntityPointer class has been removed from the grid interface and from most implementations. However, the file entitypointer.hh is still there, and needs to be removed.The EntityPointer class has been removed from the grid interface and from most implementations. However, the file entitypointer.hh is still there, and needs to be removed.https://gitlab.dune-project.org/core/dune-grid/-/issues/43Deprecation of ForLoop causes deprecation warnings in grid tests2017-04-07T14:32:03ZMartin NolteDeprecation of ForLoop causes deprecation warnings in grid testsThe grid tests still make use of the (now deprecated) ForLoop. This causes annoying deprecation warnings. Example:
```
Scanning dependencies of target test-spgrid-2
[ 50%] Building CXX object dune/grid/test/CMakeFiles/test-spgrid-2.di...The grid tests still make use of the (now deprecated) ForLoop. This causes annoying deprecation warnings. Example:
```
Scanning dependencies of target test-spgrid-2
[ 50%] Building CXX object dune/grid/test/CMakeFiles/test-spgrid-2.dir/test-spgrid.cc.o
In file included from /home/nolte/numerics/master-py/dune-grid/dune/grid/utility/persistentcontainermap.hh:10:0,
from /home/nolte/numerics/master-py/dune-grid/dune/grid/utility/persistentcontainer.hh:8,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/spgrid/persistentcontainer.hh:6,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/spgrid.hh:7,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/test/test-spgrid.cc:12:
/home/nolte/numerics/master-py/dune-common/dune/common/forloop.hh:4:2: warning: #warning The header dune/common/forloop.hh is deprecated. Use directly "Hybrid::forEach" and include dune/common/hybridutilities.hh. [-Wcpp]
#warning The header dune/common/forloop.hh is deprecated. Use directly "Hybrid::forEach" and include dune/common/hybridutilities.hh.
^~~~~~~
In file included from /home/nolte/numerics/master-py/dune-grid/dune/grid/test/checkgeometry.hh:9:0,
from /home/nolte/numerics/master-py/dune-grid/dune/grid/test/gridcheck.hh:24,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/test/test-spgrid.cc:15:
/home/nolte/numerics/master-py/dune-common/dune/common/forloop.hh:4:2: warning: #warning The header dune/common/forloop.hh is deprecated. Use directly "Hybrid::forEach" and include dune/common/hybridutilities.hh. [-Wcpp]
#warning The header dune/common/forloop.hh is deprecated. Use directly "Hybrid::forEach" and include dune/common/hybridutilities.hh.
^~~~~~~
In file included from /home/nolte/numerics/master-py/dune-grid/dune/grid/test/checkentityseed.hh:11:0,
from /home/nolte/numerics/master-py/dune-grid/dune/grid/test/gridcheck.hh:25,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/test/test-spgrid.cc:15:
/home/nolte/numerics/master-py/dune-common/dune/common/forloop.hh:4:2: warning: #warning The header dune/common/forloop.hh is deprecated. Use directly "Hybrid::forEach" and include dune/common/hybridutilities.hh. [-Wcpp]
#warning The header dune/common/forloop.hh is deprecated. Use directly "Hybrid::forEach" and include dune/common/hybridutilities.hh.
^~~~~~~
In file included from /home/nolte/numerics/master-py/dune-grid/dune/grid/test/checkiterators.hh:8:0,
from /home/nolte/numerics/master-py/dune-grid/dune/grid/test/checkintersectionit.hh:14,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/test/test-spgrid.cc:16:
/home/nolte/numerics/master-py/dune-common/dune/common/forloop.hh:4:2: warning: #warning The header dune/common/forloop.hh is deprecated. Use directly "Hybrid::forEach" and include dune/common/hybridutilities.hh. [-Wcpp]
#warning The header dune/common/forloop.hh is deprecated. Use directly "Hybrid::forEach" and include dune/common/hybridutilities.hh.
^~~~~~~
In file included from /home/nolte/numerics/master-py/dune-grid/dune/grid/test/checkpartition.hh:13:0,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/test/test-spgrid.cc:19:
/home/nolte/numerics/master-py/dune-common/dune/common/forloop.hh:4:2: warning: #warning The header dune/common/forloop.hh is deprecated. Use directly "Hybrid::forEach" and include dune/common/hybridutilities.hh. [-Wcpp]
#warning The header dune/common/forloop.hh is deprecated. Use directly "Hybrid::forEach" and include dune/common/hybridutilities.hh.
^~~~~~~
In file included from /home/nolte/numerics/master-py/dune-grid/dune/grid/utility/persistentcontainer.hh:8:0,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/spgrid/persistentcontainer.hh:6,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/spgrid.hh:7,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/test/test-spgrid.cc:12:
/home/nolte/numerics/master-py/dune-grid/dune/grid/utility/persistentcontainermap.hh: In member function ‘void Dune::PersistentContainerMap<G, IdSet, Map>::resize(const Value&)’:
/home/nolte/numerics/master-py/dune-grid/dune/grid/utility/persistentcontainermap.hh:88:14: warning: ‘template<template<int <anonymous> > class Operation, int first, int last> struct Dune::ForLoop’ is deprecated [-Wdeprecated-declarations]
return ForLoop< Resize, 0, Grid::dimension >::apply( *this, value );
^~~~~~~
In file included from /home/nolte/numerics/master-py/dune-grid/dune/grid/utility/persistentcontainermap.hh:10:0,
from /home/nolte/numerics/master-py/dune-grid/dune/grid/utility/persistentcontainer.hh:8,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/spgrid/persistentcontainer.hh:6,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/spgrid.hh:7,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/test/test-spgrid.cc:12:
/home/nolte/numerics/master-py/dune-common/dune/common/forloop.hh:19:62: note: declared here
struct DUNE_DEPRECATED_MSG("Use Hybrid::forEach instead!") ForLoop
^~~~~~~
In file included from /home/nolte/numerics/master-py/dune-grid/dune/grid/test/gridcheck.hh:24:0,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/test/test-spgrid.cc:15:
/home/nolte/numerics/master-py/dune-grid/dune/grid/test/checkgeometry.hh: In member function ‘void Dune::GeometryChecker<Grid>::checkGeometry(const Dune::GridView<VT>&)’:
/home/nolte/numerics/master-py/dune-grid/dune/grid/test/checkgeometry.hh:137:11: warning: ‘template<template<int <anonymous> > class Operation, int first, int last> struct Dune::ForLoop’ is deprecated [-Wdeprecated-declarations]
ForLoop<SubEntityGeometryChecker,0,GridView<VT>::dimension>
^~~~~~~
In file included from /home/nolte/numerics/master-py/dune-grid/dune/grid/utility/persistentcontainermap.hh:10:0,
from /home/nolte/numerics/master-py/dune-grid/dune/grid/utility/persistentcontainer.hh:8,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/spgrid/persistentcontainer.hh:6,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/spgrid.hh:7,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/test/test-spgrid.cc:12:
/home/nolte/numerics/master-py/dune-common/dune/common/forloop.hh:19:62: note: declared here
struct DUNE_DEPRECATED_MSG("Use Hybrid::forEach instead!") ForLoop
^~~~~~~
In file included from /home/nolte/numerics/master-py/dune-grid/dune/grid/test/gridcheck.hh:25:0,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/test/test-spgrid.cc:15:
/home/nolte/numerics/master-py/dune-grid/dune/grid/test/checkentityseed.hh: In function ‘void Dune::checkEntitySeed(const Dune::GridView<VT>&, std::ostream&)’:
/home/nolte/numerics/master-py/dune-grid/dune/grid/test/checkentityseed.hh:212:5: warning: ‘template<template<int <anonymous> > class Operation, int first, int last> struct Dune::ForLoop’ is deprecated [-Wdeprecated-declarations]
ForLoop< CheckEntitySeed::IfHasEntitySeed, 0, dimension >::apply( gridView, output );
^~~~~~~
In file included from /home/nolte/numerics/master-py/dune-grid/dune/grid/utility/persistentcontainermap.hh:10:0,
from /home/nolte/numerics/master-py/dune-grid/dune/grid/utility/persistentcontainer.hh:8,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/spgrid/persistentcontainer.hh:6,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/spgrid.hh:7,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/test/test-spgrid.cc:12:
/home/nolte/numerics/master-py/dune-common/dune/common/forloop.hh:19:62: note: declared here
struct DUNE_DEPRECATED_MSG("Use Hybrid::forEach instead!") ForLoop
^~~~~~~
In file included from /home/nolte/numerics/master-py/dune-grid/dune/grid/test/checkintersectionit.hh:14:0,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/test/test-spgrid.cc:16:
/home/nolte/numerics/master-py/dune-grid/dune/grid/test/checkiterators.hh: In static member function ‘static void CheckIterators<GridView>::apply(const GridView&)’:
/home/nolte/numerics/master-py/dune-grid/dune/grid/test/checkiterators.hh:58:11: warning: ‘template<template<int <anonymous> > class Operation, int first, int last> struct Dune::ForLoop’ is deprecated [-Wdeprecated-declarations]
Dune::ForLoop< CheckCodim, 1, GridView::dimension >::apply( gridView );
^~~~~~~
In file included from /home/nolte/numerics/master-py/dune-grid/dune/grid/utility/persistentcontainermap.hh:10:0,
from /home/nolte/numerics/master-py/dune-grid/dune/grid/utility/persistentcontainer.hh:8,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/spgrid/persistentcontainer.hh:6,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/spgrid.hh:7,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/test/test-spgrid.cc:12:
/home/nolte/numerics/master-py/dune-common/dune/common/forloop.hh:19:62: note: declared here
struct DUNE_DEPRECATED_MSG("Use Hybrid::forEach instead!") ForLoop
^~~~~~~
In file included from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/test/test-spgrid.cc:19:0:
/home/nolte/numerics/master-py/dune-grid/dune/grid/test/checkpartition.hh: In static member function ‘static void CheckPartitionType<GridView, pitype>::apply(const GridView&)’:
/home/nolte/numerics/master-py/dune-grid/dune/grid/test/checkpartition.hh:110:11: warning: ‘template<template<int <anonymous> > class Operation, int first, int last> struct Dune::ForLoop’ is deprecated [-Wdeprecated-declarations]
Dune::ForLoop< CheckCodim, 0, GridView::dimension >::apply( gridView );
^~~~~~~
In file included from /home/nolte/numerics/master-py/dune-grid/dune/grid/utility/persistentcontainermap.hh:10:0,
from /home/nolte/numerics/master-py/dune-grid/dune/grid/utility/persistentcontainer.hh:8,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/spgrid/persistentcontainer.hh:6,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/spgrid.hh:7,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/test/test-spgrid.cc:12:
/home/nolte/numerics/master-py/dune-common/dune/common/forloop.hh:19:62: note: declared here
struct DUNE_DEPRECATED_MSG("Use Hybrid::forEach instead!") ForLoop
^~~~~~~
In file included from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/test/test-spgrid.cc:19:0:
/home/nolte/numerics/master-py/dune-grid/dune/grid/test/checkpartition.hh: In constructor ‘CheckPartitionDataHandle<GridView, iftype>::CheckPartitionDataHandle(const GridView&)’:
/home/nolte/numerics/master-py/dune-grid/dune/grid/test/checkpartition.hh:242:11: warning: ‘template<template<int <anonymous> > class Operation, int first, int last> struct Dune::ForLoop’ is deprecated [-Wdeprecated-declarations]
Dune::ForLoop< Contains, 0, dimension >::apply( contains_ );
^~~~~~~
In file included from /home/nolte/numerics/master-py/dune-grid/dune/grid/utility/persistentcontainermap.hh:10:0,
from /home/nolte/numerics/master-py/dune-grid/dune/grid/utility/persistentcontainer.hh:8,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/spgrid/persistentcontainer.hh:6,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/spgrid.hh:7,
from /home/nolte/numerics/master-py/dune-spgrid/dune/grid/test/test-spgrid.cc:12:
/home/nolte/numerics/master-py/dune-common/dune/common/forloop.hh:19:62: note: declared here
struct DUNE_DEPRECATED_MSG("Use Hybrid::forEach instead!") ForLoop
^~~~~~~
[100%] Linking CXX executable test-spgrid-2
[100%] Built target test-spgrid-2
```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-grid/-/issues/16Implement free functions `leafGridView(grid)` and `levelGridView(grid, level)`2017-04-07T14:32:14ZAnsgar Burchardtansgar.burchardt@tu-dresden.deImplement free functions `leafGridView(grid)` and `levelGridView(grid, level)`At the [last developer meeting](http://users.dune-project.org/projects/dune-developer-meeting-2015/wiki/Protocol) it was decided to implement free functions `leafGridView(grid)` and `levelGridView(grid, level)` (7.1.3).
At the [last developer meeting](http://users.dune-project.org/projects/dune-developer-meeting-2015/wiki/Protocol) it was decided to implement free functions `leafGridView(grid)` and `levelGridView(grid, level)` (7.1.3).
DUNE 3.0.0https://gitlab.dune-project.org/core/dune-common/-/issues/26clean up accidential merge of !162017-06-05T05:56:09ZJö Fahlkejorrit@jorrit.declean up accidential merge of !16When merging the simple documentation fix !70 I accidentially merged !16 too. This issue is for coming up with any bright idea how to clean this up.When merging the simple documentation fix !70 I accidentially merged !16 too. This issue is for coming up with any bright idea how to clean this up.Jö Fahlkejorrit@jorrit.deJö Fahlkejorrit@jorrit.dehttps://gitlab.dune-project.org/core/dune-common/-/issues/22Requested cmake version not sufficient for target_compile_definitions2017-06-05T05:56:09ZMarkus BlattRequested cmake version not sufficient for target_compile_definitionsWith master I get the following configure error with cmake version 2.8.9
```
CMake Error at cmake/modules/DuneTestMacros.cmake:225 (target_compile_definitions):
Unknown CMake command "target_compile_definitions".
Call Stack (most r...With master I get the following configure error with cmake version 2.8.9
```
CMake Error at cmake/modules/DuneTestMacros.cmake:225 (target_compile_definitions):
Unknown CMake command "target_compile_definitions".
Call Stack (most recent call first):
dune/common/parallel/test/CMakeLists.txt:1 (dune_add_test)
```
https://gitlab.dune-project.org/core/dune-grid/-/issues/10`Mapper::size` & `IndexSet::size` should return size_t (or some unsigned type)2021-01-21T22:02:59ZAnsgar Burchardtansgar.burchardt@tu-dresden.de`Mapper::size` & `IndexSet::size` should return size_t (or some unsigned type)The `Mapper::size` method currently returns `int`, but I think it should return a `size_t` (or some other unsigned type) similar to `std::vector::size`.
I'm also wondering if `IndexSet::size` should also return a `size_t` instead of `...The `Mapper::size` method currently returns `int`, but I think it should return a `size_t` (or some other unsigned type) similar to `std::vector::size`.
I'm also wondering if `IndexSet::size` should also return a `size_t` instead of `IndexType`? It's not returning an index after all.DUNE 3.0.0https://gitlab.dune-project.org/core/dune-common/-/issues/20Dune::real_t conflicts with metis/parmetis::real_t2017-06-05T05:56:09ZTobias MalkmusDune::real_t conflicts with metis/parmetis::real_tThis causes the headercheck to fail for header `dune-grid/dune/grid/utility/parmetisgridpartitioner.hh`
This bug can also be triggered by trying to compile:
```c++
#include <config.h>
#include <parmetis.h>
#include <dune/common/type...This causes the headercheck to fail for header `dune-grid/dune/grid/utility/parmetisgridpartitioner.hh`
This bug can also be triggered by trying to compile:
```c++
#include <config.h>
#include <parmetis.h>
#include <dune/common/typetraits.hh>
namespace Dune
{
real_t d;
}
int main ()
{
return 0;
}
```https://gitlab.dune-project.org/core/dune-grid/-/issues/5Memory Leak in AmiraMeshReader::readFunction2017-04-07T14:32:14ZJonathan YouettMemory Leak in AmiraMeshReader::readFunctionThe internal AmiraMesh object is created on the heap but not deallocated after the routine finishes.
The attached patch fixes this.
Best
Jonny [0001-Fix-memory-leak-in-readFunction.patch](/uploads/073ddedcf3d2b164b0855b53b23b062e/00...The internal AmiraMesh object is created on the heap but not deallocated after the routine finishes.
The attached patch fixes this.
Best
Jonny [0001-Fix-memory-leak-in-readFunction.patch](/uploads/073ddedcf3d2b164b0855b53b23b062e/0001-Fix-memory-leak-in-readFunction.patch)
https://gitlab.dune-project.org/core/dune-common/-/issues/13Deprecate Dune::array2018-12-23T09:43:36ZElias PippingDeprecate Dune::arrayIt seems that `std::array` can now be assumed to exist so that `Dune::array` is no longer necessary? This seems consistent with e.g. pdelab/dune-pdelab!62. At the same time, `Dune::array` is currently not even deprecated as far as I can ...It seems that `std::array` can now be assumed to exist so that `Dune::array` is no longer necessary? This seems consistent with e.g. pdelab/dune-pdelab!62. At the same time, `Dune::array` is currently not even deprecated as far as I can tell and still used in `dune/geometry/genericgeometry/referenceelements.hh`.
If nobody objects, I'd like to go ahead, deprecate the class and replace the (single) remaining use of Dune::array in the core modules (through `std::array`).DUNE 2.6.02017-11-10https://gitlab.dune-project.org/core/dune-common/-/issues/11istl_assign_to_fmatrix is broken2017-06-05T05:56:11ZElias Pippingistl_assign_to_fmatrix is brokenI'm trying to break up issue #5 into manageable pieces here.
It's currently apparently meant to be possible to construct a `DenseMatrix` from a C-style matrix through the function `istl_assign_to_fmatrix` defined in densematrix.hh.
...I'm trying to break up issue #5 into manageable pieces here.
It's currently apparently meant to be possible to construct a `DenseMatrix` from a C-style matrix through the function `istl_assign_to_fmatrix` defined in densematrix.hh.
One can use the function directly or through `DenseMatrix::operator=` and thus also in the `FieldMatrix` copy constructor. All of this will compile and is apparently supposed to:
```c++
double sourceMatrix23[2][3] = { { 0, 1, 2 }, { 3, 4, 5 } };
{
Dune::FieldMatrix<double, 2, 3> const targetMatrix = sourceMatrix23;
}
{
Dune::FieldMatrix<double, 2, 3> targetMatrix;
targetMatrix = sourceMatrix23;
}
{
Dune::FieldMatrix<double, 2, 3> targetMatrix;
istl_assign_to_fmatrix(targetMatrix, sourceMatrix23);
}
{
Dune::DynamicMatrix<double> targetMatrix(2, 3);
targetMatrix = sourceMatrix23;
}
{
Dune::DynamicMatrix<double> targetMatrix(2, 3);
istl_assign_to_fmatrix(targetMatrix, sourceMatrix23);
}
```
None of this does anything reasonable at runtime, though. If you look at the implementation, i.e.
```c++
template< class DenseMatrix, class K, int N, int M >
void istl_assign_to_fmatrix ( DenseMatrix &denseMatrix, const K (&values)[ M ][ N ] )
{
for( int i = 0; i < N; ++i )
for( int j = 0; j < M; ++j )
denseMatrix[ i ][ j ] = values[ i ][ j ];
}
```
you will see that when the signature matches a `double[2][3]`, it is actually treated as a `double[3][2]` in the body of the loop. With assertions enabled, the program will fail to run because it'll try to write to the entry `[2][0]` of the target matrix, which does not exist.
For a square matrix, the implementation is fine as-is. The fix here is obvious. The question is: Since it seems nobody out there is using this functionality (and it might have made more sense in a time before initializer lists): Is it maybe appropriate to remove the function entirely?https://gitlab.dune-project.org/core/dune-common/-/issues/6MPI_LB and MPI_UB deprecation warnings2017-06-05T05:56:11ZMarco AgneseMPI_LB and MPI_UB deprecation warnings`MPI_LB` and `MPI_UB` macros are deprecated in MPI-2 and should replaced by the function `MPI_Type_get_extent`
See here for more info:
https://www.open-mpi.org/doc/v1.8/man3/MPI_Type_get_extent.3.php`MPI_LB` and `MPI_UB` macros are deprecated in MPI-2 and should replaced by the function `MPI_Type_get_extent`
See here for more info:
https://www.open-mpi.org/doc/v1.8/man3/MPI_Type_get_extent.3.phphttps://gitlab.dune-project.org/core/dune-geometry/-/issues/35Recursive call of referenceEmbeddings leads to millions of warnings2024-02-07T13:16:31ZSimon PraetoriusRecursive call of referenceEmbeddings leads to millions of warningsIn the `ReferenceElementImplementation` there is a helper function `referenceEmbeddings()` (https://gitlab.dune-project.org/core/dune-geometry/-/blob/master/dune/geometry/referenceelementimplementation.hh?ref_type=heads#L213) that is imp...In the `ReferenceElementImplementation` there is a helper function `referenceEmbeddings()` (https://gitlab.dune-project.org/core/dune-geometry/-/blob/master/dune/geometry/referenceelementimplementation.hh?ref_type=heads#L213) that is implemented recursively. The case `dim == 0` is not handled explicitly but might occure in this recursive instantiation. Recent compilers, e.g. gcc-12, instantiate this function and then give lots of warnings (with `-Wall`) about array access with index `size_t(-1)`. This is resulting from `array[dim-1]` probably.
This function is unfortunately undocumented. I don't know what it should return and how the case `dim = 0` should behave. A simple solution would be to handle this case explicitly to silence the warning.https://gitlab.dune-project.org/core/dune-common/-/issues/356Follow-up from "Split config file into public and private config files"2023-11-30T18:17:28ZSantiago Ospina De Los Ríossospinar@gmail.comFollow-up from "Split config file into public and private config files"The following discussion from !1262 should be addressed:
- [ ] @mathis.kelm started a [discussion](https://gitlab.dune-project.org/core/dune-common/-/merge_requests/1262#note_132330): (+1 comment)
> @santiago.ospina in DuMux we us...The following discussion from !1262 should be addressed:
- [ ] @mathis.kelm started a [discussion](https://gitlab.dune-project.org/core/dune-common/-/merge_requests/1262#note_132330): (+1 comment)
> @santiago.ospina in DuMux we use definitions like `HAVE_DUNE_FOAMGRID` in our headers. With this change, we've noticed that for dependencies without a `config.h.cmake` file (e.g. dune-subgrid, dune-foamgrid) these definitions are no longer added to the `config.h` file generated for our module. The function `dune_parse_module_config_file` is not called for dependencies without `config.h.cmake` so neither the detection nor the public headers are included in the legacy config header of downstream modules.
> The new config header `include/dumux-config.hh` does try to include public config headers of the dependencies in question, but those are not generated.
>
> Are all DUNE modules expected to have a `config.h.cmake` file now or should at least the detection of dependencies still be included in downstream config headers? Should we make changes in our module?CMake ModernizationSantiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.comhttps://gitlab.dune-project.org/core/dune-istl/-/issues/114Jacobi algorithm updates b=b-Ax rather than b=b-(L+U)x2023-10-20T11:19:59ZSantiago Ospina De Los Ríossospinar@gmail.comJacobi algorithm updates b=b-Ax rather than b=b-(L+U)xPerhaps I am missing something, but while debugging a unrelated bug, I noticed that the [jacobi method](https://en.wikipedia.org/wiki/Jacobi_method) is computing ${ \mathbf {x} ^{(k+1)}=D^{-1}(\mathbf {b} -(L+U+D)\mathbf {x} ^{(k)})=D^{-...Perhaps I am missing something, but while debugging a unrelated bug, I noticed that the [jacobi method](https://en.wikipedia.org/wiki/Jacobi_method) is computing ${ \mathbf {x} ^{(k+1)}=D^{-1}(\mathbf {b} -(L+U+D)\mathbf {x} ^{(k)})=D^{-1}(\mathbf {b}-A\mathbf {x} ^{(k)})}$ rather than ${ \mathbf {x} ^{(k+1)}=D^{-1}(\mathbf {b} -(L+U)\mathbf {x} ^{(k)}).}$
[Here](https://gitlab.dune-project.org/core/dune-istl/-/blob/bc2a9ef589554d2d1b0b4a48ee675e8ed1d6701e/dune/istl/gsetc.hh#L484) is the offending line:
```c++
for (; j.index()<i.index(); ++j)
rhs -= (*j) * x[j.index()]; // b-=Lx
coliterator diag=j; // this is the diagonal entry!
for (; j!=endj; ++j)
rhs -= (*j) * x[j.index()]; // since entry was not skipped, this is b-=(D+U)x
```
If I am not making an stupid mistake, it should be something like this:
```c++
for (; j.index()<i.index(); ++j)
rhs -= (*j) * x[j.index()]; // b-=Lx
coliterator diag=j++; // store diagonal entry and advance iterator
for (; j!=endj; ++j)
rhs -= (*j) * x[j.index()]; // b-=Ux
```
Does this make sense?