Core Modules issueshttps://gitlab.dune-project.org/groups/core/-/issues2017-05-25T21:04:49Zhttps://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-common/-/issues/147`x` vs `y` in documentation2019-09-09T14:44:29ZAnsgar Burchardtansgar.burchardt@tu-dresden.de`x` vs `y` in documentationThe `DenseVector::axpy(a, y)` method is documented as
```
vector space axpy operation ( *this += a y )
```
The same for `DenseVector::operator +=(y)`, `-=(y)`, ...
Usually `axpy` means `y := ax + y` which matches `axpy = alpha x plus ...The `DenseVector::axpy(a, y)` method is documented as
```
vector space axpy operation ( *this += a y )
```
The same for `DenseVector::operator +=(y)`, `-=(y)`, ...
Usually `axpy` means `y := ax + y` which matches `axpy = alpha x plus y`. The parameter naming in DUNE doesn't match this and is therefore confusing.
In other places DUNE uses `y` as the result: for example `FieldMatrix::mv(x, y)` computes `y := Ax`.
I propose to rename the parameters so that `y` always is the name of the result.https://gitlab.dune-project.org/core/dune-common/-/issues/91Deprecate DUNE_DEPRECATED and DUNE_DEPRECATED_MSG2021-01-17T19:27:48ZJö Fahlkejorrit@jorrit.deDeprecate DUNE_DEPRECATED and DUNE_DEPRECATED_MSGWe're fully on C++14 now (see !320), we should be able to use the attributes `[[deprecated]]` and `[[deprecated("msg")]]` instead.We're fully on C++14 now (see !320), we should be able to use the attributes `[[deprecated]]` and `[[deprecated("msg")]]` instead.DUNE 2.8.0https://gitlab.dune-project.org/core/dune-common/-/issues/71remove `throw(...)` or replace by `noexcept`2017-05-02T17:20:44ZSimon Praetoriusremove `throw(...)` or replace by `noexcept`The `throw(...)` specification was marked deprecated in C++11 since it was not really useful. The replacement `noexcept` was introduced to mark a function to not throw an exception, to maybe allow the compiler to make more aggressive opt...The `throw(...)` specification was marked deprecated in C++11 since it was not really useful. The replacement `noexcept` was introduced to mark a function to not throw an exception, to maybe allow the compiler to make more aggressive optimization (especially in the context of move semantics). In Dune::common there are a lot of functions marked with `throw(...)`. Activating the flag `-std=c++1z` in g++-7 then leads to a compiler error since the deprecated features are removed in the upcoming standard.
*Suggestion:* Since it is already deprecated and does not have an effect, remove the `throw(...)` specification on the following functions and maybe replace `throw()` by `noexcept` where applicable:
- bigunsignedint.hh
- debugallocator.hh
- timer.hh
- poolallocator.hh
- parallel/remoteindices.hh
- parallel/indexset.hh
- mallocallocator.hh
- debugstream.hhhttps://gitlab.dune-project.org/core/dune-common/-/issues/353Increase minimal GCC version from 9 to 102023-11-20T21:45:27ZChristoph GrüningerIncrease minimal GCC version from 9 to 10I want to increase Dune Core master's (will become Dune 2.10) minimal required GCC version from 9 to 10. Debian 11 comes with GCC 10. Ubuntu 20.04 provides a package gcc-10, so it is easy to use Dune with Ubuntu 22.04.
Is there any reas...I want to increase Dune Core master's (will become Dune 2.10) minimal required GCC version from 9 to 10. Debian 11 comes with GCC 10. Ubuntu 20.04 provides a package gcc-10, so it is easy to use Dune with Ubuntu 22.04.
Is there any reason to not increase the minimal compiler to GCC 10?
In the Dune developer meeting 2022, we [decided to increase the GCC version to 10](https://dune-project.org/community/meetings/2022-02-devmeeting/#minimum-versions-of-gcc-clang-cmake-python), unless we are presented cases not considered.https://gitlab.dune-project.org/core/dune-grid/-/issues/130Change policy regarding auto&& in grid range generators?2021-07-25T19:13:12ZTimo KochChange policy regarding auto&& in grid range generators?As stated in the docs of the rangegenerators
```c++
We are aware that people like Bjarne Stroustrup and Herb
Sutter advertise the use `auto&&`. Sadly GCC prior to version 6 has a bug (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6350...As stated in the docs of the rangegenerators
```c++
We are aware that people like Bjarne Stroustrup and Herb
Sutter advertise the use `auto&&`. Sadly GCC prior to version 6 has a bug (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63506), which
prevents the use of `auto&&` in template functions. For this reason
we currently advice the use of `const auto&`.
```
Newer compilers emit a warning ("-Wrange-loop-analysis") if the type doesn't match what's deduced by the range.
So for example when compiling some code with YaspGrid (range return temporaries/copies) there is a lot of warnings like
```c++
warning: loop variable 'element' is always a copy because the range of type ... does not return a reference: use non-reference type.
```
Turning off this warning is not a good solution IMO since it actually detects wrong usage for example
```c++
dune-grid/dune/grid/uggrid/uglbgatherscatter.hh:57:12: note: use reference type 'const Dune::Entity<0, 3, const Dune::UGGrid<3>, UGGridEntity> &' to prevent copying
for (const auto entity : entities(gridView, Codim<codim>()))
^~~~~~~~~~~~~~~~~~~
&
```
recently fixed in dune-uggrid.
Using `auto&&` seems to get rid of the warning and `auto&&` collapses to the right type for both situations.
Given that gcc 6 is no longer supported, should this policy be revised?Timo KochTimo Kochhttps://gitlab.dune-project.org/core/dune-common/-/issues/213Simd generates many test sources during cmake configuration2020-10-11T10:52:02ZSimon PraetoriusSimd generates many test sources during cmake configurationIn `dune/common/simd/test` a lot of files are generated during the CMake configuration run. As far as I understand, it is related to the problem that one big test would need too much memory. Thus, it is split up into smaller tests. See #...In `dune/common/simd/test` a lot of files are generated during the CMake configuration run. As far as I understand, it is related to the problem that one big test would need too much memory. Thus, it is split up into smaller tests. See #151, !633, and !193. So, this file generation for the simd tests probably makes perfectly sense.
But, I see 100s of lines of output during the standard cmake configuration. This makes it harder to find actual problems in cmake and to inspect the output for missing files.
- Is it necessary to see all the files that are generated for the tests? (Maybe we can turn the `message(STATUS "Generating A -> B")` into a log message in CMakeOutput.txt instead of printing it always)
- Wouldn't it be better to generate the files only when requesting to build the simd tests? Or even make it part of the test? (Maybe this can be achieved by writing a custom target or run a cmake script on build of the tests)https://gitlab.dune-project.org/core/dune-grid/-/issues/111[recipes] Bad exception-catching pattern2020-06-10T12:13:40ZJö Fahlkejorrit@jorrit.de[recipes] Bad exception-catching patternThe new recipes use the exception-catching pattern
```c++
int main(int argc, char** argv)
{
try{
//...
}
catch (Dune::Exception &e){
std::cerr << "Dune reported error: " << e << std::endl;
return 1;
}
catch (...){
...The new recipes use the exception-catching pattern
```c++
int main(int argc, char** argv)
{
try{
//...
}
catch (Dune::Exception &e){
std::cerr << "Dune reported error: " << e << std::endl;
return 1;
}
catch (...){
std::cerr << "Unknown exception thrown!" << std::endl;
return 1;
}
}
```
Although this is common in programs based on Dune, we should avoid teaching this. It turns at least standard exceptions into a useless error message. And under certain circumstances the standard library would already print much more useful error messages for exceptions that leave `main()`, including Dune exceptions, because these are derived from `std::exception` these days. And if something not derived from `std::exception` throws out of main, at least the name of the type will be printed.
Alternatives:
- Don't handle any exception. Has the drawback that the standard library produces useful error messages only under certain circumstances (debug libraries being installed I think, but I'm not sure). Has the advantage that it concentrates on the core of these educational examples, and leaves out distracting side-questions.
- Handle `std::exception`: A useful error message can be produced for most exceptions, including Dune exceptions, and `Dune::className(e)` can be used to print the precise dynamic type of the exception.
- Handle `std::exception` and `Dune::Exception`. You can avoid printing the type of the exception twice, because Dune exceptions tend to already include it in their message. But that is poorly specified, plus it makes these educational examples more complicated than they need to be.
- Handle only `Dune::Exception`: similar to handling just `std::exception`, but you leave the standard exceptions to be reported by the standard library. Really no advantage over just handling `std::exception`.Linus SeelingerLinus Seelingerhttps://gitlab.dune-project.org/core/dune-common/-/issues/200Require more recent version of CMake2020-12-07T09:38:41ZChristoph GrüningerRequire more recent version of CMakeDune is compatible with a CMake 3.1, which was released end of 2014. The most current version is 3.17 and it offers tons of features and bug fixes. Since Dune 2.6 we require CMake 3.1. To make it short, it is time to bump the version so ...Dune is compatible with a CMake 3.1, which was released end of 2014. The most current version is 3.17 and it offers tons of features and bug fixes. Since Dune 2.6 we require CMake 3.1. To make it short, it is time to bump the version so something more recent.
What would be the most recent version you felt comfortable as a requirement? Please keep in mind that Dune 2.7 was released three months ago, so probably it will take a couple of months before 2.8 gets released.
I propose one of these versions (please extend):
* 3.10
* 3.12
* 3.13
CMake packages from popular distributions (please extend):
* Debian 10: CMake 3.13
* Ubuntu 18.04 LTS: CMake 3.10.2
* Ubuntu 19.04: CMake 3.13
* Ubuntu 20.04 LTS: CMake 3.16
* RHEL 8: CMake 3.11
* openSuse Leap 15.1: 3.10
* openSuse Leap 15.2 (still beta): 3.13
Important CMake features:
* CMake 3.11: version-files support `SameMinorVersion` for compatibility checks (important as Dune often increases the minor version, not the major version)
* CMake 3.12: FindPython3 (better Python detecetion)
* CMake 3.13: `target_link_libraries`, `target_compile_options`, and other functions for adding target properties work for `INTERFACE` targets (handy for better Dune build system)New CMake Build-Systemhttps://gitlab.dune-project.org/core/dune-common/-/issues/199[CMake] Improve module / dependency system2021-03-10T11:47:52ZChristoph Grüninger[CMake] Improve module / dependency systemThe current build system is implemented in CMake and was designed to replace the former system based on Autotools. Especially the modules, variable passing, and dependency handling is bad, as every module has to re-run the tests from all...The current build system is implemented in CMake and was designed to replace the former system based on Autotools. Especially the modules, variable passing, and dependency handling is bad, as every module has to re-run the tests from all direct and indirect dependencysNew CMake Build-Systemhttps://gitlab.dune-project.org/core/dune-common/-/issues/184Get rid of Fortran2020-03-13T20:16:47ZChristoph GrüningerGet rid of FortranWe should get rid of Fortran. We can use the C bindings for LAPACK and BLAS. This would reduce the complexity of the current build code.
I know that two arguments are no longer valid against having Fortran
* With Ninja 1.10 Fortran is s...We should get rid of Fortran. We can use the C bindings for LAPACK and BLAS. This would reduce the complexity of the current build code.
I know that two arguments are no longer valid against having Fortran
* With Ninja 1.10 Fortran is supported.
* With LLVM 10 they got a Fortran frontend.
Any thoughts?https://gitlab.dune-project.org/core/dune-istl/-/issues/72Add CI configuration with DUNE_ISTL_WITH_CHECKING2020-10-06T15:20:57ZNils-Arne DreierAdd CI configuration with DUNE_ISTL_WITH_CHECKINGShould we add a CI configuration which has `DUNE_ISTL_WITH_CHECKING` set?
See !298 for example.Should we add a CI configuration which has `DUNE_ISTL_WITH_CHECKING` set?
See !298 for example.https://gitlab.dune-project.org/core/dune-common/-/issues/157Drop Python 2 support2020-01-17T12:38:33ZDominic Kempfdominic.kempf@iwr.uni-heidelberg.deDrop Python 2 supportYou might have heard that Python 2 will not be supported beyond January 1st, 2020.
By that time, Dune should also drop the support IMO.
However, with Dune's Python efforts being in a state of evolution right now, we could spare us compat...You might have heard that Python 2 will not be supported beyond January 1st, 2020.
By that time, Dune should also drop the support IMO.
However, with Dune's Python efforts being in a state of evolution right now, we could spare us compatibility hassle by dropping the support even earlier than that.
Opinions? @andreas.dedner?
Within the core modules, the only affected code is the cmake code searching for the python interpreter/libs and the convenience stuff that we built around the 2/3 issue (like forcing a major version etc.).https://gitlab.dune-project.org/core/dune-common/-/issues/152deprecate `VectorSize`2019-09-09T14:44:29ZAnsgar Burchardtansgar.burchardt@tu-dresden.dedeprecate `VectorSize`In densematrix.hh there is a helper class `VectorSize` that returns `N` for objects `v` of type `FieldVector<K,N>` and returns `v.size()` for other objects.
Given `FieldVector` also provides a `size()` method, this helper class seems unn...In densematrix.hh there is a helper class `VectorSize` that returns `N` for objects `v` of type `FieldVector<K,N>` and returns `v.size()` for other objects.
Given `FieldVector` also provides a `size()` method, this helper class seems unneeded: just call `v.size()`.
It does not seem to be used in other core module.
I propose to deprecate the helper class.DUNE 2.7.0https://gitlab.dune-project.org/core/dune-grid/-/issues/77VTKSequenceWriter should expose vtkWriter_->clear()2020-02-17T14:41:50ZWilhelm NeubertVTKSequenceWriter should expose vtkWriter_->clear()Since `addCellData` and `addVertexData` of the internal VTKWriter are exposed through the VTKSequenceWriterBase parent class, it would be consistent to also add the `clear` function to this interface. It saves the user of VTKSequenceWrit...Since `addCellData` and `addVertexData` of the internal VTKWriter are exposed through the VTKSequenceWriterBase parent class, it would be consistent to also add the `clear` function to this interface. It saves the user of VTKSequenceWriter from dragging around another shared_ptr to the underlying VTKWriter to clear unwanted VTKFunction references.
The implementation of this is trivial, so if you agree that this should exist, I'd be willing to create a pull request providing this.https://gitlab.dune-project.org/core/dune-istl/-/issues/33UMFPack Memory Limitations2019-11-24T08:17:15ZKilian WeishauptUMFPack Memory LimitationsCurrently, __UMFPack__ throws an `out of memory` exception when the memory consumption becomes larger than 2GB.
Inspired by this thread (https://forum.kde.org/viewtopic.php?f=74&t=123386), I was able to circumvent the problem (see attac...Currently, __UMFPack__ throws an `out of memory` exception when the memory consumption becomes larger than 2GB.
Inspired by this thread (https://forum.kde.org/viewtopic.php?f=74&t=123386), I was able to circumvent the problem (see attached [umfpack_diff.txt](/uploads/3e2f4338b91c53bba94140b039d787ec/umfpack_diff.txt)).
I'm not sure if using the signatures for `long int` should be the default or if there should be some kind of specialization.https://gitlab.dune-project.org/core/dune-common/-/issues/27[cmake] Update UseLATEX.cmake2017-06-05T05:56:09ZDominic Kempfdominic.kempf@iwr.uni-heidelberg.de[cmake] Update UseLATEX.cmakeWe are shipping UseLATEX.cmake from Kenneth Moreland in version 1.10
However, his development is currently at version 2.3, see
https://github.com/kmorel/UseLATEX
I consider it a good idea to update the shipped version at some poin...We are shipping UseLATEX.cmake from Kenneth Moreland in version 1.10
However, his development is currently at version 2.3, see
https://github.com/kmorel/UseLATEX
I consider it a good idea to update the shipped version at some point and test that everything works fine.DUNE 3.0.0https://gitlab.dune-project.org/core/dune-istl/-/issues/5SPQR uses methods only introduced in Suitesparse 4.3.02017-05-21T00:30:58ZDominic Kempfdominic.kempf@iwr.uni-heidelberg.deSPQR uses methods only introduced in Suitesparse 4.3.0So I researched my issue from !8 by diving into the suitesparse code:
Those methods here:
```
/home/dominic/dune/dune-istl/dune/istl/spqr.hh: In member function ‘virtual void Dune::SPQR<Dune::BCRSMatrix<Dune::FieldMatrix<K, n, p>, T...So I researched my issue from !8 by diving into the suitesparse code:
Those methods here:
```
/home/dominic/dune/dune-istl/dune/istl/spqr.hh: In member function ‘virtual void Dune::SPQR<Dune::BCRSMatrix<Dune::FieldMatrix<K, n, p>, TA> >::apply(Dune::SPQR<Dune::BCRSMatrix<Dune::FieldMatrix<K, n, p>, TA> >::domain_type&, Dune::SPQR<Dune::BCRSMatrix<Dune::FieldMatrix<K, n, p>, TA> >::range_type&, Dune::InverseOperatorResult&)’:
/home/dominic/dune/dune-istl/dune/istl/spqr.hh:154:42: error: ‘cholmod_common’ has no member named ‘SPQR_flopcount’
std::cout<<"Flops Taken: "<<cc_->SPQR_flopcount<<std::endl;
^
/home/dominic/dune/dune-istl/dune/istl/spqr.hh:155:44: error: ‘cholmod_common’ has no member named ‘SPQR_analyze_time’
std::cout<<"Analysis Time: "<<cc_->SPQR_analyze_time<<" s"<<std::endl;
^
/home/dominic/dune/dune-istl/dune/istl/spqr.hh:156:45: error: ‘cholmod_common’ has no member named ‘SPQR_factorize_time’
std::cout<<"Factorize Time: "<<cc_->SPQR_factorize_time<<" s"<<std::endl;
^
/home/dominic/dune/dune-istl/dune/istl/spqr.hh:157:45: error: ‘cholmod_common’ has no member named ‘SPQR_solve_time’
std::cout<<"Backsolve Time: "<<cc_->SPQR_solve_time<<" s"<<std::endl;
```
were introduced in SuiteSparse 4.3.0. However, debian stable provides 4.2.1. So, I guess we should:
* remove it
* replace it
* guard it.
Pick your favorite!https://gitlab.dune-project.org/core/dune-common/-/issues/2Make FieldVector::size() static2021-01-23T23:24:09ZCarsten Gräsergraeser@math.fau.deMake FieldVector::size() staticIn order to use the `size()` method of `FieldVector` in compile-time context we made it `constexpr` some time ago. Unfortunately this is only partly useful, because one cannot do things like this
template<class V>
auto foo(V ...In order to use the `size()` method of `FieldVector` in compile-time context we made it `constexpr` some time ago. Unfortunately this is only partly useful, because one cannot do things like this
template<class V>
auto foo(V v) -> std::array<int,v.size()>;
The reason is that v itself is not a constexpr. This can be solved by making the method `static constexpr`. Then one could still use it as before, but also in a static context.https://gitlab.dune-project.org/core/dune-grid/-/issues/140Why is Geometry not copy-assignable?2023-09-28T15:37:11ZSimon PraetoriusWhy is Geometry not copy-assignable?The `Geometry` class has a deleted copy-assignment operator. Why is this operator deleted? I tried to follow the git history but it end in a commit from 9y ago: https://gitlab.dune-project.org/core/dune-grid/-/commit/432cba1ba059ea0beaac...The `Geometry` class has a deleted copy-assignment operator. Why is this operator deleted? I tried to follow the git history but it end in a commit from 9y ago: https://gitlab.dune-project.org/core/dune-grid/-/commit/432cba1ba059ea0beaac615e715a97ea69bc98c7 that was imported from SVN. As far as I can tell, all real implementations from dune-geometry are copy-assignable.
Making a class not copy-assignable results in complicated code when we want to store a geometry in a class, e.g. in the implementation of grid-functions in dune-functions. There, we need to use a `std::optional` or pointer types to construct a new copy (copy construction seems to be still allowed). This has further consequences: The `std::optional<Geometry>` then is also not copyable.
I just want to understand the reasoning behind the deleted copy operator. Maybe it cannot be implemented efficiently (for some reason) in a specific grid manager?