Open efaulhaber opened 3 years ago
I figured I could just use
num_corners == 0
since I don't need any corner connectivity. This worked perfectly fine until I refined one quadrant to level 4. In this case, I needed to callp4est_balance
twice to obtain a balanced forest.
You should be able to omit connecting corners and edges as well in your case.
Make sure you call balance only for faces, there is a parameter to the function. It should never be necessary to call balance twice. If this still occurs, please report.
Is it fine to use
num_corners == 0
if corner connectivity is not needed, and is this a bug? Or did I use this incorrectly, and should I have specified the corner connectivity even if I don't use it myself?
You would not need corners or edges. This should all work -- please follow up with more information.
I created a periodic rectangle connectivity, similar to p4est_connectivity_new_periodic
but with num_corners = 0
. Then, I refined the bottom left quadrant to level 4.
Balancing once yields this mesh:
Balancing twice yields this mesh:
This does not happen when I use p4est_connectivity_new_periodic
(with corner connectivity).
Here's a quick and dirty MWE to demonstrate this behavior. It yields the following output showing that the first balancing produces 25 quadrants while the second balancing creates 3 more.
[p4est] Into p4est_new with min quadrants 0 level 0 uniform 1
[p4est] New p4est with 1 trees on 1 processors
[p4est] Done p4est_new with 1 total quadrants
[p4est] Into p4est_refine with 1 total quadrants, allowed level 29
[p4est] Done p4est_refine with 13 total quadrants
[p4est] Into p4est_balance FACE with 13 total quadrants
[p4est] Done p4est_balance with 25 total quadrants
[p4est] Into p4est_balance FACE with 25 total quadrants
[p4est] Done p4est_balance with 28 total quadrants
Thanks, this is really helpful! I'll copy @tisaac, since it may be related to one of the later evolutions of the balance algorithm.
(It may also be related to #101, which is so far not part of the official branches but ideally should be in the future.)
I'm sorry about missing this issue last year!
My interpretation is that omitting corners from this periodic mesh should be considered incorrect. When you omit the corners data structures, you are telling the topology traversal routines, for example, "the only tree-corners neighboring (tree 0, corner 0) are the ones that can be found across faces (and edges in 3D)". In this case, this gets interpreted as "the only tree-corners neighboring (tree 0, corner 0) are (tree 0, corner 1) [the neighbor across the x face] and (tree 0, corner 2) [the neighbor across the y face]." That means that in balance the affect of (tree 0, corner 0) on (tree 0, corner 3) are not considered.
Let me come back to this. Thanks again to @efaulhaber on your pictures!
Your top picture, even without corner information, should be face balancing the top right quadrant one level deeper. This is apparently not happening. So I'd suspect that corner information has some effect backwards on face connection, which is somewhat against the usual flow of information in p4est.
This may be related to #238, which is being investigated.
After discussing the issue some more, we basically concur with @tisaac's view. Technically, even for face- or edge-only balance, we require (parts of) the full 3x3 neighborhood of a quadrant (3x3x3 of an octant) to be known. Omitting corner (or edge) connections removes certain blocks from the neighborhood at tree boundaries, turning it into a cross-shape instead of a full cube, which leads to incomplete balance. The principle that should be maintained can be stated as follows:
Connectivity completeness: If a 3D connectivity contains natural connections between trees that are edge neighbors without being face neighbors, these edges shall be encoded explicitly in the connectivity structure. If a connectivity implies natural connections between trees that are corner neighbors without being face (or edge) neighbors, these corners shall be encoded explicitly.
A connectivity can be
p4est_connectivity_is_valid
checks for some, yet not all, of potential contradictions.What we need to do before closing the issue, is
p4est_connectivity.h
,p4est_connectivity_complete
,p4est_connectivity_is_complete
.Any further comments are very welcome.
The documentation of the 2D connectivity has been extended in #236.
I am using p4est in a DG code, so I only need face connectivity and no corner connectivity. In the docs, it says
and
I figured I could just use
num_corners == 0
since I don't need any corner connectivity. This worked perfectly fine until I refined one quadrant to level 4. In this case, I needed to callp4est_balance
twice to obtain a balanced forest.Is it fine to use
num_corners == 0
if corner connectivity is not needed, and is this a bug? Or did I use this incorrectly, and should I have specified the corner connectivity even if I don't use it myself?