Vulcan's overheating feature is an engineering preview for selected Pro accounts. Supported Part O and TM59 assessments are not yet available. Selecting Overheating may show a validation message and prevent a run. A successful simulation, a research metric or a screenshot is not evidence that a dwelling complies.
This page describes the implementation and validation status reviewed on 11 November 2026. Preview access and deployed versions can differ from the implementation under test. Existing HEM calculations remain separate.
Using the existing model
The integration uses Build Geometry, Quick Sim, Create Scenarios and View Results. It captures the complete dwelling before HEM combines rooms, retaining geometry, room identities, constructions, openings, systems and the selected weather.
The flow is open a dwelling → choose Overheating in Quick Sim → Run → select a room in Results. The latest tested implementation completes this flow as an explicitly labelled engineering preview on a valid six-room model without authored internal doors. Quick Sim and batch produce identical captured model, generated input, weather and room-temperature series. This is not an assessed result and must not be used for a submission; availability depends on the deployed preview version.
Overheating is protected by the existing Pro entitlement and account preview flag. The run dispatcher checks access for queued jobs, retries and reruns before loading the engine. Losing access does not remove saved results or exports.
Assumed internal doors
An existing model does not need a door-entry exercise. Where a room has one unambiguous shared boundary with a circulation space, the preview can infer one door. Explicit connections and known solid, party or fire restrictions take precedence. It does not put doors between adjacent bedrooms or through every shared wall.
Assumed doors appear dotted on the plan. Select one to use the existing Details controls; edited doors are solid. Delete suppresses that assumption, and undo restores it. Saved overrides travel with the Vulcan CSV. These are overheating assumptions, separate from the dwelling's external doors.
The current research default is 0.762 m wide by 1.981 m high, with a discharge coefficient of 0.6. Closed doors retain a finite transfer path: 0.0076 m², converted to a power-law flow coefficient at 1 Pa using a reference air density of 1.2 kg/m³ and exponent 0.65. This is an engineering approximation, not a measured door leakage curve. The implemented 2017 research schedule closes doors during 23:00–08:00. The editions have separate schedules.
In eight annual engineering tests on a flat and two-storey house, explicitly saving the same door dimensions produced identical temperatures and airflow after CSV reload. Smaller or suppressed doors changed temperatures; finite leakage remained during closed-door hours. These synthetic tests validate the authoring path, while real-building validation of the defaults remains outstanding. Ambiguous layouts retain their known connections and report the limitation. A missing airflow path is not necessarily conservative. Room labels also do not create walls: a drawing with several bedroom labels inside one undivided thermal space cannot establish separate bedroom results.
Methods and weather
The implementation keeps three profiles separate. All currently remain unavailable for supported assessments:
| Profile | Intended use | Current limitation |
|---|---|---|
| England Part O with corrected TM59:2017 | England dynamic thermal assessment | Physical conversion, convergence and independent building validation remain incomplete. |
| Corrected TM59:2017 design | Original design method | Separate opening controls are implemented; supported building scope and method exceptions remain incomplete. |
| TM59:2026 design | Current design practice | Separate gains and criteria, captured Stage 1→2, and a conditional research-only Stage 3 cooling run are implemented in the current code. Cooling controls and natural-ventilation priority are not qualified; whole-method validation remains incomplete. |
Rechecked on 11 November 2026, CIBSE still directs Part O compliance to TM59:2017 and recommends TM59:2026 for current design practice. An England compliance label does not automatically apply elsewhere. CIBSE method status.
You do not need to buy CIBSE files to help test the software. Development uses lawfully available engineering weather. That can test conversion, controls, native/browser agreement and the application, but does not substitute for the weather required by an assessment.
A future supported assessment will use the customer's suitable licensed file through the existing local weather selection. The intended England baseline is the relevant location's 2016-generation DSY1, 2020s, high-emissions, 50th-percentile file. TM59:2026 has a separate 2025-generation DSY1, 2050s, RCP8.5, 50th-percentile requirement. Check the project's scope before purchasing any additional locations or scenarios.
For the 2025 generation, CIBSE advises replacing v1.0 with corrected v1.1, which fixes horizontal infrared radiation data relevant to EnergyPlus. CIBSE weather requirements and corrections.
Vulcan records weather identity and hash. A filename alone does not verify its generation, scenario or licence. Licensed weather is not bundled with Vulcan's public test fixtures, and HEM's default weather is not silently substituted for an overheating assessment.
What has been tested
The implementation uses a source-built EnergyPlus 26.1 browser worker. Engine source, build settings, patches, loader, schema and asset hashes are recorded. Changes for the browser build do not alter the EnergyPlus physical algorithms. The browser build is still subject to Vulcan's own validation; upstream engine capability alone does not validate the conversion.
| Check | Evidence and limit |
|---|---|
| Method arithmetic | Automated tests cover corrected gains, separate occupied/sleep/opening masks, time boundaries, denominators, equality, rounding, missing series and individual failing rooms. Hand-calculated references check criteria separately. This is not external assessor review. |
| Native/browser comparison | With matching pinned mathematical functions, current annual three-room 2017, 2026 Stage 1 and six-room fixtures produce byte-identical CSVs. An independently repeated native recipe confirms the 2017 case. This does not establish building accuracy or timestep convergence. |
| Timestep convergence | A current 64 m² Part O fixture differs by up to 0.156919°C in hourly room air temperature between 30 and 60 steps/hour, exceeding the declared 0.1°C engineering screen. Matching criterion counts do not waive this failure. |
| Additional flat convergence | A separate five-room, 64 m² Bedford-weather fixture passes the same 30→60-step screen: maximum hourly air difference 0.061555°C and operative difference 0.034287°C. Coarser timesteps fail. This does not resolve the separate failing case or qualify a universal timestep. |
| 2026 opening constraints | A captured Stage 2 cap produces identical native/browser values across 52,560 timestep rows. Security/guarding evidence in the fixture is synthetic. The near-zero leakage sweep did not establish a stable substitute for the method’s zero-infiltration condition. |
| Physical components | Native and browser probes exercise thermal constructions, solar shading, airflow, window controls and door schedules. Whole-dwelling conversion and validation remain incomplete. |
| Application integration | A six-room engineered fixture ran through the actual guarded dispatcher and worker; its unassessed record was written and read through File System Access and opened in Results. That test does not exercise the assessment service or produce assessment metrics. The sixteen-case browser suite also covers access denial, door editing/CSV, cancellation and recovery; assessment-view tests deliberately use synthetic records. No case establishes a supported assessment journey. |
| Queue and resources | One active worker and at most four waiting jobs are tested. Running and queued cancellation, failure recovery and repeated output are checked. Sampled browser-process memory is not a measurement of private peak memory. |
| Independent building reference | Public measured-temperature data has been imported with its gaps and timestamps retained. A reproducible, independently reviewed dwelling assessment has not yet been completed. |
Native/browser comparison tolerances were declared before reviewing output: temperatures 0.00001°C + 0.00001 × abs(native value); other numeric channels 0.0000001 + 0.00001 × abs(native value). The matched-maths comparisons above agree exactly. Earlier native builds using the host mathematical library differed under active airflow feedback; those failures are retained in the development evidence.
In one three-zone annual engineering fixture, warm browser simulation took about 5.4–5.7 seconds, with 57–179 ms worker initialization and 4–4.5 ms output processing. These observations used an Apple M5 Pro, 24 GiB RAM, macOS (Darwin 25.5.0) and Chrome 156, a six-step-per-hour model and public RAF Bedford weather. They are fixture measurements, not a performance promise or a cold-download benchmark. Larger models and finer timesteps require separate measurement.
A reproducible engineering pair also retains real HEM and EnergyPlus runs from the same five-room source CSV, defaults and public weather. HEM combines it into one thermal zone; EnergyPlus retains five. Gains and controls also differ. The paired data records those differences and must not be treated as a matched-input benchmark or measured ground truth.
Interpreting results and evidence
Room tables, traces, breach markers, night views, heatmaps and reports use a shared evaluator. A failing applicable room affects the dwelling result. The room overlay assigns one metric to each thermal room; it does not show a calculated temperature gradient within the room.
The preview reuses the room table, plan overlay and existing chart controls. Select a room to see operative, air and outdoor temperatures over its hottest seven-day period or the full year. Optional aligned details show retained openings, airflow and gains. The table reports peak hourly mean operative temperature and explicitly says Not assessed, without breach colours or a compliance verdict.
A run record retains model/scenario identity, snapshot and weather hashes, generated input, engine/build and method versions, time settings, assumptions, diagnostics and timings. Exports include available input, metrics, time series and solver logs. Missing, failed, cancelled and not-assessed results remain distinguishable. Research results cannot supply a compliance verdict.
Part O evidence also needs the modelling report and applicable compliance checklist. Calculated evidence does not replace the designer's declaration, mitigation justification or building-control review. Government guidance on the report and checklist.
Before supported assessment release
Release requires verified conversion on representative flats and houses, representative door/airflow and timestep checks, the remaining method exceptions, an independently checked building reference, and a complete supported Quick Sim and batch journey with matching reports and exports. TM59:2026 additionally needs validation of its captured stage chain, natural-ventilation priority and cooling controls, a source-faithful zero-infiltration representation, and independent qualification of applicable cooling results.
The preview flag does not waive those checks. Until they are complete, use the preview for feedback on authoring and diagnostic behaviour, and use an established assessment process for project submissions.