Edge-hanging corner neighbors in the p8est_mesh_t
hannesbrandt opened this issue · comments
As pointed out by @scottaiton (#235) the p8est_mesh_t does not provide information about same size corner-neighbors across a hanging edge, since the corresponding entries of quad_to_corner are set to -1.
We could provide the hanging corner neighbors using corner_offset, corner_quad and corner_corner. The quad_to_corner array would then index into local_num_quadrants + local_num_ghosts + [0 .. local_num_corners - 1]. We could use the entries of corner_corner to encode information similar to edge_edge, e.g. by setting corner_corner to 0..7 for non-hanging neighbors and to 8..15 for hanging corner neighbors.
Thereby, we have access to the corner neighbors across hanging edges and maintain the possibility to distinguish between hanging and non-hanging neighbors.
Furthermore, there is an open todo in the documentation of the p8est_mesh_t
TODO: In case of an inter-tree neighbor relation in a brick-like
* situation (one same-size neighbor, diagonally opposite edge/corner),
* use the same encoding as for edges/corners within a tree.
This might be a good opportunity to resolve it as well.
As pointed out by @scottaiton (#235) the
p8est_mesh_tdoes not provide information about same size corner-neighbors across a hanging edge, since the corresponding entries ofquad_to_cornerare set to -1. We could provide the hanging corner neighbors usingcorner_offset,corner_quadandcorner_corner. Thequad_to_cornerarray would then index into local_num_quadrants + local_num_ghosts + [0 .. local_num_corners - 1]. We could use theentries ofcorner_cornerto encode information similar toedge_edge, e.g. by settingcorner_cornerto 0..7 for non-hanging neighbors and to 8..15 for hanging corner neighbors. Thereby, we have access to the corner neighbors across hanging edges and maintain the possibility to distinguish between hanging and non-hanging neighbors.
I'd agree to add this case with the necessary information. I'm wondering whether we'd need to use the 8..15 values, since for edge_edge we use it for orientation, where here we'd use it for flagging hanging/non-hanging context. Since this information can, if necessary, be looked up from child id and corner number, it may suffice to state the formula/expression in the documentation and use 0..7 values only.
Shall we keep the -1 value when there is no same-size corner neighbor at the hanging edge at all, and only activate this situation when there are at least two mutual hanging-edge corner neighbors?
Furthermore, there is an open todo in the documentation of the
p8est_mesh_tTODO: In case of an inter-tree neighbor relation in a brick-like * situation (one same-size neighbor, diagonally opposite edge/corner), * use the same encoding as for edges/corners within a tree..This might be a good opportunity to resolve it as well.
Yes, it would be. However I'm thinking to keep it simple and always use the indirect lookup-arrays for inter-tree neighbors by principle. Then we might just remove this comment.
This will be a breaking change. We may make this explicit by changing the interface of p4est_mesh_new_ext with a parameter to activate this encoding by a boolean. We may also update the documentation/use of btype. With the proposed change, we must document the balancing requirements more explicitly.
Related question: do we need to keep p4est_mesh_get_neighbors? The function appears somwhat outdated, clumsy, and limited.
I'd agree to add this case with the necessary information. I'm wondering whether we'd need to use the 8..15 values, since for edge_edge we use it for orientation, where here we'd use it for flagging hanging/non-hanging context. Since this information can, if necessary, be looked up from child id and corner number, it may suffice to state the formula/expression in the documentation and use 0..7 values only.
I think child id and corner number are not enough to determine if two same size corner neighbors are edge-hanging or not, one also needs to check for the existence of a coarser quadrant sharing the edge with the two quadrants. This should still be possible with the information already supplied in the mesh, e.g. by checking the correct entries of quad_to_face. Nonetheless, I agree that using the 8..15 encoding might be counterintuitive.
Shall we keep the -1 value when there is no same-size corner neighbor at the hanging edge at all, and only activate this situation when there are at least two mutual hanging-edge corner neighbors?
Keeping the -1 value whenever there is no same-size neighbor seems like a good solution to me.
Related question: do we need to keep p4est_mesh_get_neighbors? The function appears somwhat outdated, clumsy, and limited.
I agree. Especially the not-yet-consistent encodings could be very confusing to the user. Maybe neighbor-relationship-specific get_{face,edge,corner}_neighbors functions translating the encodings back to face number, orientation, size relation,... are a more intuitive approach to this? Would it make sense to mark p4est_mesh_get_neighbors as outdated, but keep it for backwards compatibility?
I'd agree to add this case with the necessary information. I'm wondering whether we'd need to use the 8..15 values, since for edge_edge we use it for orientation, where here we'd use it for flagging hanging/non-hanging context. Since this information can, if necessary, be looked up from child id and corner number, it may suffice to state the formula/expression in the documentation and use 0..7 values only.
I think child id and corner number are not enough to determine if two same size corner neighbors are edge-hanging or not, one also needs to check for the existence of a coarser quadrant sharing the edge with the two quadrants. This should still be possible with the information already supplied in the mesh, e.g. by checking the correct entries of
quad_to_face. Nonetheless, I agree that using the 8..15 encoding might be counterintuitive.
Ok, let's give this a try. With the added parameter to mesh_new_ext we'll go for the simple solution.
To be future proof we may make this parameter an enum, so we can add further options later.
Shall we keep the -1 value when there is no same-size corner neighbor at the hanging edge at all, and only activate this situation when there are at least two mutual hanging-edge corner neighbors?
Keeping the -1 value whenever there is no same-size neighbor seems like a good solution to me.
Cool.
Related question: do we need to keep p4est_mesh_get_neighbors? The function appears somwhat outdated, clumsy, and limited.
I agree. Especially the not-yet-consistent encodings could be very confusing to the user. Maybe neighbor-relationship-specific
get_{face,edge,corner}_neighborsfunctions translating the encodings back to face number, orientation, size relation,... are a more intuitive approach to this? Would it make sense to markp4est_mesh_get_neighborsas outdated, but keep it for backwards compatibility?
Sounds good! We can mark the function as obsolete now and remove it for 2.9.0. We may think about optionally re-enabling it with --enable-mesh-deprecated, but we may also choose not to go there at all.
Ok, let's give this a try. With the added parameter to mesh_new_ext we'll go for the simple solution.
To be future proof we may make this parameter an enum, so we can add further options later.
Ok, I will start working on an implementation. Should the new parameter also be stored in the p4est_mesh_t? This would be the easiest way to access it during the mesh generation and would also allow to reproduce how a mesh was created later on.
If I am not mistaken, p4est_iterate ignores hanging corners for its iter_cornercallback. So, I would add the hanging corner information in mesh_iter_edge, when it is called for the edge that connects the edge-hanging corner neighbors.