01OpenStudio Today

Two schemas and two ways to represent a building model

OpenStudio exposes a typed Model API backed by OpenStudio.idd. The Forward Translator converts that model to an EnergyPlus IDF.

E+

Simulation engine

EnergyPlus

schema → text

Input schema Energy+.idd

858 object types

Objects, fields, units, choices, defaults, and references

defines

Input model

.idf text

Building,
  Example Office,
  0.0,         !- North Axis
  Suburbs;     !- Terrain

The text file is the simulation payload.

OS

Modeling platform

OpenStudio

schema → objects

Model schema OpenStudio.idd

563 object types

A similar—but independently designed—set of model records

backs

Primary interface

Model API

model = OpenStudio::Model::Model.new
building = model.getBuilding

Typed classes, object relationships, and Model helper methods

.osm text persists the model

Work here OpenStudio Model

Forward Translator

Generate EnergyPlus IDF

Run EnergyPlus

The Forward Translator converts the OpenStudio Model to EnergyPlus IDF.

02The project goal

Make the OpenStudio Model work directly on EnergyPlus IDF

Resolve differences in object names, fields, relationships, and behavior while keeping the OpenStudio Model API.

Preserve

OS

The familiar interface

OpenStudio Model API

Keep the interface that applications, measures, and users already know.

Typed objects Relationships Model helper methods

Resolve differences

Schema differences

Implement OpenStudio Model behavior on EnergyPlus IDF objects.

Names & fields Corresponding objects Object relationships

Use directly

E+

The model saved as IDF

EnergyPlus IDD + IDF

Load, edit, and save EnergyPlus IDF directly instead of maintaining a second OpenStudio schema.

Energy+.idd defines the schema IDF text stores the model Load · edit · save directly

Keep the OpenStudio modeling experience. Make EnergyPlus IDF the model underneath it.

03The easy case

The easy case: the Model class and IDD object line up

Original OpenStudio has a CurveQuadratic class with scalar methods named after the EnergyPlus fields.

EnergyPlus IDF

Curve:Quadratic

IDD type

Curve:Quadratic,
  Capacity Modifier,  !- Name
  0.8,                !- Coefficient1 Constant
  0.2,                !- Coefficient2 x
  0.0,                !- Coefficient3 x**2
  0.0,                !- Minimum Value of x
  1.0;                !- Maximum Value of x

near 1:1

OpenStudio Model · Ruby

CurveQuadratic

Model class

curve = OpenStudio::Model::CurveQuadratic.new(model)
curve.setName("Capacity Modifier")
curve.setCoefficient1Constant(0.8)
curve.setCoefficient2x(0.2)
curve.setCoefficient3xPOW2(0.0)
curve.setMinimumValueofx(0.0)
curve.setMaximumValueofx(1.0)

Even here

OpenStudio still maintains its own schema, its own Model objects, and the translation code that writes EnergyPlus IDF.

04Small differences appear

Mostly parallel—but the names no longer match exactly

The object still maps cleanly, but type and field names are no longer identical.

EnergyPlus IDF

Coil:Heating:Fuel

IDD type

Coil:Heating:Fuel,
  Main Heating Coil,          !- Name
  Always On Discrete,         !- Availability Schedule Name
  NaturalGas,                 !- Fuel Type
  0.85,                       !- Burner Efficiency
  10000,                      !- Nominal Capacity
  Heating Coil Inlet Node,    !- Air Inlet Node Name
  Heating Coil Outlet Node,   !- Air Outlet Node Name
  ,                           !- Temperature Setpoint Node Name
  50,                         !- On Cycle Parasitic Electric Load
  ,                           !- Part Load Fraction Correlation Curve Name
  100;                        !- Off Cycle Parasitic Fuel Load

same idea

OpenStudio Model · Ruby

CoilHeatingGas

Model class

coil = OpenStudio::Model::CoilHeatingGas.new(model)
coil.setName("Main Heating Coil")
coil.setFuelType("NaturalGas")
coil.setGasBurnerEfficiency(0.85)
coil.setNominalCapacity(10000)
coil.setOnCycleParasiticElectricLoad(50)
coil.setOffCycleParasiticGasLoad(100)

?

Where are the node setters? The simple field mapping ends here.

Gas ↔ Fuel GasBurnerEfficiency ↔ Burner Efficiency GasLoad ↔ Fuel Load

The scalar fields still map. The node fields hint at something structurally different.

05The first structural divergence

Nodes: objects in OpenStudio, shared names in EnergyPlus

OpenStudio connects equipment through a Node object. EnergyPlus repeats “Fan Outlet Node” in the adjoining equipment fields.

E+

EnergyPlus IDF

Shared node names

Fan:ConstantVolume

Air Outlet Node Name "Fan Outlet Node"

same name

Coil:Heating:Fuel

Air Inlet Node Name "Fan Outlet Node"

Aa

Same text means the same node.
No Node object exists in the IDF.

OS

OpenStudio Model

Node and Connection objects

Equipment Fan

OS:Connection

Model object Node Fan Outlet Node

inout

OS:Connection

Equipment Coil

The OpenStudio Node named “Fan Outlet Node” is a Model object connected to the fan and coil. In the IDF, “Fan Outlet Node” is simply repeated in the two equipment fields.

06A second structural divergence

OpenStudio groups default schedules; EnergyPlus assigns each one directly

SpaceType and DefaultScheduleSet are OpenStudio Model objects. EnergyPlus has Space, but not SpaceType or DefaultScheduleSet; each load names its schedule directly.

