Core Modules issueshttps://gitlab.dune-project.org/groups/core/-/issues2018-01-30T20:18:42Zhttps://gitlab.dune-project.org/core/dune-istl/-/issues/38Mention Vc support in changelog2018-01-30T20:18:42ZJö Fahlkejorrit@jorrit.deMention Vc support in changelogSee also core/dune-common#94See also core/dune-common#94DUNE 2.6.0Christian EngwerChristian Engwer2018-01-26https://gitlab.dune-project.org/core/dune-common/-/issues/95Changelog: add something on Python support2018-02-26T14:40:08ZAndreas DednerChangelog: add something on Python supportDUNE 2.6.0https://gitlab.dune-project.org/core/dune-common/-/issues/94Changelog: any mention of VC etc missing2017-11-13T12:09:18ZAndreas DednerChangelog: any mention of VC etc missingDUNE 2.6.0Jö Fahlkejorrit@jorrit.deJö Fahlkejorrit@jorrit.dehttps://gitlab.dune-project.org/core/dune-common/-/issues/93dunecontrol: `dunecontrol --configure-flags=${flags}` and `dunecontrol config...2017-12-07T23:17:26ZAnsgar Burchardtansgar.burchardt@tu-dresden.dedunecontrol: `dunecontrol --configure-flags=${flags}` and `dunecontrol configure ${flags}` do not work with cmake options@simon.praetorius noticed that the `dunecontrol --configure-flags=${FLAGS}` and `dunecontrol configure ${FLAGS}` commands don't pass ${FLAGS} to cmake.
dunecontrol could be changed to pass them on, but I noticed that there is still some...@simon.praetorius noticed that the `dunecontrol --configure-flags=${FLAGS}` and `dunecontrol configure ${FLAGS}` commands don't pass ${FLAGS} to cmake.
dunecontrol could be changed to pass them on, but I noticed that there is still some code to convert autotools options to cmake options for handling `CXXFLAGS=...` as ${FLAGS}. This would break and users would have to specify -DCMAKE_CXX_COMPILER=... instead.
I believe we should still change dunecontrol as there is currently no way to pass cmake-specific options (`-D...`) to cmake via dunecontrol's command line arguments.DUNE 2.6.0https://gitlab.dune-project.org/core/dune-localfunctions/-/issues/8Multiple uses of deprecated `const ReferenceElement &`2017-11-10T20:32:11ZMartin NolteMultiple uses of deprecated `const ReferenceElement &`Currently, the tests spit out multiple warnings on the deprecated conversion
```
operator const Dune::Geo::DeprecatedReferenceElement<double, 3> &
```
being used:
- `dune/localfunctions/whitney/edges0.5/common.hh`
- `dune/localfunctions/...Currently, the tests spit out multiple warnings on the deprecated conversion
```
operator const Dune::Geo::DeprecatedReferenceElement<double, 3> &
```
being used:
- `dune/localfunctions/whitney/edges0.5/common.hh`
- `dune/localfunctions/rannacherturek/rannachertureklocalinterpolation.hh`DUNE 2.6.0Jö Fahlkejorrit@jorrit.deJö Fahlkejorrit@jorrit.de2017-11-10https://gitlab.dune-project.org/core/dune-geometry/-/issues/15clang fails to compile topologyfactory.hh2017-11-03T12:19:43ZJanick Gerstenbergerclang fails to compile topologyfactory.hhclang (ubunutu:16.4,debian:9) fails with the following errors
```sh
/duneci/modules/dune-geometry/dune/geometry/topologyfactory.hh:133:15: error: member reference base type 'Object *' (aka 'const typename Factory::Object *') is not a st...clang (ubunutu:16.4,debian:9) fails with the following errors
```sh
/duneci/modules/dune-geometry/dune/geometry/topologyfactory.hh:133:15: error: member reference base type 'Object *' (aka 'const typename Factory::Object *') is not a structure or union
object.reset( Factory::create( gt, key ) );
~~~~~~^~~~~~
/duneci/modules/dune-geometry/dune/geometry/topologyfactory.hh:134:20: error: member reference base type 'Object *' (aka 'const typename Factory::Object *') is not a structure or union
return object.get();
~~~~~~^~~~
```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-geometry/-/issues/14Redesign of reference elements not documented in recent changes2017-11-29T17:56:56ZCarsten Gräsergraeser@math.fau.deRedesign of reference elements not documented in recent changesThe changes done in !52 should be mentioned in the 'recent changes'/'release notes'. We should especially highlight the non-compatible changes.The changes done in !52 should be mentioned in the 'recent changes'/'release notes'. We should especially highlight the non-compatible changes.DUNE 2.6.0Steffen Müthingsteffen.muething@iwr.uni-heidelberg.deSteffen Müthingsteffen.muething@iwr.uni-heidelberg.de2017-11-10https://gitlab.dune-project.org/core/dune-common/-/issues/90FieldVector & FieldMatrix -- implicit conversion2017-10-29T10:02:58ZClaus-Justus Heineclaus-justus.heine@ians.uni-stuttgart.deFieldVector & FieldMatrix -- implicit conversionHi there,
the following two constructors are causing trouble for me. Not being "explicit" they lead to implicit type conversion. The concrete example is that a `Fieldvector<SCALAR, DIM>` can be **implicitly** converted to a `FieldVector...Hi there,
the following two constructors are causing trouble for me. Not being "explicit" they lead to implicit type conversion. The concrete example is that a `Fieldvector<SCALAR, DIM>` can be **implicitly** converted to a `FieldVector<FieldMatrix<SCALAR, D1, D2>, DIM>`. The two constructors implementing this bug/feature are
* `dune/common/fmatrix.hh`, around line 100
* `dune/common/fvector.hh`, around line 145
Changing the fmatrix copy-constructor does not seem to be a good idea. But if the FieldVector constructor could be made "explicit", that would be great.
Still, there may be side-effects when changing to "explicit" Dunno.
Cheers,
Claushttps://gitlab.dune-project.org/core/dune-common/-/issues/89Vc still broken in 2.62017-10-31T12:36:50ZJö Fahlkejorrit@jorrit.deVc still broken in 2.6Enabling Vc in the CI: infrastructure/issues0#44
Use of proxies in Vc: #59, to backport: !338, !339
Vc issues with g++-7.2.0: #88, to backport: !341Enabling Vc in the CI: infrastructure/issues0#44
Use of proxies in Vc: #59, to backport: !338, !339
Vc issues with g++-7.2.0: #88, to backport: !341DUNE 2.6.0Jö Fahlkejorrit@jorrit.deJö Fahlkejorrit@jorrit.de2017-11-10https://gitlab.dune-project.org/core/dune-common/-/issues/88Vc issue with c++172017-10-27T08:25:32ZJö Fahlkejorrit@jorrit.deVc issue with c++17See https://gitlab.dune-project.org/core/dune-common/-/jobs/21149
```
[ 28%] Building CXX object dune/common/test/CMakeFiles/concept.dir/concept.cc.o
In file included from /usr/include/Vc/vector.h:252:0,
from /usr/inclu...See https://gitlab.dune-project.org/core/dune-common/-/jobs/21149
```
[ 28%] Building CXX object dune/common/test/CMakeFiles/concept.dir/concept.cc.o
In file included from /usr/include/Vc/vector.h:252:0,
from /usr/include/Vc/Vc:30,
from /builds/core/dune-common/dune/common/test/fmatrixtest.cc:19:
/usr/include/Vc/common/algorithms.h: In function 'Vc_1::enable_if<(! std::is_arithmetic<typename InputIt::value_type>::value), UnaryFunction> Vc_1::simd_for_each_n(InputIt, std::size_t, UnaryFunction)':
/usr/include/Vc/common/algorithms.h:204:17: error: 'for_each_n' is not a member of 'std'
return std::for_each_n(first, count, std::move(f));
^~~~~~~~~~
/usr/include/Vc/common/algorithms.h:204:17: note: suggested alternative: 'for_each'
return std::for_each_n(first, count, std::move(f));
^~~~~~~~~~
for_each
```
Apparently, `Vc/common/algorithms.h` should include `<algorithm>` so `std::for_each_n()` is declared. This is only a problem with c++17 because that code portion is inside an `#ifdef Vc_CXX17`.
Although this is probably an issue in Vc (1.3.2), we're going to have to work around it somehow, since 1.3.2 is packaged...
See also: infrastructure/issues0#44https://gitlab.dune-project.org/core/dune-istl/-/issues/37Remove #warning reminders2017-10-21T12:21:37ZMartin NolteRemove #warning remindersThere are two reminders to rethink the dune-istl interface in form of #warning. These are annoying and do not convey any information to the user.There are two reminders to rethink the dune-istl interface in form of #warning. These are annoying and do not convey any information to the user.DUNE 2.6.0https://gitlab.dune-project.org/core/dune-common/-/issues/87fmatrixtest fails with vc on ubuntu 17.042017-10-05T20:01:45ZCarsten Gräsergraeser@math.fau.defmatrixtest fails with vc on ubuntu 17.04Since I don't use the SIMD stuff I can only provide an error log: [fmatrixtest_error](/uploads/0c686e1ba81ebc34354be4bf7fe368bf/fmatrixtest_error)Since I don't use the SIMD stuff I can only provide an error log: [fmatrixtest_error](/uploads/0c686e1ba81ebc34354be4bf7fe368bf/fmatrixtest_error)https://gitlab.dune-project.org/core/dune-common/-/issues/86Headercheck reports it is disabled2017-10-03T10:37:58ZJanick GerstenbergerHeadercheck reports it is disabledI added `-DENABLE_HEADDERCHECK=1` to my opts files despite that the headercheck reports that it is disabled even after __successfully__ completing.I added `-DENABLE_HEADDERCHECK=1` to my opts files despite that the headercheck reports that it is disabled even after __successfully__ completing.https://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/15682