Core Modules issueshttps://gitlab.dune-project.org/groups/core/-/issues2023-09-29T11:05:40Zhttps://gitlab.dune-project.org/core/dune-grid/-/issues/179FS#1709 Add test for subentity orientation2023-09-29T11:05:40ZCarsten Gräsergraeser@math.fau.deFS#1709 Add test for subentity orientation# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Aug 19, 2015 13:58 |
| Type | Bug Report |
| Version | Git (pre2.4) [cmake] |
| Operating S...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Aug 19, 2015 13:58 |
| Type | Bug Report |
| Version | Git (pre2.4) [cmake] |
| Operating System | Unspecified / All |
# Description
On the developer meeting 2013 we decided that subentities should always have a unique orientation which is in general not consistent with the orientation provided by the reference element embedding.
Checkindexset.hh must be extended to test for this consistency guarantee.
https://gitlab.dune-project.org/core/dune-grid/-/issues/178FS#1550 Make Geometry default constructible2023-09-29T13:53:35ZMartin NolteFS#1550 Make Geometry default constructible
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Jan 9, 2015 10:54 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System | Unspeci...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Jan 9, 2015 10:54 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System | Unspecified / All |
# Description
Geometries are now copy constructible and copy assignable objects. However, in some situations it, like storing geometries in a vector indexed by the index set, a default constructor would be extremely convenient.
As a geometry can always model the identity, there seems no design principle speaking against such default constructibility. Only the return value of "type()" needs to be implementation-defined.
Since nobody will use a default constructed geometry, I would even propose to specify undefined behavior for all methods. This way, implementations simply storing a pointer internally remain trivial.
Are there any reasons not to add this default constructor to the interface?Simon PraetoriusSimon Praetoriushttps://gitlab.dune-project.org/core/dune-grid/-/issues/177FS#1615 Geometry interface not elaborate enough for hessian computation2023-11-04T08:33:47ZChristian EngwerFS#1615 Geometry interface not elaborate enough for hessian computation
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Reported at | Apr 14, 2015 09:13 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System |...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Reported at | Apr 14, 2015 09:13 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System | Unspecified / All |
# Description
If I want to compute the hessian of a discrete function I have to map from local to global coordinates. In this case I need in addition to the jacobianInverseTranspose the same for second derivatives.
This issues is in the first place a reminder for the interface problem ;-)https://gitlab.dune-project.org/core/dune-grid/-/issues/176FS#1285 semantic of maxLevel2023-09-29T10:58:29ZAndreas DednerFS#1285 semantic of maxLevel
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Andreas Dedner (A.S.Dedner@warwick.ac.uk) |
| Reported at | Apr 23, 2013 21:05 |
| Type | FAQ |
| Version | 2.2 |
| Operating System | Unspecified / All |
# D...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Andreas Dedner (A.S.Dedner@warwick.ac.uk) |
| Reported at | Apr 23, 2013 21:05 |
| Type | FAQ |
| Version | 2.2 |
| Operating System | Unspecified / All |
# Description
In a parallel run is the semantics of maxLevel
1) the maxLevel for the local partition?
2) the maxLevel of the grid over all processors?
ALU takes the second view at the moment but I think the first makes more sense and I would like to change ALU's behaviour (no way to make backward compatible...)Santiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.comhttps://gitlab.dune-project.org/core/dune-grid/-/issues/175LoadBalance of GeometryGrid is deactivated2023-10-02T14:32:14ZSimon PraetoriusLoadBalance of GeometryGrid is deactivatedWhen using a `GeometryGrid` wrapper in parallel, it is surprising that the `loadBalance(...)` functions are actually commented out. The effect is that the `GridDefaultImplementation` is used, which means: no load balancing at all. This m...When using a `GeometryGrid` wrapper in parallel, it is surprising that the `loadBalance(...)` functions are actually commented out. The effect is that the `GridDefaultImplementation` is used, which means: no load balancing at all. This means, `GeometryGrid` cannot be used with most grid managers that require a `loadBalance()` call after setup (except if you call that function on the host grid directly).
The corresponding code, see https://gitlab.dune-project.org/core/dune-grid/-/blob/master/dune/grid/geometrygrid/grid.hh?ref_type=heads#L437 simply has an `#if 0` without proper documentation why, since about 13y. So, no-one used `GeometryGrid` in parallel since then?
In my opinion, the behavior is a bug. The proper behavior would be at least an error message if that function does not work with the `GeometryGrid` wrapper. One aspect could probably be difficult: If a `DiscreteCoordFunction` is used that is based on discrete data, then this data also needs to be communicated in the load-balancing step. But, I think, this could be implemented.https://gitlab.dune-project.org/core/dune-istl/-/issues/112Building istl-solver-playground causes compile time error2023-11-28T21:08:36ZGitLab Support BotBuilding istl-solver-playground causes compile time errorHello ISTL Devs,
Thank you so much for maintaining this project.
Here is a short bug report ~
*Bug summary*
Building istl-solver-playground on Intel Mac causes compile time error due
to missing identifier in standard header fenv.h
*To...Hello ISTL Devs,
Thank you so much for maintaining this project.
Here is a short bug report ~
*Bug summary*
Building istl-solver-playground on Intel Mac causes compile time error due
to missing identifier in standard header fenv.h
*To Reproduce*
```
$ pwd
> release-build/dune-istl/src
$ make istl-solver-playground
> [ 0%] Building CXX object
src/CMakeFiles/istl-solver-playground.dir/istl-solver-playground.cc.o
DUNE/dune-istl/src/istl-solver-playground.cc:104:6: error: use of
undeclared identifier 'feenableexcept'; did you mean 'feraiseexcept'?
feenableexcept(FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW);// | FE_UNDERFLOW);
^~~~~~~~~~~~~~
feraiseexcept
/Library/Developer/CommandLineTools/SDKs/MacOSX12.3.sdk/usr/include/fenv.h:299:12:
note: 'feraiseexcept' declared here
extern int feraiseexcept(int /* excepts */);
^
1 error generated
```
*Expected behavior*
Should be able to find the correct identifier based on the platform.
*Describe your setup*
* Source: Tested on branches master and release/2.9 from
https://gitlab.dune-project.org/core/dune-istl.git
* Compiler: Homebrew clang version 16.0.3
* Target: x86_64-apple-darwin21.6.0, MacOSX12.3.sdk
* Cmake version 3.27.4
* GNU Make 4.4.1
*Additional context*
1. `feenableexcept` must be within preprocessor conditionals to guard
against its compilation on Mac and windows. Both of them instead have
`feraiseexecpt`. I have tested this only on MacOS and it fixes the issue.
Best wishes,
Sanchihttps://gitlab.dune-project.org/core/dune-grid/-/issues/174Feature request: include UGGrid in dune.grid python bindings2023-09-26T14:15:01ZChristian EngwerFeature request: include UGGrid in dune.grid python bindingsCurrently UGGrid is not bundled in the `dune-grid` python bindings. As UGGrid is an optional dependency of `dune-grid`, it is not (easily) possible to offer different python packages. I suggest to include UGGrid in the default `dune-grid...Currently UGGrid is not bundled in the `dune-grid` python bindings. As UGGrid is an optional dependency of `dune-grid`, it is not (easily) possible to offer different python packages. I suggest to include UGGrid in the default `dune-grid` packages.https://gitlab.dune-project.org/core/dune-common/-/issues/352DUNE ENV 2.02024-02-22T15:19:29ZRobert KDUNE ENV 2.0The desire is to build DUNE without automatic virtual env creation and pip install.
Related to
- !222.
- !960
- !1104The desire is to build DUNE without automatic virtual env creation and pip install.
Related to
- !222.
- !960
- !1104https://gitlab.dune-project.org/core/dune-grid/-/issues/173MultipleCodimMultipleGeomTypeMapper not assignable2023-09-07T09:56:57ZChristian EngwerMultipleCodimMultipleGeomTypeMapper not assignableUntil 2017 the mapper was assignable. Later the `layout_` was changed to be `const`, which broke the (default) assignment.
Is this in purpose?
In general I'd consider assignability as something natural for this type of data. The fix wo...Until 2017 the mapper was assignable. Later the `layout_` was changed to be `const`, which broke the (default) assignment.
Is this in purpose?
In general I'd consider assignability as something natural for this type of data. The fix would be relatively simple.
@core: comments?https://gitlab.dune-project.org/core/dune-common/-/issues/351[Python bindings] Compilation fails with Python 3.112023-08-30T11:01:21ZValentina Schüller[Python bindings] Compilation fails with Python 3.11Installing `dune-common` fails when using Python 3.11, seemingly due to issues in the `pybind11` code. The error messages I get are very similar to those reported [here](https://github.com/sirfz/tesserocr/issues/298) and fixing it is see...Installing `dune-common` fails when using Python 3.11, seemingly due to issues in the `pybind11` code. The error messages I get are very similar to those reported [here](https://github.com/sirfz/tesserocr/issues/298) and fixing it is seemingly related to using a newer version of cython which supports Python 3.11. E.g.,
```plaintext
FAILED: python/dune/typeregistry/CMakeFiles/_typeregistry.dir/_typeregistry.cc.o
/usr/bin/g++-12 -DENABLE_GMP=1 -DENABLE_MPI=1 -DENABLE_QUADMATH=1 -DHAVE_CONFIG_H -D_GLIBCXX_USE_FLOAT128 -D_typeregistry_EXPORTS -I/tmp/pip-install-enwkyj4j/dune-common_30d26d5c16504f4cadc30ff0c9fb6446/_skbuild/linux-x86_64-3.11/cmake-build -I/tmp/pip-install-enwkyj4j/dune-common_30d26d5c16504f4cadc30ff0c9fb6446 -I/home/valentina/mambaforge/envs/richards-swe/include/python3.11 -std=c++17 -O3 -DNDEBUG -O3 -DNDEBUG -fPIC -fext-numeric-literals -MD -MT python/dune/typeregistry/CMakeFiles/_typeregistry.dir/_typeregistry.cc.o -MF python/dune/typeregistry/CMakeFiles/_typeregistry.dir/_typeregistry.cc.o.d -o python/dune/typeregistry/CMakeFiles/_typeregistry.dir/_typeregistry.cc.o -c /tmp/pip-install-enwkyj4j/dune-common_30d26d5c16504f4cadc30ff0c9fb6446/python/dune/typeregistry/_typeregistry.cc
In file included from /tmp/pip-install-enwkyj4j/dune-common_30d26d5c16504f4cadc30ff0c9fb6446/dune/python/pybind11/attr.h:13,
from /tmp/pip-install-enwkyj4j/dune-common_30d26d5c16504f4cadc30ff0c9fb6446/dune/python/pybind11/pybind11.h:45,
from /tmp/pip-install-enwkyj4j/dune-common_30d26d5c16504f4cadc30ff0c9fb6446/dune/python/common/typeregistry.hh:21,
from /tmp/pip-install-enwkyj4j/dune-common_30d26d5c16504f4cadc30ff0c9fb6446/python/dune/typeregistry/_typeregistry.cc:8:
/tmp/pip-install-enwkyj4j/dune-common_30d26d5c16504f4cadc30ff0c9fb6446/dune/python/pybind11/cast.h: In function ‘std::string pybind11::detail::error_string()’:
/tmp/pip-install-enwkyj4j/dune-common_30d26d5c16504f4cadc30ff0c9fb6446/dune/python/pybind11/cast.h:446:36: error: invalid use of incomplete type ‘PyFrameObject’ {aka ‘struct _frame’}
446 | " " + handle(frame->f_code->co_filename).cast<std::string>() +
```
_See the attached file for the full error output:_ [dune_common_output.txt](/uploads/1fded00175fb83a485405c650a753bbf/dune_common_output.txt)
**Note:** This issue will most probably apply to `dune-grid`, `dune-fem`, etc. I have decided to open it here since this seems to be the baseline package for all of the others.
Here is some information about my system:
- `g++-12 --version`: 12.3.0
- `python3 --version`: Python 3.11.4
Full conda environment:
```plaintext
# Name Version Build Channel
_libgcc_mutex 0.1 conda_forge conda-forge
_openmp_mutex 4.5 2_gnu conda-forge
bzip2 1.0.8 h7f98852_4 conda-forge
ca-certificates 2023.7.22 hbcca054_0 conda-forge
ld_impl_linux-64 2.40 h41732ed_0 conda-forge
libexpat 2.5.0 hcb278e6_1 conda-forge
libffi 3.4.2 h7f98852_5 conda-forge
libgcc-ng 13.1.0 he5830b7_0 conda-forge
libgomp 13.1.0 he5830b7_0 conda-forge
libnsl 2.0.0 h7f98852_0 conda-forge
libsqlite 3.42.0 h2797004_0 conda-forge
libuuid 2.38.1 h0b41bf4_0 conda-forge
libzlib 1.2.13 hd590300_5 conda-forge
ncurses 6.4 hcb278e6_0 conda-forge
openssl 3.1.2 hd590300_0 conda-forge
pip 23.2.1 pyhd8ed1ab_0 conda-forge
python 3.11.4 hab00c5b_0_cpython conda-forge
readline 8.2 h8228510_1 conda-forge
setuptools 68.1.2 pyhd8ed1ab_0 conda-forge
tk 8.6.12 h27826a3_0 conda-forge
tzdata 2023c h71feb2d_0 conda-forge
wheel 0.41.2 pyhd8ed1ab_0 conda-forge
xz 5.2.6 h166bdaf_0 conda-forge
```
Let me know if you need any additional information!
Best,
Valentinahttps://gitlab.dune-project.org/core/dune-localfunctions/-/issues/22Thread safety.2023-09-19T15:05:29ZRobert KThread safety.It seems that the evaluation of shape functions is not thread safe. Is this something that can be fixed easily?It seems that the evaluation of shape functions is not thread safe. Is this something that can be fixed easily?Santiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.comhttps://gitlab.dune-project.org/core/dune-common/-/issues/350Vc code not compiling2023-12-21T16:12:35ZChristoph GrüningerVc code not compilingThe expensive tests were not run for !1275, so I decided to install Vc and test locally. To my surprise I cannot compile dune-common's Vc/SIMD tests, as they fail with ambiguous overloads. This happens for master and both GCC 13 and Clan...The expensive tests were not run for !1275, so I decided to install Vc and test locally. To my surprise I cannot compile dune-common's Vc/SIMD tests, as they fail with ambiguous overloads. This happens for master and both GCC 13 and Clang 16. (Vc 1.4.3, most recent).
Is anybody using Vc? Is it me or my new compilers? What happyenden to the runners of the expensive tests?
I have to yet tried the 2.9 branch, maybe we have to fix this prior to the upcoming patch release 2.9.1.DUNE 2.10.0https://gitlab.dune-project.org/core/dune-common/-/issues/349debugaligntest fails with Clang 17 branch2023-12-21T16:12:25ZChristoph Grüningerdebugaligntest fails with Clang 17 branch`debugaligntest` fails with Clang 16 (and the not yet released version of Clang 17). With g++ 13 I see no issue. Any idea what went wrong?
```
> ./debugaligntest
CHECK FAILED(default construct): misalignment not detected for Dune::Al...`debugaligntest` fails with Clang 16 (and the not yet released version of Clang 17). With g++ 13 I see no issue. Any idea what went wrong?
```
> ./debugaligntest
CHECK FAILED(default construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<bool, 32ul>
CHECK FAILED(destruct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<bool, 32ul>
CHECK FAILED(move construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<bool, 32ul>
CHECK FAILED(copy construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<bool, 32ul>
CHECK FAILED(default construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<char, 32ul>
CHECK FAILED(destruct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<char, 32ul>
CHECK FAILED(move construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<char, 32ul>
CHECK FAILED(copy construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<char, 32ul>
CHECK FAILED(default construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<signed char, 32ul>
CHECK FAILED(destruct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<signed char, 32ul>
CHECK FAILED(move construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<signed char, 32ul>
CHECK FAILED(copy construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<signed char, 32ul>
CHECK FAILED(default construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<unsigned char, 32ul>
CHECK FAILED(destruct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<unsigned char, 32ul>
CHECK FAILED(move construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<unsigned char, 32ul>
CHECK FAILED(copy construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<unsigned char, 32ul>
CHECK FAILED(default construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<short, 32ul>
CHECK FAILED(destruct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<short, 32ul>
CHECK FAILED(move construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<short, 32ul>
CHECK FAILED(copy construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<short, 32ul>
CHECK FAILED(default construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<unsigned short, 32ul>
CHECK FAILED(destruct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<unsigned short, 32ul>
CHECK FAILED(move construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<unsigned short, 32ul>
CHECK FAILED(copy construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<unsigned short, 32ul>
CHECK FAILED(default construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<int, 32ul>
CHECK FAILED(destruct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<int, 32ul>
CHECK FAILED(move construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<int, 32ul>
CHECK FAILED(copy construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<int, 32ul>
CHECK FAILED(default construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<unsigned int, 32ul>
CHECK FAILED(destruct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<unsigned int, 32ul>
CHECK FAILED(move construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<unsigned int, 32ul>
CHECK FAILED(copy construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<unsigned int, 32ul>
CHECK FAILED(default construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<long, 32ul>
CHECK FAILED(destruct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<long, 32ul>
CHECK FAILED(move construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<long, 32ul>
CHECK FAILED(copy construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<long, 32ul>
CHECK FAILED(default construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<unsigned long, 32ul>
CHECK FAILED(destruct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<unsigned long, 32ul>
CHECK FAILED(move construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<unsigned long, 32ul>
CHECK FAILED(copy construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<unsigned long, 32ul>
CHECK FAILED(default construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<long long, 32ul>
CHECK FAILED(destruct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<long long, 32ul>
CHECK FAILED(move construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<long long, 32ul>
CHECK FAILED(copy construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<long long, 32ul>
CHECK FAILED(default construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<unsigned long long, 32ul>
CHECK FAILED(destruct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<unsigned long long, 32ul>
CHECK FAILED(move construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<unsigned long long, 32ul>
CHECK FAILED(copy construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<unsigned long long, 32ul>
CHECK FAILED(default construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<wchar_t, 32ul>
CHECK FAILED(destruct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<wchar_t, 32ul>
CHECK FAILED(move construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<wchar_t, 32ul>
CHECK FAILED(copy construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<wchar_t, 32ul>
CHECK FAILED(default construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<char16_t, 32ul>
CHECK FAILED(destruct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<char16_t, 32ul>
CHECK FAILED(move construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<char16_t, 32ul>
CHECK FAILED(copy construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<char16_t, 32ul>
CHECK FAILED(default construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<char32_t, 32ul>
CHECK FAILED(destruct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<char32_t, 32ul>
CHECK FAILED(move construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<char32_t, 32ul>
CHECK FAILED(copy construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<char32_t, 32ul>
CHECK FAILED(default construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<float, 32ul>
CHECK FAILED(destruct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<float, 32ul>
CHECK FAILED(move construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<float, 32ul>
CHECK FAILED(copy construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<float, 32ul>
CHECK FAILED(default construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<double, 32ul>
CHECK FAILED(destruct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<double, 32ul>
CHECK FAILED(move construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<double, 32ul>
CHECK FAILED(copy construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<double, 32ul>
CHECK FAILED(default construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<long double, 32ul>
CHECK FAILED(destruct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<long double, 32ul>
CHECK FAILED(move construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<long double, 32ul>
CHECK FAILED(copy construct): misalignment not detected for Dune::AlignedNumberImpl::AlignedNumber<long double, 32ul>
TEST FAILED: 72/8103 checks failed in this test.
```DUNE 2.10.0https://gitlab.dune-project.org/core/dune-common/-/issues/348Storage duration of MPIHelper singleton2024-02-22T09:53:43ZSantiago Ospina De Los Ríossospinar@gmail.comStorage duration of MPIHelper singletonThe following discussion from !1274 should be addressed:
- [ ] @andreas.dedner started a [discussion](https://gitlab.dune-project.org/core/dune-common/-/merge_requests/1274#note_129413): (+4 comments)
> Just wanted to mention that...The following discussion from !1274 should be addressed:
- [ ] @andreas.dedner started a [discussion](https://gitlab.dune-project.org/core/dune-common/-/merge_requests/1274#note_129413): (+4 comments)
> Just wanted to mention that we ran into problem with this singleton pattern with the python bindings - in fact the issue can come up with any code that combines multiple object files I believe.
> The issue has to do with 'semantic interposition` and leads to segfaults with clang:
>
> Basically, clang did not guarantee that these singleton are unique between different units. So the variable would be initialized in one object file but there might be a separate version of the `singleton` in a different unit that was not initialized. That obviously leads to problems. I looked at this some time ago and by default gcc assumes semantic-interposition if not explicitly turned off (that is the ELF default). The version of clang that was available at the time (2y ago but don't have the version) provided no semantic-interposition by default and unfortunately had no flag to turn it on.
>
> We solved the problem in dune-fem by putting the singleton into `libdunefem` which all other modules link against. That makes the singleton truly unique. The hard ones we had were template dependent singletons...
>
> The following blog post that I found at the time has been updated in 2022 and apparently clang has a flag now to turn on `semantic interposition`: https://maskray.me/blog/2021-05-09-fno-semantic-interposition
> So we could probably require that flag for python bindings to avoid the issue or possibly the singleton can be instantiated in `libdunecommon`.Andreas DednerAndreas Dednerhttps://gitlab.dune-project.org/core/dune-common/-/issues/347dune_add_test does not work with aliased targets2023-08-01T16:03:30ZSantiago Ospina De Los Ríossospinar@gmail.comdune_add_test does not work with aliased targetsIt turns out that non-mutable targets are not usable with `dune_add_test` because the dune testing facilities want to mutate the target.
* With the introduction of !1247, we want to make more regular usage of aliased targets as they rep...It turns out that non-mutable targets are not usable with `dune_add_test` because the dune testing facilities want to mutate the target.
* With the introduction of !1247, we want to make more regular usage of aliased targets as they represent the non-mutable version of a target.
* Another instance of this case is when using an imported library or executable. Since they are imported, they are non-mutable.
The offending line is [here](https://gitlab.dune-project.org/core/dune-common/-/blob/48a5251d7f79d0203b7b20933b8589386212a8b9/cmake/modules/DuneTestMacros.cmake#L362), where the test wants to modify the properties of the target to (not) be excluded from `make all`.
```cmake
# Make sure to exclude the target from all, even when it is user-provided
if(DUNE_BUILD_TESTS_ON_MAKE_ALL AND (NOT ADDTEST_EXPECT_COMPILE_FAIL))
set_property(TARGET ${ADDTEST_TARGET} PROPERTY EXCLUDE_FROM_ALL 0)
else()
set_property(TARGET ${ADDTEST_TARGET} PROPERTY EXCLUDE_FROM_ALL 1)
endif()
```https://gitlab.dune-project.org/core/dune-common/-/issues/346ParallelError in dune-grid Python bindings with OpenMPI2023-09-22T14:15:23ZValentina SchüllerParallelError in dune-grid Python bindings with OpenMPIHi everyone,
I encountered an issue with the DUNE Python bindings last week, which I can trigger by calling `dune.grid.structuredGrid()`.
To summarize: I have to call `from mpi4py import MPI` before using functions from `dune.grid`, oth...Hi everyone,
I encountered an issue with the DUNE Python bindings last week, which I can trigger by calling `dune.grid.structuredGrid()`.
To summarize: I have to call `from mpi4py import MPI` before using functions from `dune.grid`, otherwise DUNE throws a `ParallelError`:
```py
import dune.grid
# from mpi4py import MPI <-- this line will prevent the RuntimeError
dune.grid.structuredGrid([-1], [0], [10])
```
```
RuntimeError: ParallelError [Communication:/home/valentina/mambaforge/envs/richards-swe/include/dune/common/parallel/mpicommunication.hh:118]:
You must call MPIHelper::instance(argc,argv) in your main() function before using the MPI Communication!
```
It seems like MPI is not initialized properly by the Python bindings in this setup.
**Remark 1.** The following additional import statements _do not_ prevent this error:
- `import mpi4py`
- `import dune.common`
- it also does not help to do `from dune.grid import structuredGrid`
**Remark 2.** If I use MPICH instead of OpenMPI, I do not need `from mpi4py import MPI`. Checking the [DUNE source code for the error](https://github.com/dune-project/dune-common/blob/master/dune/common/parallel/mpicommunication.hh#L118) indicates that there is a difference between OpenMPI and MPICH with respect to how/if MPI is initialized by DUNE/the Python bindings?
**Remark 3.** Note that I never actually use `MPI` from mpi4py in this example. A linter will thus complain about the import statement, which is unfortunate.
## Environment
Latest version of DUNE modules installed via PyPI (`pip install dune-fem`):
```
dune-alugrid 2.9.0.2
dune-common 2.9.0
dune-fem 2.9.0.2
dune-geometry 2.9.0
dune-grid 2.9.0
dune-istl 2.9.0
dune-localfunctions 2.9.0
...
mpi4py 3.1.4
```
- Python: 3.10.11 (inside a mamba/conda environment)
- gcc/g++ 11.3 (Ubuntu 22.04)
- OpenMPI: 4.1.2.
I verified that OpenMPI and mpi4py are installed and working correctly on my system, using a [simple MPI example](https://mpitutorial.com/tutorials/mpi-hello-world/) and the [first example from the mpi4py tutorial](https://mpi4py.readthedocs.io/en/stable/tutorial.html#point-to-point-communication).
Let me know if you need any additional information!
Best,
ValentinaAndreas DednerAndreas Dednerhttps://gitlab.dune-project.org/core/dune-grid/-/issues/172ParallelError in dune-grid Python bindings with OpenMPI2023-07-14T08:44:01ZValentina SchüllerParallelError in dune-grid Python bindings with OpenMPIHi everyone,
I encountered an issue with the DUNE Python bindings last week, which I can trigger by calling `dune.grid.structuredGrid()`.
To summarize: I have to call `from mpi4py import MPI` before using functions from `dune.grid`, oth...Hi everyone,
I encountered an issue with the DUNE Python bindings last week, which I can trigger by calling `dune.grid.structuredGrid()`.
To summarize: I have to call `from mpi4py import MPI` before using functions from `dune.grid`, otherwise DUNE throws a `ParallelError`:
```py
import dune.grid
# from mpi4py import MPI <-- this line will prevent the RuntimeError
dune.grid.structuredGrid([-1], [0], [10])
```
```
RuntimeError: ParallelError [Communication:/home/valentina/mambaforge/envs/richards-swe/include/dune/common/parallel/mpicommunication.hh:118]:
You must call MPIHelper::instance(argc,argv) in your main() function before using the MPI Communication!
```
It seems like MPI is not initialized properly by the Python bindings in this setup.
**Remark 1.** The following additional import statements _do not_ prevent this error:
- `import mpi4py`
- `import dune.common`
- it also does not help to do `from dune.grid import structuredGrid`
**Remark 2.** If I use MPICH instead of OpenMPI, I do not need `from mpi4py import MPI`. Checking the [DUNE source code for the error](https://github.com/dune-project/dune-common/blob/master/dune/common/parallel/mpicommunication.hh#L118) indicates that there is a difference between OpenMPI and MPICH with respect to how/if MPI is initialized by DUNE/the Python bindings?
**Remark 3.** Note that I never actually use `MPI` from mpi4py in this example. A linter will thus complain about the import statement, which is unfortunate.
## Environment
Latest version of DUNE modules installed via PyPI (`pip install dune-fem`):
```
dune-alugrid 2.9.0.2
dune-common 2.9.0
dune-fem 2.9.0.2
dune-geometry 2.9.0
dune-grid 2.9.0
dune-istl 2.9.0
dune-localfunctions 2.9.0
...
mpi4py 3.1.4
```
- Python: 3.10.11 (inside a mamba/conda environment)
- gcc/g++ 11.3 (Ubuntu 22.04)
- OpenMPI: 4.1.2.
I verified that OpenMPI and mpi4py are installed and working correctly on my system, using a [simple MPI example](https://mpitutorial.com/tutorials/mpi-hello-world/) and the [first example from the mpi4py tutorial](https://mpi4py.readthedocs.io/en/stable/tutorial.html#point-to-point-communication).
Let me know if you need any additional information!
Best,
Valentinahttps://gitlab.dune-project.org/core/dune-grid/-/issues/171Incomplete type `Dune::dgf::PeriodicFaceTransformationBlock::AffineTransforma...2023-07-13T09:30:32ZChristian HeinigkIncomplete type `Dune::dgf::PeriodicFaceTransformationBlock::AffineTransformation` with clang-15.0.7Hi all,
building the `releases/v2.9` and `master` branches with `clang 15.0.7` runs into the following error in an `ubuntu:lunar` container:
```
[ 47%] Building CXX object CMakeFiles/dunegrid.dir/dune/grid/io/file/dgfparser/blocks/ver...Hi all,
building the `releases/v2.9` and `master` branches with `clang 15.0.7` runs into the following error in an `ubuntu:lunar` container:
```
[ 47%] Building CXX object CMakeFiles/dunegrid.dir/dune/grid/io/file/dgfparser/blocks/vertex.cc.o
In file included from /dune/dune-grid/dune/grid/io/file/dgfparser/blocks/periodicfacetrans.cc:7:
In file included from /dune/dune-grid/dune/grid/io/file/dgfparser/blocks/periodicfacetrans.hh:9:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/vector:64:
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/stl_vector.h:1143:34: error: arithmetic on a pointer to an incomplete type 'Dune::dgf::PeriodicFaceTransformationBlock::AffineTransformation'
return *(this->_M_impl._M_start + __n);
~~~~~~~~~~~~~~~~~~~~~~ ^
/dune/dune-grid/dune/grid/io/file/dgfparser/blocks/periodicfacetrans.hh:44:32: note: in instantiation of member function 'std::vector<Dune::dgf::PeriodicFaceTransformationBlock::AffineTransformation>::operator[]' requested here
return transformations_[ i ];
^
/dune/dune-grid/dune/grid/io/file/dgfparser/blocks/periodicfacetrans.hh:29:14: note: forward declaration of 'Dune::dgf::PeriodicFaceTransformationBlock::AffineTransformation'
struct AffineTransformation;
^
In file included from /dune/dune-grid/dune/grid/io/file/dgfparser/blocks/periodicfacetrans.cc:7:
In file included from /dune/dune-grid/dune/grid/io/file/dgfparser/blocks/periodicfacetrans.hh:9:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/vector:64:
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/stl_vector.h:988:50: error: arithmetic on a pointer to an incomplete type 'Dune::dgf::PeriodicFaceTransformationBlock::AffineTransformation'
{ return size_type(this->_M_impl._M_finish - this->_M_impl._M_start); }
~~~~~~~~~~~~~~~~~~~~~~~ ^
/dune/dune-grid/dune/grid/io/file/dgfparser/blocks/periodicfacetrans.hh:49:33: note: in instantiation of member function 'std::vector<Dune::dgf::PeriodicFaceTransformationBlock::AffineTransformation>::size' requested here
return transformations_.size();
^
/dune/dune-grid/dune/grid/io/file/dgfparser/blocks/periodicfacetrans.hh:29:14: note: forward declaration of 'Dune::dgf::PeriodicFaceTransformationBlock::AffineTransformation'
struct AffineTransformation;
^
[ 52%] Building CXX object CMakeFiles/dunegrid.dir/dune/grid/io/file/dgfparser/dgfparser.cc.o
2 errors generated.
gmake[2]: *** [CMakeFiles/dunegrid.dir/build.make:188: CMakeFiles/dunegrid.dir/dune/grid/io/file/dgfparser/blocks/periodicfacetrans.cc.o] Error 1
gmake[2]: *** Waiting for unfinished jobs....
In file included from /dune/dune-grid/dune/grid/io/file/dgfparser/dgfparser.cc:14:
In file included from /dune/dune-geometry/dune/geometry/referenceelements.hh:14:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/vector:64:
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/stl_vector.h:1143:34: error: arithmetic on a pointer to an incomplete type 'Dune::dgf::PeriodicFaceTransformationBlock::AffineTransformation'
return *(this->_M_impl._M_start + __n);
~~~~~~~~~~~~~~~~~~~~~~ ^
/dune/dune-grid/dune/grid/io/file/dgfparser/blocks/periodicfacetrans.hh:44:32: note: in instantiation of member function 'std::vector<Dune::dgf::PeriodicFaceTransformationBlock::AffineTransformation>::operator[]' requested here
return transformations_[ i ];
^
/dune/dune-grid/dune/grid/io/file/dgfparser/blocks/periodicfacetrans.hh:29:14: note: forward declaration of 'Dune::dgf::PeriodicFaceTransformationBlock::AffineTransformation'
struct AffineTransformation;
^
In file included from /dune/dune-grid/dune/grid/io/file/dgfparser/dgfparser.cc:14:
In file included from /dune/dune-geometry/dune/geometry/referenceelements.hh:14:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/vector:64:
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/stl_vector.h:988:50: error: arithmetic on a pointer to an incomplete type 'Dune::dgf::PeriodicFaceTransformationBlock::AffineTransformation'
{ return size_type(this->_M_impl._M_finish - this->_M_impl._M_start); }
~~~~~~~~~~~~~~~~~~~~~~~ ^
/dune/dune-grid/dune/grid/io/file/dgfparser/blocks/periodicfacetrans.hh:49:33: note: in instantiation of member function 'std::vector<Dune::dgf::PeriodicFaceTransformationBlock::AffineTransformation>::size' requested here
return transformations_.size();
^
/dune/dune-grid/dune/grid/io/file/dgfparser/blocks/periodicfacetrans.hh:29:14: note: forward declaration of 'Dune::dgf::PeriodicFaceTransformationBlock::AffineTransformation'
struct AffineTransformation;
^
2 errors generated.
gmake[2]: *** [CMakeFiles/dunegrid.dir/build.make:258: CMakeFiles/dunegrid.dir/dune/grid/io/file/dgfparser/dgfparser.cc.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:1897: CMakeFiles/dunegrid.dir/all] Error 2
gmake: *** [Makefile:146: all] Error 2
--- Failed to build dune-grid ---
```
I'm resulting to an older image at the moment, because I have not much time to debug this. I just wanted to write this issue down somewhere and figured you might want to take a look.
Best,
Christianhttps://gitlab.dune-project.org/core/dune-common/-/issues/345Document how to make interdependent targets on different namespaces2023-10-05T11:35:07ZSantiago Ospina De Los Ríossospinar@gmail.comDocument how to make interdependent targets on different namespacesThe following discussion from !1247 should be addressed:
- [ ] @simon.praetorius started a [discussion](https://gitlab.dune-project.org/core/dune-common/-/merge_requests/1247#note_129022): (+13 comments)
> Unfortunately, this does...The following discussion from !1247 should be addressed:
- [ ] @simon.praetorius started a [discussion](https://gitlab.dune-project.org/core/dune-common/-/merge_requests/1247#note_129022): (+13 comments)
> Unfortunately, this does not work properly. If one target depends on the other target (e.g. via `target_link_libraries`), the dependency must be included before. Otherwise I get the fatal error "The following imported targets are referenced, but are missing..." automatically generated in the target file. Not sure how to fix this properly. I have to create the libraries in the right order, I think, and then it works. But this is not the way to want to resolve dependencies.https://gitlab.dune-project.org/core/dune-common/-/issues/344Split exported targets in module and others2024-03-03T12:51:35ZSantiago Ospina De Los Ríossospinar@gmail.comSplit exported targets in module and othersThe following discussion from !1247 should be addressed:
- [ ] @simon.praetorius started a [discussion](https://gitlab.dune-project.org/core/dune-common/-/merge_requests/1247#note_129102): (+2 comments)
> I think here was a misund...The following discussion from !1247 should be addressed:
- [ ] @simon.praetorius started a [discussion](https://gitlab.dune-project.org/core/dune-common/-/merge_requests/1247#note_129102): (+2 comments)
> I think here was a misunderstanding: "MODULE_LIBRARY" just means that it can be linked by default and is part of DUNE_LIBS, I think. But, if `NO_MODULE_LIBRARY` is set, we do not mean that it should not be exported, it just should not be linked by default to all targets. Example: dunealbertagridXd in dune-grid. This is excluded from the list of module libraries, because we don't know which dimensionworld should be used. This has to be selected by the user when calling `add_dune_alberta_flags`. Now, if it is not a module library, it is not put into the INTERFACE_LIBRARIES set and thus no unscoped targets are created. Thus, dune-grid alberta cannot be used in downstream target. This is just one example, where we can find a fix in dune-grid soon. But in other modules this might be more critical.
>
> We need to merge https://gitlab.dune-project.org/core/dune-grid/-/merge_requests/709 otherwise albertagrid cannot be used.DUNE 2.10.0Santiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.com