EnergyPlus & OpenStudio Workflow

EnergyPlus is a solver, not a design program. Given a fully-specified model - geometry, materials, loads, schedules, HVAC - and a weather file, it computes the heat balance for every zone at every timestep and writes out energy, loads and comfort results. It has no drawing canvas and no friendly menus; its input is the IDF file, a long structured text description of the building. You can read an IDF, and it is worth peeking at one once to see there is no magic, but you would not author a real building that way.

So you use an interface. OpenStudio (from NREL) is a free platform - an application and an SDK - that gives EnergyPlus a modern model, a geometry link (often via SketchUp or Rhino), and a measures system for automation. Ladybug Tools - specifically Honeybee - wraps EnergyPlus inside Grasshopper, so parametric Rhino geometry flows straight into an energy model, which is superb for early, iterative studies. Commercial fronts like DesignBuilder and IES-VE offer polished, all-in-one workflows. All of them ultimately write an IDF (or equivalent) and call the same engine. The EPW weather file feeds the run. Understanding this split means you always know where a problem lives: a weird result is usually your inputs in the interface, not a bug in the engine.

Almost every energy model, in any tool, follows the same sequence. 1. Geometry: build or import the zoned volumes and their surfaces (from lesson 4.2 - this is where your zoning decisions land). 2. Constructions: assign materials and assemblies to walls, roof, floor and glazing, which sets their U-values and the glazing's solar properties. 3. Loads: define the internal gains - people density, lighting power density, equipment - per zone. 4. Schedules: say when those loads and the systems operate, hour by hour and day by day (occupancy, lighting, setpoints) - schedules are as influential as any physical input and a top cause of wrong results.

5. HVAC: choose a system type and its setpoints and efficiencies (from a simple 'ideal loads' system for early load studies to a detailed plant for design). 6. Run: hand the assembled model plus the EPW to EnergyPlus and let it solve. 7. Read: open the outputs and interpret them. The crucial insight is that this is a loop, not a line: you build the model once, then iterate steps 3-7 - change one input, re-run, compare - to answer design questions. The single run is trivial; the disciplined comparison of runs is the actual work, and the reason early, fast models beat late, heavy ones.

Because the steps are the same everywhere, the workflow is what transfers when you change tools or firms - not the menus. Someone who understands that constructions set U-values, that schedules decide when loads act, and that the run is just the engine solving the balance can pick up an unfamiliar interface quickly, because they know what each panel must be asking for. The tool is a dialect; the seven-step workflow is the language.

It is tempting to obsess over physical inputs - the exact U-value, the precise glazing - but the inputs that most often swing results are the operational ones: schedules, setpoints and load densities. A model where the lights and AC are assumed on 24/7 will predict wildly more energy than one with realistic occupancy hours; a cooling setpoint of 22 C versus 26 C changes the cooling load dramatically (and 26 C with fans is both comfortable and code-friendly in much of India). These are assumptions, and honest modelling means making them visible and sensible.

This is the practical face of the performance gap from lesson 0.1: real buildings deviate from modelled assumptions mostly through operation - how people actually use and run the space - not through physics. So two habits matter. First, use realistic, documented schedules and setpoints, and lean on standard templates (ECBC/ASHRAE occupancy profiles) rather than guessing. Second, run a quick sensitivity check: change one uncertain input across a plausible range and see how much the answer moves. If EUI barely budges, you need not chase that input; if it swings, that is where to spend effort getting the assumption right. This is what separates a defensible model from a plausible-looking one.

A finished run produces a lot: an HTML summary report (in OpenStudio/EnergyPlus) with annual energy by end use, EUI, unmet comfort hours and peak loads; and detailed CSV time-series you can chart hour by hour. Start with the summary. Check the EUI and its end-use split first - does the balance look sane for the climate (cooling-heavy in India)? Then check unmet hours: if the HVAC failed to hold the setpoint for many hours, your system is undersized or your schedules are off, and the energy number is not yet trustworthy. Then read the peak loads and the load breakdown (lesson 4.3) to see where the demand comes from.

Read everything comparatively and skeptically. A single absolute EUI is an estimate with error bars; the difference between two runs under the same assumptions is far more robust, which is why you always model a baseline and options. Sanity-check against benchmarks and against your own hand-reasoning from the heat balance - if the model says a heavily-shaded, low-load office is heating-dominated in Chennai, something is wrong, not revealed. And remember the boundary: compliance and certification are judged by the accredited authority against the code's own rules (ECBC, Eco Niwas Samhita, GRIHA), and MEP plant sizing belongs to the engineer. The model is decision-support - powerful, free, and only as honest as the assumptions you fed it.

A single run is a data point; a study is a set of runs designed to answer a question, and that is what practice actually delivers. The backbone of most studies is a baseline - a defensible reference design - against which you test options one variable at a time: baseline versus deeper shading, baseline versus better glazing, baseline versus a higher setpoint. Because every option shares the baseline's assumptions, the difference between them is robust even where the absolute numbers carry error, which is the whole reason simulation is trusted for decisions.

Good studies are disciplined in three ways. First, change one thing at a time so you can attribute the effect - change five inputs at once and you cannot say which one moved the result. Second, document assumptions and versions: which EPW, which schedules, which tool version, so the study is reproducible and a reviewer can trust it. Third, quantify uncertainty where it matters - a quick sensitivity sweep on the inputs you are least sure of tells you whether your conclusion is solid or fragile. This is also how you keep honest about scope: the study supports a design decision and prepares evidence, but statutory ECBC/Eco Niwas Samhita compliance is signed off by the accredited authority against the code's own baseline, and plant sizing is the MEP engineer's responsibility. A well-built study says clearly what it does and does not prove - and that honesty is what makes an energy model worth commissioning.

One more discipline separates a study that ages well from one that does not: keep the model and its results together and version them like drawings. Note the tool and engine version, the weather file, and the date, and archive the baseline alongside each option so a reviewer - or your future self - can re-run and reproduce the numbers. Energy models are living documents that get revisited as a design evolves, and an undocumented run whose assumptions nobody remembers is worth very little, however sophisticated it looked on the day.