GalerkinToolkit / GalerkinToolkit.jl

FEM toolbox with automatic code generation, HPC support, and more.
MIT License
23 stars 0 forks source link

visualizing two level mesh with square periodic unit cell #64

Open jfdev001 opened 8 months ago

jfdev001 commented 8 months ago

Commit 539e79b371fefd02372bcb5343b4f9c0a35e71ef adds two new vectors: coarse_cell_permuted_fine_node_to_final_node (this was originally called coarse_cell_fine_node_to_final_node but I renamed it) and coarse_cell_unpermuted_fine_node_to_final_node. The coarse_cell_unpermuted_fine_node_to_final_node is used to get the coordinate mapping of fine nodes; however, the resulting visualization does not match what is expected. There appears to still be some sort of "rotation" occurring just based on the paraview image (see attached). To reproduce this, run the below and open 20240305-periodic-final-gmsh.vtu in paraview

julia> include("example.jl")
julia> TMP.test_two_level_mesh_with_square_periodic_unit_cell()

image

fverdugo commented 8 months ago

Hi @jfdev001,

I think I know what is going on and it has nothing to do with the permutations.

The problem is that we are using the reference cell of the fine mesh to map the coordinates. It should be the reference cell of the coarse mesh. They coincide if both meshes are generated with GalerkinToolkit, but they will be different if you use gmsh to generate one. As you can see now we use the one of the fine mesh:

https://github.com/fverdugo/GalerkinToolkit.jl/blob/a589b12c499f5cf2728c317912d97277b8520d3b/src/geometry.jl#L3583

In general, we need to use two reference cells (one for the fine mesh and another for the coarse mesh), namely fine_refcell and coarse_refcell.

For instance, in this line, we want to use the reference cell of the fine mesh:

https://github.com/fverdugo/GalerkinToolkit.jl/blob/a589b12c499f5cf2728c317912d97277b8520d3b/src/geometry.jl#L3753

In this other line, we need the reference cell of the coarse mesh:

https://github.com/fverdugo/GalerkinToolkit.jl/blob/a589b12c499f5cf2728c317912d97277b8520d3b/src/geometry.jl#L3668

Please remove the last code that added the extra vector for the unpermuted indices. We don't need it. Maybe use git revert?

jfdev001 commented 8 months ago

I think 7c143729fa2f4b8ed0417f2782ed1cedb775475a fixes the issue. I will expand the testing (i.e., higher dimensional coarse mesh (2, 2), maybe also periodic puzzle piece?) since I haven't tried that yet. The resulting periodic square two level mesh is shown below and is in output/20240305-periodic-final-gmsh.vtu (I will also move the function in example.jl to tests eventually and rename the output file accordingly). Reproducible by,

julia> include("example.jl")
julia> TMP.test_two_level_mesh_with_square_periodic_unit_cell()

image

jfdev001 commented 8 months ago

Problem persists when a periodic unit cell mesh is used in conjunction with a 2 x 2 coarse mesh. I'm looking into it now. See commit 16677ae9a488fcba6fe3cf040c2fb9b8cc8c8676 and reproduce with

julia> include("example.jl")
julia> TMP.test_two_level_mesh_with_periodic_square_unit_cell()

where the output file of interest is final-mesh-with-periodic-square-unit-cell-gmsh-and-2x2-coarse-mesh.vtu

image

fverdugo commented 8 months ago

Hi @jfdev001,

make sure that the physical groups you define in gmsh are consistent with the physical groups you get in a 1x1 cartesian mesh in GalerkinToolkit.

In addition, here we need to use coarse_refcell instead:

https://github.com/fverdugo/GalerkinToolkit.jl/blob/73c6380d02158b97138483e89ebe3ecc6b2254f1/src/geometry.jl#L3595