Core Modules issueshttps://gitlab.dune-project.org/groups/core/-/issues2018-02-02T14:11:31Zhttps://gitlab.dune-project.org/core/dune-istl/-/issues/36Feature/MultiTypeBlock* Scalar Operations2018-02-02T14:11:31ZMax Kahntmax.kahnt@fu-berlin.deFeature/MultiTypeBlock* Scalar OperationsI added some functionality to `MultiTypeBlockMatrix` and `MultiTypeBlockVector` in order to initialize them from a scalar value or scale them by the convenient `operator*=` and `operator/=`.
Unfortunately, I cannot create merge requests...I added some functionality to `MultiTypeBlockMatrix` and `MultiTypeBlockVector` in order to initialize them from a scalar value or scale them by the convenient `operator*=` and `operator/=`.
Unfortunately, I cannot create merge requests or push feature branches, so find my commits attached as patches.
- Add constructors from scalars: [commit-d0361dd](/uploads/35f3902deef9866bc6f451d4980fff08/commit-d0361dd)
- Use IsNumber traits to condense operator*= methods: [commit-96a90f9](/uploads/b168f7919e6741d35b70719017c5fa2d/commit-96a90f9)
- Add operator*= and operator/= (to MultiTypeBlockMatrix): [commit-8d2d748](/uploads/e644115588ba5e3cc5ef16cb71f365d1/commit-8d2d748)
- Add operator/= (to MultiTypeBlockVector): [commit-7cdc176](/uploads/3c851180e3fb3701e0204e38cbdf48ef/commit-7cdc176)https://gitlab.dune-project.org/core/dune-geometry/-/issues/13Introduction of value semantics for ReferenceElement changed semantics of int...2017-09-19T17:10:56ZCarsten Gräsergraeser@math.fau.deIntroduction of value semantics for ReferenceElement changed semantics of integrationOuterNormal()Before the restructuring the methods `integrationOuterNormal()`, `position()` and `type()` of `ReferenceElement` returned const references to cached values. After the change these methods all return copies. While it seems natural to retu...Before the restructuring the methods `integrationOuterNormal()`, `position()` and `type()` of `ReferenceElement` returned const references to cached values. After the change these methods all return copies. While it seems natural to return values if the reference elements are returned by values themselves, it breaks compatibility.
A consequence of this are the broken tests in dune-localfunctions. There, the Raviart-Thomas elements store pointers to the result of `integrationOuterNormal()`. While this could be adjusted in dune-localfunctions, users may also run into the same problem breaking their code without an error message.https://gitlab.dune-project.org/core/dune-istl/-/issues/35Suspicious loop condition `i = iend` in ildl.hh:352017-11-03T20:08:14ZJö Fahlkejorrit@jorrit.deSuspicious loop condition `i = iend` in ildl.hh:35https://gitlab.dune-project.org/core/dune-istl/blob/master/dune/istl/ildl.hh#L35:
```c++
template< class Matrix >
inline static void bildl_subtractBCT ( const Matrix &B, const Matrix &CT, Matrix &A )
{
for( auto i = A.begin(), ...https://gitlab.dune-project.org/core/dune-istl/blob/master/dune/istl/ildl.hh#L35:
```c++
template< class Matrix >
inline static void bildl_subtractBCT ( const Matrix &B, const Matrix &CT, Matrix &A )
{
for( auto i = A.begin(), iend = A.end(); i = iend; ++i )
{ // ...
```
This was reported to me by @michael.haidl, who was annoyed by the compiler warning...https://gitlab.dune-project.org/core/dune-common/-/issues/85`FindTBB.cmake` conflicts with other project's `FindTBB.cmake`2020-01-19T20:45:16ZJö Fahlkejorrit@jorrit.de`FindTBB.cmake` conflicts with other project's `FindTBB.cmake`We just had a case that we wanted to build with PACXX, which needs to look for TBB, so it ships a `FindTBB.cmake`. If that version of `FindTBB.cmake` is selected over Dune's `FindTBB.cmake` while building Dune, certain cmake functions (...We just had a case that we wanted to build with PACXX, which needs to look for TBB, so it ships a `FindTBB.cmake`. If that version of `FindTBB.cmake` is selected over Dune's `FindTBB.cmake` while building Dune, certain cmake functions (`add_dune_tbb_flags()`) are missing.Jö Fahlkejorrit@jorrit.deJö Fahlkejorrit@jorrit.dehttps://gitlab.dune-project.org/core/dune-grid/-/issues/70Segmentation fault in test-ug on macOS2020-05-22T07:04:25ZSteffen Müthingsteffen.muething@iwr.uni-heidelberg.deSegmentation fault in test-ug on macOSI get a nasty segfault in the UG destructor when running `test-ug`:
```
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
frame #0: 0x00007fff959312fa libdyld.dylib`stack_not_16_byte_al...I get a nasty segfault in the UG destructor when running `test-ug`:
```
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
frame #0: 0x00007fff959312fa libdyld.dylib`stack_not_16_byte_aligned_error
libdyld.dylib`stack_not_16_byte_aligned_error:
-> 0x7fff959312fa <+0>: movdqa %xmm0, (%rsp)
0x7fff959312ff <+5>: int3
libdyld.dylib`_dyld_func_lookup:
0x7fff95931300 <+0>: pushq %rbp
0x7fff95931301 <+1>: movq %rsp, %rbp
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
* frame #0: 0x00007fff959312fa libdyld.dylib`stack_not_16_byte_aligned_error
frame #1: 0x00007fff5fbfccd0
frame #2: 0x0000000101012a48 libugS2.dylib`UG::D2::DDD_XferEnd() at cmds.cc:445
frame #3: 0x0000000100f95b29 libugS2.dylib`UG::D2::DisposeAMGLevels(theMG=0x0000000102018c00) at ugm.cc:4249
frame #4: 0x0000000100fce584 libugS2.dylib`UG::D2::DisposeBottomHeapTmpMemory(theMG=0x0000000102018c00) at mgheapmgr.cc:100
frame #5: 0x0000000100fbbc37 libugS2.dylib`::PreProcessAdaptMultiGrid(theMG=0x0000000102018c00) at refine.cc:6392
frame #6: 0x0000000100fbbd04 libugS2.dylib`UG::D2::AdaptMultiGrid(theMG=0x0000000102018c00, flag=2, seq=0, mgtest=0) at refine.cc:6465
frame #7: 0x00000001008d9775 libdunegrid.dylib`Dune::UGGrid<2>::adapt(this=0x0000000101d0d6b0) at uggrid.cc:307
frame #8: 0x0000000100010b8a test-ug`void markOne<Dune::UGGrid<2> >(grid=0x0000000101d0d6b0, num=0, ref=1) at test-ug.cc:118
frame #9: 0x000000010000d32d test-ug`generalTests(greenClosure=true) at test-ug.cc:163
frame #10: 0x000000010000d8ce test-ug`main(argc=1, argv=0x00007fff5fbfd740) at test-ug.cc:223
frame #11: 0x00007fff95935235 libdyld.dylib`start + 1
```
I don't have the slightest idea what's wrong here, and I can't even run this under gdb because it causes gdb to hang (this was obtained with lldb).https://gitlab.dune-project.org/core/dune-common/-/issues/84ICE with gcc 7 on the simd-branch2018-05-22T12:02:16ZJö Fahlkejorrit@jorrit.deICE with gcc 7 on the simd-branchhttps://gitlab.dune-project.org/core/dune-common/-/jobs/15682https://gitlab.dune-project.org/core/dune-common/-/jobs/15682https://gitlab.dune-project.org/core/dune-grid/-/issues/69Testing GeometryGrid with DiscreteCoordFunction fails2017-11-10T15:30:25ZOliver Sanderoliver.sander@tu-dresden.deTesting GeometryGrid with DiscreteCoordFunction failsIn !201 I extended the GeometryGrid unit test to also test grids with a DiscreteCoordFunction. Interestingly, this test fails, because the subIndex method in YaspGrid is not implemented for all dimensions. Is this a bug in YaspGrid? I...In !201 I extended the GeometryGrid unit test to also test grids with a DiscreteCoordFunction. Interestingly, this test fails, because the subIndex method in YaspGrid is not implemented for all dimensions. Is this a bug in YaspGrid? In GeometryGrid? Or am I using DiscreteCoordFunction wrongly?DUNE 2.6.0https://gitlab.dune-project.org/core/dune-geometry/-/issues/12Update composite quadraturerule to use the improved refinement interface2017-08-29T14:57:11ZJö Fahlkejorrit@jorrit.deUpdate composite quadraturerule to use the improved refinement interfacePlease update `quadraturerules/compositequadraturerule.hh` to use the new refinement interface. It you feel like it, you may also update it to also provide the new refinement interface.Please update `quadraturerules/compositequadraturerule.hh` to use the new refinement interface. It you feel like it, you may also update it to also provide the new refinement interface.https://gitlab.dune-project.org/core/dune-grid/-/issues/68Parallel GmshReader2018-04-18T09:36:18ZAlireza MazaheriParallel GmshReaderUsing parallel GmshReader results in simulating a problem multiple times.
It looks like the parser needs to be wrapped with, for example, something like this:
`
// create parse object
if (MPIHelper::getCollectiveCommunicat...Using parallel GmshReader results in simulating a problem multiple times.
It looks like the parser needs to be wrapped with, for example, something like this:
`
// create parse object
if (MPIHelper::getCollectiveCommunication().rank() == 0)
{
// create parse object
GmshReaderParser<Grid> parser(factory,verbose,insertBoundarySegments);
parser.read(fileName);
}
`
and similarly for the rest of the file. The above fix appears to fix the issue.https://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-grid/-/issues/67VTK tests take a long time in CI2017-08-30T12:23:53ZSteffen Müthingsteffen.muething@iwr.uni-heidelberg.deVTK tests take a long time in CII just noticed that the VTK tests take a long time in the CI system (more than 10 minutes in total for each target). Is there something we can do about that (smaller grids or maybe build those tests with optimization)? Running those test...I just noticed that the VTK tests take a long time in the CI system (more than 10 minutes in total for each target). Is there something we can do about that (smaller grids or maybe build those tests with optimization)? Running those tests takes more than third of the overall time required for compiling + running...DUNE 2.6.0https://gitlab.dune-project.org/core/dune-grid/-/issues/66External UG support is broken2017-08-30T12:23:53ZMarkus BlattExternal UG support is brokenIf I explicitly disable dune-uggrid and dune-grid falls back to using UG in Debian oldstable, I get the following compilation errors:
```
[ 68%] Building CXX object lib/CMakeFiles/dunegrid.dir/__/dune/grid/io/file/dgfparser/dgfug.cc.o
I...If I explicitly disable dune-uggrid and dune-grid falls back to using UG in Debian oldstable, I get the following compilation errors:
```
[ 68%] Building CXX object lib/CMakeFiles/dunegrid.dir/__/dune/grid/io/file/dgfparser/dgfug.cc.o
In file included from /home/mblatt/src/dune/current/dune-grid/dune/grid/uggrid.hh:63:0,
from /home/mblatt/src/dune/current/dune-grid/dune/grid/io/file/dgfparser/dgfug.hh:19,
from /home/mblatt/src/dune/current/dune-grid/dune/grid/io/file/dgfparser/dgfug.cc:5:
/home/mblatt/src/dune/current/dune-grid/dune/grid/uggrid/ugwrapper.hh: In static member function ‘static void* Dune::UG_NS<2>::CreateDomain(const char*, int, int)’:
/home/mblatt/src/dune/current/dune-grid/dune/grid/uggrid/ugwrapper.hh:1046:65: error: invalid conversion from ‘int’ to ‘const DOUBLE* {aka const double*}’ [-fpermissive]
return UG_NAMESPACE ::CreateDomain(name, segments, corners);
^
/home/mblatt/src/dune/current/dune-grid/dune/grid/uggrid/ugwrapper.hh:1046:65: error: too few arguments to function ‘void* UG::D2::CreateDomain(const char*, const DOUBLE*, UG::DOUBLE, UG::INT, UG::INT, UG::INT)’
In file included from /home/mblatt/src/dune/current/dune-grid/dune/grid/uggrid/ugincludes.hh:16:0,
from /home/mblatt/src/dune/current/dune-grid/dune/grid/uggrid.hh:58,
from /home/mblatt/src/dune/current/dune-grid/dune/grid/io/file/dgfparser/dgfug.hh:19,
from /home/mblatt/src/dune/current/dune-grid/dune/grid/io/file/dgfparser/dgfug.cc:5:
/usr/include/ug/std_domain.h:97:27: note: declared here
void *CreateDomain (const char *name, const DOUBLE *MidPoint,
^
In file included from /home/mblatt/src/dune/current/dune-grid/dune/grid/uggrid.hh:63:0,
from /home/mblatt/src/dune/current/dune-grid/dune/grid/io/file/dgfparser/dgfug.hh:19,
from /home/mblatt/src/dune/current/dune-grid/dune/grid/io/file/dgfparser/dgfug.cc:5:
/home/mblatt/src/dune/current/dune-grid/dune/grid/uggrid/ugwrapper.hh: In static member function ‘static void* Dune::UG_NS<2>::CreateBoundarySegment(const char*, int, int, int, UG::INT*, const double*, const double*, UG::D2::BndSegFuncPtr, void*)’:
/home/mblatt/src/dune/current/dune-grid/dune/grid/uggrid/ugwrapper.hh:1072:59: error: invalid conversion from ‘UG::INT* {aka int*}’ to ‘UG::INT {aka int}’ [-fpermissive]
userData);
^
/home/mblatt/src/dune/current/dune-grid/dune/grid/uggrid/ugwrapper.hh:1072:59: error: cannot convert ‘const double*’ to ‘const INT* {aka const int*}’ for argument ‘7’ to ‘void* UG::D2::CreateBoundarySegment(const char*, UG::INT, UG::INT, UG::INT, UG::D2::BoundaryType, UG::INT, const INT*, const DOUBLE*, const DOUBLE*, UG::D2::BndSegFuncPtr, void*)’
In file included from /home/mblatt/src/dune/current/dune-grid/dune/grid/uggrid.hh:102:0,
from /home/mblatt/src/dune/current/dune-grid/dune/grid/io/file/dgfparser/dgfug.hh:19,
from /home/mblatt/src/dune/current/dune-grid/dune/grid/io/file/dgfparser/dgfug.cc:5:
/home/mblatt/src/dune/current/dune-grid/dune/grid/uggrid/ugwrapper.hh: In static member function ‘static void* Dune::UG_NS<3>::CreateDomain(const char*, int, int)’:
/home/mblatt/src/dune/current/dune-grid/dune/grid/uggrid/ugwrapper.hh:1046:65: error: invalid conversion from ‘int’ to ‘const DOUBLE* {aka const double*}’ [-fpermissive]
/home/mblatt/src/dune/current/dune-grid/dune/grid/uggrid/ugwrapper.hh:1072:59: error: cannot convert ‘const double*’ to ‘const INT* {aka const int*}’ for argument ‘7’ to ‘void* UG::D2::CreateBoundarySegment(const char*, UG::INT, UG::INT, UG::INT, UG::D2::BoundaryType, UG::INT, const INT*, const DOUBLE*, const DOUBLE*, UG::D2::BndSegFuncPtr, void*)’
In file included from /home/mblatt/src/dune/current/dune-grid/dune/grid/uggrid.hh:102:0,
from /home/mblatt/src/dune/current/dune-grid/dune/grid/io/file/dgfparser/dgfug.hh:19,
from /home/mblatt/src/dune/current/dune-grid/dune/grid/io/file/dgfparser/dgfug.cc:5:
/home/mblatt/src/dune/current/dune-grid/dune/grid/uggrid/ugwrapper.hh: In static member function ‘static void* Dune::UG_NS<3>::CreateDomain(const char*, int, int)’:
/home/mblatt/src/dune/current/dune-grid/dune/grid/uggrid/ugwrapper.hh:1046:65: error: invalid conversion from ‘int’ to ‘const DOUBLE* {aka const double*}’ [-fpermissive]
return UG_NAMESPACE ::CreateDomain(name, segments, corners);
^
/home/mblatt/src/dune/current/dune-grid/dune/grid/uggrid/ugwrapper.hh:1046:65: error: too few arguments to function ‘void* UG::D3::CreateDomain(const char*, const DOUBLE*, UG::DOUBLE, UG::INT, UG::INT, UG::INT)’
In file included from /home/mblatt/src/dune/current/dune-grid/dune/grid/uggrid/ugincludes.hh:16:0,
from /home/mblatt/src/dune/current/dune-grid/dune/grid/uggrid.hh:97,
from /home/mblatt/src/dune/current/dune-grid/dune/grid/io/file/dgfparser/dgfug.hh:19,
from /home/mblatt/src/dune/current/dune-grid/dune/grid/io/file/dgfparser/dgfug.cc:5:
/usr/include/ug/std_domain.h:97:27: note: declared here
void *CreateDomain (const char *name, const DOUBLE *MidPoint,
^
In file included from /home/mblatt/src/dune/current/dune-grid/dune/grid/uggrid.hh:102:0,
from /home/mblatt/src/dune/current/dune-grid/dune/grid/io/file/dgfparser/dgfug.hh:19,
from /home/mblatt/src/dune/current/dune-grid/dune/grid/io/file/dgfparser/dgfug.cc:5:
/home/mblatt/src/dune/current/dune-grid/dune/grid/uggrid/ugwrapper.hh: In static member function ‘static void* Dune::UG_NS<3>::CreateBoundarySegment(const char*, int, int, int, UG::INT*, const double*, const double*, UG::D3::BndSegFuncPtr, void*)’:
/home/mblatt/src/dune/current/dune-grid/dune/grid/uggrid/ugwrapper.hh:1072:59: error: invalid conversion from ‘UG::INT* {aka int*}’ to ‘UG::INT {aka int}’ [-fpermissive]
userData);
^
/home/mblatt/src/dune/current/dune-grid/dune/grid/uggrid/ugwrapper.hh:1072:59: error: cannot convert ‘const double*’ to ‘const INT* {aka const int*}’ for argument ‘7’ to ‘void* UG::D3::CreateBoundarySegment(const char*, UG::INT, UG::INT, UG::INT, UG::D3::BoundaryType, UG::INT, const INT*, const DOUBLE*, const DOUBLE*, UG::D3::BndSegFuncPtr, void*)’
lib/CMakeFiles/dunegrid.dir/build.make:146: recipe for target 'lib/CMakeFiles/dunegrid.dir/__/dune/grid/io/file/dgfparser/dgfug.cc.o' failed
make[2]: *** [lib/CMakeFiles/dunegrid.dir/__/dune/grid/io/file/dgfparser/dgfug.cc.o] Error 1
CMakeFiles/Makefile2:4009: recipe for target 'lib/CMakeFiles/dunegrid.dir/all' failed
make[1]: *** [lib/CMakeFiles/dunegrid.dir/all] Error 2
Makefile:147: recipe for target 'all' failed
make: *** [all] Error 2
```
Maybe supporting it has become infeasible, already?https://gitlab.dune-project.org/core/dune-common/-/issues/80dune_python_install_package: avoid error when pip is not installed, but nothi...2017-12-11T15:59:48ZAnsgar Burchardtansgar.burchardt@tu-dresden.dedune_python_install_package: avoid error when pip is not installed, but nothing to install`dune_python_install_package` currently checks that `pip` was found at the beginning of the function and errors out when it was not found. However, when `DUNE_PYTHON_INSTALL_LOCATION` is `none` and `DUNE_PYTHON_VIRTUALENV_SETUP` is fals...`dune_python_install_package` currently checks that `pip` was found at the beginning of the function and errors out when it was not found. However, when `DUNE_PYTHON_INSTALL_LOCATION` is `none` and `DUNE_PYTHON_VIRTUALENV_SETUP` is false, `pip` would never be called.
It would be nice if `dune_python_install_package` would not return an error in this case.DUNE 2.6.0Andreas DednerAndreas Dednerhttps://gitlab.dune-project.org/core/dune-grid/-/issues/65free function `referenceElement(Geometry)`2017-08-30T12:23:53ZAnsgar Burchardtansgar.burchardt@tu-dresden.defree function `referenceElement(Geometry)`[Some time ago][1] we wanted to add a free function to make accessing the reference element easier.
PDELab already has something like this (pdelab/dune-pdelab!116).
The meeting notes say @martin.nolte wanted to look at this.
[1]: htt...[Some time ago][1] we wanted to add a free function to make accessing the reference element easier.
PDELab already has something like this (pdelab/dune-pdelab!116).
The meeting notes say @martin.nolte wanted to look at this.
[1]: https://www.dune-project.org/community/meetings/2015-09-devmeeting/protocol/#sec-7-1-2DUNE 2.6.0https://gitlab.dune-project.org/core/dune-common/-/issues/79locale dependency when parsing ranges in parametertreeparse2017-08-12T21:34:31ZJö Fahlkejorrit@jorrit.delocale dependency when parsing ranges in parametertreeparseThe function `parseRange(const std::string&, Iterator, const Iterator&)` in [parametertree.hh](dune/common/parametertree.hh#L229) is dependent on the current locale, see flyspray/FS#1528.The function `parseRange(const std::string&, Iterator, const Iterator&)` in [parametertree.hh](dune/common/parametertree.hh#L229) is dependent on the current locale, see flyspray/FS#1528.https://gitlab.dune-project.org/core/dune-grid/-/issues/64IndexSet/IdSet interface classes have default constructors2017-08-11T18:21:54ZOliver Sanderoliver.sander@tu-dresden.deIndexSet/IdSet interface classes have default constructorsRecently I noticed that the IndexSet and IdSet interface classes have default constructors. For example, the following code does indeed build:
UGGrid<2>::LocalIdSet foo;
I don't understand why such code should be allowed, because yo...Recently I noticed that the IndexSet and IdSet interface classes have default constructors. For example, the following code does indeed build:
UGGrid<2>::LocalIdSet foo;
I don't understand why such code should be allowed, because you really cannot do anything with such a default-constructed object. Is this a bug? Or is there a purpose that I just don't see?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/78dunecontrol still replaces hyphens by underscores2017-10-30T14:13:37ZOliver Sanderoliver.sander@tu-dresden.dedunecontrol still replaces hyphens by underscoresI tried 'dunecontrol update' in a directory full of Dune modules, and got the error messages
--- calling update for dune-grid ---
Fordere an von origin
Aktualisiere a4de6c24d..ff651f7ce
dune_grid seems to be using git, and could not be
...I tried 'dunecontrol update' in a directory full of Dune modules, and got the error messages
--- calling update for dune-grid ---
Fordere an von origin
Aktualisiere a4de6c24d..ff651f7ce
dune_grid seems to be using git, and could not be
and
--- calling update for dune-book-examples ---
WARNING: dune_book_examples is not under a known version control system.
Both error messages are justified in my case, but note how dunecontrol gets the module names wrong: it replaces the hyphens by underscores.https://gitlab.dune-project.org/core/dune-istl/-/issues/32Verbosity level changes GeneralizedPCGSolver behaviour2017-07-28T10:17:47ZJanick GerstenbergerVerbosity level changes GeneralizedPCGSolver behaviourDuring some experiments with the AMG preconditioner I noticed that the behaviour of the `GeneralizedPCGSolver` changed when using verbosity level >2.
level 1 produces a seemingly working result with output like
```
=== GeneralizedPCGSo...During some experiments with the AMG preconditioner I noticed that the behaviour of the `GeneralizedPCGSolver` changed when using verbosity level >2.
level 1 produces a seemingly working result with output like
```
=== GeneralizedPCGSolver
=== rate=0, T=11.5603, TIT=inf, IT=1
```
the value of T changes but the rest is constant.
using level 2 results in non-convergence
```
=== GeneralizedPCGSolver
Iter Defect Rate
0 0.00256222
1 0.00519744 2.02849
...
6000 0.000353568 0.999963
=== rate=0.99967, T=3.44023, TIT=0.000573372, IT=6001
```
I have not managed to create another example which exhibits the same behaviour, which would be suitable as a test.
Also I expect that all other solver can exhibit the same behaviour since the convergence criterion is handled the same way.https://gitlab.dune-project.org/core/dune-grid/-/issues/63UGGrid should not query size of the message from the data handle on the recei...2018-08-10T09:22:18ZMarkus BlattUGGrid should not query size of the message from the data handle on the receiving side (when loadbalancing)According to a discussion on the mailing list there situations where this is not possible. Yet when scattering UGGrid asks the data handle for the size of the data sent for each element. Later on this size is passed to the scatter method...According to a discussion on the mailing list there situations where this is not possible. Yet when scattering UGGrid asks the data handle for the size of the data sent for each element. Later on this size is passed to the scatter method.
The call occurs in [dune/grid/uggrid/uglbgatherscatter.hh#L99](/core/dune-grid/blob/ff651f7cebb6a9a68306e816d3c17472fcbb09d8/dune/grid/uggrid/uglbgatherscatter.hh#L99). This only happens for the communication with the datahandle when loadbalancing. All other communication seems to use [dune/grid/uggrid/ugmessagebuffer.hh#L83-L107](/core/dune-grid/blob/ff651f7cebb6a9a68306e816d3c17472fcbb09d8/dune/grid/uggrid/ugmessagebuffer.hh#L83-L107) which does the right thing.DUNE 2.6.0