BUG: Cross mesh interpolation breaks for parallel nested meshes about firedrake

[ReubenHill]

I think there's a bug somewhere in cell location - I'm seeing nans returned for the reference cell locations which trigger the error. This will need some debugging in places like locate.c

[ReubenHill]

This may also be related to #3089

[ReubenHill]

This is at least in part due to insufficient robustness in the vertex-only mesh voting algorithm.

2 things need to be done.

Where multiple ranks claim the same $L^1$ distance (in one case here, $0.0$), but disagree about rank, as happens in rare occurrences where a point is exactly on a mesh cell vertex at a parallel boundary which is visible to 3 or more ranks, the cell location algorithm should be triggered again.
The cell that was initially identified should be disregarded, and it should be told to produce the next best cell: when we find a cell with identical $L^1$ distance and rank as given by the voting algorithm, the search stops.
Whilst the parent mesh cell may not be identical, the point will certainly be given the correct parent mesh PyOP2 label.
If no such cell is found, we can safely treat the point as being not-locally visible.
This will ensure halo points are assigned correctly.

In these rare cases, the voting algorithm can also claim that a rank which has identified a point as self-owned will be told by a rank of higher number that a rank of lower number in fact owns the point: if that lower rank does not think it owns it then the above procedure would cause the point to be lost.
At present, when this occurs, an error is triggered.
To fix this, if there is a tie after minimising $L^1$ distance, a point which a rank has identified as self-owned should be chosen before choosing the lowest numbered rank.

[ReubenHill]

@pbrubeck I think #3293 fixes this. I haven't checked the performance implications but I think the algorithm is sound.

[pbrubeck]

@pbrubeck I think #3293 fixes this. I haven't checked the performance implications but I think the algorithm is sound.

Great. We could simply compare the runtime of the relevant VOM tests?