Core Modules issueshttps://gitlab.dune-project.org/groups/core/-/issues2023-09-29T10:58:29Zhttps://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-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-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/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/343Follow-up from "[cleanup][OverloadCompilerFlags] Move compiler flag overloadi...2023-09-18T21:16:45ZAndreas DednerFollow-up from "[cleanup][OverloadCompilerFlags] Move compiler flag overloading to user script."The following discussion from !1251 should be addressed:
- [ ] @santiago.ospina started a [discussion](https://gitlab.dune-project.org/core/dune-common/-/merge_requests/1251#note_128976): (+26 comments)
> @robert.kloefkorn There i...The following discussion from !1251 should be addressed:
- [ ] @santiago.ospina started a [discussion](https://gitlab.dune-project.org/core/dune-common/-/merge_requests/1251#note_128976): (+26 comments)
> @robert.kloefkorn There is some errors in the CI for [dune-istl](https://gitlab.dune-project.org/core/dune-istl/-/jobs/491718) and [dune-ugrid](https://gitlab.dune-project.org/staging/dune-uggrid/-/jobs/490354) wrt the configuration of dune-py. The only change in between the failing pipelines seems to be this MR. The error seems to be that the generated cmake has/non-existing wrong parameters.https://gitlab.dune-project.org/core/dune-grid/-/issues/170DGF documentation is rendered with missing information2023-09-22T16:00:19ZSantiago Ospina De Los Ríossospinar@gmail.comDGF documentation is rendered with missing informationThe documentation of the DGF parser in the [source code](https://gitlab.dune-project.org/core/dune-grid/-/blob/master/dune/grid/io/file/dgfparser/dgfparser.hh#L78) and the documentation rendered in the [Doxygen documentation](https://dun...The documentation of the DGF parser in the [source code](https://gitlab.dune-project.org/core/dune-grid/-/blob/master/dune/grid/io/file/dgfparser/dgfparser.hh#L78) and the documentation rendered in the [Doxygen documentation](https://dune-project.org/doxygen/2.9.0/group__DuneGridFormatParser.html#details) doesn't seem to match to me. In particular, the _usage_ section is completely skipped while the _format_ section is rendered as the _usage_ section. Maybe this is done on purpose?Santiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.comhttps://gitlab.dune-project.org/core/dune-geometry/-/issues/33FTBFS with gcc-132023-07-13T13:02:11ZOliver Sanderoliver.sander@tu-dresden.deFTBFS with gcc-13Reported by Debian for the 2.9.0 release: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037631Reported by Debian for the 2.9.0 release: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037631https://gitlab.dune-project.org/core/dune-geometry/-/issues/32Problem using `GeometryType::none`2023-09-20T11:52:31ZAlexander MüllerProblem using `GeometryType::none`If the function
`Dune::ReferenceElements<ScalarType, dim>::general` is used it returns the object with topology id 0.
Thus, I witnessed the failure of several codes, such as
https://gitlab.dune-project.org/fufem/dune-fufem/-/blob/maste...If the function
`Dune::ReferenceElements<ScalarType, dim>::general` is used it returns the object with topology id 0.
Thus, I witnessed the failure of several codes, such as
https://gitlab.dune-project.org/fufem/dune-fufem/-/blob/master/dune/fufem/boundarypatch.hh#L135,
or
https://gitlab.dune-project.org/staging/dune-functions/-/blob/master/dune/functions/functionspacebases/subentitydofs.hh#L70,
Though the behavior is that in 2D I pass in `GeometryType::none` and get the reference element of topolgy ID 0, which is the triangle, in the subsequent code this fails due to multiple reasons.
The crucial code is https://gitlab.dune-project.org/core/dune-geometry/-/blob/master/dune/geometry/referenceelements.hh#L156,
which hands out in https://gitlab.dune-project.org/core/dune-geometry/-/blob/master/dune/geometry/referenceelements.hh#L66 the element with the topology ID 0.
This is due to the default construction of the GeoemtryType in https://gitlab.dune-project.org/core/dune-geometry/-/blob/master/dune/geometry/type.hh#L244.
Thus, at several places, the type at hand should be checked with `isNone()`. I prepared a pull request for dune-fufem, but before I pollute every code with my isNone checks, I wanted to discuss, if we can cure this here.
For example, in 2D, the handed-out ReferenceElement is the triangle. Thus, if we create a Reference element that returns something better, which e.g. does nothing or returns zero in the case of geometryType::none in
https://gitlab.dune-project.org/core/dune-geometry/-/blob/master/dune/geometry/referenceelement.hh#L153.
Then, it could be cured maybe for all implementations.
I don't know the impact on perfomance here. @simon.praetorius @oliver.sander do you have an opinion here?https://gitlab.dune-project.org/core/dune-grid/-/issues/168VTKWriter with tensor data does not compile2023-06-04T10:02:59ZCarsten Gräsergraeser@math.fau.deVTKWriter with tensor data does not compileUsing `VTKWriter::addVertexData(gridFUnction, FieldInfo("name", FieldInfo::Type::tensor, dim))` leads to a compilation error.
While there is code in the `VTKWriter` to dynamically throw an exception, because tensor data is not supported,...Using `VTKWriter::addVertexData(gridFUnction, FieldInfo("name", FieldInfo::Type::tensor, dim))` leads to a compilation error.
While there is code in the `VTKWriter` to dynamically throw an exception, because tensor data is not supported, this is not triggered here, because the code fails to compile. We should make it transparent to the user what is actually failing by
* documenting that tensor data is not supported,
* ideally catching this case with a static assertion.https://gitlab.dune-project.org/core/dune-common/-/issues/338[Python] Create Python bindings when Python package has different name to dun...2023-09-22T14:01:44ZAlexander Müller[Python] Create Python bindings when Python package has different name to dune moduleI'm trying and struggling currently to create working python bindings for python bindings, where the pypi package should have a different name to the dune module and to the actual python package.
I'm using all 2.9 branches
I.e. my dune...I'm trying and struggling currently to create working python bindings for python bindings, where the pypi package should have a different name to the dune module and to the actual python package.
I'm using all 2.9 branches
I.e. my dune-module is called "ikarus" which is not available at pypi. Thus, as a workaround I want to name the pypi package `pyikarus`.
Thus I want the behaviour to be `pip install pyikarus` and in the python code `import ikarus` and my cpp folder structure should also be with `ikarus`.
I investigated, and my current setup is:
In the top-level `setup.py` I have
```python
...
metadata["name"] = "pyikarus"
setup(**metadata)
```
In `python/ikarus/setup.py.in` I have
```python
REQUIRED_PACKAGES = '${RequiredPythonModules}'.replace(';',' ').split(' ')
setup(
name="pyikarus",
description="${ProjectDescription}",
version="${ProjectVersionString}",
author="${ProjectAuthor}",
author_email="${ProjectMaintainerEmail}",
packages=find_packages(exclude=["docs/*"]),
zip_safe=0,
package_data={"": ["*.so"], "pyikarus": ["data/*.cmake"]},
install_requires=REQUIRED_PACKAGES,
include_package_data=True,
)
```
and in `python/ikarus/CMakeLists.txt`
```cmake
add_subdirectory(ikarus)
set(CXX_MAX_STANDARD 20)
set(PYPI_PACKAGE_NAME "pyikarus")
dune_python_configure_bindings(
PATH
"."
PACKAGENAME
${PYPI_PACKAGE_NAME}
CMAKE_METADATA_FLAGS
DUNE_OPTS_FILE
CXX_MAX_STANDARD
)
if(POLICY CMP0087)
cmake_policy(SET CMP0087 NEW)
endif()
```
There are several points where I have to state `ikarus` or `pyikarus`. Brute forcing some variants of these options always returns errors.
Thus, if I install my uploaded package from pypi and try to compile my code with `dune-py`, I get two different error messages.
If I pass to `dune_python_configure_bindings` above the name `pyikarus`, I get errors like
<details>
<summary>pyikarus error message</summary>
```python
---------------------------------------------------------------------------
CompileError Traceback (most recent call last)
Cell In[35], line 1
----> 1 svk = iks.StVenantKirchhoff(emodul=1000,nu=0.3)
3 svkPS = svk.asPlainStress()
File /dune/dune-common/build-cmake/dune-env/lib/python3.10/site-packages/ikarus/materials.py:33, in materialConstructorDecorator..wrapper(emodul, nu)
31 includes += ["ikarus/python/finiteElements/materials/material.hh"]
32 moduleName = func.__name__+"_" + hashIt(element_type)
---> 33 module = generator.load(
34 includes=includes,
35 typeName=element_type,
36 moduleName=moduleName
37 )
39 # dispatcher = { 'NeoHooke' : NeoHooke, 'StVenantKirchhoff' : StVenantKirchhoff}
42 return eval("module."+func.__name__+"(emodul,nu)")
File /dune/dune-common/build-cmake/python/dune/generator/generator.py:172, in SimpleGenerator.load(self, includes, typeName, moduleName, extraCMake, defines, preamble, postscript, options, bufferProtocol, dynamicAttr, baseClasses, holder, *args)
168 for nr, (tn, a, o, b, d, bc, h) in enumerate( zip(typeName, args, options, bufferProtocol, dynamicAttr, baseClasses, holder) ):
169 source += self.main(nr, includes, tn, *a, options=o,
170 bufferProtocol=b, dynamicAttr=d,
171 baseClasses=bc, holder=h)
--> 172 return self.post(moduleName, source, postscript, extraCMake)
File /dune/dune-common/build-cmake/python/dune/generator/generator.py:124, in SimpleGenerator.post(self, moduleName, source, postscript, extraCMake)
122 # make sure to reload the builder here in case it got updated
123 from . import builder
--> 124 module = builder.load(moduleName, source, self.typeName[0], extraCMake)
126 return module
File /dune/dune-common/build-cmake/python/dune/generator/cmakebuilder.py:382, in Builder.load(self, moduleName, source, pythonName, extraCMake)
380 module = sys.modules.get("dune.generated." + moduleName)
381 if module is None:
--> 382 self._buildModule( moduleName, source, pythonName, extraCMake )
384 ## TODO remove barrier here
385 comm.barrier()
File /dune/dune-common/build-cmake/python/dune/generator/cmakebuilder.py:732, in MakefileBuilder._buildModule(self, moduleName, source, pythonName, extraCMake)
729 # check return code
730 if exit_code > 0:
731 # retrieve stderr output
--> 732 raise CompileError(buffer_to_str(stderr))
CompileError: /dune/dune-common/build-cmake/dune-env/.cache/dune-py/python/dune/generated/StVenantKirchhoff_de7f96cf2f383220c197a4a670079062.cc:10:10: fatal error: ikarus/finiteElements/mechanics/materials.hh: No such file or directory
10 | #include
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
```
</details>
Thus, the underlying cmake script does maybe not include the correct subdirectories to make the headers findable.
If I pass to `dune_python_configure_bindings` above the name `ikarus` I get errors like
<details>
<summary>pyikarus error message</summary>
```python
---------------------------------------------------------------------------
CompileError Traceback (most recent call last)
Cell In[4], line 1
----> 1 svk = iks.StVenantKirchhoff(emodul=1000,nu=0.3)
3 svkPS = svk.asPlainStress()
File /dune/dune-common/build-cmake/dune-env/lib/python3.10/site-packages/ikarus/materials.py:33, in materialConstructorDecorator..wrapper(emodul, nu)
31 includes += ["ikarus/python/finiteElements/materials/material.hh"]
32 moduleName = func.__name__+"_" + hashIt(element_type)
---> 33 module = generator.load(
34 includes=includes,
35 typeName=element_type,
36 moduleName=moduleName
37 )
39 # dispatcher = { 'NeoHooke' : NeoHooke, 'StVenantKirchhoff' : StVenantKirchhoff}
42 return eval("module."+func.__name__+"(emodul,nu)")
File /dune/dune-common/build-cmake/python/dune/generator/generator.py:172, in SimpleGenerator.load(self, includes, typeName, moduleName, extraCMake, defines, preamble, postscript, options, bufferProtocol, dynamicAttr, baseClasses, holder, *args)
168 for nr, (tn, a, o, b, d, bc, h) in enumerate( zip(typeName, args, options, bufferProtocol, dynamicAttr, baseClasses, holder) ):
169 source += self.main(nr, includes, tn, *a, options=o,
170 bufferProtocol=b, dynamicAttr=d,
171 baseClasses=bc, holder=h)
--> 172 return self.post(moduleName, source, postscript, extraCMake)
File /dune/dune-common/build-cmake/python/dune/generator/generator.py:124, in SimpleGenerator.post(self, moduleName, source, postscript, extraCMake)
122 # make sure to reload the builder here in case it got updated
123 from . import builder
--> 124 module = builder.load(moduleName, source, self.typeName[0], extraCMake)
126 return module
File /dune/dune-common/build-cmake/python/dune/generator/cmakebuilder.py:374, in Builder.load(self, moduleName, source, pythonName, extraCMake)
370 def load(self, moduleName, source, pythonName, extraCMake=None):
371 # check if we need to initialize dune-py either because
372 # this is the first call to load or because an external module with metadata has been registered
373 if not self.initialized or not self.externalPythonModules == getExternalPythonModules():
--> 374 self.initialize()
376 # check whether module is already compiled and build it if necessary
377 # (only try to build module on rank 0!)
378 # TODO replace if rank with something better and remove barrier further down
379 if comm.rank == 0:
File /dune/dune-common/build-cmake/python/dune/generator/cmakebuilder.py:616, in MakefileBuilder.initialize(self)
615 def initialize(self):
--> 616 super().initialize()
617 # check that the compile script is available
618 script = os.path.join(self.generated_dir,"buildScript.sh")
File /dune/dune-common/build-cmake/python/dune/generator/cmakebuilder.py:213, in Builder.initialize(self)
211 self.cacheExternalModules()
212 # create dune-py module
--> 213 self.build_dunepy_from_template(self.dune_py_dir)
214 # create tag file so that dune-py is not rebuilt on the next build
215 open(tagfile, 'a').close()
File /dune/dune-common/build-cmake/python/dune/generator/cmakebuilder.py:472, in MakefileBuilder.build_dunepy_from_template(dunepy_dir, force)
468 if not useNinja:
469 # call base class dunepy_from_template (re-initialize)
470 force = Builder.generate_dunepy_from_template(dunepy_dir, force=True)
--> 472 Builder.callCMake(["cmake"] + defaultCMakeFlags() + ["."],
473 cwd=dunepy_dir,
474 infoTxt="Configuring dune-py with CMake (make)",
475 active=True, # print details anyway
476 )
478 # obtain bash and make command generated by cmake
479 # when ninja is used makeCmd is the ninja command
480 try:
File /dune/dune-common/build-cmake/python/dune/generator/cmakebuilder.py:263, in Builder.callCMake(cmake_args, cwd, infoTxt, verbose, active, logLevel, env)
260 if cmake.returncode > 0:
261 # retrieve stderr output
262 print(stderr,stdout)
--> 263 raise CompileError(buffer_to_str(stderr))
265 return stdout, stderr
CompileError: ---- LOCK
---- ACQUIRED
-- Generating CXX compiler script for CXXFLAGS overloading on command line
---- RELEASE
---- DONE
CMake Error at /dune/dune-common/build-cmake/dune-env/lib/cmake/ikarus/ikarus-targets.cmake:61 (set_target_properties):
The link interface of target "ikarus" contains:
autodiff::autodiff
but the target was not found. Possible reasons include:
* There is a typo in the target name.
* A find_package call is missing for an IMPORTED target.
* An ALIAS target is missing.
Call Stack (most recent call first):
/dune/dune-common/build-cmake/dune-env/lib/cmake/ikarus/ikarus-config.cmake:55 (include)
/dune/dune-common/cmake/modules/DuneModuleDependencies.cmake:170 (find_package)
/dune/dune-common/cmake/modules/DuneModuleDependencies.cmake:289 (find_dune_package)
/dune/dune-common/cmake/modules/DuneModuleDependencies.cmake:336 (dune_process_dependency_leafs)
/dune/dune-common/cmake/modules/DuneModuleDependencies.cmake:46 (dune_create_dependency_leafs)
/dune/dune-common/cmake/modules/DuneProject.cmake:90 (dune_create_dependency_tree)
CMakeLists.txt:106 (dune_project)
```
</details>
which indicates by the linking error, that in some cmake file the linking is not done correctly, thus indicating the first version with `pyikarus` is better? But anyway the headers are not findable in this first case. Changes in the files in `python/ikarus/` does not change the error messages.
Can someone please point me to the correct changes. I'm willing to create then a proper MR to enable this functionality, if this is of interest. Otherwise, if this should already work can someone correct my mistakes?
The current folder structure can be found at https://github.com/ikarus-project/ikarus/tree/feature/pythonBindingsV3.
Thanks, and any help is very much appreciated.Alexander MüllerAlexander Müllerhttps://gitlab.dune-project.org/core/dune-common/-/issues/332How to add include directories to dune targets2024-02-23T16:12:30ZSantiago Ospina De Los Ríossospinar@gmail.comHow to add include directories to dune targets### Issue
In order to move to a target based build system, our targets need to be equipped with the necessary include directories so that we can stop relying on project-wise include commands (i.e. `target_include_directories` vs `includ...### Issue
In order to move to a target based build system, our targets need to be equipped with the necessary include directories so that we can stop relying on project-wise include commands (i.e. `target_include_directories` vs `include_directories`). Currently, we are using `include_directories` in `dune_project()` so that all the targets in the project see the header files of all dependencies and the project itself. This needs to be removed in favor of the target based approach (i.e. `target_include_directories`). The question here is: what is the best alternative to enforce `target_include_directories` in all dune modules?
### Alternatives
_@simon.praetorius made a great summary in https://gitlab.dune-project.org/core/dune-common/-/merge_requests/1249#note_127842_
There are some ideas how to move the include_directories property from a global property into targets:
1. Manually setting the include dir to a target. Pro: it is explicit and works right now. Con: Every module needs to create a library. It is quiet a complicated cmake statement to get right. It should actually be something like
```cmake
target_include_directories(<target> [INTERFACE]
$<BUILD_INTERFACE:${PROJECT_BINARY_DIR}>
$<BUILD_INTERFACE:${PROJECT_SOURCE_DIR}>
$<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}>)
```
2. Extending the function `dune_project(<target> [INTERFACE]...)` by additional arguments to directly create a module library and set the include directories on this. Pro: expects only little change in the code, can be backwards compatible. Con: now `dune_project` has two functions, configuring the module and creating a library. See !944
3. Adding a helper function just for the purpose of semiautomatically configuring a module library, e.g., `dune_add_module_library(<target> [INTERFACE]...)`. Pro: clear separation of functionality `dune_project` vs. `dune_add_library` but still some automatism. Con: Not yet clear about backwards compatible implementation.CMake ModernizationSimon PraetoriusSimon Praetoriushttps://gitlab.dune-project.org/core/dune-istl/-/issues/109Why shared_ptr used in solver factory?2023-10-21T11:22:32ZSimon PraetoriusWhy shared_ptr used in solver factory?The `SolverFactory::get` and `SolverFactory::getPreconditioner` and the utility method `getSolverFromFactory` all return the result by `shared_ptr`. Why? A factory should mostly return a `unique_ptr`, or to cite [Herb Sutter GitW \#90](h...The `SolverFactory::get` and `SolverFactory::getPreconditioner` and the utility method `getSolverFromFactory` all return the result by `shared_ptr`. Why? A factory should mostly return a `unique_ptr`, or to cite [Herb Sutter GitW \#90](https://herbsutter.com/2013/05/30/gotw-90-solution-factories/):
> Guideline: A factory that produces a reference type should return a `unique_ptr` by default, or a `shared_ptr` if ownership is to be shared with the factory.
The issue with `shared_ptr` is, that 1. creation, copy, and destruction costs something, 2. a `shared_ptr` cannot be converted into a `unqiue_ptr`, but vice versa is fine.
Maybe second part of the guideline applies here? Do I miss something?https://gitlab.dune-project.org/core/dune-common/-/issues/330[discussion] drop or simplify pip & venv magic during configure2023-04-27T14:33:51ZChristian Engwer[discussion] drop or simplify pip & venv magic during configureAs we have seen in !1235, the automagic handling of python dependencies leads to a couple of strange problems, e.g. packages installed automatically by `cmake` are not always found.
I would like to start a discussion on how we can simpl...As we have seen in !1235, the automagic handling of python dependencies leads to a couple of strange problems, e.g. packages installed automatically by `cmake` are not always found.
I would like to start a discussion on how we can simply this whole cmake-venv-pip integration. My provocative statement is that it leads to more problems than it solves and that a clear error message about missing dependencies would be far more helpful.
Opinions?https://gitlab.dune-project.org/core/dune-grid/-/issues/166All grid factories should support custom communicators2023-02-09T20:40:48ZChristian EngwerAll grid factories should support custom communicatorsCurrently the support of custom communicators for parallel grid construction is very inconsistent.
- `GmshReader` doesn't support custom communicators at all
- `DGFGridFactory` supports this for some meshes, so that the interface is i...Currently the support of custom communicators for parallel grid construction is very inconsistent.
- `GmshReader` doesn't support custom communicators at all
- `DGFGridFactory` supports this for some meshes, so that the interface is inconsistent
- `StructuredGridFactory` also doesn't allow any custom communicator
Surely we will have to think about how to pass the custom communicator to the grid, but imho it would be very helpful to support a common interface.https://gitlab.dune-project.org/core/dune-common/-/issues/329Build requirements are not properly documented2023-09-23T10:46:42ZCarsten Gräsergraeser@math.fau.deBuild requirements are not properly documentedCurrently the build instructions in `README.md` and `INSTALL` are missing a lot of very important information that should be added:
* An internet connection is needed because `pip` is used to download python packages.
* When no connecti...Currently the build instructions in `README.md` and `INSTALL` are missing a lot of very important information that should be added:
* An internet connection is needed because `pip` is used to download python packages.
* When no connection is available, one gets several warnings and error messages.
However, the build seems to terminate successfully. Furthermore CMake says that the optional package `Python3`has been found.
Either this is not a problem and the build is successful, then we should not scare users with these error messages. Or this
means that the python-bindings cannot be used than this should be properly reported to the user.
* If the internet connection is available, it is used to download executable code from third party locations that is executed later.
* Since the required python modules are not documented it's also not possible that the user provides them on his own
to avoid this dangerous behavior. Notice that even if the python packages mentioned in the error messages are installed
globally, the attempt to download them and the mentioned error messages persists.
BTW:
One can argue that downloading and executing code from third party locations is a no-go unless the user explicitly opts in.
This ticket is not about changing this behavior now. But we should at least be honest and clearly document this and tell the
users how it can be disabled.Markus BlattMarkus Blatt