Energy Modeling Software: Compare Building Scenarios on a Clear Basis

Energy modeling software estimates how a building uses energy under defined conditions. It combines geometry, fabric, weather, occupancy, schedules, and system assumptions to simulate performance. Its value is comparing choices on a clear basis, rather than promising an exact future bill.

This article explains the modeling workflow, engine and interface choices, input controls, scenario comparison, and result review. It includes a worked envelope comparison and a pilot plan. Qualified staff still need to select suitable methods and confirm the requirements for the project.

Start with the question the model must answer

An early design comparison may need a different model from an investigation of an existing building. Define the decision, required outputs, available evidence, and review process first.

For example, a design team may compare envelope options while holding other assumptions constant. A facilities team may instead examine schedules using measured consumption and known building information.

Distinguish energy use from cost, carbon, comfort, and peak demand. These measures need different inputs. A reduction in one does not establish an identical result in another.

The official EnergyPlus overview describes a whole-building simulation engine. It illustrates the analysis layer. The project also needs a practical way to prepare and review its inputs.

Understand the engine, interface, and workflow

The engine performs calculations. An interface helps users create geometry, enter inputs, run cases, and inspect results. Other tools can automate repeated tasks around the engine.

Compare these layers separately. Products using the same engine can provide different input, review, and reporting experiences.

The national laboratory’s building energy modeling overview describes EnergyPlus and OpenStudio as related tools with distinct roles. An engine name alone does not define the complete workflow.

Record engine versions and important settings with each run. Updates may affect inputs or results, so preserve a reproducible record rather than only the latest model.

Build geometry for the intended analysis

A detailed architectural model does not automatically provide a suitable energy model. Analysis needs appropriate spaces, thermal zones, surfaces, openings, and relationships.

Thermal zones group areas according to the analysis approach. They are not always identical to rooms. The modeler should explain the zoning basis and simplifications.

Check imported geometry for missing surfaces, gaps, duplicated areas, and incorrect relationships. An attractive model can still contain analytical errors.

Anomoz’s guide to BIM software explains broader model workflows. Control the handover without assuming that direct export removes review work.

Keep fabric and weather assumptions visible

Record the source for construction properties, glazing, shading, and other inputs. Distinguish confirmed product data from early assumptions.

Record the weather file, location, time basis, and intended use. A typical-year file and measured weather for a specific period serve different purposes.

Also check units during import. A plausible number in the wrong unit may not trigger an obvious software error. Independently inspect key inputs before running many scenarios.

When an assumption changes, preserve the earlier version and reason. A later report should explain which basis produced its comparison.

Give schedules the attention they deserve

Schedules influence when people, lighting, equipment, and systems affect the model. Use evidence and assumptions that suit the question rather than leaving every default untouched.

A weekday office pattern may not represent regular evening use. Show the chosen pattern and its source.

Separate design assumptions from observed operation. If actual records inform an update, label that change and identify which cases use it.

Test holidays and special periods. Copying one weekly pattern across the year can hide important differences. Keep the treatment consistent in directly compared scenarios.

Represent systems at the right level

The model needs a system representation appropriate to the study. Early work may use simplified assumptions, while later studies need specific equipment and control detail.

A familiar equipment name does not establish the correct configuration. Review connected components, capacities, schedules, and controls.

Distinguish idealized loads from modeled system energy. They answer different questions. Make that basis clear in the report.

For revision practices, Anomoz’s article on document revision control provides context. The analytical model still needs its own technical review.

Compare scenarios through controlled changes

Each case should identify its baseline, purpose, changes, software version, and outputs. Preserve a shared basis for factors intended to stay constant.

If the question concerns glazing, changing occupancy and system schedules at the same time creates a broader comparison. Explain it rather than attributing the difference solely to glazing.

Keep a scenario register with concise descriptions. It is more useful than files named “final,” “new,” and “final again.”

Anomoz’s guide to project document management explains source and revision practices. Apply them to input sets, runs, and issued reports.

Review warnings and plausibility

A completed simulation is not automatically credible. Inspect warnings, input consistency, unexpected end uses, and checks appropriate to the project.

Compare results with evidence and independent expectations. Investigate unusual outputs rather than changing inputs solely to make charts look reasonable.

Document review limits. A model may support relative comparisons while leaving uncertainty about absolute consumption. State that distinction.

When measured data is available, align periods, weather, units, and scope before interpreting a difference. A close total is not the only useful test.

Align measured consumption with model scope

Define what a bill or meter covers. A site bill may include loads outside the modeled building. A submeter may cover only one system.

