Core Modules issueshttps://gitlab.dune-project.org/groups/core/-/issues2022-05-02T12:00:49Zhttps://gitlab.dune-project.org/core/dune-istl/-/issues/103BCRSMatrix deallocator seems to have a memory leak2022-05-02T12:00:49ZSantiago Ospina De Los Ríossospinar@gmail.comBCRSMatrix deallocator seems to have a memory leakWhen using an address sanitizer (`-fsanitize=address`), I get a message on matrix deconstruction saying that objects passed on delete do not match. The important bit is the size of the allocated and deallocated memory:
* size of the all...When using an address sanitizer (`-fsanitize=address`), I get a message on matrix deconstruction saying that objects passed on delete do not match. The important bit is the size of the allocated and deallocated memory:
* size of the allocated type: 19208 bytes;
* size of the deallocated type: 8 bytes.
Checking out the lines where it diagnoses the issue, allocation happens when [resting the shaped pointer to the sparsity pattern `j_`](https://gitlab.dune-project.org/core/dune-istl/-/blob/9dae4be71564781f0650c87ef8f380c4c00abe8f/dune/istl/bcrsmatrix.hh#L2245):
```c++
j_.reset(sizeAllocator_.allocate(allocationSize_),Deallocator(sizeAllocator_));
```
Now, the `Deallocator` functor in the line above looks like this:
```c++
void operator()(size_type* p) { sizeAllocator_.deallocate(p,1); }
```
The second argument refers to the size to the deallocation chunk. `1` means that it will only deallocate `1*sizeof(T)` bytes while we actually need `allocationSize_*sizeof(T)` bytes which matches with the allocated chunk of memory. So this may explain the warning. When setting the deallocator with `allocationSize_` the warning goes away. I could not find the `Deallocator` object being used elsewhere, so it seems safe to change its behaviour here. If this makes sense, I can push a MR with the fix.https://gitlab.dune-project.org/core/dune-geometry/-/issues/31QuadPy now is propietary2022-04-25T16:45:01ZSantiago Ospina De Los Ríossospinar@gmail.comQuadPy now is propietaryI got informed that the `QuadPy` module changed to be proprietary. Indeed in seems to only provide the binaries in PyPI https://pypi.org/project/quadpy/ while the main repository now only contains the README. Not sure if `dune-geometry` ...I got informed that the `QuadPy` module changed to be proprietary. Indeed in seems to only provide the binaries in PyPI https://pypi.org/project/quadpy/ while the main repository now only contains the README. Not sure if `dune-geometry` needs to do something special since we never distribute it explicitly nor have it as a hard dependency. But I wanted to leave the record...https://gitlab.dune-project.org/core/dune-common/-/issues/305[python][bug] Deadlock in cmakebuilder2022-04-25T08:52:36ZTimo Koch[python][bug] Deadlock in cmakebuilderCommit d3e697332dcc80fd1535c694466eda7649bb93d7 introduces a bug in the cmake builder.
`Popen.wait` deadlocks if the command produces enough output to fill the buffer. The docs clearly warns about this https://docs.python.org/3/library/s...Commit d3e697332dcc80fd1535c694466eda7649bb93d7 introduces a bug in the cmake builder.
`Popen.wait` deadlocks if the command produces enough output to fill the buffer. The docs clearly warns about this https://docs.python.org/3/library/subprocess.html#subprocess.Popen.wait. `communicate` has to be called.Timo KochTimo Kochhttps://gitlab.dune-project.org/core/dune-common/-/issues/304Messed up python compile output after !11152022-04-25T08:51:45ZTimo KochMessed up python compile output after !1115Commit eebb02805eaca397c54a82bf54789ffaf62c921e messed up the Python log output. The message differentiating between different compilation modes (`PrintCompiling`, no idea why the variable name is uppercase.., e.g. here https://gitlab.du...Commit eebb02805eaca397c54a82bf54789ffaf62c921e messed up the Python log output. The message differentiating between different compilation modes (`PrintCompiling`, no idea why the variable name is uppercase.., e.g. here https://gitlab.dune-project.org/core/dune-common/-/blob/master/python/dune/generator/cmakebuilder.py#L275) is lost because the local variable has no effect when it's in a separate function.Timo KochTimo Kochhttps://gitlab.dune-project.org/core/dune-common/-/issues/303[python] pybind11 name of FieldVector does not contain the field type2022-05-06T16:25:19ZChristian Engwer[python] pybind11 name of FieldVector does not contain the field typeThe field type changes the type of the FieldVector, but registerFieldVector only considers the dimension and does not adhere the field type.
This breaks any code using `field_type != double`.The field type changes the type of the FieldVector, but registerFieldVector only considers the dimension and does not adhere the field type.
This breaks any code using `field_type != double`.https://gitlab.dune-project.org/core/dune-common/-/issues/302Python and MPI does not work anymore.2022-04-08T12:12:17ZRobert KPython and MPI does not work anymore.Somewhere between commit 240bccb5ad830f791d38bea43fad285aa1b4ae76 (works fine) and commit 73ec17e1f45a376f7e026d9ce6b2d404531f83b6 (does not work) the ability to run DUNE Python scripts with MPI broke.
With the current master I get:
Wit...Somewhere between commit 240bccb5ad830f791d38bea43fad285aa1b4ae76 (works fine) and commit 73ec17e1f45a376f7e026d9ce6b2d404531f83b6 (does not work) the ability to run DUNE Python scripts with MPI broke.
With the current master I get:
With the current master I get
```
Traceback (most recent call last):
File "/home/robertk/work/Dune/stable/cfd-playground/examples/euler/euler.py", line 67, in <module>
gridView = view( grid( Model.domain, dimgrid=dim ) ) in
File "/home/robertk/work/Dune/stable/dune-grid/build-cmake/python/dune/grid/_grids.py", line 195, in yaspGrid
gridView = view( grid( Model.domain, dimgrid=dim ) )
File "/home/robertk/work/Dune/stable/dune-grid/build-cmake/python/dune/grid/_grids.py", line 195, in yaspGrid
constructor = equidistantOffsetCoordinates(
File "/home/robertk/work/Dune/stable/dune-grid/build-cmake/python/dune/grid/_grids.py", line 122, in equidistantOffsetCoordinates
constructor = equidistantOffsetCoordinates( on
File "/home/robertk/work/Dune/stable/dune-grid/build-cmake/python/dune/grid/_grids.py", line 122, in equ.tidistantOffsetCoordinates
mod = moduleYaspCoordinates(dim) on
File "/home/robertk/work/Dune/stable/dune-grid/build-cmake/python/dune/grid/_grids.py", line 116, in mod.tuleYaspCoordinates
mod = moduleYaspCoordinates(dim)
File "/home/robertk/work/Dune/stable/dune-grid/build-cmake/python/dune/grid/_grids.py", line 116, in moduleYaspCoordinates ul
module = builder.load(moduleName, source, "yasp coordinates dim={dim}".format(dim = dim)) # , self.typeName[0], extraCMake) eN
File "/home/robertk/work/Dune/stable/dune-common/build-cmake/python/dune/generator/cmakebuilder.py", line 276, in load e
module = builder.load(moduleName, source, "yasp coordinates dim={dim}".format(dim = dim)) # , self.typeName[0], extraCMake)
File "/home/robertk/work/Dune/stable/dune-common/build-cmake/python/dune/generator/cmakebuilder.py", line e 276, in load
self.initialize()
File "/home/robertk/work/Dune/stable/dune-common/build-cmake/python/dune/generator/cmakebuilder.py", linine 191, in initialize
removeGenerated(['30'], date=True, verbose=False)
File "/home/robertk/work/Dune/stable/dune-common/build-cmake/python/dune/generator/remove.py", line 82, e in removeGenerated
self.initialize()
File "/home/robertk/work/Dune/stable/dune-common/build-cmake/python/dune/generator/cmakebuilder.py", line 191, in initialize
for line in fileinput.input( os.path.join(generated_dir, 'CMakeLists.txt'), inplace = True): in
File "/usr/lib/python3.9/fileinput.py", line 249, in __next__
removeGenerated(['30'], date=True, verbose=False)
File "/home/robertk/work/Dune/stable/dune-common/build-cmake/python/dune/generator/remove.py", line 82, in removeGenerated
for line in fileinput.input( os.path.join(generated_dir, 'CMakeLists.txt'), inplace = True):
File "/usr/lib/python3.9/fileinput.py", line 249, in __next__
line = self._readline()
File "/usr/lib/python3.9/fileinput.py", line 343, in _readline
line = self._readline() on
File "/usr/lib/python3.9/fileinput.py", line 343, in _readline .t
os.rename(self._filename, self._backupfilename)
FileNotFoundError: [Errno 2] No such file or directory: '/home/robertk/work/Dune/stable/cache/dune-py/pythonon/dune/generated/CMakeLists.txt' -> '/home/robertk/work/Dune/stable/cache/dune-py/python/dune/generated/C.tMakeLists.txt.bak'
os.rename(self._filename, self._backupfilename)
FileNotFoundError: [Errno 2] No such file or directory: '/home/robertk/work/Dune/stable/cache/dune-py/python/dune/generated/CMakeLists.txt' -> '/home/robertk/work/Dune/stable/cache/dune-py/python/dune/generated/CulMakeLists.txt.bak'
```https://gitlab.dune-project.org/core/ci-config/-/issues/3CI problems with some combinations of runner & python tests2022-04-15T21:57:01ZChristian EngwerCI problems with some combinations of runner & python testsSome pipelines fail with hard to debug errors, see e.g.
[jobs/332326](https://gitlab.dune-project.org/core/dune-grid/-/jobs/332326),
[jobs/332326](https://gitlab.dune-project.org/core/dune-grid/-/jobs/332326),
[jobs/332335](https://gitla...Some pipelines fail with hard to debug errors, see e.g.
[jobs/332326](https://gitlab.dune-project.org/core/dune-grid/-/jobs/332326),
[jobs/332326](https://gitlab.dune-project.org/core/dune-grid/-/jobs/332326),
[jobs/332335](https://gitlab.dune-project.org/core/dune-grid/-/jobs/332335) or
[jobs/334487](https://gitlab.dune-project.org/core/dune-grid/-/jobs/334487).
The problem are `ValueError: Invalid file object: <_io.BufferedReader name=20>` in the python bindings during `callCMake`:
```
DUNE-INFO: Rebuilding dune-py module
Traceback (most recent call last):
File "test-ug.py", line 14, in <module>
grid = dune.grid.ugGrid(reader, dimgrid=2)
File "/builds/core/dune-grid/build-cmake/python/dune/grid/_grids.py", line 235, in ugGrid
gridModule = module(includes, typeName)
File "/builds/core/dune-grid/build-cmake/python/dune/grid/grid_generator.py", line 349, in module
module = generator.load(includes, typeName, typeHash, *args, **kwargs)
File "/duneci/modules/dune-common/build-cmake/python/dune/generator/generator.py", line 169, in load
return self.post(moduleName, source, postscript, extraCMake)
File "/duneci/modules/dune-common/build-cmake/python/dune/generator/generator.py", line 121, in post
module = builder.load(moduleName, source, self.typeName[0], extraCMake)
File "/duneci/modules/dune-common/build-cmake/python/dune/generator/cmakebuilder.py", line 345, in load
self.compile(infoTxt=PrintCompiling, target=moduleName)
File "/duneci/modules/dune-common/build-cmake/python/dune/generator/cmakebuilder.py", line 241, in compile
logLevel=logging.INFO
File "/duneci/modules/dune-common/build-cmake/python/dune/generator/cmakebuilder.py", line 219, in callCMake
_, stderr = cmake.communicate()
File "/usr/lib/python3.7/subprocess.py", line 939, in communicate
stdout, stderr = self._communicate(input, endtime, timeout)
File "/usr/lib/python3.7/subprocess.py", line 1672, in _communicate
selector.register(self.stdout, selectors.EVENT_READ)
File "/usr/lib/python3.7/selectors.py", line 352, in register
key = super().register(fileobj, events, data)
File "/usr/lib/python3.7/selectors.py", line 238, in register
key = SelectorKey(fileobj, self._fileobj_lookup(fileobj), events, data)
File "/usr/lib/python3.7/selectors.py", line 225, in _fileobj_lookup
return _fileobj_to_fd(fileobj)
File "/usr/lib/python3.7/selectors.py", line 40, in _fileobj_to_fd
"{!r}".format(fileobj)) from None
ValueError: Invalid file object: <_io.BufferedReader name=20>
```
These errors are unrelated to the changes of the corresponding MR. It seems that some runners are more likely to experience these problems, but I currently don't understand what exactly leads to the problem.
I observed the problem with `dune-ci@epic.uni-muenster.de`, `dune-ci@sky.uni-muenster.de`, `ci-tu-dresden` and one further Dresden runner. On the other hand it is not strictly due to some particular runner, as for an job, I observed, that it failed a couple of times in Dresden and the went through on sky.
I' unsure whether this is is a problem of the python bindings or of the docker images?!https://gitlab.dune-project.org/core/dune-grid/-/issues/152C++ and Python types of YaspGrid inconsistent2022-05-09T16:39:31ZChristian EngwerC++ and Python types of YaspGrid inconsistentWhen I create a `YaspGrid` from python, e.g. in the following way
```
domain = cartesianDomain([0,0],[1,1],[gridSize,gridSize])
grid = yaspGrid(domain, dimgrid=2)
```
the exact C++ type is `Dune::YaspGrid<2, Dune::EquidistantOffsetCoordi...When I create a `YaspGrid` from python, e.g. in the following way
```
domain = cartesianDomain([0,0],[1,1],[gridSize,gridSize])
grid = yaspGrid(domain, dimgrid=2)
```
the exact C++ type is `Dune::YaspGrid<2, Dune::EquidistantOffsetCoordinates<double, 2>>`, where as
`YaspGrid<2> corresponds to `Dune::YaspGrid<2, Dune::EquidistantCoordinates<double, 2>>`.
This is really surprising when trying to use a python generated `YaspGrid` in C++.https://gitlab.dune-project.org/core/dune-common/-/issues/301How call GenerateTypeName for `Foo<Signature>`2022-04-01T13:37:37ZChristian EngwerHow call GenerateTypeName for `Foo<Signature>`When defining function bindings, it is not so uncommon, that the first template argument is a signature, e.g.
`double(Dune::FieldVector<double,2>)`.
I couldn't figure out how to specify such a type for the python type registry.
If I c...When defining function bindings, it is not so uncommon, that the first template argument is a signature, e.g.
`double(Dune::FieldVector<double,2>)`.
I couldn't figure out how to specify such a type for the python type registry.
If I call
```
GenerateTypeName("Foo", "double(Dune::FieldVector<double,2>)")
```
it interprets the second string as a member name and tries to register `Foo::double(Dune::FieldVector<double,2>)`.
If I try something like
```
GenerateTypeName("Foo", MetaType<double(Dune::FieldVector<double,2>)>)
```
it fails, because the signature is nothing we could register as a complete type, or could and should we?https://gitlab.dune-project.org/core/dune-common/-/issues/300GenerateTypeName is fragile2023-04-09T14:08:30ZChristian EngwerGenerateTypeName is fragileThe `GenerateTypeName` infrastructure in `typeregistry.hh` requires detailed knowledge about the details of the C++ type. Providing these manually is error-prone, see e.g. the global basis in dune-functions (dune-functions#70).
The glob...The `GenerateTypeName` infrastructure in `typeregistry.hh` requires detailed knowledge about the details of the C++ type. Providing these manually is error-prone, see e.g. the global basis in dune-functions (dune-functions#70).
The global basis defines a `DiscreteGlobalBasisFunction`, but sets a type name to `GlobalBasis::DiscreteFunction`. When trying to generate C++ code the can operate on such a discrete function, we get compiler errors, because there is no typename `GlobalBasis::DiscreteFunction` in the concrete `GlobalBasis`.
Couldn't we make `GenerateTypeName` more robust by using `className` to directly extract the correct type name?
The problem is that `GenerateTypeName` is hardly documented, thus I'm unsure about implications of such a change.https://gitlab.dune-project.org/core/dune-grid/-/issues/151Wrong subscript in test-yaspgrid-backuprestore-tensor2022-03-19T15:54:12ZChristoph GrüningerWrong subscript in test-yaspgrid-backuprestore-tensorI gave GCC 12.0 a try and when compiling `test-yaspgrid-backuprestore-tensor`, I get the following warning
`array subscript 18446744071562067968 is above array bounds of ‘std::__array_traits<int, 3>::_Type’ {aka ‘const int [3]’}`. I coul...I gave GCC 12.0 a try and when compiling `test-yaspgrid-backuprestore-tensor`, I get the following warning
`array subscript 18446744071562067968 is above array bounds of ‘std::__array_traits<int, 3>::_Type’ {aka ‘const int [3]’}`. I couldn't find out what the problem is, but it seems to be unrelated to my recently changed binomial code. Also, only when compiling this test I get the warning.
The whole warning:
```
Built target test-yaspgrid-backuprestore-tensor
[ 90%] Building CXX object dune/grid/test/yasp/CMakeFiles/test-yaspgrid-entityshifttable.dir/test-yaspgrid-entityshifttable.cc.o
In file included from /usr/include/c++/12/functional:63,
from /home/gruenich/dune/complete/dune-common/dune/common/test/collectorstream.hh:8,
from /home/gruenich/dune/complete/dune-common/dune/common/test/testsuite.hh:11,
from /home/gruenich/dune/complete/dune-grid/dune/grid/test/yasp/test-yaspgrid-entityshifttable.cc:6:
In static member function ‘static constexpr _Tp& std::__array_traits<_Tp, _Nm>::_S_ref(const _Tp (&)[_Nm], std::size_t) [with _Tp = int; long unsigned int _Nm = 3]’,
inlined from ‘constexpr const std::array<_Tp, _Nm>::value_type& std::array<_Tp, _Nm>::operator[](size_type) const [with _Tp = int; long unsigned int _Nm = 3]’ at /usr/include/c++/12/array:219:25,
inlined from ‘static constexpr int Dune::Yasp::BinomialTable<n>::evaluate(int, int) [with int n = 1]’ at /home/gruenich/dune/complete/dune-grid/dune/grid/yaspgrid/yaspgridentity.hh:41:23,
inlined from ‘constexpr int Dune::Yasp::subEnt(int, int) [with int dimworld = 1]’ at /home/gruenich/dune/complete/dune-grid/dune/grid/yaspgrid/yaspgridentity.hh:105:60,
inlined from ‘static constexpr long long unsigned int Dune::Yasp::calculate_entity_shift<dim>::evaluate(int, int) [with int dim = 1]’ at /home/gruenich/dune/complete/dune-grid/dune/grid/yaspgrid/yaspgridentity.hh:192:69,
inlined from ‘Dune::TestSuite testEntityShiftTable(const std::vector<long long unsigned int>*, bool) [with F = Dune::Yasp::calculate_entity_shift<1>; int dim = 1]’ at /home/gruenich/dune/complete/dune-grid/dune/grid/test/yasp/test-yaspgrid-entityshifttable.cc:64:21:
/usr/include/c++/12/array:61:36: warning: array subscript 18446744071562067968 is above array bounds of ‘std::__array_traits<int, 3>::_Type’ {aka ‘const int [3]’} [-Warray-bounds]
61 | { return const_cast<_Tp&>(__t[__n]); }
| ~~~^
In file included from /home/gruenich/dune/complete/dune-grid/dune/grid/yaspgrid.hh:69,
from /home/gruenich/dune/complete/dune-grid/dune/grid/test/yasp/test-yaspgrid-entityshifttable.cc:7:
/home/gruenich/dune/complete/dune-grid/dune/grid/yaspgrid/yaspgridentity.hh: In function ‘Dune::TestSuite testEntityShiftTable(const std::vector<long long unsigned int>*, bool) [with F = Dune::Yasp::calculate_entity_shift<1>; int dim = 1]’:
/home/gruenich/dune/complete/dune-grid/dune/grid/yaspgrid/yaspgridentity.hh:85:54: note: while referencing ‘Dune::Yasp::BinomialTable<1>::_values’
85 | static constexpr std::array<int,(n+1)*(n+2)/2> _values = computeValues(std::make_index_sequence<(n+1)*(n+2)/2>{});
|
```
For future reference:
```
> gcc-12 --version
gcc-12 (SUSE Linux) 12.0.1 20220317 (experimental) [revision c43cb355f25dd22133d15819bd6ec03d3d3939fd]
```https://gitlab.dune-project.org/core/dune-common/-/issues/299make doc fails to build latex docs2023-02-12T20:37:37ZMarkus Blattmake doc fails to build latex docsNot sure whether its me, my system or DUNE, but I get latex compile errors during `make doc`:
```
[ 5%] Building PDF from communication.tex...
Rc files read:
/etc/LatexMk
/home/mblatt/src/dune/current/dune-common/build-cmake/doc/com...Not sure whether its me, my system or DUNE, but I get latex compile errors during `make doc`:
```
[ 5%] Building PDF from communication.tex...
Rc files read:
/etc/LatexMk
/home/mblatt/src/dune/current/dune-common/build-cmake/doc/comm/doc_comm_communication_tex.latexmkrc
Latexmk: This is Latexmk, John Collins, 29 September 2020, version: 4.70b.
Set environment variable BIBINPUTS='/home/mblatt/src/dune/current/dune-common/build-cmake/doc/comm:'
Set environment variable TEXINPUTS='/home/mblatt/src/dune/current/dune-common/build-cmake/doc/comm:'
Latexmk: applying rule 'bibtex /home/mblatt/src/dune/current/dune-common/build-cmake/doc/comm/communication'...
Rule 'bibtex /home/mblatt/src/dune/current/dune-common/build-cmake/doc/comm/communication': The following rules & subrules became out-of-date:
'bibtex /home/mblatt/src/dune/current/dune-common/build-cmake/doc/comm/communication'
------------
Run number 1 of rule 'bibtex /home/mblatt/src/dune/current/dune-common/build-cmake/doc/comm/communication'
------------
For rule 'bibtex /home/mblatt/src/dune/current/dune-common/build-cmake/doc/comm/communication', running '&run_bibtex( )' ...
------------
Running '/usr/bin/bibtex "/home/mblatt/src/dune/current/dune-common/build-cmake/doc/comm/communication.aux"'
------------
/usr/bin/bibtex: Not writing to /home/mblatt/src/dune/current/dune-common/build-cmake/doc/comm/communication.blg (openout_any = p).
I couldn't open file name `/home/mblatt/src/dune/current/dune-common/build-cmake/doc/comm/communication.blg'
Latexmk: Errors, so I did not complete making targets
Collected error summary (may duplicate other messages):
bibtex /home/mblatt/src/dune/current/dune-common/build-cmake/doc/comm/communication: Could not open bibtex log file for '/home/mblatt/src/dune/current/dune-common/build-cmake/doc/comm/communication'
Latexmk: Use the -f option to force complete processing,
unless error was exceeding maximum runs, or warnings treated as errors.
make[3]: *** [doc/comm/CMakeFiles/doc_comm_communication_tex.dir/build.make:77: doc/comm/CMakeFiles/doc_comm_communication_tex] Fehler 12
make[2]: *** [CMakeFiles/Makefile2:1977: doc/comm/CMakeFiles/doc_comm_communication_tex.dir/all] Fehler 2
make[1]: *** [CMakeFiles/Makefile2:699: CMakeFiles/doc.dir/rule] Fehler 2
```https://gitlab.dune-project.org/core/dune-grid/-/issues/150python bindings don't allow shared_ptr<Grid>2022-03-26T19:19:09ZChristian Engwerpython bindings don't allow shared_ptr<Grid>A `Grid` can not be copied and as such has to be passed around either by reference or as a `shared_ptr`. The python bindings use the default holder type, which is `unique_ptr`. This makes it really difficult to pass a Grid constructed vi...A `Grid` can not be copied and as such has to be passed around either by reference or as a `shared_ptr`. The python bindings use the default holder type, which is `unique_ptr`. This makes it really difficult to pass a Grid constructed via the `python` bindings to existing code that stores the grid as a `shared_ptr`. I assume it would work with a reference, but the bindings should be flexible enough to work with different (reasonable) usage patterns.
We should switch the holder type of the `Grid` to `shared_ptr`. For other types like `GridView` I guess `unique_ptr` is OK, as we nowadays encourage people to copy a `GridView`, as it is supposed to be light weight.https://gitlab.dune-project.org/core/dune-grid/-/issues/149tensorproduct constructors not working in python bindings2022-05-09T16:39:30ZChristian Engwertensorproduct constructors not working in python bindingsIn C++ it is possible to construct tensorproduct grids, using a vectors with offsets per dimension.
This is currently not possible in python.In C++ it is possible to construct tensorproduct grids, using a vectors with offsets per dimension.
This is currently not possible in python.https://gitlab.dune-project.org/core/dune-grid/-/issues/148Test header checkjacobians.hh is not used2022-03-04T22:19:09ZCarsten Gräsergraeser@math.fau.deTest header checkjacobians.hh is not usedThere is a header `dune/grid/test/checkjacobians.hh` in dune-grid that is supposed to check the Jacobian-related interface of a geometry. However, this header is not included anywhere in the core. I also could not find any use in a grid ...There is a header `dune/grid/test/checkjacobians.hh` in dune-grid that is supposed to check the Jacobian-related interface of a geometry. However, this header is not included anywhere in the core. I also could not find any use in a grid implementation.
The header was introduced in 2015 (99990bf9) by renaming `checkjacobians.cc`. But even in this revision I cannot find any usage of it. Since then it has seen some cosmetic changes, but they all may originate from systematic grep&renaming procedures.
Since the geometry-interface is checked by `checkgeometry.hh` in from dune-geometry I wonder if this header is obsolete.https://gitlab.dune-project.org/core/dune-common/-/issues/298Test failure alignedallocatortest on AppleClang2022-05-06T11:02:28ZTimo KochTest failure alignedallocatortest on AppleClangWith "The CXX compiler identification is AppleClang 12.0.5.12050022"
I get an `std::bad_alloc` in the `alignedallocatortest` on master.
```
Start 113: alignedallocatortest
113: Test command: dune-common/build-cmake/dune/common/test/ali...With "The CXX compiler identification is AppleClang 12.0.5.12050022"
I get an `std::bad_alloc` in the `alignedallocatortest` on master.
```
Start 113: alignedallocatortest
113: Test command: dune-common/build-cmake/dune/common/test/alignedallocatortest
113: Test timeout computed to be: 300
113: libc++abi: terminating with uncaught exception of type std::bad_alloc: std::bad_alloc
1/1 Test #113: alignedallocatortest .............Subprocess aborted***Exception: 0.02 sec
```https://gitlab.dune-project.org/core/dune-geometry/-/issues/30Cleanup FieldMatrix utilities2022-03-03T18:22:51ZCarsten Gräsergraeser@math.fau.deCleanup FieldMatrix utilitiesThe header `affinegeometry.hh` contains a collection of `FieldMatrix` helper functions in `struct FieldMatrixHelper` that contains some duplicate code and some utilities that should be moved to dune-common. E.g.
* I was surprised to fin...The header `affinegeometry.hh` contains a collection of `FieldMatrix` helper functions in `struct FieldMatrixHelper` that contains some duplicate code and some utilities that should be moved to dune-common. E.g.
* I was surprised to find that dune-geometry contains an implementation for the (left/right) inverse of any `FieldMatrix<n,m>` of full rank which is orthogonal to the one in dune-common, which only supports square matrices of size up to 3. Furthermore the 1x1 and 3x3 implementation differ.
* `FieldMatrixHelper` reimplements `A.mv(x,y)` and `A.mtv(x,y)`.
* `FieldMatrixHelper` reimplements `A*B` (Fun fact: `FieldMatrix` itself already contains three implementations: `operator*`, `leftmultiplyany`, `rightmultiplyany`))
* `FieldMatrixHelper` contains a dense Cholesky-factorization that might be really helpful in other places.
This ticket is a reminder that this should be cleaned up.https://gitlab.dune-project.org/core/dune-common/-/issues/297Cmake fails with" -D CMAKE_DISABLE_FIND_PACKAGE_Python3=ON"2023-02-22T12:03:56ZMarkus BlattCmake fails with" -D CMAKE_DISABLE_FIND_PACKAGE_Python3=ON"```
-- using C macro definitions from /home/mblatt/src/dune/opm-master/dune-common/doc/doxygen/doxygen-macros for Doxygen
-- Skipping building CMake API documentation (Python interpreter was not found!)
CMake Error at cmake/modules/DuneP...```
-- using C macro definitions from /home/mblatt/src/dune/opm-master/dune-common/doc/doxygen/doxygen-macros for Doxygen
-- Skipping building CMake API documentation (Python interpreter was not found!)
CMake Error at cmake/modules/DunePythonTestCommand.cmake:92 (add_dependencies):
Cannot add target-level dependencies to non-existent target "test_python".
The add_dependencies works for top-level logical targets created by the
add_executable, add_library, or add_custom_target commands. If you want to
add file-level dependencies see the DEPENDS option of the add_custom_target
and add_custom_command commands.
Call Stack (most recent call first):
dune/python/test/CMakeLists.txt:1 (dune_python_add_test)
CMake Error at python/dune/common/CMakeLists.txt:1 (add_python_targets):
Unknown CMake command "add_python_targets".
-- Configuring incomplete, errors occurred!
See also "/home/mblatt/src/dune/opm-master/dune-common/opts-opm-no-python.cmake/CMakeFiles/CMakeOutput.log".
See also "/home/mblatt/src/dune/opm-master/dune-common/opts-opm-no-python.cmake/CMakeFiles/CMakeError.log".
```https://gitlab.dune-project.org/core/dune-common/-/issues/296Python bindings require virtual environment2023-02-28T13:27:06ZTimo KochPython bindings require virtual environmentThe Python bindings are currently silently disabled if no virtual environment package is found on the system (https://gitlab.dune-project.org/core/dune-common/-/blob/master/cmake/modules/DunePythonVirtualenv.cmake#L129). While it's good ...The Python bindings are currently silently disabled if no virtual environment package is found on the system (https://gitlab.dune-project.org/core/dune-common/-/blob/master/cmake/modules/DunePythonVirtualenv.cmake#L129). While it's good practice to use a virtual environment, I don't see why this should be a hard requirement for using the Python bindings.
It might be that it's currently required (although this is not obvious without having an overview over all CMake files). In this case, this issue should be considered a feature request.
If a virtual environment stays/is a hard requirement, this should be checked earlier IMO, e.g. [here](https://gitlab.dune-project.org/core/dune-common/-/blob/master/cmake/modules/DunePythonCommonMacros.cmake#L90).https://gitlab.dune-project.org/core/dune-common/-/issues/295Python tests fail with "ValueError: Invalid file object: <_io.BufferedReader ...2022-04-15T21:57:02ZChristoph GrüningerPython tests fail with "ValueError: Invalid file object: <_io.BufferedReader name=20>"Changes to code that is unrelated to Python and Python tests leads to error like
```
DUNE-INFO: Compiling HierarchicalGrid (new)
Traceback (most recent call last):
File "test_gf1.py", line 56, in <module>
gridView = structuredGri...Changes to code that is unrelated to Python and Python tests leads to error like
```
DUNE-INFO: Compiling HierarchicalGrid (new)
Traceback (most recent call last):
File "test_gf1.py", line 56, in <module>
gridView = structuredGrid([0,0],[1,1],[10,10])
File "/builds/core/dune-grid/build-cmake/python/dune/grid/core.py", line 52, in structuredGrid
return yaspGrid(domain, dimgrid=len(lower))
File "/builds/core/dune-grid/build-cmake/python/dune/grid/_grids.py", line 38, in yaspGrid
gridModule = module(includes, typeName, ctor)
File "/builds/core/dune-grid/build-cmake/python/dune/grid/grid_generator.py", line 348, in module
module = generator.load(includes, typeName, typeHash, *args, **kwargs)
File "/duneci/modules/dune-common/build-cmake/python/dune/generator/generator.py", line 169, in load
return self.post(moduleName, source, postscript, extraCMake)
File "/duneci/modules/dune-common/build-cmake/python/dune/generator/generator.py", line 121, in post
module = builder.load(moduleName, source, self.typeName[0], extraCMake)
File "/duneci/modules/dune-common/build-cmake/python/dune/generator/cmakebuilder.py", line 341, in load
self.compile(infoTxt=PrintCompiling, target=moduleName)
File "/duneci/modules/dune-common/build-cmake/python/dune/generator/cmakebuilder.py", line 237, in compile
logLevel=logging.INFO
File "/duneci/modules/dune-common/build-cmake/python/dune/generator/cmakebuilder.py", line 215, in callCMake
_, stderr = cmake.communicate()
File "/usr/lib/python3.7/subprocess.py", line 939, in communicate
stdout, stderr = self._communicate(input, endtime, timeout)
File "/usr/lib/python3.7/subprocess.py", line 1672, in _communicate
selector.register(self.stdout, selectors.EVENT_READ)
File "/usr/lib/python3.7/selectors.py", line 352, in register
key = super().register(fileobj, events, data)
File "/usr/lib/python3.7/selectors.py", line 238, in register
key = SelectorKey(fileobj, self._fileobj_lookup(fileobj), events, data)
File "/usr/lib/python3.7/selectors.py", line 225, in _fileobj_lookup
return _fileobj_to_fd(fileobj)
File "/usr/lib/python3.7/selectors.py", line 40, in _fileobj_to_fd
"{!r}".format(fileobj)) from None
ValueError: Invalid file object: <_io.BufferedReader name=20>
```
This happens at least for dune-grid and dune-functions, see for example dune-grid!571