Drop 3d connectivity broken ?

[pkestene]

Description

When running ./p8est_simple drop 5 (from example/simple sub-directory), one obtains the following log

...
[p4est 0]  Balance tree 3 A 8912
[p4est 0]  Into balance tree 4 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 4 inlist 0 outlist 686 ancestor 19 insert 161
[p4est 0]  Balance tree 4 A 1226
[libsc 0] Abort: Assertion 'p4est_quadrant_is_ancestor (tq, s) || (p4est_quadrant_is_equal (tq, s) && tq->level == P4EST_QMAXLEVEL)'
[libsc 0] Abort: ../src/p4est_algorithms.c:1062
[libsc 0] Abort: Obtained 11 stack frames
...

To Reproduce

p4est configured with ./configure --enable-mpi --enable-debug CFLAGS=-O0 CC=mpicxx

Additional information

I checked current HEAD (develop) and v2.8.6 and v2.8.5 with the same results.

[pkestene]

Is it possible (somehow) that, after the refined step, the octree is "too" off-balanced that p4est_balance is unable to fix it ?

[cburstedde]

Is it possible (somehow) that, after the refined step, the octree is "too" off-balanced that p4est_balance is unable to fix it ?

Good find. The drop connectivity is indeed unusual. We had previously determined that every connectivity always needs full edge and corner information to support balance, even if balance is not extended across edges and/or faces. So we'd have to determine first whether the drop connectivity is complete. Any volunteers @pkestene @tim-griesbach ?

[cburstedde]

Is it possible (somehow) that, after the refined step, the octree is "too" off-balanced that `p4est_balance` is unable to fix it ?

Thanks for the report! Generally, balance is designed such that absolutely any mesh is legal as input. We'll have to double-check the drop connectivity, and if the error persists look deeper into balance. Which is on our list already, but we tend to get distracted since it usually works.

[tim-griesbach]

The drop connectivity is indeed unusual. We had previously determined that every connectivity always needs full edge and corner information to support balance, even if balance is not extended across edges and/or faces. So we'd have to determine first whether the drop connectivity is complete. Any volunteers @pkestene @tim-griesbach ?

I checked the drop connectivity definition and did not find any problem with it. @hannesbrandt and I investigated the reported assertion crash in the past in the issue #238 and ended up investigating the balance algorithm (#238 (comment)). I think as @cburstedde mentioned this issue may require to continue the deeper look into balance.

[cburstedde]

I checked the drop connectivity definition and did not find any problem with it. @hannesbrandt and I investigated the reported assertion crash in the past in the issue #238 and ended up investigating the balance algorithm (#238 (comment)). I think as @cburstedde mentioned this issue may require to continue the deeper look into balance.

Thanks! Yes, we'll get back to the balance algorithm in depth early next year.