Core Modules issueshttps://gitlab.dune-project.org/groups/core/-/issues2020-10-05T10:00:05Zhttps://gitlab.dune-project.org/core/dune-geometry/-/issues/25Add static_assert to constructor of AxisAlignedCubeGeometry2020-10-05T10:00:05ZKilian WeishauptAdd static_assert to constructor of AxisAlignedCubeGeometryUsing `AxisAlignedCubeGeometry` with `dim != coorddim` and the constructor taking only two arguments leads
to potentially wrong results.
The constructor's comment actually hints to this issue:
```c++
/** \brief Constructor from a...Using `AxisAlignedCubeGeometry` with `dim != coorddim` and the constructor taking only two arguments leads
to potentially wrong results.
The constructor's comment actually hints to this issue:
```c++
/** \brief Constructor from a lower left and an upper right corner
\note Only for dim==coorddim
*/
AxisAlignedCubeGeometry(const Dune::FieldVector<ctype,coorddim> lower,
const Dune::FieldVector<ctype,coorddim> upper)
```
Since both `dim` and `coorddim` are known at compile time, a `static_assert` could prevent wrong usage.
Alternatively, this constructor could be disabled by SFINAE.
Is there any reason why this is not done yet?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/37Drop support for clang-3.5?2017-08-04T09:59:29ZCarsten Gräsergraeser@math.fau.deDrop support for clang-3.5?Unfortunately I found out that clang-3.5 has a severe bug with the handling of `std::integer_sequence` which is maybe related to the `sizeof...` operator.
This does not only lead to compile failures. It's easy to give examples where c...Unfortunately I found out that clang-3.5 has a severe bug with the handling of `std::integer_sequence` which is maybe related to the `sizeof...` operator.
This does not only lead to compile failures. It's easy to give examples where clang-3.5 silently produces incorrect code. A dune-less test case using only `std::index_sequence` in an idiomatic non-artificial way for tuple-unpacking is attached to the corresponding issue in dune-functions: https://gitlab.dune-project.org/staging/dune-functions/issues/10
As a consequence we should either avoid using related features in dune or **drop
support for clang-3.5**. Since we are already using `std::integer_sequence`
in the core for some time I'd strongly vote for the latter
to avoid people running into hard to track issues with
correct code producing wrong results.DUNE 2.5.0https://gitlab.dune-project.org/core/dune-istl/-/issues/26Add a generic factory for solver setup using configuration from a ParameterTree2020-01-19T16:59:41ZChristian EngwerAdd a generic factory for solver setup using configuration from a ParameterTree**This is a followup on !5 and !1.**
The idea is to allow creating solvers / preconditioners from ParameterTrees.
A solver (including preconditioner) should be configurable via an ini file, similar to (we might want to change the seman...**This is a followup on !5 and !1.**
The idea is to allow creating solvers / preconditioners from ParameterTrees.
A solver (including preconditioner) should be configurable via an ini file, similar to (we might want to change the semantics slightly in some places...):
```
[solver]
precond = SeqSSOR
solver = CGSolver
[SeqSSOR]
iterations = 1
relaxation = 1.8
[CGSolver]
reduction=1e-9
maxit = 5000
verbose = 3
```
**Necessary steps:**
* [x] make interface classes really dynamic (see !84)
* [x] add constructors taking a `ParameterTree` (see !315)
* [x] use these new constructors in a solver factory (see !312)
* [x] rewrite the factories to use the `ParameterizedFactory` in `dune-common` (see !312)
* [x] review and cleanup the `ParameterTree` *"interface"*
* [x] remove static AMG configurations (coarse solver, smoother, etc) (explicit dispatch in !312)
* [x] switch `Hierarchy<T>` to use `std::shared_ptr` or `std::unique_ptr` for internal memory management instead of manual `new`/`delete`)(see !274 and !333)
1. introduce a value semantics wrapper class for the polymorphic interface classes
1. add concepts for simple precompilation for a range of field types, e.g. vectorized data.
1. review the concepts of how to instantiate and pre-compile the factoriesDUNE 2.7.0Christian EngwerChristian Engwerhttps://gitlab.dune-project.org/core/dune-geometry/-/issues/26dune_python_add_test with SCRIPT instead of COMMAND2021-03-23T10:34:38ZSimon Praetoriusdune_python_add_test with SCRIPT instead of COMMANDDue to the recent changes in `dune_python_add_test` in https://gitlab.dune-project.org/core/dune-common/-/merge_requests/914 the dune-geometry cmake configuration fails, see https://gitlab.dune-project.org/core/dune-common/-/jobs/199670Due to the recent changes in `dune_python_add_test` in https://gitlab.dune-project.org/core/dune-common/-/merge_requests/914 the dune-geometry cmake configuration fails, see https://gitlab.dune-project.org/core/dune-common/-/jobs/199670https://gitlab.dune-project.org/core/dune-grid/-/issues/14Introduce `hasGeometry` capability2017-04-07T14:32:14ZAnsgar Burchardtansgar.burchardt@tu-dresden.deIntroduce `hasGeometry` capabilityAt the DUNE Developer Meeting 2013 it was decided that grids must provide subentities of all codimensions, however they don't have to provide a geometry for all of them. It was further decided to implement a `hasGeometry` capability to i...At the DUNE Developer Meeting 2013 it was decided that grids must provide subentities of all codimensions, however they don't have to provide a geometry for all of them. It was further decided to implement a `hasGeometry` capability to indicate for which entites a geometry is provided.
I assume this means adding
```c++
template <typename Entity>
struct hasGeometry
{
const static bool v = false;
};
```
in the `Dune::Capabilities` namespace?
Or should this be a property of the grid? i.e. `template<typename Grid, int codim> struct hasGeometry`?
Reference: https://www.dune-project.org/community/meetings/2013-09-devmeeting/#subentity-of-all-co-dimensionshttps://gitlab.dune-project.org/core/dune-common/-/issues/36[cmake] installation of communication.pdf broken2017-06-05T05:56:08ZFelix Gruber[cmake] installation of communication.pdf brokenThe merge of !109 broke the installation of communication.pdf:
~~~
CMake Error at doc/comm/cmake_install.cmake:36 (file):
file INSTALL cannot find
"/home/data/gruber/src/dune-git/dune-common/doc/comm/communication.pdf".
Call S...The merge of !109 broke the installation of communication.pdf:
~~~
CMake Error at doc/comm/cmake_install.cmake:36 (file):
file INSTALL cannot find
"/home/data/gruber/src/dune-git/dune-common/doc/comm/communication.pdf".
Call Stack (most recent call first):
doc/cmake_install.cmake:43 (include)
cmake_install.cmake:62 (include)
~~~
This seems to be caused by two things:
1. `dune_add_latex_document` now calls `add_latex_document` with the `EXCLUDE_FROM_ALL` option, which causes communication.pdf not to appear in the dependencies of the install target.
2. install seems to search for communication.pdf in the source dir instead of the build dir.https://gitlab.dune-project.org/core/dune-istl/-/issues/25build_tests failure with ICC 17 in paamg/test/2020-01-20T19:03:02ZRené Fritzebuild_tests failure with ICC 17 in paamg/test/I'm not sure if this is really an issue with ICC itself, but I cannot build tests in paamg/test/:
```
[ 10%] Building CXX object dune/istl/paamg/test/CMakeFiles/pthreaddirectamgtest.dir/main77_pthreaddirectamgtest.cc.o
cd /home/hpc/pr62z...I'm not sure if this is really an issue with ICC itself, but I cannot build tests in paamg/test/:
```
[ 10%] Building CXX object dune/istl/paamg/test/CMakeFiles/pthreaddirectamgtest.dir/main77_pthreaddirectamgtest.cc.o
cd /home/hpc/pr62zo/di73dez2/build-main-gdt-phase1/dune-istl/dune/istl/paamg/test && /lrz/sys/parallel/mpi.ibm/pecurrent/intel/bin/mpicc -DENABLE_GMP=1 -DENABLE_MPI=1 -DHAVE_CONFIG_H -DMPICH_SKIP_MPICXX -DMPIPP_H -DMYAMG="Dune::Amg::AMG<Operator,Vector,Smoother>" -I/home/hpc/pr62zo/di73dez2/build-main-gdt-phase1/dune-istl -I/home/hpc/pr62zo/di73dez2/main_gdt/dune-istl -I/opt/ibmhpc/pecurrent/mpich2/intel/include64 -I/opt/ibmhpc/pecurrent/base/include -I/home/hpc/pr62zo/di73dez2/main_gdt/dune-common -DNDEBUG -std=c++11 -g -w -openmp -O3 -ftz -xHost -ipo -no-prec-div -std=c++14 -O2 -g -DNDEBUG -o CMakeFiles/pthreaddirectamgtest.dir/main77_pthreaddirectamgtest.cc.o -c /home/hpc/pr62zo/di73dez2/build-main-gdt-phase1/dune-istl/dune/istl/paamg/test/main77_pthreaddirectamgtest.cc
/lrz/sys/parallel/mpi.ibm/pecurrent/intel/bin/mpicc[100]: eval[1]: Operator,Vector,Smoother: cannot open [No such file or directory]
make[3]: *** [dune/istl/paamg/test/CMakeFiles/pthreaddirectamgtest.dir/main77_pthreaddirectamgtest.cc.o] Error 1
```
this is with cmake 3.4 and on both master and releases/2.5 branch. Escaping the brackets or adding single qoutes around the define in CMakeLists.txt does not help.https://gitlab.dune-project.org/core/dune-geometry/-/issues/27deprecation warning for Topology classes2021-07-16T17:58:32ZAndreas Dednerdeprecation warning for Topology classesThe deprecation of the Topology classes is not working as I would expect it to - but no idea how to fix it.
If you look at https://gitlab.dune-project.org/core/dune-geometry/-/jobs/234387 for example you'll see that warnings are being t...The deprecation of the Topology classes is not working as I would expect it to - but no idea how to fix it.
If you look at https://gitlab.dune-project.org/core/dune-geometry/-/jobs/234387 for example you'll see that warnings are being thrown all over the place although nothing in dune-geometry should be using these classes anymore. As far as I can see any inclusion of types.hh leads to multiple warnings. Same in dune-localfunction (https://gitlab.dune-project.org/core/dune-localfunctions/-/jobs/233937) and in dune-fem the CI output is truncated due to it becoming too large.
Any idea how to fix this?DUNE 2.8.0https://gitlab.dune-project.org/core/dune-grid/-/issues/13dune-grid-2.4.1 fails to build with UG 3.13.02018-01-15T15:13:11ZMichaël Sghaïerdune-grid-2.4.1 fails to build with UG 3.13.0Hi,
I wanted to build DUNE with the official tarballs (2.4.1), using UG (3.13.0) but dunecontrol fails to build dune-grid. I attached the [error log](/uploads/0791a39e7a161680d68b71d7058f9b3d/build).
I investigated the problem and...Hi,
I wanted to build DUNE with the official tarballs (2.4.1), using UG (3.13.0) but dunecontrol fails to build dune-grid. I attached the [error log](/uploads/0791a39e7a161680d68b71d7058f9b3d/build).
I investigated the problem and line 348 of the error log shows:
```
In file included from /usr/local/include/ug/gm.h:62:0,
from /home/misg/gsoc2016/dune/dune-grid-2.4.1/dune/grid/uggrid/ugincludes.hh:15,
from /home/misg/gsoc2016/dune/dune-grid-2.4.1/dune/grid/uggrid.hh:46,
from /home/misg/gsoc2016/dune/dune-grid-2.4.1/dune/grid/io/file/dgfparser/dgfug.hh:19,
from /home/misg/gsoc2016/dune/dune-grid-2.4.1/dune/grid/io/file/dgfparser/dgfug.cc:5:
/usr/local/include/ug/dimension.h:31:2: error: #error **** define at least dimension two OR three ****
#error **** define at least dimension two OR three ****
^
```
After some researches, It appears that UG did the following change in its last version: `Rename macros _2 and _3 to UG_DIM_2 and UG_DIM_3 respectively, to avoid clashes with symbols of the same name in libc++.` but `dune-grid-2.4.1/dune/grid/uggrid.hh` still uses the `_2` and `_3` macros instead of `UG_DIM_2` and `UG_DIM_3` and thus causes the bug mentioned above.
Just replacing all `_2` and `_3` macros respectively by `UG_DIM_2` and `UG_DIM_3` in `uggrid.hh` fixes the bug and makes the build passes successfully.https://gitlab.dune-project.org/core/dune-common/-/issues/35[gitlab-ci] Have correct locale for parametertreelocaletest in docker container2017-06-05T05:56:08ZDominic Kempfdominic.kempf@iwr.uni-heidelberg.de[gitlab-ci] Have correct locale for parametertreelocaletest in docker containerI stumbled over this problem before and solved it. I will need to search the solution again though during the next days if @ansgar hasnt got a quick fix ready.I stumbled over this problem before and solved it. I will need to search the solution again though during the next days if @ansgar hasnt got a quick fix ready.Dominic Kempfdominic.kempf@iwr.uni-heidelberg.deDominic Kempfdominic.kempf@iwr.uni-heidelberg.dehttps://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-grid/-/issues/11Printgrid produces malformed outputfile name2017-04-07T14:32:14ZDominic Kempfdominic.kempf@iwr.uni-heidelberg.dePrintgrid produces malformed outputfile nameThe concatenation of base names and rank number is broken: Instead of `printgrid_0`, we get `_0intgrid`. Introduced with 78f96ebf.The concatenation of base names and rank number is broken: Instead of `printgrid_0`, we get `_0intgrid`. Introduced with 78f96ebf.https://gitlab.dune-project.org/core/dune-common/-/issues/33Parametertreetest needs adaptation for empty subtree extraction2017-06-05T05:56:08ZJö Fahlkejorrit@jorrit.deParametertreetest needs adaptation for empty subtree extractionHey @smuething, could you adapt the parametertreetest for !101? It checks that extracting an empty subtree generates an exception, which does not happen anymore...Hey @smuething, could you adapt the parametertreetest for !101? It checks that extracting an empty subtree generates an exception, which does not happen anymore...DUNE 3.0.0Steffen Müthingsteffen.muething@iwr.uni-heidelberg.deSteffen Müthingsteffen.muething@iwr.uni-heidelberg.dehttps://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/8autotools fail to find dune-grid lib2017-04-07T14:32:14ZTobias Malkmusautotools fail to find dune-grid libA fix can be found in branch bugfix/libcheck-autotools
This should be added to the new release canidate 2.4r1.A fix can be found in branch bugfix/libcheck-autotools
This should be added to the new release canidate 2.4r1.DUNE 2.4.1Steffen Müthingsteffen.muething@iwr.uni-heidelberg.deSteffen Müthingsteffen.muething@iwr.uni-heidelberg.dehttps://gitlab.dune-project.org/core/dune-common/-/issues/32densevector with unsigned int as size_type2017-06-05T05:56:08ZTobias Malkmusdensevector with unsigned int as size_typeFor a vector implementation derived from `DenseVector` which has `unsigned int` as `size_type`, `end() - begin()` results in a negative value on my machine,
hence coping the vector using `std::copy()` is not possible.
In branch !97 ...For a vector implementation derived from `DenseVector` which has `unsigned int` as `size_type`, `end() - begin()` results in a negative value on my machine,
hence coping the vector using `std::copy()` is not possible.
In branch !97 i added a small test which triggers this bug and a fix for it.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-grid/-/issues/7Unit tests for the old alugrid fail to compile2017-04-07T14:32:14ZJö Fahlkejorrit@jorrit.deUnit tests for the old alugrid fail to compileWith g++-4.9.2, autotools buildsystem, alugrid-1.52 (tar ball), and today's releases/2.4 branches (core/dune-common@532a9f30, core/dune-geometry@1d263376, and 32b29ad3), ALUGrid-related unit tests fail to compile. The issues encountered...With g++-4.9.2, autotools buildsystem, alugrid-1.52 (tar ball), and today's releases/2.4 branches (core/dune-common@532a9f30, core/dune-geometry@1d263376, and 32b29ad3), ALUGrid-related unit tests fail to compile. The issues encountered seem to be mostly related to EntityPointer -> Entity conversions.
See also !30.DUNE 2.4.1https://gitlab.dune-project.org/core/dune-common/-/issues/31dunecontrol: extremly unhelpful error when dependencies are separated by ","2017-06-05T05:56:08ZJö Fahlkejorrit@jorrit.dedunecontrol: extremly unhelpful error when dependencies are separated by ","When separating dependencies in the `Depends:`-line in `dune.module` by a comma (`,`), The error message becomes something like this:
```
joe@paranoia:~/linuxhome/Projekte/pra-wire-sose-2016/Dune$ ./dunecontrol --opts=debug.opts all
-...When separating dependencies in the `Depends:`-line in `dune.module` by a comma (`,`), The error message becomes something like this:
```
joe@paranoia:~/linuxhome/Projekte/pra-wire-sose-2016/Dune$ ./dunecontrol --opts=debug.opts all
----- using default flags $CONFIGURE_FLAGS from /home/joe/linuxhome/Projekte/pra-wire-sose-2016/Dune/debug.opts -----
ERROR: invalid module name (dependency of dune_cppbasics)
Execution of dunecontrol terminated due to errors!
```
The code in dunemodules.lib looks like it is meant to support this, but seems top be buggy.
This happens the the 2.4 branch, no idea about master.