Record the period, unit, boundary, and known gaps. A difference can reflect unmatched boundaries rather than a model defect.

Next, inspect weather and operating conditions. A typical-year model and a particular year’s bill do not necessarily share the same basis. The modeler should define the comparison method.

Keep measured and modeled values distinct in charts. Label sources and periods. A blended series can make simulation look like observation.

For a pilot, select a documented period with complete meter records. Ask a reviewer to identify included loads and exclusions, then trace corresponding outputs to the relevant run.

If a meter interval is missing, preserve the gap and document any approved treatment. An estimate should not later appear as original measured data.

Finally, state what the comparison supports. A reviewed model may suit design exploration without providing an exact operational prediction. Ask vendors to show how their tools preserve these boundaries.

A worked example: two envelope options

Consider a building study comparing two envelope choices. The team defines the decision and outputs, then builds a reviewed baseline with a recorded weather file and schedule set.

First, create a named scenario from that baseline. Change only the intended properties and record their sources. Run both cases on the same software basis.

Review warnings before calculating differences. If the team discovers a geometry error, correct it through a revision and rerun the affected comparison.

Inspect more than the annual total. The decision may need selected peak, comfort, or end-use outputs. Use measures the study actually supports.

Finally, issue a report with inputs, changes, results, and limits. A second qualified user should identify and repeat the comparison without guessing which files belong together.

Keep cost and carbon assumptions separate

An energy result may feed a cost or carbon calculation. Those calculations need their own factors, periods, and sources.

A tariff can include more than a single price per unit. A carbon comparison depends on the chosen factor and time basis. The responsible team should confirm the method.

Do not present a modeled percentage as a guaranteed saving. Actual use can change with weather, occupancy, controls, and other conditions.

Show assumptions that affect the ranking of alternatives. A small difference may not justify a strong conclusion when important uncertainty remains.

Evaluate the complete modeling workflow

Give candidates the same building and question. Include geometry updates, schedule changes, and one controlled comparison.

1. Confirm the analysis and accepted outputs.
2. Prepare geometry, weather, fabric, and schedules.
3. Review the baseline and important warnings.
4. Run an alternative and compare results.
5. Export a reproducible review package.

Measure preparation, correction, run management, and reporting effort. Ask a second reviewer to inspect assumptions. A fast engine may not save time if checking remains difficult.

Compare licenses, computing, training, support, and integration. Open-source engines can reduce license costs while still requiring skilled setup.

Test archives and exits. Preserve the model, sources, relevant files, software basis, and report references needed later.

Make model defaults easy to audit

Defaults help users start work, but they can become hidden assumptions. Ask the tool to distinguish values entered by the project team from inherited library or template values.

For example, a copied building template may carry schedules or system settings from a different use. The reviewer needs a practical way to find them.

Next, change one default in a controlled test and inspect which cases it affects. A library update should not alter an issued comparison without the team’s knowledge.

Keep the original basis with historical runs. Current templates and old outputs may legitimately differ, but the record should explain why.

This also improves handovers between modelers. A new author should identify important assumptions without asking the original author to reconstruct months of decisions.

Keep model review separate from option approval

A technically reviewed simulation and a business decision are separate milestones. The model review checks whether the case and outputs support the intended analysis. Option approval may also consider cost, constructability, maintenance, or other project factors outside the simulation.

Record both decisions clearly. A scenario marked reviewed should not automatically appear as the selected design. Likewise, a preferred business option should not cause the team to hide limitations in the model that informed it.

Next, test a change after option selection. Suppose the team receives updated product data for the preferred envelope. Preserve the earlier input and decision, then identify which runs and comparisons need review. Do not silently replace the original evidence beneath an issued recommendation.

Also define ownership for external factors. Finance may approve a cost basis while the modeling team owns energy outputs. Keeping these roles explicit reduces the chance that an unreviewed spreadsheet factor becomes part of a headline performance claim.

Prepare a compact review package

Include the study question, source register, baseline, changes, important diagnostics, selected outputs, and limitations. The package should make the comparison understandable without forcing the reviewer to inspect every raw output file before finding the main basis.

Then ask a second qualified user to trace one reported result to its run. If they cannot identify the weather file, schedule set, and engine basis, improve the package. The problem may lie in record organization rather than the simulation itself.

Finally, archive the accepted package alongside the live project. Later work can use new information without erasing what the team knew when it made the earlier decision. This supports clearer project learning and more dependable future comparisons.

Choose a model your team can explain

Useful energy modeling software supports clear inputs, controlled cases, and reviewable results. Start with a defined decision and pilot. Choose the workflow that makes assumptions and changes easiest to inspect.