[Sichao25]

For the use case of locating the owning rank of a query point in a distributed mesh, the current redev implementation has some ambiguity near partition boundaries. The proposed solution is to return multiple candidate ranks when a query point is close to an RCB partition boundary. These candidates are identified by traversing the RCB partition tree and exploring both branches when the point falls within a specified tolerance of a cut. The tolerance is scaled based on the local spacing of the RCB partition, with an additional factor to control.

test_boundaryRouting is a standalone test that reproduces the boundary-routing issue and is currently marked as an expected failure in CTest. test_candidateRanks is the unit test that verifies whether the traversal returns the correct candidate ranks.

Please let me know if you have any concerns or suggestions.

[jacobmerson]

I have not had a chance to look at the code yet, but the description of the solution seems backwards to me.

Let's consider the point query problem. A point always has a well defined RCB partition that it falls within. The problem comes from the elements part of the mapping. The solution to that should not be based on any tolerances, but instead should be based on a geometric primitive operation. Essentially, rather than asking "which RCB partitions is this element inside of with an arbitrary tolerance?", we need to ask "which RCB partitions does this element intersect with?". The initial primitives can be overly inclusive (i.e., bounding box intersection) and then later be refined to improve performance.

Note: we already have some basic BBOX intersection queries implemented as part of the localization that you can take advantage of.

As I am writing this out, I think there is a symmetry to the query when you start querying objects that are higher dimensional than points. That is, a element you are querying may intersect with multiple RCB partitions and the resulting map to processes may also have multiple candidates (produced by the same geometric primitive queries).

[Sichao25]

Okay, I see your point. So, what we want is to extend the existing redev routing from a single rank to multiple candidate ranks by identifying the RCB partitions that intersect the actual mesh element. That does seem like a better approach.

[jacobmerson]

If I remember correctly, redev doesn't "know" about elements, so the specific logic about intersections will go into PCMS/donwstream code. The key need in redev is being able to handle multiple candidate ranks.

[Sichao25]

That's correct.