Force a working BLAS kernel on the runners that need one

[iory]

test_sdf_from_robot_with_scale_parameter has been going red on some runs of a commit and green on others, most recently on 15d396f, which produced one failing run and one clean one. The assertion said the signed distance field had been built on a grid 7.4 times too wide:

worst |sdf| is 0.5357201464651443 (4.19 grid cells of 0.127984),
tolerance 0.19197599999999998

It is not scipy 1.8.0, which is what the failing cells had in common by coincidence. In run 34554196186 the numpy-latest/scipy-1.8.0 cell passed while numpy-1.23.5/scipy-1.8.0 failed; in 34552744465 the numpy-latest/scipy-1.8.0 cell failed.

What it is

numpy's bundled OpenBLAS detects the Intel(R) Xeon(R) 6973P-C as Core: Cooperlake, and that kernel returns wrong results for (4, 4) by (4, n) double-precision products once n passes roughly 128. Most rows come back as [10*x + 10, 0, 0]: the homogeneous row folded into the first column and the other two zeroed. 2311 of 2503 rows on the sample.

That is the product trimesh.transform_points makes, so every mesh a URDF scales or places is built from it. The collision mesh comes out a shape the bunny never had, SDFGen sizes the grid from its bounding box, and the failure surfaces four layers from the cause. The Mitsuba viewer sizing a Panda scene wrong in the same job was this too.

Minimal reproducer:

import numpy as np
n = 2503
V = np.random.default_rng(0).random((n, 3))
M = np.eye(4); M[:3, :3] = np.diag([10.0, 10.0, 10.0])
stack = np.column_stack((V, np.ones(n)))
print(np.abs(np.dot(M, stack.T).T[:, :3] - V * 10.0).max())
# 0.0 anywhere healthy, 10.0 on a Xeon 6973P-C

How it was pinned down

One runner per job, 145 jobs over five batches, printing the diagnostics whether or not the assertion held, because a machine can carry the defect and still pass: an over-wide grid on its own only moves the worst vertex to about half a cell, measured at four grid sizes.

CPU	runners	result
Intel Xeon 6973P-C	10	all reproduced the failure, to the last digit of both the resolution and the worst vertex
AMD EPYC 7763 / 9V45 / 9V74	120	all clean
Intel Xeon Platinum 8573C	15	all clean

On an affected runner:

	max abs diff
np.dot (2503, 3) x (3, 3)	0.0
(4, 4) x (4, n), n = 4, 16, 64	0.0
(4, 4) x (4, n), n = 256	10.0, 128 of 256 rows
(4, 4) x (4, n), n = 2503	10.0, 2311 of 2503 rows
einsum, which does not use BLAS	0.0
OPENBLAS_NUM_THREADS=1	10.0
OPENBLAS_CORETYPE=HASWELL	0.0
OPENBLAS_CORETYPE=SKYLAKEX	0.0
OPENBLAS_CORETYPE=NEHALEM	0.0
OPENBLAS_CORETYPE=SAPPHIRERAPIDS	10.0

Single threads make no difference, so it is not a race. einsum and the (3, 3) product are exact, so it is that kernel and that shape.

What this changes

The workflow checks that product after installing numpy and scipy, and sets OPENBLAS_CORETYPE=HASWELL only on a runner that fails it, with a warning annotation naming the CPU. Haswell rather than SkylakeX because the setting has to be harmless on the machines it is not aimed at, and the EPYC 7763s that are most of the pool have no AVX-512. Healthy runners keep their own kernels. It cannot be done from inside the session: OpenBLAS reads the variable when it loads.

Confirmed end to end on a batch of forty runners: five were 6973P-C, the guard tripped on exactly those five, and all forty then produced the correct grid.

tests/conftest.py runs the same check at session start and stops with the reason and the command to set, so the same machine under someone's desk costs a sentence rather than an afternoon.

What this does not change

• The test. It was right. The field really was wrong, and widening the tolerance to 4.19 grid cells would have taught it to accept a misshapen robot.
• skrobot or trimesh. Both are correct; the multiply is not. Routing Link.collision_mesh around the matrix product would only make a broken machine look like it was working.
• The Windows job. There is no evidence the affected CPU is in that pool, and an untested cross-platform version of this guard is the riskier change. Worth revisiting if unexplained geometry failures turn up there.

Not reported upstream. The closest existing reports are OpenBLAS #2168, #3454, #5267 and #2769; none names this CPU.