slow writing of (ensight) surfaces

Observed in EP1819. The point merging now appears to be the main bottleneck. @Chiara

changed the description

assigned to @mark

Developing some test code that restricts the merge algorithm to a subset of points. In this particular case, the boundary points. This is still not the perfect solution, but should cut back the number of comparisons. One observation while looking through the code (@Mattijs): by default we use (0,0,0) for the comparison basis, with an unused option (point::max) to trigger the evaluation of a point average as the comparison basis. I think that this is also wrong. Instead I believe we should be using something like the minimum point in the set as the comparison basis to improve the initial sort. If we imagine a cloud of points that is vaguely spherical around the origin. Using the middle point produces search shells with lots of points at the same radius, whereas using the min point of its bounding box will produce search shells with a smaller fraction of points in each search radius. This should reduce the number of comparisons within the sorted list. Should still be okay provided that the overall bounding box of the points to be merged spans less than ROOTVGREAT.

mentioned in commit f7cbb067

With the changes to point merging (preserving the original point order), should also revisit #2048 (closed) (ccmToFoam conversion). We can probably now do better with handling the interface merging.

mentioned in commit 24c0b30d

changed milestone to %v2212

Based on the testing from @Chiara (EP1819) with the debug surface writer, using scheduled was generally faster than nonBlocking. So make this the new default, but with a user-option to adjust if required.

Since the surfaceWriter also manages its own internal bookkeeping for when to merge/expire the surfaces, also cache the globalIndex for field merging there to further reduce communication.

mentioned in commit dbd59548

mentioned in commit b7592c1e

mentioned in issue #2639 (closed)