Which run was the one we reported?
The architect changes the glazing ratio, the client upgrades the heat pump specification, and the facade engineer revises the U-values. Each change means another energy model run for the compliance calculation or the operational energy estimate. After a month there are a dozen versions of the model file, named things like 'run7_new_glazing_v2'. The design team asks which result is current, and what assumptions sit behind it.
The engineer who ran them knows, mostly. If they are on holiday, or have left, nobody else does.
Why runs lose their context
- Model files record the inputs, but only in the modelling software, which few people can open.
- Run naming is informal and differs between engineers.
- The drawings or information each run was based on are not recorded.
- Results are copied into reports and emails, detached from the run that produced them.
- Nobody compares runs systematically to see what changed the result.
Handover is another weak point. When a project passes from one engineer to another, or when the modelling is done by a specialist and the results used by the design team, the context behind each run rarely travels with the file.
What the confusion costs
| Gap | Consequence |
|---|---|
| Wrong run reported | Design team works to an outdated result |
| Inputs unknown | Cannot explain why a result changed |
| Knowledge with one engineer | Project stalls when they are away |
| Runs repeated to rebuild context | Engineer time and fee consumed |
Energy results increasingly drive design decisions and client commitments, so knowing exactly what each number rests on matters.
The risk grows as projects go on. Early runs are exploratory and nobody minds if they are loose. Later runs support compliance submissions and statements to the client, and by then the habits formed in the early stages, informal names, no input record, have become the way the project works.
How we build a run log
- Each time an engineer completes a run, a short form records the purpose, the model file, the drawing revisions it was based on and the key inputs such as fabric values, systems and assumptions.
- Where the modelling software can export inputs and results as reports or data files, we read them automatically instead of retyping.
- Runs are numbered consistently per project, and the current reported run is clearly marked.
- Any two runs can be compared, showing which inputs changed and how the key outputs moved.
- An assumptions summary for the current run is produced in plain language for the design team and client.
- Result files and reports are stored against each run, so a figure in a report can be traced to its source.
- When an architectural drawing is revised, runs based on the old revision are flagged as possibly outdated.
We start by looking at how your engineers name and store runs today and which exports your modelling tools produce. The form is kept short on purpose. A few key fields filled every time are more useful than a long form filled once and then abandoned.
How the team works with a log
Anyone in the practice can see which run is current and what it assumes, without opening the modelling software. When the client asks why the result moved, the comparison answers it.
If the engineer who ran the model is away, the next engineer picks up from a clear record.
Is this your modelling today?
- Model files are named informally and multiply quickly.
- It is hard to say which run was last reported.
- Explaining a changed result means reopening model files.
- Only one engineer knows the history.
- Drawing changes do not trigger a review of runs.