support for running on a distributed memory system about overlap_checker HOT 1 OPEN

tagging @makeclean because john mentioned that you'd be interested in this

I should also mention that I've looked at the acceleration structure to see which objects potentially overlap to see whether it's worth doing something else (other than relying on the file system) to distribute the work of the checker.

the following image shows the linearised list of shapes (from iter_clite) showing which solids potentially intersect.

black dots indicate the pair had intersecting bounding boxes. assuming this file is representative, it seems as though most nodes would need access to a significant proportion of shapes to get their work done.

in an ideal world it might be possible to reorder the shapes into some optimal ordering to minimise the number of files loaded. the following image shows the above solids reordered, via hierarchical clustering:

but it's unclear to me how spending the time to calculate this would be a win

from overlap_checker.