[DrunkOnJava]

Summary

mesh_bodies_vs_ifc and saved_meshes_vs_ifc were 2,752 of the 5,548 s of scorer time in Measure run 41655009606. Their output is unchanged on every model (66 of 66 files byte-identical, with and without --saved-meshes); on the BIM4LCA office, as built, the pair takes 163.6 s where it took 576.4 s, one scorer at a time on one runner (default exports; 138.7 s against 444.8 s with --saved-meshes).

Motivation

#1237. In a Measure run the office's mesh_bodies_vs_ifc took 418 s alone and 940 s beside the other steps, saved_meshes_vs_ifc 300 s and 397 s, on a runner that is CPU-bound.

Changes

• tools/re/mesh_bodies_vs_ifc.py: opens each IFC once. surface_distance is pruned and exact. A point's nearest distance is the minimum over a set of triangles that holds every one that could be nearest, found with a block box, then a triangle box, then the triangle's plane and the side planes of its edges as lower bounds (slivers, whose computed plane is unreliable, are measured against every point). Every candidate is measured by the arithmetic the exhaustive search uses (one function now serves both), so the result is the same float, not an approximation; the argument is in the docstring. A triangle is left out only when a lower bound on it exceeds the nearest distance found plus 1e-6 ft and 4e-9 of the extent, which covers the 1e-9 barycentric tolerance of inside even on a 1e7 ft triangle (the first version's 1e-9 did not: a point 0.99e-9 outside such a triangle measured 0.003 where the exhaustive search says 0). Jobs of 200,000 pairs or fewer, and any input that is not finite, still take the exhaustive search.
• tools/re/ifc_common.py: mesh_parts meshes with one create_shape per part in a forked process pool, falling back to serial if a worker dies, and, when RVT_MESH_CACHE names a directory, keeps what it meshed as npz shards (keyed by the file's path, size and mtime and by every setting) for the next scorer. Fewer than 16 parts are meshed without a pool. RVT_MESH_WORKERS sets the pool size. A worker stops at its next part if its parent has died, a shard is named by process and time, a pool that breaks prints one line on stderr and falls back to serial, and a part IfcOpenShell cannot mesh keeps its reason in MESH_FAILURES (also in the cache; nothing prints it, so no output changes).
• tools/re/saved_meshes_vs_ifc.py: meshes through mesh_parts in place of ifcopenshell.geom.iterator, and lists bodies in ascending instance id, the order the iterator returns them in with one thread. The iterator's order with several threads varies from run to run, and it decides the order of the tables' tied rows (the office's 269 doors and 269 windows); a first version that listed them by type order changed one tie in a local run.
• tools/ci/measure-reference-models.sh: the two scorers run one after the other as one task per model (meshes), with RVT_MESH_CACHE set to the model's folder, so Revit's side is meshed once; the folder's size is logged and the folder removed with the model's other bulky outputs.

Testing

Unit tests are banned; identity is Measure against Measure, outputs diffed file by file.

Identity, -f ref=8add3443615ba576bdb81c822548243b5cd314dd -f base=none -f nordic=true -f r2025=true -f scorers="mesh_bodies_vs_ifc saved_meshes_vs_ifc", once without and once with -f ifc_flags=--saved-meshes, scorers from main (8add344) against scorers from this branch (9851ae6, main merged in). nordic=true is four offices now (as built, permit, and the two terrain variants), 33 models in all:

flags	main run	branch run	mesh_bodies_vs_ifc.txt and saved_meshes_vs_ifc.txt
default	41696367238	41696379231	66 identical, 0 different
--saved-meshes	41696391719	41696404128	66 identical, 0 different

Peak memory with four offices (vmstat.log, 16 GiB runners, no swap in any run): used memory peaked 2.9 GiB above the start with default exports (main: 4.9) and 6.0 GiB with --saved-meshes (main: 5.2); the lowest free memory was 9.5 and 6.6 GiB (main: 7.6 and 7.2). The Measure step took 6:01 and 6:33 against main's 8:17 and 8:24, on runners of different CPUs (main on an EPYC 9V45; the branch on a 7763 and a 9V74), so those are not a pair.

The earlier identity runs on 3ff51de (main 41676807914 and 41676812191 against 41686047329 and 41686052305) were 62 of 62 identical as well. The speed measurements below were taken on 3ff51de; the later commits changed only the slack and the robustness items above.

Speed, the office as built, one scorer at a time on one runner (MEASURE_JOBS=1, /usr/bin/time; a throwaway branch, fd34397, since deleted, added main's two scorers beside the new ones; runs 41685996778 and 41686000775 hold its cpu.log and outputs): the old and new outputs are identical there as well.

runner	scorer	main wall (CPU), s	this branch wall (CPU), s
AMD EPYC 7763, default exports (41685996778)	mesh_bodies_vs_ifc	427.5 (427.8)	158.6 (495.2) on its own; 46.1 (46.4) after saved_meshes_vs_ifc
	saved_meshes_vs_ifc	148.9 (573.5)	115.3 (442.7); 117.5 as the first of the pair
	the pair as Measure runs it	576.4	163.6
AMD EPYC 9V74, --saved-meshes (41686000775)	mesh_bodies_vs_ifc	321.9 (322.2)	123.5 (374.4) on its own; 39.6 (39.9) after saved_meshes_vs_ifc
	saved_meshes_vs_ifc	122.9 (467.8)	98.9 (377.2); 99.1 as the first of the pair
	the pair as Measure runs it	444.8	138.7

With one pool worker the new scorers take 302.8 s (mesh_bodies_vs_ifc) and 271.9 s (saved_meshes_vs_ifc) on the first runner: the pruning accounts for the 125 s that mesh_bodies_vs_ifc loses, the pool for the rest of the wall time. The pool's user time is higher than serial (the 4 vCPUs are probably two cores' hyperthreads, and each worker parses the parts it meshes again), so it buys wall time on an idle runner and not CPU on a busy one; the shared meshes and the pruning are what lower the CPU (the pair's 1,001 CPU-s become 496 on the first runner).

In Measure runs, the same pair of runs on one CPU type (AMD EPYC 7763, --saved-meshes, both offices running beside each other, 3ff51de): mesh_bodies_vs_ifc 830 and 842 s to 52 and 53 s, saved_meshes_vs_ifc 442 and 439 s to 324 and 324 s, the Measure step 885 s to 421 s.

Largest resident set of a single process (/usr/bin/time reports the largest in the tree, and the pool runs several): 0.76 to 0.89 GB, against 1.18 to 1.89 GB for main's scorers, which were one process each.

Not done, and limits

• The identity runs cover the reference models, the BIM4LCA offices and the R2025 models; the holdout and BIMcollab models were not run.
• No cache across runs: the BIM4LCA models are "read by byte range for the run and never stored", and the workflow keeps no measure cache directory; the cache here lives in the model's folder and is deleted with it.
• A RuntimeWarning from numpy prints the file and line it came from. None appears in any current output, but this PR moves every line, so a model that ever printed one would differ from main's text.
• fix(measure): saved_meshes_vs_ifc scores each file's bodies in its own frame, so the office's turned export compares box for box #1282 and ci(measure): exports run in parallel and every model's steps run as tasks of their own, heaviest first (#1237) #1285 are merged and this is merged with main. ifcopenshell.geom.iterator and create_shape give the same triangles bit for bit on the 538 Revit parts of the office (checked locally), and Measure's identical outputs say the same on the rest.
• saved_mesh_status_vs_ifc.py and fitting_faces_vs_ifc.py import meshes and surface_distance; their signatures hold (meshes gained an optional model).

Breaking changes

None.

[DrunkOnJava]

Automated Claude Code review (the maintainer's review agent; it compared both scorers' outputs across four runs and fuzzed the pruned distance against the exhaustive one): no blocking items. Fixed anyway in 9851ae6: the pruning slack now covers the barycentric tolerance of a very large triangle, and a pool worker stops when its parent dies, shards and the cache key cannot collide, a broken pool says so, and the cache's size is logged before it is deleted.