dune-grid-glue issueshttps://gitlab.dune-project.org/extensions/dune-grid-glue/-/issues2023-07-13T13:02:11Zhttps://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-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-grid-glue/-/issues/17orientation of intersection.centerUnitOuterNormal()?2017-08-02T07:31:55ZFelix Schindlerorientation of intersection.centerUnitOuterNormal()?The question can be drastically simplified! :) See below for my previous rambling...
Given two grids and a `GridGlue` between them, there seems to be an obvious orientation of the glue induced by the ordering of the grids (or rather t...The question can be drastically simplified! :) See below for my previous rambling...
Given two grids and a `GridGlue` between them, there seems to be an obvious orientation of the glue induced by the ordering of the grids (or rather the ordering of the grid views provided in the constructors of the extractors provided in the constructor of `GridGlue`).
From what I understand, the grid given first can be interpreted as the _inside_ grid, while the grid given second can be interpreted as the _outside_ grid.
I would thus expect the outer normals of all intersections contained in the glue to point from the inside grid in the direction of the outside grid.
My original questions from below stand:
* is my expectation wrong?
* does the code behave wrong?
* is there a way for me to guarantee that the created intersections' normals have the "correct" orientation?
Thank you very much in advance!
==================================================
This was the old question:
Dear all,
I encountered the following situation and I am not sure whether I have the wrong expectations, I am using the code wrong, or whether this could be a bug:
* I am currently on the 2.3.1 core modules (sorry for that) and the `releases/2.4` branch of dune-grid-glue.
* I have some piece of code which
- creates an `SGrid<2, 2>` with `3x3` entities (I will call this the macro grid),
- for each entity of the macro grid I create a separate `SGrid<2, 2>` as a grid of the physical domain spanned by the macro entity (I will call those local grids) and do some refinements (not necessarily the same amount of levels in different macro entities),
- for each inner intersection of the macro grid, I create a glue, using `GridGlue::Codim1Extractor`, `GridGlue::ContactMerge` and a custom class based on `GridGlue::ExtractorPredicate<GridView, 1>`.
This works as expected and for each macro intersection I obtain a glue wich allows me to iterate over the glued intersections and access the corresponding entities of the local grids on either side.
What I noticed, however, is that __the orientation of the coupling normal does not coincide with the orientation of the normal of the "matching" local intersection__.
What I mean by that is the following. Consider the following Picture, showing
* a local grid on the left with refinement level 0 and one intersection `LI0` involved,
* a local grid on the right with refinement level 1 and two intersections `RI0` and `RI1` involved,
* the coupling glue inbetween with its two intersections `CI0` and `CI1`
Note that the physical domains of the left and the right grid match exactly, so there is no actual distance between them.
```
-------+ + +-------
| | |
| CI0 RI0 RE0
| | |
LE0 LI0 + +------
| | |
| CI1 RI1 RE1
| | |
-------+ + +------
```
Regarding the glue, say I created it _looking from the left_, i.e. the left grid is given first and the right grid second.
Now in order to assemble a DG coupling integral w.r.t to the physical integral covering `LI0` (or (`CI0` and `CI1`) or (`RI0` and `RI1`), which should all be the same integral), I iterate over the coupling and on each coupling intersection, say `CI0`
* I get the inside, which is `LE0`
*I get the outside, which is `RE0`
* I get the `centerUnitOuterNormal()`
__My expectation now is the following:__ the `centerUnitOuterNormal()` of `LI0` and `CI0` (and `CI1`) should coincide.
__What happens is:__ the `centerUnitOuterNormal()` of `LI0` is `[1 0]`, the `centerUnitOuterNormal()` of `CI0` or `CI1` can be either `[1 0]` or `[-1 0]`, where I could not yet determine a rule.
My expectation is due to the fact that I have created the glue _looking from the left_ and `LE0` is given as inside, `RE0` is given as outside and I am accessing an _outer_ normal.
Now the question is as follows:
* is my expectation wrong?
* does the code behave wrong?
* is there a way for me to guarantee that the created intersections' normals have the "correct" orientation?
Thank you very much in advance!https://gitlab.dune-project.org/extensions/dune-grid-glue/-/issues/16mixed dim overlapping - second fallback method2017-08-02T07:31:55ZTimo Kochmixed dim overlapping - second fallback methodI'm using grid glue with complex one-dimensional network grids that sometimes also have disconnected patches and rather small dimensions. Examples are attached. For both grids when intersecting with a three-dimensional grid.
I get the f...I'm using grid glue with complex one-dimensional network grids that sometimes also have disconnected patches and rather small dimensions. Examples are attached. For both grids when intersecting with a three-dimensional grid.
I get the following output a lot
```
Algorithm entered second fallback method. This probably should not happen.
Algorithm entered second fallback method. This probably should not happen.
Algorithm entered second fallback method. This probably should not happen.
Algorithm entered second fallback method. This probably should not happen.
```
The second network grid exits after some time with the following error
```
.../dune-grid-glue/dune/grid-glue/merging/overlappingmerge.cc:141: virtual void
Dune::GridGlue::OverlappingMerge<3, 1, 3, double>::computeIntersections(const Dune::GeometryType &, const std::vector<Dune::FieldVector<T, dimworld> > &, std::bitset<(1 << dim1)> &, unsigned int, const Dune::GeometryType &, const std::vector<Dune::FieldVector<T, dimworld> > &, std::bitset<(1 << dim2)> &, unsigned int, std::vector<RemoteSimplicialIntersection> &)
[dim1 = 3, dim2 = 1, dimworld = 3, T = double]: Assertion `dimis != 1' failed.
```
Do you have any idea what that might be related too? Could there still be a connection to #11?
Otherwise I would start finding simpler versions of such grids that also cause fallback or similar errors.
I could imagine that being quite tedious as until now my smaller network examples all worked fine.
![network2](/uploads/0a15640540ce8a8e506b4e220834cffb/network2.png)
![network1](/uploads/3b2fe9ec06a36e1dcccca3e5a5ee8ab0/network1.png) https://gitlab.dune-project.org/extensions/dune-grid-glue/-/issues/15dune-grid-glue and hanging nodes2017-08-02T07:31:55ZJonathan Youettdune-grid-glue and hanging nodesI need to add the possibility to project surfaces with hanging nodes using `ContactMerge` and the `Codim1Extractor` and would like to have your opinion on how to implement this best.
First of all, the problem is that `StandardMerge` ass...I need to add the possibility to project surfaces with hanging nodes using `ContactMerge` and the `Codim1Extractor` and would like to have your opinion on how to implement this best.
First of all, the problem is that `StandardMerge` assumes that along every edge there exists exactly one pair of neighbors.
In my mind there are two possibilities:
1. Modify `StandardMerge` (or add a `NonConformingContactMerge`) by storing for each edge a vector of neighbors and use this information within the advancing front algorithm.
2. Modify `Codim1Extractor` (or add a `NonConformingCodim1Extractor`) such that elements containing a hanging node are split up into "conforming" triangles before handing them over to the merger (similar to how quadrilaterals are treated)
For possibility 1. I am not sure if computing nonconforming neighbor information works without addionally knowing the underlying gridview and the extractor predicate, hence it would
destroy all decoupling done in dune-grid-glue.
Possibility 2. should work but it is rather difficult in comparison with 1. https://gitlab.dune-project.org/extensions/dune-grid-glue/-/issues/11mixed dim overlapping epsilon issue2017-08-02T07:31:55ZTimo Kochmixed dim overlapping epsilon issueWe created the following modified mixeddimoverlapping test:
[mixeddimoverlappingtest.cc](/uploads/a36283104553cb4740332554e296a5f7/mixeddimoverlappingtest.cc)
A 2x2x2 unit cube grid is intersected with a 3-element one-dimensional gri...We created the following modified mixeddimoverlapping test:
[mixeddimoverlappingtest.cc](/uploads/a36283104553cb4740332554e296a5f7/mixeddimoverlappingtest.cc)
A 2x2x2 unit cube grid is intersected with a 3-element one-dimensional grid on the z-axis. If I'm correct this should result in 4 intersections (and each intersection has four outside and four inside neighbors/embeddings because they are located on the edge).
We get four intersections for the unit cube.
Now, scaling the unit cube (and the one-dimensional grid) with epsilon produces the following results:
* eps = 1e-3: (only 3 intersections are found!?)
```
This is Codim0Extractor on a <3,3> grid!
This is Codim0Extractor on a <1,3> grid!
GridGlue: Constructor succeeded!
>>>> rank 0 coords: 27 and 4
>>>> rank 0 entities: 64 and 6
>>>> rank 0 types: 8 and 3
0 GridGlue::mergePatches : rank 0 / 0
StandardMerge building merged grid...
setup took 0.000171649 seconds.
intersection construction took 0.00623633 seconds.
0 GridGlue::mergePatches : The number of remote intersections is 3
Gluing successful, 3 remote intersections found!
```
* eps = 1e-8: (following error message)
```
This is Codim0Extractor on a <3,3> grid!
This is Codim0Extractor on a <1,3> grid!
GridGlue: Constructor succeeded!
>>>> rank 0 coords: 27 and 4
>>>> rank 0 entities: 64 and 6
>>>> rank 0 types: 8 and 3
0 GridGlue::mergePatches : rank 0 / 0
StandardMerge building merged grid...
setup took 0.000171437 seconds.
mixeddimoverlappingtest: /home-local/timok/monolithic/dune-grid-glue/dune/grid-glue/merging/overlappingmerge.cc:114: virtual void Dune::GridGlue::OverlappingMerge<3, 1, 3, double>::computeIntersections(const Dune::GeometryType &, const std::vector<Dune::FieldVector<T, dimworld> > &, std::bitset<(1 << dim1)> &, unsigned int, const Dune::GeometryType &, const std::vector<Dune::FieldVector<T, dimworld> > &, std::bitset<(1 << dim2)> &, unsigned int, std::vector<RemoteSimplicialIntersection> &) [dim1 = 3, dim2 = 1, dimworld = 3, T = double]: Assertion `dimis != 1' failed.
Aborted (core dumped)
```
* eps = 1e-10: (0 intersections found)
```
This is Codim0Extractor on a <3,3> grid!
This is Codim0Extractor on a <1,3> grid!
GridGlue: Constructor succeeded!
>>>> rank 0 coords: 27 and 4
>>>> rank 0 entities: 64 and 6
>>>> rank 0 types: 8 and 3
0 GridGlue::mergePatches : rank 0 / 0
StandardMerge building merged grid...
setup took 0.000168485 seconds.
intersection construction took 0.0311377 seconds.
0 GridGlue::mergePatches : The number of remote intersections is 0
Gluing successful, 0 remote intersections found!
```Katja HanowskiKatja Hanowskihttps://gitlab.dune-project.org/extensions/dune-grid-glue/-/issues/8Intersection: require same number of "inside" and "outside" embeddings2017-08-02T07:31:55ZAnsgar Burchardtansgar.burchardt@tu-dresden.deIntersection: require same number of "inside" and "outside" embeddingsCurrently an `Intersection` can have n₀ embeddings into grid0 and n₁ embeddings into grid₁.
However it is unclear what the semantics in the n₀ ≠ n₁ case are: how does one known what embedding into the first grid has to go with which emb...Currently an `Intersection` can have n₀ embeddings into grid0 and n₁ embeddings into grid₁.
However it is unclear what the semantics in the n₀ ≠ n₁ case are: how does one known what embedding into the first grid has to go with which embedding into the second grid?
I propose to require that the number of embeddings is the same for both grids.
https://gitlab.dune-project.org/extensions/dune-grid-glue/-/issues/7semantics of `Intersection::neighbor()`2017-08-02T07:31:55ZAnsgar Burchardtansgar.burchardt@tu-dresden.desemantics of `Intersection::neighbor()`I'm curious what the semantics of the `Intersection::neighbor()` method in parallel setups is:
It is supposed to return both the number of embeddings of the intersection into the (inside or outside) grid *and* if the outside is a local ...I'm curious what the semantics of the `Intersection::neighbor()` method in parallel setups is:
It is supposed to return both the number of embeddings of the intersection into the (inside or outside) grid *and* if the outside is a local entity.
So what happens if the outside is *not* a local entity? If we return "0", how does one know how many embeddings there are?
As this is a question about the parallel part of dune-grid-glue, I think @christi might be the best person to ask?https://gitlab.dune-project.org/extensions/dune-grid-glue/-/issues/6undefinded behaviour in conformingmerge.hh2017-08-02T07:31:55ZAnsgar Burchardtansgar.burchardt@tu-dresden.deundefinded behaviour in conformingmerge.hhWhile building the tests, gcc warns about undefined behaviour in conformingmerge.hh.
It looks like an out-of-bounds array access: grid1Local_[0] should only have indices (0,...,dim-1), but j loops from 0 to dim.
```
In file included...While building the tests, gcc warns about undefined behaviour in conformingmerge.hh.
It looks like an out-of-bounds array access: grid1Local_[0] should only have indices (0,...,dim-1), but j loops from 0 to dim.
```
In file included from .../dune/grid-glue/test/overlappingcouplingtest.cc:23:0:
.../dune/grid-glue/merging/conformingmerge.hh: In member function ‘void Dune::GridGlue::ConformingMerge<dim, dimworld, T>::computeIntersections(const Dune::GeometryType&, const std::vector<Dune::FieldVector<_ctype, dimworld> >&, std::bitset<(1 << dim)>&, unsigned int, const Dune::GeometryType&, const std::vector<Dune::FieldVector<_ctype, dimworld> >&, std::bitset<(1 << dim)>&, unsigned int, std::vector<typename Dune::GridGlue::StandardMerge<T, dim, dim, dimworld>::RemoteSimplicialIntersection>&) [with int dim = 3; int dimworld = 3; T = double; typename Dune::GridGlue::StandardMerge<T, dim, dim, dimworld>::RemoteSimplicialIntersection = Dune::GridGlue::StandardMerge<double, 3, 3, 3>::RemoteSimplicialIntersection]’:
.../dune/grid-glue/merging/conformingmerge.hh:215:53: warning: iteration 3u invokes undefined behavior [-Waggressive-loop-optimizations]
newSimplicialIntersection.grid1Local_[0][j] = refElement.position(subVertices[i][j],dim);
^
.../dune/grid-glue/merging/conformingmerge.hh:214:7: note: containing loop
for (int j=0; j<dim+1; j++) {
^
```