Core Modules issueshttps://gitlab.dune-project.org/groups/core/-/issues2023-10-02T15:41:54Zhttps://gitlab.dune-project.org/core/dune-grid/-/issues/181GridFactory should export element permutation2023-10-02T15:41:54ZSimon PraetoriusGridFactory should export element permutation### Summary
When creating a grid using a grid factory, the element numbering put into the factory is not necessarily the numbering ending up in the created grid, e.g. `ALUGrid` performs some renumbering - I think to guarantee that the gr...### Summary
When creating a grid using a grid factory, the element numbering put into the factory is not necessarily the numbering ending up in the created grid, e.g. `ALUGrid` performs some renumbering - I think to guarantee that the grid can always be refined by bisection afterwards. This renumbering is not directly exported but is required for some applications, e.g., when we also have stored a finite element basis associated to the local vertices, or a geometry mapping. While we have the `insertionIndex` of elements and vertices we can compute the element permutation afterwards, but one always has to think about this again how to do it without comparing coordinates.
1. Is there an easy way to extract this permutation that I am simply not aware of?
2. Would this be a useful interface extension of the `GridFactory` or better a utility next to it?https://gitlab.dune-project.org/core/dune-grid/-/issues/180FS#1714 Generalize intersection concept for network grids2023-09-29T11:06:15ZOliver Sanderoliver.sander@tu-dresden.deFS#1714 Generalize intersection concept for network grids
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Reported at | Sep 4, 2015 10:50 |
| Type | Feature Request |
| Version | Git (pre2.4) [cmake] |
| Operating Sys...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Reported at | Sep 4, 2015 10:50 |
| Type | Feature Request |
| Version | Git (pre2.4) [cmake] |
| Operating System | Unspecified / All |
# Description
Together with Timo Koch and Natalie Schröder (and a few others), I have recently put some work into FoamGrid, a grid manager for 1d and 2d network grids.
Check it out at users.dune-project.org/projects/dune-foamgrid
As it turns out, the intersection concept in dune-grid is not quite general enough for network grids. Therefore, I request certain generalizations to the dune grid interface to improve working with network grids. On the way, these changes also solve a few issues we have had with dune-grid-glue.
The requested changes are not very invasive, but they are a bit subtle. To ease the discussion, and to make sure we are all talking about the same thing, I have tried to write a semi-formal change request document. This document, which I will attach here, gives the reasons why I want to change the interface, and the requested changes in as much detail as possible (to me). Additionally, it describes one alternative approach to the same problem, which I am not proposing, but which was part of the discussion for a while.
It is quite a long document for a small change. It is open for discussion in all regards. Once we settle on something, the document shall make sure that we all remember the details of what we agreed upon.
# Attachments
* [dicr-multiple-intersections.pdf](/uploads/55d15dbc9bdbc85e11ee12e4b6ab656f/dicr-multiple-intersections.pdf)
https://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,
Christian