Core Modules issueshttps://gitlab.dune-project.org/groups/core/-/issues2024-03-12T19:34:19Zhttps://gitlab.dune-project.org/core/dune-grid/-/issues/169FTBFS with gcc-132024-03-12T19:34:19ZOliver 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=1037632Reported by Debian for the 2.9.0 release: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037632https://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-common/-/issues/341FTBFS with gcc-132023-07-12T08:54:18ZOliver 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=1037630
```
cd /<<PKGBUILDDIR>>/build/dune/common/simd/test && /usr/bin/c++ -DENABLE_MPI=1 -DENABLE_QUADMATH=1 -DHAVE_CONFIG_H -D_GLIBCXX_USE_FL...Reported by Debian for the 2.9.0 release: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037630
```
cd /<<PKGBUILDDIR>>/build/dune/common/simd/test && /usr/bin/c++ -DENABLE_MPI=1 -DENABLE_QUADMATH=1 -DHAVE_CONFIG_H -D_GLIBCXX_USE_FLOAT128 -I/<<PKGBUILDDIR>>/build -I/<<PKGBUILDDIR>> -isystem /usr/lib/x86_64-linux-gnu/openmpi/include -isystem /usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -std=c++17 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIE -fext-numeric-literals -MD -MT dune/common/simd/test/CMakeFiles/looptest.dir/looptest.cc.o -MF CMakeFiles/looptest.dir/looptest.cc.o.d -o CMakeFiles/looptest.dir/looptest.cc.o -c /<<PKGBUILDDIR>>/build/dune/common/simd/test/looptest.cc
In file included from /usr/include/c++/13/cassert:44,
from /<<PKGBUILDDIR>>/dune/common/simd/interface.hh:17,
from /<<PKGBUILDDIR>>/dune/common/simd/simd.hh:13,
from /<<PKGBUILDDIR>>/dune/common/simd/loop.hh:13,
from /<<PKGBUILDDIR>>/build/dune/common/simd/test/looptest.cc:12:
/<<PKGBUILDDIR>>/dune/common/simd/loop.hh: In constructor ‘Dune::LoopSIMD<T, S, A>::LoopSIMD()’:
/<<PKGBUILDDIR>>/dune/common/simd/loop.hh:70:31: error: ‘uintptr_t’ does not name a type
70 | assert(reinterpret_cast<uintptr_t>(this) % std::min(alignof(LoopSIMD<T,S,A>),alignof(std::max_align_t)) == 0);
| ^~~~~~~~~
/<<PKGBUILDDIR>>/dune/common/simd/loop.hh:14:1: note: ‘uintptr_t’ is defined in header ‘<cstdint>’; did you forget to ‘#include <cstdint>’?
13 | #include <dune/common/simd/simd.hh>
+++ |+#include <cstdint>
14 | #include <dune/common/typetraits.hh>
/<<PKGBUILDDIR>>/dune/common/simd/loop.hh: In constructor ‘Dune::LoopSIMD<T, S, A>::LoopSIMD(const Dune::LoopSIMD<T, S, OA>&)’:
/<<PKGBUILDDIR>>/dune/common/simd/loop.hh:82:31: error: ‘uintptr_t’ does not name a type
82 | assert(reinterpret_cast<uintptr_t>(this) % std::min(alignof(LoopSIMD<T,S,A>),alignof(std::max_align_t)) == 0);
| ^~~~~~~~~
/<<PKGBUILDDIR>>/dune/common/simd/loop.hh:82:31: note: ‘uintptr_t’ is defined in header ‘<cstdint>’; did you forget to ‘#include <cstdint>’?
make[5]: *** [dune/common/simd/test/CMakeFiles/looptest.dir/build.make:835: dune/common/simd/test/CMakeFiles/looptest.dir/looptest.cc.o] Error 1
make[5]: *** Waiting for unfinished jobs....
```https://gitlab.dune-project.org/core/dune-common/-/issues/340[Python] Former JIT compilation confuses latter2023-06-14T17:54:19ZAlexander Müller[Python] Former JIT compilation confuses latterI have a new grid implementation where I'm currently adding Python bindings.
Whereas I managed to register and compile my grid, later compilation failed, no matter what object.
The code at hand is:
```python
reader = (readeriga.json, "....I have a new grid implementation where I'm currently adding Python bindings.
Whereas I managed to register and compile my grid, later compilation failed, no matter what object.
The code at hand is:
```python
reader = (readeriga.json, "../../iga/test/auxiliaryFiles/element.ibra")
gridView = igaGrid(reader, dimgrid=2,dimworld=2)
v = FieldVector((2,1)) # this line fails
```
The error is as follows:
```python
Traceback (most recent call last):
File "/dune/dune-common/build-cmake/python/dune/common/__init__.py", line 86, in FieldVector
return globals()[fv](values)
KeyError: 'FieldVector_2'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/tmp/dune-iga/dune/python/test/readGrid.py", line 23, in <module>
v= FieldVector((2,1))
File "/dune/dune-common/build-cmake/python/dune/common/__init__.py", line 90, in FieldVector
cls = _loadVec(includes, typeName).FieldVector
File "/dune/dune-common/build-cmake/python/dune/common/__init__.py", line 74, in _loadVec
return generator.load(
File "/dune/dune-common/build-cmake/python/dune/generator/generator.py", line 172, in load
return self.post(moduleName, source, postscript, extraCMake)
File "/dune/dune-common/build-cmake/python/dune/generator/generator.py", line 124, in post
module = builder.load(moduleName, source, self.typeName[0], extraCMake)
File "/dune/dune-common/build-cmake/python/dune/generator/cmakebuilder.py", line 388, in load
module = importlib.import_module("dune.generated." + moduleName)
File "/usr/lib/python3.10/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
File "<frozen importlib._bootstrap>", line 1004, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'dune.generated.fieldvector_2371cd404c10f9fc2031e51d552c58df'
```
A similar error is created for every other object I try to compile afterward. Thus, I think there is no issue regarding the FieldVector.
I researched and debugged the issue and during first problem arises in
[cmakebuilder.py685](https://gitlab.dune-project.org/core/dune-common/-/blob/releases/2.9/python/dune/generator/cmakebuilder.py?ref_type=heads#L685).
This process fails with error code -11 (I don't know what that means, if it is important, or even if it is always reproducible).
After this the [line](https://gitlab.dune-project.org/core/dune-common/-/blob/releases/2.9/python/dune/generator/cmakebuilder.py?ref_type=heads#L388) fails, since the module as never generated.
Interestingly, if I do this by hand and mimic the make command as follows:
```bash
/dune/dune-common/build-cmake/dune-env/.cache/dune-py/python/dune/generated# make -q -f CMakeFiles/fieldvector_2371cd404c10f9fc2031e51d552c58df.dir/fieldvector_2371cd404c10f9fc2031e51d552c58df.make fieldvector_2371cd404c10f9fc2031e51d552c58df.so
```
and
`bash buildScript.sh fieldvector_2371cd404c10f9fc2031e51d552c58df`
my Python script from above does not raise the exception and
```bash
DUNE-DEBUG: Module fieldvector_2371cd404c10f9fc2031e51d552c58df not loaded
DUNE-DEBUG: Loading fieldvector_2371cd404c10f9fc2031e51d552c58df
```
works as expected.
How can this behavior be explained? I refactored my code several times but no difference.https://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/339wheel installation failed during make install2023-12-06T08:10:28ZSimon Praetoriuswheel installation failed during make installWhen installing dune modules, you typically specify where to install everything, e.g., by `-DCMAKE_INSTALL_PREFIX=<path>`. This path seems to be ignored during some wheel installation in the python bindings setup. I get the error/warning...When installing dune modules, you typically specify where to install everything, e.g., by `-DCMAKE_INSTALL_PREFIX=<path>`. This path seems to be ignored during some wheel installation in the python bindings setup. I get the error/warning:
```
Installing wheel for python package at /opt/sources/dune/dune-geometry/build-cmake/python/. into /usr/local/share/dune/wheelhouse...
CMake Warning at /opt/sources/dune/dune-common/cmake/modules/DuneExecuteProcess.cmake:76 (message):
wheel installation failed - ignored
Run
command:/opt/sources/dune/dune-common/build-cmake/dune-env/bin/python;-m;pip;wheel;-w;/usr/local/share/dune/wheelhouse;--no-deps;/opt/sources/dune/dune-geometry/build-cmake/python/.
Return code: 2
Output:
ERROR: Exception:
Traceback (most recent call last):
File "/opt/sources/dune/dune-common/build-cmake/dune-env/lib/python3.10/site-packages/pip/_internal/cli/base_command.py", line 165, in exc_logging_wrapper
status = run_func(*args)
File "/opt/sources/dune/dune-common/build-cmake/dune-env/lib/python3.10/site-packages/pip/_internal/cli/req_command.py", line 205, in wrapper
return func(self, options, args)
File "/opt/sources/dune/dune-common/build-cmake/dune-env/lib/python3.10/site-packages/pip/_internal/commands/wheel.py", line 111, in run
ensure_dir(options.wheel_dir)
File "/opt/sources/dune/dune-common/build-cmake/dune-env/lib/python3.10/site-packages/pip/_internal/utils/misc.py", line 101, in ensure_dir
os.makedirs(path)
File "/usr/lib/python3.10/os.py", line 215, in makedirs
makedirs(head, exist_ok=exist_ok)
File "/usr/lib/python3.10/os.py", line 225, in makedirs
mkdir(name, mode)
PermissionError: [Errno 13] Keine Berechtigung: '/usr/local/share/dune'
Call Stack (most recent call first):
python/cmake_install.cmake:53 (dune_execute_process)
cmake_install.cmake:95 (include)
```
The error is correct, i.e., the location `/usr/local/share/dune` is by default readonly.
- How can I specify where to install wheel? (I actually don't know what this is, but if it is required, I am fine with it)
- It would be nice to get this flag as a hint in the error message.
- Is this something required? If not, why is it installed at all?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/337Libraries with NO_EXPORT option are exported as module libraries2023-07-04T11:44:33ZSantiago Ospina De Los Ríossospinar@gmail.comLibraries with NO_EXPORT option are exported as module librariesIf a library target asks to not be exported (i.e., `dune_add_library(libname NO_EXPORT [...])`) it gets excluded from the export set of the library (e.g. [this line](https://gitlab.dune-project.org/core/dune-common/-/blob/fa23cf444d632f9...If a library target asks to not be exported (i.e., `dune_add_library(libname NO_EXPORT [...])`) it gets excluded from the export set of the library (e.g. [this line](https://gitlab.dune-project.org/core/dune-common/-/blob/fa23cf444d632f9447292cc1a9eb07e88a2fce18/cmake/modules/DuneAddLibrary.cmake#L186)). That's the expected behavior.
However, the library _name_ is still exported in the `${${ProjecName}_LIBRARIES}` variable in the export file: set [here](https://gitlab.dune-project.org/core/dune-common/-/blob/fa23cf444d632f9447292cc1a9eb07e88a2fce18/cmake/modules/DuneAddLibrary.cmake#L192) and exported [here](https://gitlab.dune-project.org/core/dune-common/-/blob/fa23cf444d632f9447292cc1a9eb07e88a2fce18/cmake/modules/DuneProject.cmake#L199). This is not correct as the library was not exported and consumers have no idea how to resolve such a library name. In particular, this fails when the consumer wants to enable all dune packages with `dune_enable_all_packages`, `dune_target_enable_all_packages` or directly linking to the dependent libraries.
The correct behavior is incidentally fixed in !1247 by having internal and external library modules: `${${ProjecName}_INTERFACE_LIBRARIES}` is set [here](https://gitlab.dune-project.org/core/dune-common/-/merge_requests/1247/diffs#a18835a94745be4f5f1e2d86451897c5accab3d3_183_214) and exported [here](https://gitlab.dune-project.org/core/dune-common/-/merge_requests/1247/diffs#28f9da52000ccbac5f7d99b068322a2dae1d5a5d_200_204), where this variable is only set for exported module libraries.
_Edit: Link to the export set is updated to the correct line._Simon PraetoriusSimon Praetoriushttps://gitlab.dune-project.org/core/dune-common/-/issues/336Python-related build-failure on the 2.9 branch2023-05-04T19:58:09ZOliver Sanderoliver.sander@tu-dresden.dePython-related build-failure on the 2.9 branchI cannot build the `releases/2.9` branch on my up-to-date Debian testing machine. After a fresh clone, I get
```
~/dune-2.9> ./dune-common/bin/dunecontrol all
--- going to build dune-common dune-geometry dune-localfunctions dune-uggrid...I cannot build the `releases/2.9` branch on my up-to-date Debian testing machine. After a fresh clone, I get
```
~/dune-2.9> ./dune-common/bin/dunecontrol all
--- going to build dune-common dune-geometry dune-localfunctions dune-uggrid dune-grid dune-istl dune-matrix-vector dune-solvers dune-typetree dune-gmsh4 dune-functions dune-fufem dune-elasticity dune-gfe ---
--- calling all for dune-common ---
--- calling vcsetup for dune-common ---
--- calling cmake for dune-common ---
cmake "/home/sander/dune-2.9/dune-common"
-- The C compiler identification is GNU 12.2.0
-- The CXX compiler identification is GNU 12.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test cxx_std_flag_17
-- Performing Test cxx_std_flag_17 - Success
-- Performing Test compiler_supports_cxx17
-- Performing Test compiler_supports_cxx17 - Success
-- Looking for std::experimental::make_array<int,int>
-- Looking for std::experimental::make_array<int,int> - found
-- Looking for std::move<std::experimental::detected_t<std::decay_t,int>>
-- Looking for std::move<std::experimental::detected_t<std::decay_t,int>> - found
-- Looking for std::identity
-- Looking for std::identity - not found
-- Performing Test DUNE_HAVE_CXX_UNEVALUATED_CONTEXT_LAMBDA
-- Performing Test DUNE_HAVE_CXX_UNEVALUATED_CONTEXT_LAMBDA - Failed
-- Found LATEX: /usr/bin/latex
-- Found LatexMk: /usr/bin/latexmk (found version "Version 4.79")
-- Could NOT find Sphinx (missing: SPHINX_EXECUTABLE)
-- Found Doxygen: /usr/bin/doxygen (found version "1.9.4") found components: doxygen dot
-- Found PkgConfig: /usr/bin/pkg-config (found version "1.8.1")
-- Performing tests for dune-common (from /home/sander/dune-2.9/dune-common/cmake/modules/DuneCommonMacros.cmake)
-- Set Minimal Debug Level to 4
-- Looking for sgemm_
-- Looking for sgemm_ - not found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Looking for dgemm_
-- Looking for dgemm_ - found
-- Found BLAS: /usr/lib/x86_64-linux-gnu/libblas.so;/usr/lib/x86_64-linux-gnu/libf77blas.so;/usr/lib/x86_64-linux-gnu/libatlas.so
-- Looking for cheev_
-- Looking for cheev_ - not found
-- Looking for cheev_
-- Looking for cheev_ - found
-- Found LAPACK: /usr/lib/x86_64-linux-gnu/liblapack.so;/usr/lib/x86_64-linux-gnu/libblas.so;/usr/lib/x86_64-linux-gnu/libf77blas.so;/usr/lib/x86_64-linux-gnu/libatlas.so
-- Looking for dsyev_
-- Looking for dsyev_ - found
-- Found GMP: /usr/lib/x86_64-linux-gnu/libgmpxx.so
-- Performing Test QuadMath_COMPILES
-- Performing Test QuadMath_COMPILES - Success
-- Found QuadMath: (Supported by compiler)
-- Found MPI_C: /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so (found suitable version "3.1", minimum required is "3.0")
-- Found MPI: TRUE (found suitable version "3.1", minimum required is "3.0") found components: C
-- Could NOT find TBB (set TBB_DIR to path containing TBBConfig.cmake or set PKG_CONFIG_PATH to include the location of the tbb.pc file) (missing: PkgConfigTBB_LINK_LIBRARIES PkgConfigTBB_FOUND) (found version "")
-- Could NOT find PTScotch (missing: SCOTCH_LIBRARY SCOTCHERR_LIBRARY SCOTCH_INCLUDE_DIR)
-- Found METIS: /usr/lib/x86_64-linux-gnu/libmetis.so (found version "5.1")
-- Found METIS: /usr/lib/x86_64-linux-gnu/libmetis.so (found suitable version "5.1", minimum required is "5.0")
-- Found MPI_C: /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so (found version "3.1")
-- Found MPI: TRUE (found version "3.1") found components: C
-- Found ParMETIS: /usr/lib/libparmetis.so (found suitable version "4.0", minimum required is "4.0")
-- Could NOT find Vc (missing: Vc_DIR)
-- Found Python3: /usr/bin/python3 (found version "3.11.2") found components: Interpreter Development Development.Module Development.Embed
-- Found pip_/usr/bin/python3: TRUE
-- Failed to find the python package virtualenv with interpreter /usr/bin/python3. (missing: DUNE_PYTHON_virtualenv_FOUND)
-- Found venv_/usr/bin/python3: TRUE
-- Building a virtualenv in /home/sander/dune-2.9/dune-common/build-cmake/dune-env
-- Found pip_/home/sander/dune-2.9/dune-common/build-cmake/dune-env/bin/python: TRUE
-- Using scripts from /home/sander/dune-2.9/dune-common/cmake/scripts for creating doxygen stuff.
-- using /home/sander/dune-2.9/dune-common/doc/doxygen/Doxystyle to create doxystyle file
-- using C macro definitions from /home/sander/dune-2.9/dune-common/doc/doxygen/doxygen-macros for Doxygen
-- Skipping building CMake API documentation (Sphinx was not found!)
-- Installing python package abstract requirements: jinja2 mpi4py numpy pip>=21.a portalocker setuptools>=41 wheel
-- Installing python package at /home/sander/dune-2.9/dune-common/build-cmake/python/. into Dune virtual environment
-- Generating the CMake metadata file at dune/data/dune-common.cmake
-- Not adding custom target for config.h generation
-- The following OPTIONAL packages have been found:
* LATEX
* LatexMk
* Doxygen, Class documentation generator, <www.doxygen.org>
To generate the class documentation from C++ sources
* BLAS, fast linear algebra routines
* LAPACK, fast linear algebra routines
* GMP, GNU multi-precision library, <https://gmplib.org>
* QuadMath, GCC Quad-Precision Math Library, <https://gcc.gnu.org/onlinedocs/libquadmath>
* Inkscape, converts SVG images, <www.inkscape.org>
To generate the documentation with LaTeX
* Threads, Multi-threading library
* METIS (required version >= 5.0), Serial Graph Partitioning, <http://glaros.dtc.umn.edu/gkhome/metis/metis/overview>
* MPI, Message Passing Interface library
Parallel programming on multiple processors
* ParMETIS (required version >= 4.0), Parallel Graph Partitioning, <http://glaros.dtc.umn.edu/gkhome/metis/parmetis/overview>
* Python3
-- The following OPTIONAL packages have not been found:
* Sphinx, Documentation generator, <www.sphinx-doc.org>
To generate the documentation from CMake and Python sources
* TBB, Intel's Threading Building Blocks, <https://github.com/oneapi-src/oneTBB>
* PTScotch, Sequential and Parallel Graph Partitioning, <https://gitlab.inria.fr/scotch/scotch>
* Vc, C++ Vectorization library, <https://github.com/VcDevel/Vc>
For use of SIMD instructions
-- Configuring done
CMake Warning (dev) in doc/comm/CMakeLists.txt:
Policy CMP0087 is not set: Install CODE|SCRIPT allow the use of generator
expressions. Run "cmake --help-policy CMP0087" for policy details. Use
the cmake_policy command to set the policy and suppress this warning.
This warning is for project developers. Use -Wno-dev to suppress it.
-- Generating done
-- Build files have been written to: /home/sander/dune-2.9/dune-common/build-cmake
--- calling make for dune-common ---
build directory: build-cmake
cmake --build . --
[ 0%] Building CXX object CMakeFiles/dunecommon.dir/dune/common/debugalign.cc.o
[ 20%] Building CXX object CMakeFiles/dunecommon.dir/dune/common/debugallocator.cc.o
[ 20%] Building CXX object CMakeFiles/dunecommon.dir/dune/common/exceptions.cc.o
[ 20%] Building CXX object CMakeFiles/dunecommon.dir/dune/common/fmatrixev.cc.o
[ 20%] Building CXX object CMakeFiles/dunecommon.dir/dune/common/ios_state.cc.o
[ 40%] Building CXX object CMakeFiles/dunecommon.dir/dune/common/parametertree.cc.o
[ 40%] Building CXX object CMakeFiles/dunecommon.dir/dune/common/parametertreeparser.cc.o
[ 40%] Building CXX object CMakeFiles/dunecommon.dir/dune/common/path.cc.o
[ 60%] Building CXX object CMakeFiles/dunecommon.dir/dune/common/simd/test.cc.o
[ 60%] Building CXX object CMakeFiles/dunecommon.dir/dune/common/stdstreams.cc.o
[ 60%] Building CXX object CMakeFiles/dunecommon.dir/dune/common/stdthread.cc.o
[ 80%] Linking CXX static library lib/libdunecommon.a
[ 80%] Built target dunecommon
[ 80%] Building CXX object python/dune/common/CMakeFiles/_common.dir/_common.cc.o
In file included from /home/sander/dune-2.9/dune-common/dune/python/pybind11/attr.h:13,
from /home/sander/dune-2.9/dune-common/dune/python/pybind11/pybind11.h:45,
from /home/sander/dune-2.9/dune-common/dune/python/common/typeregistry.hh:21,
from /home/sander/dune-2.9/dune-common/dune/python/common/dynmatrix.hh:15,
from /home/sander/dune-2.9/dune-common/python/dune/common/_common.cc:10:
/home/sander/dune-2.9/dune-common/dune/python/pybind11/cast.h: In function ‘std::string pybind11::detail::error_string()’:
/home/sander/dune-2.9/dune-common/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>() +
|
```https://gitlab.dune-project.org/core/dune-common/-/issues/335Add service desk badge2023-11-06T13:24:33ZSantiago Ospina De Los Ríossospinar@gmail.comAdd service desk badgeIt would be nice for outside users to inform the project about issues they encounter without the need of a GitLab account. That's exactly what the [service desk](https://gitlab.dune-project.org/help/user/project/service_desk) is for and ...It would be nice for outside users to inform the project about issues they encounter without the need of a GitLab account. That's exactly what the [service desk](https://gitlab.dune-project.org/help/user/project/service_desk) is for and now we have a nice mail alias (dune-common at dune-project.org) to offer this service.
I propose to create a [Project Badge](https://gitlab.dune-project.org/help/user/project/badges) to inform people about the email to use:
* Name: Service Desk
* Badge: ![Service Desk](https://img.shields.io/badge/Service%20Desk-dune--common%40dune--project.org-informational)
* Badge Link: https://img.shields.io/badge/Service%20Desk-dune--common%40dune--project.org-informational
* Link: https://gitlab.dune-project.org/core/dune-common/-/issues/service_desk
This needs to be done by someone with owner or maintainer rights in the settings panel... (I cannot do that)Santiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.comhttps://gitlab.dune-project.org/core/dune-common/-/issues/333TransposedMatrixWrapper does not cast properly into FieldMatrix or DenseMatrix.2023-04-21T10:10:56ZRobert KTransposedMatrixWrapper does not cast properly into FieldMatrix or DenseMatrix.The recent commit https://gitlab.dune-project.org/core/dune-grid/-/commit/b2695b3c7d169348d39f20899b64a584a667aa49 breaks the compliation of the dune-spgrid python bindings because the Jacobian is returned as transposedView of the Jacobi...The recent commit https://gitlab.dune-project.org/core/dune-grid/-/commit/b2695b3c7d169348d39f20899b64a584a667aa49 breaks the compliation of the dune-spgrid python bindings because the Jacobian is returned as transposedView of the JacobianTransposed which is not a FieldMatrix. The return transposedView does not properly cast into FieldMatrix which is the assumed return type in the Python bindings.https://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/111Python test modifies source tree2024-03-12T21:27:10ZCarsten Gräsergraeser@math.fau.dePython test modifies source treeUsing `ctest` changes the file `dune/python/test/bcrsmatrix.mm` in the git source tree by removing the SPDX lines. The culprit is probably `dune/python/test/bcrsmatrix.py`, because that's the only place where this file name shows up.Using `ctest` changes the file `dune/python/test/bcrsmatrix.mm` in the git source tree by removing the SPDX lines. The culprit is probably `dune/python/test/bcrsmatrix.py`, because that's the only place where this file name shows up.https://gitlab.dune-project.org/core/dune-istl/-/issues/110Solverfactorytest not properly guareded / fails when missing SuperLU or Suite...2023-04-04T12:03:58ZChristoph GrüningerSolverfactorytest not properly guareded / fails when missing SuperLU or SuiteSparse`solverfactorytest` uses many linear solvers in `solverfactorytest.ini`, including SuperLU, UMFPack, and other direct solvers from SuiteSparse. If one of these third-party libraries are missing, running the test fails. We should add some...`solverfactorytest` uses many linear solvers in `solverfactorytest.ini`, including SuperLU, UMFPack, and other direct solvers from SuiteSparse. If one of these third-party libraries are missing, running the test fails. We should add some guards to prevent these tests from running.
I see three options:
a) Add guards for Superlu, UMFPack, and other SuiteSparse libraries to solverfactorytest. Downside is, that the test will not be executed, if only a single library is missing.
b) Split `solverfactorytest.ini` in two files and run the tests twice, once for the iterative solvers and once with the direct solvers. The latter test is guarded and is not run if a single library is missing.
c) Split `solverfactorytest.ini` into multiple files, one for the iterative solvers and one for each direct solver - and a guard for the only direct solver library used by the test. Downside is, that it adds a lot of tests.
I'd prefer b). What do you think?https://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/331[Python] Additional Cmake arguments to Python generator Dune 2.92023-03-27T13:23:30ZAlexander Müller[Python] Additional Cmake arguments to Python generator Dune 2.9I try to use JIT compilation for my module. Since my code uses c+20, the `generator.load` call fails with
```cpp
1: /dune/dune-localfefunctions/dune/localfefunctions/expressions/rebind.hh:14:26: error: ‘remove_cvref_t’ in namespace ‘s...I try to use JIT compilation for my module. Since my code uses c+20, the `generator.load` call fails with
```cpp
1: /dune/dune-localfefunctions/dune/localfefunctions/expressions/rebind.hh:14:26: error: ‘remove_cvref_t’ in namespace ‘std’ does not name a template type
1: 14 | auto rebind(const std::remove_cvref_t<E1>& u, const std::remove_cvref_t<E2>& v,
1: | ^~~~~~~~~~~~~~
1: /dune/dune-localfefunctions/dune/localfefunctions/expressions/rebind.hh:14:21: note: ‘std::remove_cvref_t’ is only available from C++20 onwards
1: 14 | auto rebind(const std::remove_cvref_t<E1>& u, const std::remove_cvref_t<E2>& v,
```
in an included header. My generator code looks like
```python
from dune.generator.generator import SimpleGenerator
from dune.common.hashit import hashIt
def linearElasticElement(basis, element, youngsMod, nu) :
generator = SimpleGenerator("LinearElastic", "Ikarus::Python")
element_type = f"Ikarus::LinearElastic<{basis.cppTypeName}>"
extraCM=["target_compile_features( TARGET PUBLIC cxx_std_20)"] # make sure we compile with C++20 enabled
#extraCM=["set(CMAKE_CXX_STANDARD 20)"] # make sure we compile with C++20 enabled
includes = []
includes += ["ikarus/finiteElements/mechanics/linearElastic.hh"]
includes += ["ikarus/python/finiteElements/linearElastic.hh"]
moduleName = "linearElastic_" + hashIt(element_type)
module = generator.load(
includes=includes,
typeName=element_type,
moduleName=moduleName,
extraCMake=extraCM,
holder="std::shared_ptr",
)
return module.LinearElastic(basis, element, youngsMod, nu)
```
is the `extraCMake` input argument suited for this use case?
Both `extraCM` I defined there didn't change the error message.
Thanks in advance! @andreas.dedner @tkoch @robert.kloefkornhttps://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/167tensorProductCoordinates does not allow coords with different number of x and...2023-10-13T07:42:34ZFlorian StreitbürgertensorProductCoordinates does not allow coords with different number of x and y coordinatesI tried to construct a grid with a different number of x and y coordinates using `tensorProductCoordinates` from dune-grid/python/dune/grid/_grids.py. I received the following error message:
```
Traceback (most recent call last):
File...I tried to construct a grid with a different number of x and y coordinates using `tensorProductCoordinates` from dune-grid/python/dune/grid/_grids.py. I received the following error message:
```
Traceback (most recent call last):
File "/home/streitfl/Schreibtisch/Dune/build/dune-hypercut/examples/anisotrop/simulations_advection.py", line 316, in <module>
advTestCase = AdvTestCase((50, 2), 0.4, boundaryValues)
File "/home/streitfl/Schreibtisch/Dune/build/dune-hypercut/examples/anisotrop/simulations_advection.py", line 98, in __init__
domain = domains.AnisotropInX(**cfg)
File "/home/streitfl/Schreibtisch/Dune/dune-hypercut/python/pyhypercut/domains.py", line 209, in __init__
BaseAnisotrop.__init__(self, cells, lowerLeft, upperRight, refinements, alpha, 0.)
File "/home/streitfl/Schreibtisch/Dune/dune-hypercut/python/pyhypercut/domains.py", line 138, in __init__
view = gridView(tensorProductCoordinates(coordinates, lowerLeft), dimgrid=2)
File "/home/streitfl/Schreibtisch/Dune/build/dune-grid/python/dune/grid/_grids.py", line 160, in tensorProductCoordinates
coords = np.array(coords, dtype=dtype)
ValueError: setting an array element with a sequence. The requested array has an inhomogeneous shape after 1 dimensions. The detected shape was (2,) + inhomogeneous part.
```
The variable coordinates in the above error message is a list containing two arrays of different sizes.Christian EngwerChristian Engwerhttps://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.