Add geometry for pillow connectivity to map the sphere

[pkestene]

Add missing geometry for this connectivity.

The transformation from logical tree-local coordinates to physical coordinates to map the sphere are based upon:

"Logically rectangular finite volume methods with adaptive refinement on the sphere", Berger et al.

https://doi.org/10.1098/rsta.2009.0168

[cburstedde]

Thanks! There's an unusual amout of CI failures, which may be unrelated. Still wondering if there is anything to be done about those at the level of this PR?

[pkestene]

Thanks! There's an unusual amout of CI failures, which may be unrelated. Still wondering if there is anything to be done about those at the level of this PR?

I took a look at the different logs; all the failures appear to be related to p4est_test_loadsave (most probably unrelated to the current PR but to the problem already mentionned in #304)

[pkestene]

@cburstedde

I have though a question regarding this "simple" 3d connectivity (2 octrees "overlapping" each other, very similar to 2d connectivity pillow; the 2 octrees use the exact same vertex)

I noticed that :

./p8est_simple pillow3d 2
./p8est_simple pillow3d 3
./p8est_simple pillow3d 4

run ok in debug mode (no error, everything fine), but

./p8est_simple pillow3d 5

fails inside p4est_balance:

[p4est] Done p8est_refine with 9326 total quadrants
[p4est] Into p8est_balance CORNER with 9326 total quadrants
[p4est 0]  Into balance tree 0 with 8261
[p4est 0]  Hash size 255 avg 0.0314 std 0.196 checks 0 0
[p4est 0]  Hash size 255 avg 0.141 std 0.37 checks 0 0
[p4est 0]  Hash size 255 avg 0.784 std 0.931 checks 0 0
[p4est 0]  Tree 0 inlist 0 outlist 7258 ancestor 148 insert 651
[p4est 0]  Balance tree 0 A 8912
[p4est 0]  Into balance tree 1 with 1065
[p4est 0]  Hash size 255 avg 0.0314 std 0.196 checks 0 0
[p4est 0]  Hash size 255 avg 0.141 std 0.37 checks 0 0
[p4est 0]  Tree 1 inlist 0 outlist 686 ancestor 19 insert 161
[p4est 0]  Balance tree 1 A 1226
[p4est 0]  first send Z 0 L 0 recv Z 0 L 0
[p4est 0]  second send Z 0 L 0 recv Z 0 L 0
[p4est 0]  total send 0 recv 0
[p4est 0]  peer 0 first S 1592 R 1592 second S 80 R 80
[p4est 0]  Tree border 0 inlist 0 outlist 0 ancestor 0 insert 98
[p4est 0]  Balance tree 0 B 8912 to 9010
[p4est 0]  Tree border 1 inlist 0 outlist 0 ancestor 0 insert 560
[p4est 0]  Balance tree 1 B 1226 to 1786
[p4est]  Global number of shipped quadrants 0
[p4est 0]  Done balance tree 0 now 9010
[p4est 0]  Done balance tree 1 now 1786
[p4est]  Into p8est_ghost_new CORNER
[p4est 0]   Total quadrants skipped 8948 ghosts to receive 0
[p4est]  Done p8est_ghost_new
[p4est 0]  Contradicting small face neighbors
[libsc 0] Abort: Assertion 'p4est_is_balanced (p4est, btype)'
[libsc 0] Abort: ../../src/p4est.c:2421
[libsc 0] Abort: Obtained 9 stack frames
[libsc 0] Stack 0: libsc.so.3(+0x1bb93) [0x7db549f69b93]
[libsc 0] Stack 1: libsc.so.3(sc_abort+0x11) [0x7db549f69b4e]
[libsc 0] Stack 2: libsc.so.3(sc_abort_verbosef+0) [0x7db549f69d78]
[libsc 0] Stack 3: libp4est.so.3(p8est_balance_ext+0x58b5) [0x7db54a095132]
[libsc 0] Stack 4: libp4est.so.3(p8est_balance+0x2f) [0x7db54a08f87a]
[libsc 0] Stack 5: p8est_simple(+0xe3a5) [0x594ef57c93a5]
[libsc 0] Stack 6: libc.so.6(+0x2a1ca) [0x7db54962a1ca]
[libsc 0] Stack 7: libc.so.6(__libc_start_main+0x8b) [0x7db54962a28b]
[libsc 0] Stack 8: p8est_simple(+0xd9a5) [0x594ef57c89a5]

Do you think the connectivity is ill-formed ?

• I used the same "trick" as for pillow is 2d, only used 8 corners, both tree 0 and 1 are using the same vertex; so nothing should be needed regarding the edges
• equivalently, but more elaborated, one could also try to use/design a connectivity with 2 separate octrees, one above the other in the "z" direction, and setup accordingly the tree_to_face, edge_to_tree, etc... (I didn't try yet). It should provide exactly the same results right ?

What would you recommend to fix the problem ? Thanks.

[cburstedde]

Interesting. This 3D pillow is really a 4D mesh? It connects two faces in a way that we don't really define in p4est: the identity permutation of face corners does not occur for two faces of the same number meeting in any legal 3D mesh. So we're definitely outside of the concept. In 2D the problem does not occur since the mesh has valid face connections.

I'm wondering why the error does not show at earlier levels though.

[cburstedde]

The connectivity encoding in 3D can join two cubes that are made of say rubber, which are rotated, translated, and deformed smoothly from the reference position, but cannot displace each other right at the touching face, edge or corner.

This can only work in the present encoding if you give one of the two cubes a negative volume. Very creative. :)

[pkestene]

Just for the record, looking at the generated mesh (when p4est_balance is ok, using a refine level smaller than 5) in paraview, everything "seems" ok by eye inspection.

But you are right, the 2 cubes map 2 overlapping hemispheres, I just apply the z->-z symetry in the p4est_geometry. I though it could be working.

I'll try the other way and provide another PR.

[pkestene]

At least, the p4est_geometry for the 2d pillow is ok; I'll keep the first commit.