dune-alugrid issueshttps://gitlab.dune-project.org/extensions/dune-alugrid/-/issues2023-08-17T14:15:20Zhttps://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-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-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-alugrid/-/issues/61Debug output when reading ALUGrid from gmsh file (master)2022-05-02T17:43:37ZTimo KochDebug output when reading ALUGrid from gmsh file (master)If I create a grid using the gmsh reader like this:
```cpp
int main (int argc, char *argv[]) try
{
Dune::MPIHelper::instance(argc, argv);
using Grid = Dune::ALUGrid<3, 3, Dune::simplex, Dune::conforming>;
auto gridFactory = ...If I create a grid using the gmsh reader like this:
```cpp
int main (int argc, char *argv[]) try
{
Dune::MPIHelper::instance(argc, argv);
using Grid = Dune::ALUGrid<3, 3, Dune::simplex, Dune::conforming>;
auto gridFactory = std::make_unique<Dune::GridFactory<Grid>>();
Dune::GmshReader<Grid>::read(*gridFactory, "ball.msh", /*verbose=*/false, /*boundarySegments=*/false);
auto grid = std::shared_ptr<Grid>(gridFactory->createGrid());
return 0;
}
```
I get tons of debug output from ALUGrid that I didn't ask for. (From some bisection compatibility check.)
```
Build neighbors took 0.000766 sec.
P[ 0 ]: Making compatible
#V0 #V1
198 0
Done: element 0 of 636 time used = 1e-05
Done: element 6 of 636 time used = 2.2e-05
...
Done: element 624 of 636 time used = 3.1e-05
Done: element 630 of 636 time used = 4.7e-05
P[ 0 ]: Grid is compatible!!
NotStrongCompatibleMacroFaces InnerFaces TotalFaces Maximum/Vertex Minimum/Vertex
487 1113 1431 26 0
Marking longest edge for initial refinement...
P[ 0 ]: BisectionCompatibility done:
P[ 0 ]: Elements: 636 0.005112 seconds used.
```https://gitlab.dune-project.org/extensions/dune-alugrid/-/issues/60Installing a 2.3 compatible alugrid version2020-12-19T21:08:06ZChristian EngwerInstalling a 2.3 compatible alugrid versionWhen reactivating an old DUNE module it is often very helpful to first get the old code working again.
Then might require having access to an old ALUGrid version. Since the Freibug website changed the old versions can not be downloaded ...When reactivating an old DUNE module it is often very helpful to first get the old code working again.
Then might require having access to an old ALUGrid version. Since the Freibug website changed the old versions can not be downloaded anymore.
I found out that the repository also contains all the old versions. Thus I created a branch `releases/1.98` and started fixing it to run with recent compilers (which is not all that trivial).
Here follows a brief installation note:
>
> At that earlier stage alugrid was not a dune module, but had to be installed. The buildsystem used autotools to generate `Makefile`s.
>
> One can setup and install alugrid locally in the home directory. Run something along the following lines
> ```
> ./autogen.sh --prefix=$HOME/install
> make
> make install
> ```https://gitlab.dune-project.org/extensions/dune-alugrid/-/issues/55Twist-free ALUGrid2020-12-19T17:38:23ZMartin AlkämperTwist-free ALUGridSee branch feature/twist-free-alugrid
I am getting closer to complete the twist-free dune-alugrid. It has a lot of changes, but has been rebased to a recent status, so a merge should not be a problem.
Open Problems:
- [ ] Orientati...See branch feature/twist-free-alugrid
I am getting closer to complete the twist-free dune-alugrid. It has a lot of changes, but has been rebased to a recent status, so a merge should not be a problem.
Open Problems:
- [ ] Orientation of 3d cube grids
- [x] Parallelism
- [x] write and build from stream
- [x] remove duplicates (not needed)
- [ ] rework picture comments/documentation
- [x] periodic elements
- [x] performance?
Short summary of what happened until now:
- removed all dune2alugrid and similar calls
- removed all twist calls
- replaced the reference element by the dune reference element and all corresponding mappings
- also all topological mappings are now purely dune - there are multiple duplicates
- introduced an isRear_ variable on all classes, that derive from hasFace, that indicates for each face, whether it is rear or front. The only meaning that is has, is to tell whether to choose the rear or front part of the myneighbour structure. Geometric information, such as, where the outer normal points is removed from this variable.
- Also added a method bool isRear(int) which replaces the twist < 0 call in many situations
- changed the macro grid builder to not orientate the faces and calculate twist. Instead the isRear components are now calculated in the gridfactory
- correctElementOrientation in the gridfactory now computes the isRear value of all faces inside each element and also either calls bisectioncompatibility for tetras or the mesh-consistency (from marcel koch) for cubes - this means that recreateboundaryIds now almost always has to be called
- recoded the choice of the refinement edge in bisection based on the previous refinement edges. So we do not store the vtxOrder anymore. Also longest edge bisection is now possible
- adjusted all cube,tetra refinement methods to be twist-free
- started parallelization by adding isRear to the communication as an additional char
Description of the open problems
- Orientation of 3d cube grids
- The algorithm from Marcel Koch yields edge-consistent (i.e. no twists on edges) cube meshes with positive volume. For the implementation we want face-consistent (i.e. no twists on faces, implies edge-consistency) meshes, but we do not get positive volume anymore
- So there are two options: 1. Use the algorithm from marcel and add face-consistency, 2. Rewrite the algorithm myself
- Parallelism:
- I have added the isRear information to some read/write methods and the backup/restore, but it is still missing somewhere
- Testing is difficult, as the easy cases work
- Write/build grid from stream was disabled during adaptiation of the macro grid builder and the grid factory, because i did not have a test case
- During the process a lot of static information has been duplicated, like from which face to get vertex 0 and similar. This can be removed. Also there are now methods, that always behave the same as there are no more twists. So they could be manually inlined to reduce the code size.
- The pictures for adaptivity and for the mappings are not up to date anymore. I updated some, but not all.
- Periodic elements need to be completely adjusted everywhere throughout both the impl, and 3d folder, as I did not work on them at all. The changes should be very similar to those already done.
- Performance bottlenecks should be identified, if any.