dune-python issueshttps://gitlab.dune-project.org/staging/dune-python/-/issues2017-11-27T14:48:57Zhttps://gitlab.dune-project.org/staging/dune-python/-/issues/3finiteelement demo with YaspGrid not working2017-11-27T14:48:57ZAndreas Dednerfiniteelement demo with YaspGrid not workingWhen switching to a YaspGrid there is an issue with the jacobianInverseTransposed being converted to a numpy array. The reason being that the return type in this case is not a FieldMatrix but a DiagonalMatrix:
jacInvTra = np.array(e...When switching to a YaspGrid there is an issue with the jacobianInverseTransposed being converted to a numpy array. The reason being that the return type in this case is not a FieldMatrix but a DiagonalMatrix:
jacInvTra = np.array(e.geometry.jacobianInverseTransposed(p.position), copy = False)
TypeError: Unable to convert function return value to a Python type! The signature was
(dune.generated.grid_4c1008dcc466e715718c2641402add74.Geometry2, dune.common.FieldVector2) -> Dune::DiagonalMatrix<double, 2>
https://gitlab.dune-project.org/staging/dune-python/-/issues/9register dune exceptions2017-07-07T09:52:47ZAndreas Dednerregister dune exceptionsRelease newer 2.5https://gitlab.dune-project.org/staging/dune-python/-/issues/12Making the parallel interface more generic causes segfaults2017-07-07T09:52:47ZMichaël SghaïerMaking the parallel interface more generic causes segfaultsAs discussed by emails, I tried to parameterized the ProxyDataHandle class by a `pybind11::object` to be more generic in the parallel interface but that ended up with many segfaults when running the parallel finite volume scheme with bot...As discussed by emails, I tried to parameterized the ProxyDataHandle class by a `pybind11::object` to be more generic in the parallel interface but that ended up with many segfaults when running the parallel finite volume scheme with both YaspGrid (see [log-generic-parallel-interface-yaspgrid.txt](/uploads/af661bc2acbe800740f01ad72deeb45a/log-generic-parallel-interface-yaspgrid.txt)) and ALUGrid (see [log-generic-parallel-interface-alugrid.txt](/uploads/31155e85f6a19e8d507751dc91ad6a4b/log-generic-parallel-interface-alugrid.txt)).
You can test it by moving on the branch associated to that change: https://gitlab.dune-project.org/michael.sghaier/dune-corepy/tree/generic_parallel_interface (look especially commit 53612e23).
I did some debugging with the case of an ALUGrid and found the causes of the two first segfaults:
- the first one was caused by a call to `static void copy ( void *dest, const T *src, std::size_t n)` line 444 of `dune-alugrid/dune/alugrid/impl/serial/serialize.h`, invoked by `inline void writeT (const T & a, const bool checkLength )` line 133. Why? Because in that function `copy`, there is this line `static_cast< T * >( dest )[ i ] = src[ i ]`. When `T` is `pybind11::object`, that call to `operator=` induces a call to `pybind11::handle::dec_ref()` that segfaults. And why? Because `dest` is actually a buffer that was allocated with malloc but never initialized with a call to `new` (see http://paste.awesom.eu/Piig in `serialize.h`) and thus `static_cast< T* >( dest )[ i ]` refers to an uninitialized part of memory instead of a `pybind11::object`.
- the second one is the same thing with `inline void readT (T& a, bool checkLength )` line 156 that caused a segfault in a call to `pybind11::handle::inc_ref()` for the same reasons.
I fixed these two segfaults by modifying these `writeT` and `readT` functions to initialize the allocated buffers, see http://paste.awesom.eu/Eg7T . After recompiling dune-alugrid and dune-corepy, these segfaults disappeared. Unfortunately, there is an other segfault that appeared and I didn't manage to fix it, so the issue remains.
Release newer 2.5https://gitlab.dune-project.org/staging/dune-python/-/issues/23multiple Python modules & multiple instances of the global state2019-08-19T11:35:25ZAnsgar Burchardtansgar.burchardt@tu-dresden.demultiple Python modules & multiple instances of the global stateYaspGrid keeps global state that is initialized in the `YaspGrid::init()` function:
```c++
Yasp::BinomialTable<dim>::init();
Yasp::EntityShiftTable<Yasp::calculate_entity_shift<dim>,dim>::init();
Yasp::EntityShiftTable<Yasp::calculate_en...YaspGrid keeps global state that is initialized in the `YaspGrid::init()` function:
```c++
Yasp::BinomialTable<dim>::init();
Yasp::EntityShiftTable<Yasp::calculate_entity_shift<dim>,dim>::init();
Yasp::EntityShiftTable<Yasp::calculate_entity_move<dim>,dim>::init();
```
The `init()` function in turn is called in YaspGrid's constructor.
It looks like the global state is duplicated between Python module, that is when one Python module (e.g. dune.generated.hierarchicalgrid_*.so) creates the YaspGrid and passes the YaspGrid instance to another Python module (e.g. gridglue.so), the global state might not be initialized in the second Python module (as no constructor was called).
Calling YaspGrid's constructor for a dummy grid in gridglue.so made my program work (this should have initialized the second copy of the global state).https://gitlab.dune-project.org/staging/dune-python/-/issues/24check developers.rst2017-09-14T10:40:12ZAndreas Dednercheck developers.rst@ansgar pointed out:
> I saw the comment in developers.rst about make_iterator causing segmentation faults, but this did work for me (when using the new class for providing an iterator range over GridGlue's intersections).@ansgar pointed out:
> I saw the comment in developers.rst about make_iterator causing segmentation faults, but this did work for me (when using the new class for providing an iterator range over GridGlue's intersections).https://gitlab.dune-project.org/staging/dune-python/-/issues/31testing entries in TypeRegistry2017-10-23T09:27:07ZAndreas Dednertesting entries in TypeRegistryAny missing includes or typos in the TypeName will only be caught
when somebody tries to use the entries the first time.
Perhaps we can come up with a way of testing the entries for
correctness, e.g., similar to a header check?Any missing includes or typos in the TypeName will only be caught
when somebody tries to use the entries the first time.
Perhaps we can come up with a way of testing the entries for
correctness, e.g., similar to a header check?https://gitlab.dune-project.org/staging/dune-python/-/issues/32add Python tests2017-10-23T18:32:09ZAnsgar Burchardtansgar.burchardt@tu-dresden.deadd Python testsI would like to add some tests that the CI system can run.
My current idea is to use `pytest` with support for parallel tests (`pytest.xdist`) each using their private temporary `DUNE_PY` directory.
Then do some stuff (create grids, fun...I would like to add some tests that the CI system can run.
My current idea is to use `pytest` with support for parallel tests (`pytest.xdist`) each using their private temporary `DUNE_PY` directory.
Then do some stuff (create grids, function spaces, evaluating stuff, ...) so some code gets compiled and run.Ansgar Burchardtansgar.burchardt@tu-dresden.deAnsgar Burchardtansgar.burchardt@tu-dresden.dehttps://gitlab.dune-project.org/staging/dune-python/-/issues/36preprocessorAssert does not work in parallel2017-10-28T23:18:01ZAndreas DednerpreprocessorAssert does not work in parallelhttps://gitlab.dune-project.org/staging/dune-python/-/issues/37writeVTK with dimR=2 fails in parallel2017-10-29T10:41:37ZAndreas DednerwriteVTK with dimR=2 fails in parallelWriting a pvtu file with dimR=2 leads to wrong results since the extension to 3d used by the writer is not carried out correctly. dimR=1 or dimR>=3 works (might be a bug in dune-grid, will investgate...)Writing a pvtu file with dimR=2 leads to wrong results since the extension to 3d used by the writer is not carried out correctly. dimR=1 or dimR>=3 works (might be a bug in dune-grid, will investgate...)https://gitlab.dune-project.org/staging/dune-python/-/issues/39notebooks/dunefunctions.py fails2018-09-13T09:46:30ZAndreas Dednernotebooks/dunefunctions.py failsThe following works
lagrangeBasis = defaultGlobalBasis(yaspView, Lagrange(2))
the second line in the script leads to seg fault
lagrangeBasis = defaultGlobalBasis(yaspView, Lagrange(1,2))The following works
lagrangeBasis = defaultGlobalBasis(yaspView, Lagrange(2))
the second line in the script leads to seg fault
lagrangeBasis = defaultGlobalBasis(yaspView, Lagrange(1,2))https://gitlab.dune-project.org/staging/dune-python/-/issues/40reduce compil;e time of hierarchic grid2017-10-31T16:07:56ZAndreas Dednerreduce compil;e time of hierarchic gridLatest changes have added to the compile time of the shared libs for grids. We should try to find ways of reducing the overload and I wanted to collect suggestions here:Latest changes have added to the compile time of the shared libs for grids. We should try to find ways of reducing the overload and I wanted to collect suggestions here:https://gitlab.dune-project.org/staging/dune-python/-/issues/41extend builder to avoid having to set up trivial dune modules2017-12-06T10:50:30ZAndreas Dednerextend builder to avoid having to set up trivial dune modulesAssume I want to add an `Operator` implementation contained in one header file. If I want to use the `builder` I will need to set up a whole dune module with that one header file to do that. It would be nice if I could simply set up a du...Assume I want to add an `Operator` implementation contained in one header file. If I want to use the `builder` I will need to set up a whole dune module with that one header file to do that. It would be nice if I could simply set up a dune subpackage (so setup.py, dune/__init__.py and dune/mymodule/__init__py) also containing this one header file and still be able to use the whole builder.
This could be achieved by adding an additional header search path to the cmake target.https://gitlab.dune-project.org/staging/dune-python/-/issues/46extend solvers for a BCRSMatrix with general BlockType2018-02-25T12:36:28ZAndreas Dednerextend solvers for a BCRSMatrix with general BlockTypeTaken from !76:
discussion on how to export the istl solvers in the general case, i.e., not only for `FieldMatrix<1,1>`.
I'm just trying to figure out how to trigger the generation of the python `solver` module. I'm not really enough of ...Taken from !76:
discussion on how to export the istl solvers in the general case, i.e., not only for `FieldMatrix<1,1>`.
I'm just trying to figure out how to trigger the generation of the python `solver` module. I'm not really enough of an istl expert I guess to be sure of getting all the possible combinations right...
My suggestion was to first focus on the `IterativeSolver` (or possibly `InverseOperator`) for a given (square) block sized matrix. That was the idea of my final suggestion, which could also be for example implemented as
~~~
dune.istl.solvers.cg(matrix,....)
~~~
in both case on module exporting all the iterative solvers for the `blockSize` associates with `matrix` would be generated. That would be quite easy to do I think. The preconditioners could also be exported in the same module and used for example like this:
~~~
seqJacobi = dune.istl.preconditioners.seqJacobi(matrix)
dune.istl.solver(matrix, seqJacobi, 1e-10)
~~~
Although I personally don't like to double `matrix` argument here.
Exporting a more general `LinearOperators` would of course be of interest but I guess only if one could derive from the virtual interface on the Python side. Of course possible but that would be a further project...https://gitlab.dune-project.org/staging/dune-python/-/issues/47dune-py does not rebuild after update of system dune-python2018-07-08T13:38:28ZMartin Noltedune-py does not rebuild after update of system dune-pythonUpdating an installed version of dune-python (or dependent modules, like dune-alugrid) does not force dune-py to rebuild already compiled python modules.
The problem seems to originate from CMake. Updating any system headers or system l...Updating an installed version of dune-python (or dependent modules, like dune-alugrid) does not force dune-py to rebuild already compiled python modules.
The problem seems to originate from CMake. Updating any system headers or system libraries does not cause CMake to recompile dependent source code in user projects. This behavior might be ok for normal projects built via CMake. However, we should avoid forcing users of dune-python to remove their dune-py module, although we might want to suggest this action upon upgrading installed dune modules anyway.
While we have a mechanism in dune-python to force completely rebuilding dune-py, this mechanism is currently restricted to changes in dune-python and designed for changes in the builder infrastructure. Due to this surprising behavior of CMake, it might be insufficient, though.https://gitlab.dune-project.org/staging/dune-python/-/issues/48dune-python should state its dependencies in setup.py2018-11-06T13:32:42ZDominic Kempfdominic.kempf@iwr.uni-heidelberg.dedune-python should state its dependencies in setup.pyI tried with a fresh env and it complained about `numpy` missing and my OpenMPI was bugged without `mpi4py`. These dependencies should be stated as `install_requires` in `setup.py`.I tried with a fresh env and it complained about `numpy` missing and my OpenMPI was bugged without `mpi4py`. These dependencies should be stated as `install_requires` in `setup.py`.https://gitlab.dune-project.org/staging/dune-python/-/issues/49include dependencies to binding header2018-12-21T10:01:18ZAndreas Dednerinclude dependencies to binding headerAt the moment the include file lists for a binding module depends on the header containing the binding code (e.g. for for the class `FooImpl`). This header has to be included in the `cc` file in `dune-py` since it contains the `registerF...At the moment the include file lists for a binding module depends on the header containing the binding code (e.g. for for the class `FooImpl`). This header has to be included in the `cc` file in `dune-py` since it contains the `registerFoo` function. But at the moment that header is also included in the `_includes` properties of the `FooImpl` python object. So any change in that binding code leads to a recompilation of all modules using `FooImpl` e.g. as parameter.
It would be could to separate the actual source files required for `FooImpl` and the header for the binding.