Energy Modelling Software Types

Energy modelling software falls into families, and the families differ in what they calculate and how much detail they need. Compliance tools implement an official method, such as SAP in the UK, and produce a rating or a pass-or-fail result against a standard. Steady-state tools estimate annual demand from average conditions and a simplified building description. Dynamic simulation tools track heat flows step by step through a year, responding to changing weather, sun and occupancy. Retrofit appraisal tools sit alongside these, comparing measures by cost and modelled benefit.

None of these families is best in general; each is best for a particular question. A compliance tool is the right choice when the question is whether a home meets a standard, because only the official method counts for that purpose. A dynamic tool is the right choice when the question involves overheating risk, complex shading or a heating system whose behaviour changes through the day. Using a dynamic tool for a simple compliance check, or a compliance tool for an overheating study, wastes effort or misses the point.

Compliance tools are constrained by design. Their inputs, defaults and calculation rules are fixed by the method, so two competent users should reach similar results from the same survey. That repeatability is valuable for certificates and regulation, but it also means the tool cannot easily represent an unusual construction or an innovative system that the method does not cover. Where a home is unusual, the modeller should say so and explain how the method handles the unusual feature, rather than forcing it silently into a standard category.

Steady-state tools are faster and need less data, which makes them useful for early options screening: comparing insulation, glazing and heating options before detailed design. Dynamic tools need detailed geometry, schedules and weather data, and they reward that effort with hourly results, such as peak loads and overheating hours. Their accuracy, however, depends heavily on input quality, and a detailed tool fed with guessed inputs can produce confident-looking results that are no better than a simpler tool fed with good inputs.

Before commissioning modelling, write the question in one sentence: is this a compliance check, an options comparison, a design sizing exercise, or an overheating investigation. Then ask the modeller which tool family fits that question, what inputs it needs from you, and what its outputs will and will not show. If the proposed tool cannot answer your sentence, it is the wrong tool however sophisticated it sounds.

Also ask about accreditation and version. Compliance software in regulated contexts is usually approved or listed for the method it implements, and using an unapproved variant can invalidate a result for official purposes. For non-regulated analysis, ask how the tool has been validated and whether its results have been checked against measured data or another tool on a similar building.

Software availability and accreditation differ by place, because methods differ by place. In the UK, SAP software is tied to the SAP method and to assessor accreditation routes, while in EU member states, national software implements national methods under the EPBD framework. A tool that is approved in one country is not automatically valid in another, and a modeller working across borders should confirm which national tool and method applies to the building in question.

For a general reader, the practical point is simpler: do not compare outputs from different tool families as if they were the same result. A steady-state annual demand figure and a dynamic simulation peak load are different quantities, and a compliance rating is a standardised score, not a simulation output. Keep the tool family attached to every number you quote.

A frequent mistake is to buy detail that the decision does not need. A full dynamic simulation for a straightforward insulation choice adds cost and delay without changing the answer, and its extra outputs can distract from the simple comparison that matters. The opposite mistake is to use a simple tool for a complex question, such as sizing a heat pump for a home with large glazed areas, where hourly behaviour matters and a steady average hides the peaks.

Another mistake is to judge software by its graphics. A polished 3D visualisation does not prove that the underlying calculation is right, and a plain spreadsheet implementing an approved method may be more trustworthy than a visually impressive tool with undocumented assumptions. Ask about method, inputs and validation, not about rendering quality.

Keep the software name, version and method with the model report, so a later reviewer can reproduce or challenge the result. When a modeller proposes a different tool for a follow-up study, ask them to explain the change in terms of the question, not in terms of novelty.

Questions to ask include: what question does this tool answer, what inputs does it need that we do not yet have, and how will we know if its result is wrong. Those questions keep software choice subordinate to the decision, where it belongs.