Fifteen case studies run the engine against published feasibility studies, measured network data, published scheme design parameters and national benchmark surveys. Where the engine and the reference disagreed, the difference was either explained or fixed in the product. Both outcomes are on this page, including the cases where the tool was wrong.
Every benchmark below is a permanent test file in the codebase, so each result is reproducible rather than a one-off claim.
Test count as at 10 August 2026: 1,177 passing, 5 skipped, 0 failures, 87 files.
Most heat network software asks to be trusted on the strength of a feature list. That is not a reasonable ask of anyone signing their name to a feasibility study. So the engine is run against work that has already been published and peer-reviewed by the market, and the comparison is put here whichever way it goes.
References are real: a consultant's issued pipe schedule, a measured Swiss network, three years of Danish smart meter data, a BEIS survey of seven operating UK networks. No self-generated test case counts as validation.
Each case is a permanent vitest file, not a screenshot in a PDF. If a future change breaks a benchmark, the test suite fails before the claim on this page becomes false.
Every engineering figure in the product carries a tier: a quoted standards clause, a named source, a labelled rule of thumb, or a placeholder. A rule of thumb is never presented as a standards clause.
Sixteen findings came out of this programme, most of them defects in our own engine. Eleven are fixed. The rest are listed below with their current status.
Scale runs from a 19-building scheme with a published pipe-by-pipe schedule up to 9,622 real building footprints across 402 km of routed main, and out to standalone district cooling, true 4-pipe heating-and-cooling, and the DESNZ zoning appraisal run building by building at London density.
| # | Case study | Scale | What is validated | Result |
|---|---|---|---|---|
| 01 | Basingstoke NHH Arup, 2019, published feasibility |
19 buildings 5.8 MW · 1,969 m |
Pipe sizing, installed cost, auto-routing | Agrees 39 of 41 segments within one DN, 33 exact, against the issued schedule. The two that differ are Arup's deliberately future-proofed DN200 spine, running at 0.3 m/s at design load because it is sized for town-centre expansion rather than present demand, which no demand-driven algorithm should reproduce. Network capex within 0.3%. Auto-routed mains within 13% of the as-built route. |
| 02 | Verbier, Switzerland OpenDHN, Zenodo, measured |
150 substations 681 pipes · 12 km |
EN 13941 heat loss against a measured energy balance | Agrees Engine 254 to 277 kW against 317.6 kW measured, or 7.1 to 7.7% of generation against 8.85% measured. Flow 21.5 l/s computed against 22.8 kg/s measured, roughly 3% on a temperature-basis difference. |
| 03 | Aalborg, Denmark 3,021 smart meters, measured |
3,021 dwellings 3 years hourly |
Domestic demand profiles and diversity | Agrees Measured diversity plateaus at 0.49. The CIBSE CP1 and Varme Ståbi default of 0.62 is confirmed conservative-safe rather than accurate, which is the useful finding. |
| 04 | BEIS UK survey 7 operating UK networks |
Population study | Heat loss per metre, cost norms, CP1 limits | Agrees Engine sits at the as-new edge of the measured band, which is the correct place for design-stage physics with no ageing or joint losses modelled. |
| 05 | Basingstoke techno-economics Arup, 2019, Table 3.9.1 |
10 financial scenarios | NPV and IRR discounting mathematics | Agrees NPV exact on all ten scenarios to a £1 tolerance. IRR within 0.55 percentage points at 40 years once the cash-flow ramp-up is accounted for. |
| 06 | South Basingstoke city-scale Real OpenStreetMap footprints |
4,090 buildings 7,660 pipes · 157 km |
Auto-routing and sizing at city scale | Found defects Routing 1.3 s, analysis 0.1 s, 0 of 4,090 unreachable. Exposed the findBestDN null-fallback affecting 54% of all pipes, and materials-only capex. Both fixed and re-verified. |
| 07 | Mijnwater Heerlen Netherlands, operating 5GDHC |
20,000 m² cluster real ambient loop |
Cooling energy balance and dominant-season sizing | Found a defect Recovers 1,000 MWh/yr of cooling into heating, net +800 MWh/yr on the mine store, COP inside the measured SCOP 3 to 5 band. Surfaced that the engine sized on the heating peak even when reporting cooling as dominant. Fixed. |
| 08 | Southampton DES UK, operating since 1986 |
11 km mains 40 GWh/yr |
Linear heat density against the UK's longest-running multi-source network | Challenges the reference A scheme that has operated for 40 years sits at 3.6 MWh/m/yr, below the BEIS bulk-scheme band of 5.9 to 18.3. That band is a bulk-scheme norm, not a viability floor, and should not be used as a screening cut-off. |
| 09 | Nottingham Enviroenergy Eastcroft EfW-CHP |
68 km mains 150 GWh/yr |
Gas counterfactual and EfW-CHP carbon factor | Agrees The tool's counterfactual matches Nottingham's own published gas comparator to within 1%. Also confirmed that a generic waste heat recovery factor of 5 gCO₂e/kWh is not a valid stand-in for EfW-CHP and understates it by more than tenfold. |
| 10 | GIS import at city scale Real OSM footprints |
9,622 footprints 3.12 Mm² floor area |
Property mapping, centroid and area derivation, demand fallbacks | Found defects Found that 95.8% of buildings imported at zero annual demand and 100% at zero peak, so every pipe sized at 0 kW. Both fixed. Mapping now completes in about 50 ms and yields 296 GWh/yr at 94.8 kWh/m²/yr. |
| 11 | Basingstoke mega-scale Real OSM, engine ceiling test |
9,622 buildings 18,147 pipes · 402 km · 195.6 MW |
The full import, route, size and cost workflow at 2.35x case study 6 | Found the ceiling Engine holds: 0 unreachable, routing 2.7 s, analysis 0.53 s. Found the real ceiling, a DN300 catalogue limit that sized a 94.5 MW trunk at 16.1 m/s and 355 bar. Catalogue extended to DN1200; now 0 over-capacity pipes at 2.94 m/s and 31 bar. |
| 12 | King's Cross district cooling Published scheme design basis |
12.5 MW cooling 9 MW chiller plant |
Standalone chilled-water sizing and electric-chiller plant energy | Agrees on design basis Sizing and plant match King's Cross's published design parameters. What is not published is stated plainly: annual cooling energy and plant electricity are a labelled illustrative reconstruction, not metered figures. |
| 13 | King's Cross full DHC Operating 4-pipe estate |
Heating + cooling one shared trench |
4-pipe DHC sizing over a shared topology and the shared-trench synergy | Agrees on design basis Sizes heating and cooling over one shared trench and quantifies the synergy that defines a true DHC scheme. The cooling side is validated against published plant; the heating-side annual energy is illustrative. |
| 14 | Zone-boundary refinement DESNZ zoning method |
Worked example per-building appraisal |
Per-building linear heat density and the network-vs-individual-ASHP zoning appraisal | Method validated The per-building appraisal, exclusion prune and resize-on-apply reproduce the DESNZ zoning method on the HMT Green Book basis. The building demands are an illustrative worked example, not a published scheme. |
| 15 | City-scale zoning, London density Real OSM footprints |
1,000 buildings 53 km · 2.4 km² |
The DESNZ zoning appraisal end to end through the real router and sizing | Performance and plausibility Runs the full building-by-building zoning appraisal over 1,000 buildings in about 30 ms, at a plausible 2.67 MWh/m/yr. In the same class as case study 6: a scale and performance test, not an accuracy claim. |
Chips reflect the comparison outcome, not a marketing grade. "Found defects" means the case study did its job.
Sixteen findings came out of this programme. Eleven are fixed and merged, one is in progress, three remain open and one turned out to be a real working limit rather than a defect. The four below are the ones that would have changed an answer given to a client.
What happened. Where no catalogue size satisfied both the velocity window and the pressure-gradient floor, findBestDN fell back to DN50 without saying so. On a real 7,660-pipe city network that hit 4,145 pipes, including a 23.4 MW main forced to DN50, which produced a computed pump head of 25 GPa.
Why it survived. Every smaller test network had a valid solution for every pipe, so the fallback path was never taken. Only real city-scale geometry reached it.
Fixed and merged Graceful degradation via findBestDNDetailed, which reports the mode it had to use. Pump head on the same network dropped to 5,044 kPa and the null-fallback count to zero.
What happened. Default pipe rates were materials-only, roughly 8x below installed cost. Any capex figure the tool produced was a lower bound presented as an estimate.
Why it matters. This is the number a business case turns on, and being wrong in the optimistic direction is the worst way to be wrong.
Fixed and merged A pipe supply and civils split calibrated against the Arup schedule to within 0.3%. Case study 6's capex moved from a £35.5m materials-only lower bound to £341m on the same network.
What happened. The non-domestic TM46 benchmark returned nothing for domestic buildings, and nothing derived a missing peak from an annual figure. Importing 9,622 real footprints gave 95.8% zero annual demand and 100% zero peak, so the engine sized every pipe at 0 kW.
Why it survived. The DECC per-dwelling archetype benchmarks that exist to fill exactly this gap were wired into the case-study scripts but never into the import path a user actually uses.
Fixed Domestic now falls back to the DECC archetype, reading built form, age band and dwelling count from the file where present and recording the assumption on the node so it is visible and editable rather than silent.
What happened. Two case-study generators wrote kWh/yr into a field defined as MWh/yr. The shipped project files claimed 19.6 TWh and 79.4 TWh of annual heat.
Why it survived. Each generator's own summary divided by 1000 a second time, so the results stayed internally consistent. The summary was right while the file a user would actually load was 1000x out. No pinned-number test would have caught it.
Fixed Generators corrected, both project files regenerated, and every shipped project is now guarded dimensionally: annual and peak must imply a physically possible full-load-equivalent hours figure.
HeatNet Designer is a feasibility and concept design platform, aimed at roughly RIBA stages 0 to 3. That boundary is deliberate. These are the limits worth knowing before you rely on an output.
Every hydraulic result is a snapshot at a design condition. There is no transient thermal propagation and no dynamic control response. Surge is a discrete Joukowsky check, not a full transient solve.
Bill of quantities unit rates are largely placeholders, labelled as such in the product. Pump and civils rates in particular are not sourced pricing. Substitute your own rates before relying on a cost output. Directionally useful, not tender-grade.
A Hardy-Cross solver balances looped topologies and closes all seven real loops in Verbier's genuine two-plant mesh. On a mesh that complex it does not tighten below its 1e-6 m³/s tolerance within its 100-iteration budget. That is a convergence-tightness limit on large real meshes, not an inability to represent them.
The optimiser assumes the controller knows the whole year in advance. This is the standard feasibility-stage assumption and the same one energyPRO makes, but it brackets the value of a thermal store from above. A real controller on a day-ahead forecast captures most, not all, of the modelled saving.
The EN 15632 plastic flexible twin-pipe physics is verified, but the catalogue numbers are representative placeholders pending certified manufacturer data. The EN 253 steel catalogue, DN20 to DN1200, uses real product dimensions.
Velocity, both TS1 distribution heat-loss checks and pump redundancy cite a clause. The other five are HeatNet design defaults, labelled as such in the product. CIBSE CP1:2020 contains no Pa/m pressure-gradient limit, no matter how many tools imply one.
Benchmarks, carbon factors, the cost library and the standards set are UK-centric. Currency is denomination-only and never converts values.
Domestic hot water diversity uses a 1/√N simultaneous-use proxy, not the fixture-unit method of BS EN 806-3.
Demands, temperatures and pipe geometry come from the reference document or dataset, not from our own assumptions. Nothing is tuned to make the comparison flattering.
The same code path a user gets. In-app reports are generated by the software's own Report tab print pipeline with no manual editing.
Not a headline total. Case study 1 compares all 41 individual pipe segments against the issued schedule; case study 5 compares all ten financial scenarios.
Each difference is either explained as an assumption rather than a physics error, or fixed in the product. Both outcomes are recorded, including the sixteen findings above.
Each benchmark becomes a vitest file in the suite, so a future change that breaks the result fails the build rather than quietly invalidating this page.
The fastest way to judge this is to run something you have already designed and see whether the engine agrees with you. Open the designer and load one of the validated case studies, or send a scheme and we will run it and send the output back.
Free to try, sign in with your email. Up to 500 buildings and 2 saved projects; enterprise and city-scale on request.