Model Software Accuracy

Software accuracy has two parts that are often confused: whether the software correctly implements its method, and whether the method itself represents reality well. A tool can implement SAP or another method flawlessly while still producing a result that differs from measured use, because the method standardises occupancy and simplifies physics. Conversely, a tool with a sophisticated physics engine can produce a wrong result if it implements its method incorrectly or if its inputs are poor. Judging accuracy therefore means asking about both implementation and method, not merely about the software's reputation.

Validation is how implementation accuracy is tested. Developers and schemes test software against reference cases with known outputs, against other tools on the same building, and, where possible, against measured data from real buildings. Accredited compliance software is typically tested against method reference cases before approval, and that approval is a meaningful signal for compliance purposes. For non-regulated tools, validation evidence may be published as test reports or may be available on request, and its absence should be noted rather than assumed away.

Inter-model comparison is a practical accuracy check that clients can request. Running the same building, with the same inputs, through two tools that implement the same method should give similar results; large differences indicate an implementation or input interpretation problem in one tool. Running the same building through tools that implement different methods will give different results, and those differences reflect method choices, not necessarily errors. The comparison is informative only when the method is held constant.

Input sensitivity limits what software accuracy can deliver. Even perfectly implemented software produces uncertain results from uncertain inputs, and a tool that reports many decimal places does not reduce input uncertainty. Accuracy claims should therefore be read as claims about calculation, not about the building: a tool can calculate precisely from imprecise inputs, and the result will still be imprecise in the sense that matters for decisions.

Before trusting a software result, ask which method and version the software implements, whether it is approved or accredited for that method where approval applies, and how it has been validated. Ask for the input schedule and the calculation summary, so that the result can be checked independently of the software's presentation. If the software cannot export inputs or a summary, its result is harder to verify, and that opacity should count against it.

Also ask about version control. Software updates can change results, particularly where methods are revised, and a result produced under an older version may not be reproducible under a newer one. Recording software name, version and method with the model report allows later reviewers to reproduce or explain differences, rather than debating a number without its provenance.

By place, software approval follows the method. UK SAP software is tied to the SAP method and assessor arrangements, while EU national software implements national methods under the EPBD framework. A tool approved in one country is not automatically valid in another, and a modeller working across borders should confirm which national tool and method applies. For advisory modelling outside regulated purposes, approval matters less, but method transparency matters just as much.

User skill is a further accuracy factor. The same software in skilled and unskilled hands produces different results, because input interpretation, default choices and detailing decisions differ. Training, experience and quality checks by the modeller therefore matter as much as the tool, and a client should judge the modeller and the software together, not the software alone.

A common mistake is to judge software by its graphics or its speed. A polished visualisation does not prove correct implementation, and a fast calculation does not prove a good method. Another mistake is to treat a software result as accurate because it is precise: many decimal places are a formatting choice, not an accuracy claim.

A further mistake is to compare tools that implement different methods and to declare one wrong. Different methods answer different questions, and their results should differ. The correct comparison holds method constant, or explains method differences explicitly.

Keep the software name, version, method and validation note with the model report. That provenance lets future reviewers judge the result on its method and implementation, not on its appearance.

Questions to ask include: what method and version does this software implement, how has it been validated, and can its inputs be exported and checked. Those questions test software accuracy properly.