OS

OpenStudio Model

Assign the defaults once

OpenStudio SpaceType Office

setDefaultScheduleSet

OS:DefaultScheduleSet Office Defaults

PeopleOccupancy Schedule

LightsLighting Schedule

EquipmentEquipment Schedule

space_type.setDefaultScheduleSet(office_defaults)

E+

EnergyPlus IDF

Write each schedule explicitly

PeopleSchedule NameOccupancy Schedule

LightsSchedule NameLighting Schedule

ElectricEquipmentSchedule NameEquipment Schedule

No DefaultScheduleSet object
The schedule assignments remain, but the set does not.

The Forward Translator resolves the defaults. When epmodel opens the IDF, the schedule assignments remain, but the original set is gone. DefaultConstructionSet has a similar issue.

07How we reconcile the schemas

Resolve each difference without changing the Model API

For each difference, we adapt epmodel, propose a change to EnergyPlus, or do both. Existing Measures must continue to run.

Always Keep the public OpenStudio Model API The Measure ecosystem keeps working

01

Adapt epmodel

Implement OpenStudio behavior with EnergyPlus objects

Example · Nodes Keep Node objects in the Model API

Node methods work as before, while epmodel reads and writes EnergyPlus node names, Branches, and related HVAC objects.

+either or both

02

Evolve EnergyPlus

Propose a change to the EnergyPlus schema

Example · Defaults Add default schedule sets

Represent the reusable schedule group directly in IDF instead of expanding it into separate load assignments.

For each difference Choose the clearest implementation in epmodel, EnergyPlus, or both. Then verify existing Model methods and Measures.

08The scale of the effort

Repeating this across the EnergyPlus IDD is a massive task

There are 858 input object types. Each one must be compared with the OpenStudio Model API, implemented, available to Measures, and tested.

EnergyPlus 25.2 858 input object types

Each type can bring fields, references, defaults, behavior, bindings, and tests.

Aa

Fields and defaults

Names, types, defaults, autosizing, validation

↔

Object relationships

References, ownership, lists, inheritance

◇

Model behavior

Constructors, helper methods, HVAC connections, removal

✓

Measures and files

Ruby bindings, IDF load and save, focused tests

hundreds of object types×fields and relationships×Model behavior and tests=a massive implementation effort

09Coding agents are integral

Coding agents changed how we can take on this work

We started by asking for one change at a time. We now give agents larger, testable assignments and let them work through the IDD in a controlled loop.

01

Started here

One request at a time

A person chose the next object, supplied the background, watched the work, and reviewed each result.

“Implement this type.”

02

Our custom program loop

Keep the work moving

The program records progress, selects the next object, calls an implementation agent, runs reviews, and returns for fixes.

Plan→Implement→Review↺

03

Increasingly possible today

Larger assignments

Agents can increasingly plan, implement, test, and correct their work across an object family—or a much larger assignment.

“Do this across all 800+ types.”

Coding agents are essential to delivering epmodel. Their ability to manage long tasks is improving quickly.

10Where we are today

An OpenStudio Measure can already transform an IDF directly

The checked-in example starts with a reference-building IDF, replaces its HVAC systems with familiar Model methods, and produces a simulation-ready IDF.

01 · Load

IDF

Existing model

RefBldgSmallOffice
New2004_Chicago.idf

The OSW names an .idf seed—not an OSM.

02 · Modify

Standard ModelMeasure pattern

air_loops = model.getAirLoopHVACs()
air_loops.each { |loop| loop.remove() }

air_loop = OpenStudio::EPModel::AirLoopHVAC.new(model)
air_loop.addBranchForZone(zone, terminal)

The Measure uses familiar Model methods to build the new air and plant loops.

03 · Run

✓

Modified IDF

model-measures.idf

EnergyPlus completed successfully.

5 → 1air loops

5zones reattached

2new plant loops

0Measure errors

Boiler hot water + air-cooled chiller + multizone VAV

11The next milestone

Alpha by the end of the fiscal year

Target · fall 2026 ALPHA

A usable epmodel release for early evaluation and feedback.

QR code for the live epmodel presentation

Open the presentationdev-8080.kbenne.net PDF Download the slides

12Bonus

Could one agent prompt generate this entire deck?

Plausibly. It would look something like this:

Agent promptOne shot

Working in this OpenStudio repository, first read the epmodel documentation and inspect the relevant source, IDD files, and checked-in workflow examples.

Build a polished, self-contained 16:9 HTML/CSS/JS presentation for OpenStudio modelers. Explain today's two-schema setup and the goal of making the Model API work directly on EnergyPlus IDF while preserving existing Model APIs and Measures. Keep OpenStudio on the left and EnergyPlus on the right.

Use repository-backed examples to progress from CurveQuadratic, to CoilHeatingGas versus Coil:Heating:Fuel, to Nodes and Connections, to SpaceType and DefaultScheduleSet. Explain the case-by-case reconciliation strategy, the scale across the IDD, why coding agents are integral, the working IDF Measure workflow, and the fall alpha target.

Use concise human language, familiar OpenStudio vocabulary, large projection-safe type, fullscreen keyboard navigation, a QR code, and a linked PDF. Serve it on port 8080. Render every slide and fix any crowding, clipping, small text, or unsupported claims before calling it done.

Plausible today. The important parts are repository access, a concrete brief, and a careful review of the rendered result.