extensions issueshttps://gitlab.dune-project.org/groups/extensions/-/issues2024-03-20T13:23:26Zhttps://gitlab.dune-project.org/extensions/dune-vtk/-/issues/7Cannot interpolate point data function obtained from VtkReader2024-03-20T13:23:26ZOliver Sanderoliver.sander@tu-dresden.deCannot interpolate point data function obtained from VtkReaderI am trying to read a grid with a point-based vector field using `VtkReader`, and obtain the values of the vector field at the grid nodes. As the object returned by `VtkReader::getPointData` is a grid function I need to call `Functions:...I am trying to read a grid with a point-based vector field using `VtkReader`, and obtain the values of the vector field at the grid nodes. As the object returned by `VtkReader::getPointData` is a grid function I need to call `Functions::interpolate` with a Lagrange basis to get the actual point values. [Is that correct? The documentation doesn't mention `interpolate` explicitely, but I see no other way to get the point values.]
Anyway, this doesn't compile, because `interpolate` apparently wants to call `derivative` for the function returend by `getPointData`, which is not implemented. Here is my test program:
```
#include <config.h>
#include <dune/functions/functionspacebases/interpolate.hh>
#include <dune/functions/functionspacebases/lagrangebasis.hh>
#include <dune/functions/functionspacebases/powerbasis.hh>
#include <dune/grid/uggrid.hh>
#include <dune/vtk/vtkreader.hh>
using namespace Dune;
int main ()
{
constexpr int dim = 3;
using Grid = UGGrid<dim>;
// Read the grid
Vtk::VtkReader<Grid> vtkReader;
vtkReader.read("my_file");
auto grid = vtkReader.createGrid();
using namespace Functions::BasisFactory;
auto basis = makeBasis(
grid->leafGridView(),
power<dim>(
lagrange<1>()
));
// Read vector-valued point data
auto displacementPointData = vtkReader.getPointData("displacement");
// Interpolate to get the vector of coefficients
std::vector<FieldVector<double,dim> > displacement(basis.size());
Functions::interpolate(basis, displacement, displacementPointData);
}
```
Am I doing something wrong here?https://gitlab.dune-project.org/extensions/dune-multidomaingrid/-/issues/7Make tag of release 2.92024-02-22T17:53:53ZSantiago Ospina De Los Ríossospinar@gmail.comMake tag of release 2.9https://gitlab.dune-project.org/extensions/dune-alugrid/-/issues/71backup/restore hindex for face/edge not implemented2023-08-17T14:15:20ZAndreas Dednerbackup/restore hindex for face/edge not implementededge/face indices are not written by dune-alugrid: dune/alugrid/impl/duneinterface/gitter_dune_impl.h line 262:
```
// TODO: backup face and edge indices
```
so backup/restore of higher order lagrange based on the hindex of dune-alugrid ...edge/face indices are not written by dune-alugrid: dune/alugrid/impl/duneinterface/gitter_dune_impl.h line 262:
```
// TODO: backup face and edge indices
```
so backup/restore of higher order lagrange based on the hindex of dune-alugrid has probably never worked.https://gitlab.dune-project.org/extensions/dune-grid-glue/-/issues/24FTBFS 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=1037633Reported by Debian for the 2.9.0 release: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037633https://gitlab.dune-project.org/extensions/dune-spgrid/-/issues/7Jacobian and JacobianInverse not implemented efficiently.2023-04-21T10:06:12ZRobert KJacobian and JacobianInverse not implemented efficiently.Currently, the `Jacobian` and `JacobianInverse` use FieldMatrix. This could and should be implemented more efficiently.Currently, the `Jacobian` and `JacobianInverse` use FieldMatrix. This could and should be implemented more efficiently.https://gitlab.dune-project.org/extensions/dune-vtk/-/issues/4Cannot write UGGrid object from Python2023-04-16T05:00:45ZOliver Sanderoliver.sander@tu-dresden.deCannot write UGGrid object from PythonThis is related to https://gitlab.dune-project.org/staging/dune-uggrid/-/issues/46
I am trying to write a `UGGrid` object from Python, but I get a compiler error. When building `dune-vtk`, the option `dune-uggrid` dependency was (AFAIC...This is related to https://gitlab.dune-project.org/staging/dune-uggrid/-/issues/46
I am trying to write a `UGGrid` object from Python, but I get a compiler error. When building `dune-vtk`, the option `dune-uggrid` dependency was (AFAICT) found correctly. Writing a `YaspGrid` object works well.
Here is my test program:
```
import dune.grid
from dune.vtk import vtkWriter
mshfile = "l-shape.msh"
grid = dune.grid.ugGrid( (dune.grid.reader.gmsh, mshfile), dimgrid=2 )
writer = vtkWriter( grid, "nameTestNonlinear")
```
Here is the error I get:
```
(dune-env) ~/skripte/skript-feec/programs> python vtk-problem.py
Authorization required, but no authorization protocol specified
Authorization required, but no authorization protocol specified
Authorization required, but no authorization protocol specified
Traceback (most recent call last):
File "/home/sander/skripte/skript-feec/programs/vtk-problem.py", line 141, in <module>
writer = vtkWriter( grid, "nameTestNonlinear", pointData = {( "value"):xFunc})
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/sander/dune-python/dune-vtk/build-cmake/python/dune/vtk/__init__.py", line 46, in vtkWriter
writer = load( allWriters[version][1],
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/sander/dune-python/dune-vtk/build-cmake/python/dune/vtk/__init__.py", line 13, in load
module = generator.load(includes, typeName, moduleName)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/sander/dune-python/dune-common/build-cmake/python/dune/generator/generator.py", line 172, in load
return self.post(moduleName, source, postscript, extraCMake)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/sander/dune-python/dune-common/build-cmake/python/dune/generator/generator.py", line 124, in post
module = builder.load(moduleName, source, self.typeName[0], extraCMake)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/sander/dune-python/dune-common/build-cmake/python/dune/generator/cmakebuilder.py", line 387, in load
self._buildModule( moduleName, source, pythonName, extraCMake )
File "/home/sander/dune-python/dune-common/build-cmake/python/dune/generator/cmakebuilder.py", line 738, in _buildModule
raise CompileError(buffer_to_str(stderr))
dune.generator.exceptions.CompileError: /home/sander/dune-python/dune-common/build-cmake/dune-env/.cache/dune-py/python/dune/generated/vtkwriter_9a4407ddde2a9c4f571d3b98d5700e5a.cc: In function ‘void pybind11_init_vtkwriter_9a4407ddde2a9c4f571d3b98d5700e5a(pybind11::module_&)’:
/home/sander/dune-python/dune-common/build-cmake/dune-env/.cache/dune-py/python/dune/generated/vtkwriter_9a4407ddde2a9c4f571d3b98d5700e5a.cc:20:60: error: ‘UGGrid’ is not a member of ‘Dune’; did you mean ‘YGrid’?
20 | using DuneType = Dune::VtkUnstructuredGridWriter<Dune::UGGrid< 2 >::LeafGridView>;
| ^~~~~~
| YGrid
/home/sander/dune-python/dune-common/build-cmake/dune-env/.cache/dune-py/python/dune/generated/vtkwriter_9a4407ddde2a9c4f571d3b98d5700e5a.cc:20:70: error: template argument 1 is invalid
20 | using DuneType = Dune::VtkUnstructuredGridWriter<Dune::UGGrid< 2 >::LeafGridView>;
| ^
compilation terminated due to -fmax-errors=2.
make: *** [/home/sander/dune-python/dune-common/build-cmake/dune-env/.cache/dune-py/python/dune/generated/CMakeFiles/vtkwriter_9a4407ddde2a9c4f571d3b98d5700e5a.dir/vtkwriter_9a4407ddde2a9c4f571d3b98d5700e5a.make:3: CMakeFiles/vtkwriter_9a4407ddde2a9c4f571d3b98d5700e5a.dir/vtkwriter_9a4407ddde2a9c4f571d3b98d5700e5a.cc.o] Fehler 1
```
@andreas.dedner , @robert.kloefkorn , @simon.praetorius , can you help? Thank you!https://gitlab.dune-project.org/extensions/dune-alugrid/-/issues/68periodic conforming grid2023-09-20T13:08:32ZAndreas Dednerperiodic conforming gridFrom an email bei Lea:
> Dear Alu-Grid-Community,
>
> is there a way to use periodic boundary conditions and adaptive refinement with a triangular (conforming) 2D-2D (or 2D-3D)-AluGrid? As long as I use no adaptive refinements everythi...From an email bei Lea:
> Dear Alu-Grid-Community,
>
> is there a way to use periodic boundary conditions and adaptive refinement with a triangular (conforming) 2D-2D (or 2D-3D)-AluGrid? As long as I use no adaptive refinements everything works as expected. I use a square with one periodic boundary generated with a dgf-file and a "walking circle" for testing. As soon as I try to use adaptive refinement and the circle approaches the domain boundary (the periodic boundary region is refined), the program runs in an infinite loop, just printing the warning
>
> (**WARNING (IGNORED) in Periodic3Top < A >::refineBalance (..) , file dune-alugrid/dune/alugrid/impl/parallel/../serial/gitter_tetra_top.cc line 2708 periodic refinement is only implemented for isometric refinement!)
>
> If this is not implemented, are there any plans to add this in a future release?
>
> Second question: Is there any way to generate a periodic AluGrid directly, without a dgf-file?
>
> Thanks for all help and suggestions!
>
> Best, Leahttps://gitlab.dune-project.org/extensions/dune-subgrid/-/issues/9CI failure for the 2.8 release branch2022-08-24T14:28:26ZOliver Sanderoliver.sander@tu-dresden.deCI failure for the 2.8 release branchSomething involving CMake and Alberta.Something involving CMake and Alberta.https://gitlab.dune-project.org/extensions/dune-subgrid/-/issues/8Periodicity lost from SP-Grid host2022-05-25T10:54:10ZEdward ColtmanPeriodicity lost from SP-Grid hostWhen creating a subgrid from a Periodic SPGrid, the calls to intersection.boundary() and intersection.neighbor() no longer reflect grid periodicity.
@MathisKelm and I are looking for a solution, and can then look to add a test for SPGrid.When creating a subgrid from a Periodic SPGrid, the calls to intersection.boundary() and intersection.neighbor() no longer reflect grid periodicity.
@MathisKelm and I are looking for a solution, and can then look to add a test for SPGrid.https://gitlab.dune-project.org/extensions/dune-grid-glue/-/issues/20undefined reference to `alloc_macro_data', etc.2021-09-07T15:45:51ZYuri Vicundefined reference to `alloc_macro_data', etc.```
[100%] Linking CXX executable contactmerge
cd /disk-samsung/freebsd-ports/math/dune-grid-glue/work/.build/examples && /usr/local/bin/cmake -E cmake_link_script CMakeFiles/contactmerge.dir/link.txt --verbose=1
/usr/bin/c++ -std=c++17 ...```
[100%] Linking CXX executable contactmerge
cd /disk-samsung/freebsd-ports/math/dune-grid-glue/work/.build/examples && /usr/local/bin/cmake -E cmake_link_script CMakeFiles/contactmerge.dir/link.txt --verbose=1
/usr/bin/c++ -std=c++17 -O2 -pipe -fno-omit-frame-pointer -fstack-protector-strong -fno-strict-aliasing -fno-omit-frame-pointer -O2 -pipe -fno-omit-frame-pointer -fstack-protector-strong -fno-strict-aliasing -fno-omit-frame-pointer -Wl,-rpath=/usr/local/lib/gcc10 -L/usr/local/lib/gcc10 -B/usr/local/bin -fstack-protector-strong -Wl,-rpath=-Wl,-rpath=/usr/local/lib/gcc10 -Wl,-rpath -Wl,/usr/local/mpi/openmpi/lib -Wl,--enable-new-dtags -pthread CMakeFiles/contactmerge.dir/contactmerge.cc.o -o contactmerge -Wl,-rpath,/usr/local/lib:/usr/local/mpi/openmpi/lib /usr/local/lib/libdunealbertagrid3d.so /usr/local/lib/libdunealbertagrid2d.so /usr/local/lib/libdunealbertagrid1d.so /usr/local/lib/libdunegrid.so /usr/local/lib/libdunegeometry.so /usr/local/lib/libduneuggrid.so /usr/local/lib/libdunecommon.so -pthread /usr/local/lib/libopenblas.so -lm -ldl /usr/local/lib/libtbb.so.12.3 /usr/local/mpi/openmpi/lib/libmpi.so
/usr/local/bin/ld: /usr/local/lib/libdunealbertagrid3d.so: undefined reference to `alloc_macro_data'
/usr/local/bin/ld: /usr/local/lib/libdunealbertagrid3d.so: undefined reference to `read_macro'
/usr/local/bin/ld: /usr/local/lib/libdunealbertagrid3d.so: undefined reference to `alberta_realloc'
/usr/local/bin/ld: /usr/local/lib/libdunealbertagrid3d.so: undefined reference to `fill_elinfo'
/usr/local/bin/ld: /usr/local/lib/libdunealbertagrid3d.so: undefined reference to `write_macro_data'
/usr/local/bin/ld: /usr/local/lib/libdunealbertagrid3d.so: undefined reference to `free_fe_space'
/usr/local/bin/ld: /usr/local/lib/libdunealbertagrid3d.so: undefined reference to `free_mesh'
/usr/local/bin/ld: /usr/local/lib/libdunealbertagrid3d.so: undefined reference to `macro_test'
/usr/local/bin/ld: /usr/local/lib/libdunealbertagrid3d.so: undefined reference to `read_dof_int_vec_xdr'
/usr/local/bin/ld: /usr/local/lib/libdunealbertagrid3d.so: undefined reference to `alberta_alloc'
/usr/local/bin/ld: /usr/local/lib/libdunealbertagrid3d.so: undefined reference to `free_dof_uchar_vec'
/usr/local/bin/ld: /usr/local/lib/libdunealbertagrid3d.so: undefined reference to `get_dof_int_vec'
/usr/local/bin/ld: /usr/local/lib/libdunealbertagrid3d.so: undefined reference to `fill_macro_info'
/usr/local/bin/ld: /usr/local/lib/libdunealbertagrid3d.so: undefined reference to `get_dof_real_d_vec'
/usr/local/bin/ld: /usr/local/lib/libdunealbertagrid3d.so: undefined reference to `get_dof_uchar_vec'
/usr/local/bin/ld: /usr/local/lib/libdunealbertagrid3d.so: undefined reference to `funcName'
/usr/local/bin/ld: /usr/local/lib/libdunealbertagrid3d.so: undefined reference to `free_macro_data'
/usr/local/bin/ld: /usr/local/lib/libdunealbertagrid3d.so: undefined reference to `write_dof_int_vec_xdr'
/usr/local/bin/ld: /usr/local/lib/libdunealbertagrid3d.so: undefined reference to `compute_neigh_fast'
/usr/local/bin/ld: /usr/local/lib/libdunealbertagrid3d.so: undefined reference to `free_dof_real_d_vec'
/usr/local/bin/ld: /usr/local/lib/libdunealbertagrid3d.so: undefined reference to `get_dof_space'
/usr/local/bin/ld: /usr/local/lib/libdunealbertagrid3d.so: undefined reference to `check_and_get_mesh'
/usr/local/bin/ld: /usr/local/lib/libdunealbertagrid3d.so: undefined reference to `free_dof_int_vec'
c++: error: linker command failed with exit code 1 (use -v to see invocation)
*** [examples/contactmerge] Error code 1
```
rev. 17bd9898df80a52e2c316fc053119d190c149a2e
OS: FreeBSD 13https://gitlab.dune-project.org/extensions/dune-metagrid/-/issues/3[parallelgrid] Add loadBalance/repartition interface to distribute elements a...2021-07-15T23:01:57ZTimo Koch[parallelgrid] Add loadBalance/repartition interface to distribute elements according to user specified distributionAn interface similar to dune-uggrid's `bool loadBalance(const std::vector<Rank>& targetProcessors, unsigned int fromLevel)` or dune-alugrid's `bool repartition ( LBDestinations &destinations )` would be nice.An interface similar to dune-uggrid's `bool loadBalance(const std::vector<Rank>& targetProcessors, unsigned int fromLevel)` or dune-alugrid's `bool repartition ( LBDestinations &destinations )` would be nice.https://gitlab.dune-project.org/extensions/dune-metagrid/-/issues/2[parallelgrid] Communicating vertex data2021-07-15T10:44:11ZTimo Koch[parallelgrid] Communicating vertex dataThe capability for communicating vertex data is currently set to `false`.
It seems that the in the `communicate` function it is iterated over elements. For every element there is also an iteration over the subentities. So it looks like ...The capability for communicating vertex data is currently set to `false`.
It seems that the in the `communicate` function it is iterated over elements. For every element there is also an iteration over the subentities. So it looks like entities of other `codim`s are also communicated. But since it's always an element loop it seems like vertices e.g. are visited more than once? Also the `InteriorBorder_InteriorBorder` interface communication is not implemented.https://gitlab.dune-project.org/extensions/dune-alugrid/-/issues/63memory issues (python bindings or internal?)2023-08-16T17:20:01ZAndreas Dednermemory issues (python bindings or internal?)There is either an issue with the python bindings for alu (not there for Yasp) or some cache that is not cleanedup after
usage in Alugrid. Consider the test script
```
from memory_profiler import profile
import gc, sys
from dune.grid i...There is either an issue with the python bindings for alu (not there for Yasp) or some cache that is not cleanedup after
usage in Alugrid. Consider the test script
```
from memory_profiler import profile
import gc, sys
from dune.grid import cartesianDomain
N = 150
domain = cartesianDomain([-1]*2, [1]*2, [N]*2)
@profile(precision=8)
def op(domain, hierarchicGrid):
if not domain:
domain = cartesianDomain([-1]*2, [1]*2, [N]*2)
view = hierarchicGrid(domain)
gc.collect()
print("======================================== profile Yasp")
from dune.grid import yaspGrid as hierarchicGrid
for i in range(15):
op(domain,hierarchicGrid)
gc.collect()
print("======================================== profile ALU - cartesianDomain")
from dune.alugrid import aluSimplexGrid as hierarchicGrid
"""
for i in range(15):
op(domain,hierarchicGrid)
gc.collect()
"""
print("======================================== profile ALU - GridFactory")
vertices = []
for i in range(N+1):
for j in range(N+1):
vertices += [[float(i),float(j)]]
simplices = []
for i in range(N):
for j in range(N):
simplices += [[i*N+j,i*N+j+1,(i+1)*N+j]]
simplices += [[(i+1)*N+j,(i+1)*N+j+1,i*N+j+1]]
domain = {"vertices":vertices, "simplices":simplices}
for i in range(15):
op(domain,hierarchicGrid)
gc.collect()
print("======================================== profile ALU - cartesianDomain II")
for i in range(15):
op(None,hierarchicGrid)
gc.collect()
```
running `python memALUGrid.py |& grep profil`:
```
======================================== profile Yasp
9 73.48437500 MiB 73.48437500 MiB 1 @profile(precision=8)
9 81.55859375 MiB 81.55859375 MiB 1 @profile(precision=8)
9 81.55859375 MiB 81.55859375 MiB 1 @profile(precision=8)
9 81.55859375 MiB 81.55859375 MiB 1 @profile(precision=8)
9 81.55859375 MiB 81.55859375 MiB 1 @profile(precision=8)
9 81.55859375 MiB 81.55859375 MiB 1 @profile(precision=8)
9 81.55859375 MiB 81.55859375 MiB 1 @profile(precision=8)
9 81.55859375 MiB 81.55859375 MiB 1 @profile(precision=8)
9 81.55859375 MiB 81.55859375 MiB 1 @profile(precision=8)
9 81.55859375 MiB 81.55859375 MiB 1 @profile(precision=8)
9 81.57812500 MiB 81.57812500 MiB 1 @profile(precision=8)
9 81.57812500 MiB 81.57812500 MiB 1 @profile(precision=8)
9 81.57812500 MiB 81.57812500 MiB 1 @profile(precision=8)
9 81.57812500 MiB 81.57812500 MiB 1 @profile(precision=8)
9 81.57812500 MiB 81.57812500 MiB 1 @profile(precision=8)
======================================== profile ALU - cartesianDomain
======================================== profile ALU - GridFactory
9 92.82812500 MiB 92.82812500 MiB 1 @profile(precision=8)
9 162.32421875 MiB 162.32421875 MiB 1 @profile(precision=8)
9 165.71484375 MiB 165.71484375 MiB 1 @profile(precision=8)
9 167.42968750 MiB 167.42968750 MiB 1 @profile(precision=8)
9 169.15625000 MiB 169.15625000 MiB 1 @profile(precision=8)
9 170.87500000 MiB 170.87500000 MiB 1 @profile(precision=8)
9 172.60156250 MiB 172.60156250 MiB 1 @profile(precision=8)
9 172.60546875 MiB 172.60546875 MiB 1 @profile(precision=8)
9 172.60937500 MiB 172.60937500 MiB 1 @profile(precision=8)
9 172.61328125 MiB 172.61328125 MiB 1 @profile(precision=8)
9 172.61328125 MiB 172.61328125 MiB 1 @profile(precision=8)
9 171.00781250 MiB 171.00781250 MiB 1 @profile(precision=8)
9 172.59765625 MiB 172.59765625 MiB 1 @profile(precision=8)
9 172.60156250 MiB 172.60156250 MiB 1 @profile(precision=8)
9 172.60156250 MiB 172.60156250 MiB 1 @profile(precision=8)
======================================== profile ALU - cartesianDomain II
9 172.60156250 MiB 172.60156250 MiB 1 @profile(precision=8)
9 172.94140625 MiB 172.94140625 MiB 1 @profile(precision=8)
9 172.94140625 MiB 172.94140625 MiB 1 @profile(precision=8)
9 172.94140625 MiB 172.94140625 MiB 1 @profile(precision=8)
9 172.94140625 MiB 172.94140625 MiB 1 @profile(precision=8)
9 172.94140625 MiB 172.94140625 MiB 1 @profile(precision=8)
9 172.94140625 MiB 172.94140625 MiB 1 @profile(precision=8)
9 172.94140625 MiB 172.94140625 MiB 1 @profile(precision=8)
9 172.94140625 MiB 172.94140625 MiB 1 @profile(precision=8)
9 172.95312500 MiB 172.95312500 MiB 1 @profile(precision=8)
9 172.95312500 MiB 172.95312500 MiB 1 @profile(precision=8)
9 172.95312500 MiB 172.95312500 MiB 1 @profile(precision=8)
9 172.95312500 MiB 172.95312500 MiB 1 @profile(precision=8)
9 172.95312500 MiB 172.95312500 MiB 1 @profile(precision=8)
9 172.95312500 MiB 172.95312500 MiB 1 @profile(precision=8
```
The amount of memory used depends on N. With `N=250` the YaspGrid is still constant `9 81.66796875 MiB 81.66796875 MiB` while Alu grows:
```
9 115.03906250 MiB 115.03906250 MiB 1 @profile(precision=8)
9 284.74218750 MiB 284.74218750 MiB 1 @profile(precision=8)
9 295.89453125 MiB 295.89453125 MiB 1 @profile(precision=8)
9 300.75390625 MiB 300.75390625 MiB 1 @profile(precision=8)
9 305.39453125 MiB 305.39453125 MiB 1 @profile(precision=8)
9 310.31250000 MiB 310.31250000 MiB 1 @profile(precision=8)
9 315.09375000 MiB 315.09375000 MiB 1 @profile(precision=8)
9 319.68359375 MiB 319.68359375 MiB 1 @profile(precision=8)
9 322.26562500 MiB 322.26562500 MiB 1 @profile(precision=8)
9 326.54687500 MiB 326.54687500 MiB 1 @profile(precision=8)
9 328.76953125 MiB 328.76953125 MiB 1 @profile(precision=8)
9 333.73437500 MiB 333.73437500 MiB 1 @profile(precision=8)
9 338.31640625 MiB 338.31640625 MiB 1 @profile(precision=8)
9 340.71093750 MiB 340.71093750 MiB 1 @profile(precision=8)
9 343.27734375 MiB 343.27734375 MiB 1 @profile(precision=8)
======================================== profile ALU - cartesianDomain II
9 345.49218750 MiB 345.49218750 MiB 1 @profile(precision=8)
9 348.36718750 MiB 348.36718750 MiB 1 @profile(precision=8)
9 350.57421875 MiB 350.57421875 MiB 1 @profile(precision=8)
9 352.94921875 MiB 352.94921875 MiB 1 @profile(precision=8)
9 355.55468750 MiB 355.55468750 MiB 1 @profile(precision=8)
9 357.76171875 MiB 357.76171875 MiB 1 @profile(precision=8)
9 360.15625000 MiB 360.15625000 MiB 1 @profile(precision=8)
9 362.68750000 MiB 362.68750000 MiB 1 @profile(precision=8)
9 365.10937500 MiB 365.10937500 MiB 1 @profile(precision=8)
9 367.16796875 MiB 367.16796875 MiB 1 @profile(precision=8)
9 369.87890625 MiB 369.87890625 MiB 1 @profile(precision=8)
9 372.25781250 MiB 372.25781250 MiB 1 @profile(precision=8)
9 374.69531250 MiB 374.69531250 MiB 1 @profile(precision=8)
9 376.87890625 MiB 376.87890625 MiB 1 @profile(precision=8)
9 377.41015625 MiB 377.41015625 MiB 1 @profile(precision=8)
```
So generating a yaspgrid takes up 8M which is not freed (pybind11 and the typeregistry possibly). While Alugrid
adds +300Mhttps://gitlab.dune-project.org/extensions/dune-polygongrid/-/issues/2wasInserted missing on factory2021-04-20T08:15:35ZAndreas DednerwasInserted missing on factoryhttps://gitlab.dune-project.org/extensions/dune-polygongrid/-/issues/1test-polygongrid fails for simplices.2024-01-27T12:25:27ZRobert Ktest-polygongrid fails for simplices.The normal check fails. My guess is that the orientation of the triangles does not coincide with the one in the reference triangle. Not sure if this is a bug or feature. For the polygonal cells the orientation has to be counter clockwise.The normal check fails. My guess is that the orientation of the triangles does not coincide with the one in the reference triangle. Not sure if this is a bug or feature. For the polygonal cells the orientation has to be counter clockwise.https://gitlab.dune-project.org/extensions/dune-codegen/-/issues/176Data structure for driver code generation2021-02-02T13:53:16ZRené HeßData structure for driver code generationAt the moment we use a series of functions to generate driver code. For a typical driver object you need
```
typedef_foo(...)
type_foo(...)
declare_foo(...)
define_foo(...)
name_foo(...)
```
Currently those functions exist for all driv...At the moment we use a series of functions to generate driver code. For a typical driver object you need
```
typedef_foo(...)
type_foo(...)
declare_foo(...)
define_foo(...)
name_foo(...)
```
Currently those functions exist for all driver objects and everything needs to be reproduced every time.
There are two ways of improving this situation:
1. Create a class for every driver object, that collects all the functions for this object. This way they are at least collected in one place.
2. Design a data structure that also takes care of creating the boilerplate parts, eg the `type_` functions that are almost identical for all obejcts. The dream scenario would be to only provide the things that are essential:
- How to create the name of the object
- How to create the name of the type
- What arguments need to be created and passed for `define...` and `typedef_...`
For now this issue just exists to discuss:
1. What kind of changes would we like for the driver generation code?
2. Is it worth doing it?
Note: This discussion came up in !422.https://gitlab.dune-project.org/extensions/dune-vcfv/-/issues/8controllingVertexIdx() sometimes returns the wrong index for subfaces2021-01-22T14:52:47ZKonstantin ReinhardtcontrollingVertexIdx() sometimes returns the wrong index for subfacesFor some 2d meshes, the `controllingVertexIdx()` function of the generated subfaces returns an incorrect index.
As an example, in the case of the attached circle mesh, the corner in the reference triangle corresponding to the `controlli...For some 2d meshes, the `controllingVertexIdx()` function of the generated subfaces returns an incorrect index.
As an example, in the case of the attached circle mesh, the corner in the reference triangle corresponding to the `controllingVertexIdx()` is not equal to either end points of the subface given by `subface->geometryInCell().corner(i)`.
However, for the attached square mesh this is true.
[VCFV_controllingVertexIdx_bug.cc](/uploads/db0142cbf202927c8eafd2b546f87740/VCFV_controllingVertexIdx_bug.cc)
[circle.msh](/uploads/046966591e0b91a9a2d4b436eb6a1ca6/circle.msh)[square.msh](/uploads/7dc4c3cac371a127a1702d7a4fbe5183/square.msh)https://gitlab.dune-project.org/extensions/dune-codegen/-/issues/174Use matrix-free solver backends from dune-pdelab2020-12-07T10:23:16ZRené HeßUse matrix-free solver backends from dune-pdelabAt the moment it is not possible to generate drivers using the matrix-free solver backends from pdelab. We should implement this and add a real system test using matrix free solvers.At the moment it is not possible to generate drivers using the matrix-free solver backends from pdelab. We should implement this and add a real system test using matrix free solvers.https://gitlab.dune-project.org/extensions/dune-codegen/-/issues/173Parameterize Solvers2021-02-04T08:33:36ZMarcel KochParameterize SolversCurrently the solvers for the coarse problem and the local problems appearing in the blockstructured preconditioner are fixed. Choosing them by setting an option in the ini file and using the istl solver factory would be beneficial.
I t...Currently the solvers for the coarse problem and the local problems appearing in the blockstructured preconditioner are fixed. Choosing them by setting an option in the ini file and using the istl solver factory would be beneficial.
I think this can be extended to the matrix-free solver wrappers.https://gitlab.dune-project.org/extensions/dune-multidomaingrid/-/issues/4IntersectionWrapper has an uninitialized variable2020-11-12T17:06:20ZSantiago Ospina De Los Ríossospinar@gmail.comIntersectionWrapper has an uninitialized variableThe file `dune/grid/multidomaingrid/subdomaingrid/intersection.hh` triggers a warning for not initialized variable in the `IntersectionWrapper::_intersectionType` object variable.The file `dune/grid/multidomaingrid/subdomaingrid/intersection.hh` triggers a warning for not initialized variable in the `IntersectionWrapper::_intersectionType` object variable.