Benchmark suite: PointCloudBVH vs picoflann/nanoflann, TriMeshSDF vs fcpw (#109)

[rmrsk]

Summary

Adds a reproducible Benchmark/ suite comparing EBGeometry against other open-source geometry-query
libraries, and consolidates all git submodules under a single Submodules/ directory.

Closes #109. Supersedes #110 (auto-closed when its base branch particle_soa_pr3 was merged and
deleted); this branch has been rebased onto main and carries the same two commits.

Background

Issue #109 proposed a reproducible benchmark suite comparing EBGeometry against other open-source
geometry-query libraries, and consolidating git submodules under a single Submodules/ directory.
This PR implements that. It builds on PointCloudBVH and TriMeshSDF, both now merged to main
(#106, #108).

Solution

Submodule consolidation. All git submodules now live under Submodules/:

• Moved common-3d-test-models → Submodules/common-3d-test-models, rewiring every relative mesh
  path (Examples MeshSDF/CSGUnion, Integrations AMReX MeshSDF/PaintEB, Examples/CMakeLists.txt, the
  docs, and the REUSE.toml note). URLs and the submodule's own name are untouched; verified MeshSDF
  and CSGUnion still load the mesh at the new path.
• Added the comparison libraries as shallow submodules: Submodules/nanoflann, Submodules/picoflann,
  Submodules/fcpw (fcpw's Eigen dependency is its own nested submodule).

Benchmark/ suite (illustrative, not CI-tested, like Integrations/):

• Benchmark/NearestNeighbor — all-nearest-neighbor over a 500k unit-cube point cloud (double):
  PointCloudBVH vs picoflann vs nanoflann. The KD-tree queries iterate in Hilbert order so their
  node cache is as warm as PointCloudBVH's leaf-order batch (natural order is ~2× slower — unfair);
  the one-time spatial sort they need for that order is reported separately, since PointCloudBVH
  reuses the ordering its build already produced for free. Representative: PointCloudBVH ~0.30,
  nanoflann ~0.24, picoflann ~0.47 µs/pt; folding the sort into the KD-trees, PointCloudBVH wins the
  end-to-end job and builds ~1.5× faster than nanoflann.
• Benchmark/MeshSDF — closest-point on a triangle mesh (armadillo, ~100k triangles):
  TriMeshSDF vs fcpw vs TriangleMeshDistance, the task all three are built for. The mesh is parsed
  once; each library builds its own structure over the same triangles and answers the same queries,
  with distances cross-checked (0 mismatches). fcpw is built with its Enoki CPU vectorization
  (vectorized MBVH) for a like-for-like float/SIMD comparison; TriangleMeshDistance is header-only,
  double-precision and scalar (a reference point, not a same-precision comparison). Representative:
  TriMeshSDF ~2.6, fcpw (Enoki) ~3.5, TriangleMeshDistance ~10.5 µs/query.

Each benchmark has a GNUmakefile, and every result is verified against a brute-force / independent
baseline. Adds a Benchmark.rst docs page (in the toctree), Benchmark/README.md, and a REUSE.toml
block for the benchmark build files/READMEs (main.cpp carry inline SPDX).

Side-effects

• fcpw is built with Enoki CPU vectorization (FCPW_USE_ENOKI, vectorized MBVH) — a like-for-like
  float/SIMD comparison with TriMeshSDF. FCPW_SIMD_WIDTH is a GNUmakefile variable (default 8 =
  AVX2; 4 = SSE, 16 = AVX-512) to match the build machine's ISA.
• TriangleMeshDistance is double-precision and scalar (no SIMD) — its query runs in double, so it
  is not a same-precision comparison; it is included as a widely-used reference point, with distances
  cross-checked against TriMeshSDF.
• The Benchmark/ and comparison submodules are not part of CI (they pull external libraries with
  their own build systems), matching how Integrations/ is treated.
• Moving common-3d-test-models changes the default mesh path in the CI-tested Examples (MeshSDF,
  CSGUnion) and Integrations examples; all were updated and re-verified.

Alternative solutions

• Fetch single-header libs on demand (curl) and gitignore them, instead of submodules. Submodules
  were chosen for exact version pinning (better for reproducible benchmarks), per Benchmarks: compare EBGeometry against other NN/geometry libraries (picoflann, nanoflann, ...) #109.
• A top-level Benchmark/ vs Integrations/Benchmark — went with top-level, since benchmarking
  against external libraries is distinct from integrating EBGeometry into an application code.

Reviewer checklist (to be completed by a human)

• The test suite compiles and runs to completion without warnings or errors.
• All relevant new features are documented in the user documentation (Sphinx).
• This contribution does not break existing sections in the user documentation.
• All relevant APIs are documented in the doxygen documentation.
• Appropriate labels have been assigned to this PR.
• New or revised proper licensing and copyright information is in place.
• A PR review has been run using @claude review.
• The continuous integration and testing hooks at GitHub run to completion.