Uncertainty & Sensitivity

Uncertainty in a building model has a few distinct sources, and naming them helps you handle each.

Scenario uncertainty - the future you cannot know: next year's weather versus the typical EPW, how many people will use the building, how they will set the thermostat, whether plug loads grow. Occupancy and operation are the biggest and least predictable of these.

Physical / parameter uncertainty - properties you cannot pin exactly: the as-built conductivity of insulation, real airtightness, thermal bridging, the true SHGC of the glazing after weathering. Manufacturers quote ideal values; buildings deliver scattered ones.

Model-form uncertainty - the simplifications in the model itself: zoning choices, how controls are represented, the fact that no model is the building.

Numerical uncertainty - solver tolerances and timesteps, usually small.

The practical point: some of these you can reduce with better data (measure the airtightness), and some you fundamentally cannot (next year's weather). Good practice is to shrink what you can and quantify what you cannot, rather than hiding all of it behind a single confident number.

It is worth internalising which sources dominate, because effort should follow them. For most buildings the scenario uncertainties - occupancy, plug loads, set-points, operation - swamp the physical ones. Two identical flats can differ by fifty percent in energy use purely because of how the occupants live, and no refinement of the wall build-up will close that. This is liberating rather than discouraging: it tells you that chasing a third-decimal U-value while guessing occupancy from a default schedule is effort spent in the wrong place. The discipline of naming your uncertainty sources, before you model, is what stops you polishing the precise inputs while the imprecise ones quietly decide the answer.

You cannot chase every uncertain input, and you do not need to - because they are not equal. Typically a handful dominate the result and the rest barely register. Sensitivity analysis is how you find the vital few.

The simplest form is one-at-a-time (OAT): hold everything at its baseline, vary one input across its plausible range, record how much the output moves, and repeat for each input. Rank the results and you get a tornado chart - horizontal bars, longest at the top, showing which inputs swing the answer most. OAT is quick and intuitive, but it misses interactions (two inputs that only matter together).

For interactions you use global sensitivity analysis - methods like Morris screening or Sobol indices - which vary many inputs together across the whole space, usually via many model runs (a Monte Carlo sample). These are more work but reveal the true drivers and their couplings.

Either way, the payoff is focus. If the tornado shows cooling set-point and infiltration dominate while wall colour is negligible, you know where to spend measurement effort, where to be conservative, and which 'decisions' are actually irrelevant. Sensitivity analysis tells you what to worry about.

A subtlety worth flagging: sensitivity is local. An input's importance depends on where the baseline sits and on the climate. Infiltration barely matters in a mild climate but dominates in a cold or very hot one; shading depth matters enormously on a west facade and little on a north one. So a tornado chart is a statement about this design in this context, not a universal ranking to memorise. Re-run it when the design or climate changes materially. Used this way, sensitivity analysis is not a one-off report but a running compass that keeps pointing you at the handful of inputs actually steering the result - and away from the many that merely feel important.

Sensitivity tells you which inputs matter; uncertainty analysis tells you how much that leaves your answer unsure. The method is propagation: instead of one value per input, assign each a plausible distribution (airtightness between X and Y, occupancy between so-many people), then sample many combinations - a Monte Carlo run of hundreds or thousands of simulations - and look at the spread of outputs.

What you get is not '87.3' but a distribution: perhaps 'annual cooling energy is very likely between 95 and 140 kWh/m2, most probably around 115.' You report percentiles - a P10-P90 range - rather than a false-precision point. This is honest, and it is genuinely more useful: a client deciding whether to buy a bigger chiller cares far more about the plausible worst case than about one optimistic point estimate.

Crucially, the width of the range comes mostly from the sensitive inputs the tornado identified - which is why the two analyses pair. Reduce uncertainty in a dominant input (measure it) and the whole range narrows. Reporting the range is not admitting the model is weak; it is stating exactly how strong it is.

There is a practical objection - 'a thousand EnergyPlus runs is too slow' - and it is fading fast. Parametric tools (Ladybug in Grasshopper, OpenStudio measures, or a spreadsheet data table for a simple model) automate the sampling, and increasingly a fast surrogate model, trained on a few hundred real runs, approximates the engine in milliseconds so that full Monte Carlo becomes routine. But the method matters more than the machinery: even a coarse propagation with a handful of scenarios (best case, expected, worst case) beats a single point, because it forces you and the client to look at the spread. The habit - never report one number where the honest answer is a range - is the transferable skill; the tooling only makes it cheaper.

The goal of all this is not more analysis for its own sake - it is better decisions when the inputs are guesses. Three habits make decisions robust.

Prefer options that win across the range, not just at the mean. If design A beats B for almost every sampled combination of occupancy and weather, that is a robust choice; if A only wins under one optimistic scenario, it is fragile. This is where simulation's comparative honesty shines - relative rankings survive uncertainty far better than absolute numbers, because many uncertainties push both options the same way and cancel out.

Design in margin where the downside is expensive. If overheating risk is sensitive to occupancy you cannot control, favour a design that stays comfortable even in the hot-and-crowded tail, not one that only works on average.

Report ranges to clients and be explicit about assumptions. 'Between 95 and 140, most likely 115, driven mainly by how the building is operated' builds trust and pre-empts the performance gap. A single confident number invites disappointment later.

Uncertainty is not a flaw in simulation to be hidden - it is information. Handled well, it turns a fragile prediction into a decision you can defend.

This reframes the whole relationship between designer and model. A single number invites a false argument - 'the model says 87, so it will be 87' - that reality is bound to lose, damaging trust in simulation itself. A range with named drivers invites the right conversation - 'the outcome depends most on how you operate the building, so let us design the controls and the commissioning to protect the good end of the range.' The uncertainty becomes a design brief, not an embarrassment. That is the mature posture this course has argued for from the start: simulation is decision-support under uncertainty, and its honesty about what it does not know is precisely what makes what it does know worth acting on.