Edge-hanging corner neighbors in the p8est_mesh_t

[hannesbrandt]

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.

[cburstedde]

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 theentries 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.

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_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.

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.

[cburstedde]

Related question: do we need to keep p4est_mesh_get_neighbors? The function appears somwhat outdated, clumsy, and limited.

[hannesbrandt]

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?

[cburstedde]

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}_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?

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.

[hannesbrandt]

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.