Fan curve is captured from a single centreline anemometer reading, which over-estimates the duct average

Raised while implementing the m/s->CFM conversion (2026-09-10). The wizard instructs ‘hold the anemometer at the duct centreline’, and ms_to_cfm multiplies that single velocity by the full cross-section. In developed turbulent duct flow the centreline runs faster than the cross-sectional average — conventionally around 0.8x for a smooth round duct — so every curve captured this way reads high by roughly 20-25%. Deliberately NOT compensated in the conversion fix: inventing a profile factor is a judgement about this specific rig’s duct runs, and a silent 0.8 multiplier is exactly the kind of unexplained fudge this codebase keeps having to dig out. The geometric conversion is exact and defensible; the approximation is in the sampling method, not the maths. The sampling step now says so in plain text (‘centreline runs faster than the duct average, so a single-point reading is an over-estimate; treat the curve as a good approximation, not a traverse’). Options if it matters later: (a) a proper log-Tchebycheff or equal-area traverse (several points per duty, averaged) — accurate but much slower with live fans held; (b) a named, operator-visible profile factor defaulting to 1.0; (c) leave as-is and treat curves as relative-shape data, which is most of their value for the fan model anyway. Note the systematic bias is CONSISTENT across duty steps, so the curve’s SHAPE (what the airflow model mostly uses) is unaffected — only the absolute magnitude is high.