search

trixi-framework / Trixi.jl

Trixi.jl: Adaptive high-order numerical simulations of conservation laws in Julia
https://trixi-framework.github.io/Trixi.jl
MIT License
527 stars 105 forks source link

Tree Mesh centering the mesh and shifting the boundaries (rectangles to quads) #1889

Open MarcoArtiano opened 6 months ago

MarcoArtiano commented 6 months ago

While studying and making some test cases about the Warm Bubble Test for compressible Euler, the mesh on the y direction seems to be shifted, rather than being from 0 to 10_000, it is from -5000 to 15000.

https://github.com/trixi-framework/Trixi.jl/blob/main/examples/tree_2d_dgsem/elixir_euler_warm_bubble.jl

coordinates_min = (0.0, 0.0)
coordinates_max = (20_000.0, 10_000.0)

# Same coordinates as in examples/structured_2d_dgsem/elixir_euler_warm_bubble.jl
# However TreeMesh will generate a 20_000 x 20_000 square domain instead
mesh = TreeMesh(coordinates_min, coordinates_max,
                initial_refinement_level = 6,
                n_cells_max = 10_000,
                periodicity = (true, false))
image image

As far as I know the mesh has to be a Quad, consequently it changes boundaries according to it.

ranocha commented 6 months ago

Looks like a (documentation) bug to me. The TreeMesh supports only quads/cubes, no rectangles. But the constructor should complain in a case like this, I think. What's your opinion, @sloede?

benegee commented 6 months ago

I added this test case for StructuredMesh and then copied it for TreeMesh to test the different flux implementations. I was not aware of the quad restriction in the first place, realized how TreeMesh adapts to the provided parameters and therefore added this comment in the elixir.

sloede commented 6 months ago

Looks like a (documentation) bug to me. The TreeMesh supports only quads/cubes, no rectangles. But the constructor should complain in a case like this, I think. What's your opinion, @sloede?

From the TreeMesh implemention: https://github.com/trixi-framework/Trixi.jl/blob/73da92c446c6f60fc09ad1cf5e579bbf5eccb34d/src/meshes/tree_mesh.jl#L122-L124

I thus understand why the code in the example behaves as expected. I think that changing the referenced lines to first compute the lengths in each direction and to then trow an error if they do not match (within an epsilon) before taking the maximum would be a nice addition for usability!