# OpenStudio wraps EnergyPlus and Radiance in one building modelling toolkit > OpenStudio is a cross-platform C++ toolkit for whole building energy modelling with EnergyPlus and advanced daylight analysis with Radiance, and it ships an SDK with entry points for C++, Ruby, Python and C#. The code is a large CMake and Conan project built on a develop branch, and on macOS even the install is a step-by-step exercise because development builds are not notarised by Apple. **NatLabRockies/OpenStudio** — OpenStudio is a cross-platform collection of software tools to support whole building energy modeling using EnergyPlus and advanced daylight analysis using Radiance. - Repository: https://github.com/NatLabRockies/OpenStudio - Website: https://www.openstudio.net/ - Stars: 651 · Forks: 238 - Language: C++ - License: NOASSERTION - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/natlabrockies-openstudio ## Two simulation engines behind one modelling front end OpenStudio is a cross-platform collection of software tools, for Windows, Mac and Linux, that supports whole building energy modelling using EnergyPlus and advanced daylight analysis using Radiance. The project describes itself as open source with the explicit aim of facilitating community development, extension and private sector adoption. The pair of engines matters, because they answer different questions. EnergyPlus is the thermal and energy simulation engine, so OpenStudio is where the description of a building, its systems and its schedules is assembled and handed to that analysis. Radiance is the daylight and lighting analysis engine, so the same geometry can be pushed through a second, quite different kind of calculation to evaluate light levels and daylighting. The audience is stated in the README: building researchers and software developers who want to get started quickly. The project site is openstudio.net, and user support goes through a community moderated question and answer resource, unmethours.com, which is the usual shape of a research-adjacent tool that has a commercial user base without a commercial support desk. The primary language is C++, and the licence is a custom one that GitHub cannot classify, with the terms in a LICENSE.md file. The last push was on 2026-10-15, and the default branch is develop rather than a release branch, which is the first thing to know about the state of the code. ## Four ways in: C++, Ruby, Python and C# The OpenStudio SDK is the part of the project that other software depends on, and the README describes it as allowing building researchers and software developers to quickly get started through multiple entry levels, with access through C++, Ruby, Python and C#. That is a deliberate design decision for a simulation tool. The people doing the analysis are often not the people writing the C++ that maintains the geometry and the model objects, and they are not the people writing the reporting layer either. A building energy model is a large, structured document, and the practical question is how a script, a spreadsheet macro, a report generator or a web service gets at it. Four language surfaces mean the model can be driven from the language a team already uses. It also means the SDK boundary is the contract, and the SDK is a versioned artefact separate from the tools, which is what allows the bindings to move at their own pace. The repository layout supports that structure. There are directories for python/, ruby/ and csharp/ alongside the C++ in src/, and an embedded/ directory for the model embedding layer, with developer/ and dependencies/ directories for the build and the third party stack. For a team choosing this project, the question of which SDK entry point you will drive is a decision to make early, not late. ## A CMake and Conan project built by Jenkins The repository is a large C++ project and it shows in the tooling. The build is CMake based, with a top level CMakeLists.txt, a CMake/ directory of modules, template files such as OpenStudio.hxx.in, OpenStudioCoreConfig.cmake.in and ProjectMacros.cmake, and CTestConfig.cmake for the test harness. Dependencies are handled with Conan, with a conanfile.py and a committed conan.lock, which is how a project of this size keeps a large native dependency tree reproducible across three platforms. Continuous integration is visible in the file names. There are Jenkinsfile_develop_ubuntu_2404, Jenkinsfile_develop_osx, Jenkinsfile_develop_windows and a separate Jenkinsfile_develop_code_coverage, plus a ci/ directory, so each operating system and the coverage job are configured independently. The code quality tooling is part of the tree as well. There is a .clang-format file, a .clang-tidy configuration, a Doxyfile.in for generated documentation, an OpenStudio.DotSettings file for IDE settings, and a .git-blame-ignore-revs file, which is a detail worth noticing. That last file exists so that a large formatting-only commit can be excluded from blame, which tells you the project has been through the kind of repository-wide reformatting that otherwise poisons the history of every line. There is also a debian/ directory for distribution packaging and an install.qs script for the installer, which is what produces the macOS installer that the installation notes talk about. ## macOS development builds need a manual Gatekeeper override The installation notes in the README cover one platform, and they are unusually detailed, which tells you where the friction is. For development builds, meaning the artefacts downloaded from GitHub Actions, you may hit a Damaged error or an Unidentified Developer warning on macOS, especially on Apple Silicon machines, and the reason given is that these builds are not notarised by Apple. The documented workaround is a fixed sequence. You mount the downloaded .dmg file in Finder and open it by right-clicking or Control-clicking it. Inside the mounted disk image you do the same to the OpenStudio-Installer.app file and launch it. A security warning dialog appears, and you click Open if it is available, or OK if that is the only choice, in which case the installer might close. Then you open System Settings or System Preferences, go to Privacy and Security, find the note that the OpenStudio application was blocked, and click the Open Anyway button. A final confirmation dialog appears, you click Open, and you enter your system password when prompted to authorise the installation. The reason to know this is that it applies to the development builds specifically, and the steps are about trusting an unsigned artefact, not about fixing an installation error. Anyone distributing OpenStudio to end users on macOS has a notarisation problem to solve on their own account. ## An alpha release and a develop branch as the default The release history tells you where the project is in its cycle. The most recent tagged versions are v4.0.0-alpha from 2026-09-01, v3.11.0 from 2026-01-15 and v3.11.0-rc3 from 2026-01-08. So the current major line is at an alpha stage, roughly eight months after the last feature release, and the repository's default branch is develop, which is where the 4.0 line is being assembled. The distinction between the release candidates and the final release in January is a normal pattern, a feature freeze, a release candidate, then the release itself. The alpha tag in September is a different kind of marker, and it is the one to pay attention to, because it suggests the 4.0 line is still moving. For an adopter, the practical split is between users and contributors. A user can take the 3.11.0 release, which is a finished artefact, and work against that. A contributor works on develop and accepts that the API may still change, and the SDK bindings move with it. The custom licence is the other thing to settle early. The licence is recorded as one that GitHub cannot classify, and the terms live in LICENSE.md, alongside a copyright.txt in the repository. A project that invites private sector adoption and community extension is exactly the kind of project where the licence terms are worth reading before you build on the SDK, and where the difference between a permissive grant and a contract-style one matters for a commercial deployment. ## Where the documentation runs out The documentation available for this project is thin in a way that matters, and it is worth being explicit about the gaps rather than writing around them. The README covers what OpenStudio is, who it is for, the SDK entry levels, where the website and the support forum are, and the macOS installation workaround. It does not give installation instructions for Windows or Linux, it does not link a getting started guide, and it does not describe the SDK API surface. The repository holds a BUILDING.md and a CONTRIBUTING.md, and a doc/ directory, but their contents are not reproduced here, so the build and contribution workflows have to be read from the repository rather than summarised. That is the honest position for anyone writing a build tutorial for this project: the source of truth is BUILDING.md and the two Jenkins pipeline definitions, not the README. The other limitation is inherent to the tool rather than to its documentation. OpenStudio is a large native code base with a heavy dependency tree, it is built per platform, and its development artefacts are not signed. A team that wants a signed, one-click install of a released build is looking at a different distribution channel than the one this repository documents. On the positive side, the SDK with four language entry points, the separation between the modelling tools and the programmatic interface, and the fact that both EnergyPlus and Radiance are behind one interface are real reasons to consider the project for building simulation work. ## Conclusion OpenStudio suits a building simulation team that needs EnergyPlus and Radiance behind one workflow and wants to script it in Python, Ruby or C#, and it is the wrong choice for a project that needs a stable released binary today, since the newest tagged version is an alpha build and the repository tracks a develop branch. Before committing, read BUILDING.md for the build path on your platform, and on macOS expect to clear the Gatekeeper warning by hand because development artefacts are not notarised. ## FAQ ### What is OpenStudio used for? OpenStudio is a cross-platform collection of tools for whole building energy modelling using EnergyPlus and advanced daylight analysis using Radiance. It is an open source project intended to support community development, extension and private sector adoption. ### Which programming languages can I use with the OpenStudio SDK? The SDK provides multiple entry levels, with access through C++, Ruby, Python and C#, so a model can be driven from whichever language a team already uses. ### Why does the macOS installer of OpenStudio show a Damaged or Unidentified Developer warning? Development builds downloaded from GitHub Actions are not notarised by Apple, so macOS blocks them. The documented workaround is to open the mounted .dmg and the OpenStudio-Installer.app by right-clicking, then use the Open Anyway button in Privacy and Security in System Settings. ### How is the OpenStudio project built and tested? The build is CMake based with dependencies managed by Conan through a conanfile.py and a conan.lock, and CTest provides the test configuration. Continuous integration is defined per platform in Jenkinsfile_develop_ubuntu_2404, Jenkinsfile_develop_osx and Jenkinsfile_develop_windows, with a separate code coverage pipeline. ### What licence does OpenStudio use? The repository carries a custom licence that GitHub cannot classify, with the terms in the LICENSE.md file and a copyright.txt alongside it, so the terms have to be read there rather than inferred from a standard licence identifier. ## Sources - [Issues](https://github.com/NatLabRockies/OpenStudio/issues) - [NatLabRockies/OpenStudio on GitHub](https://github.com/NatLabRockies/OpenStudio) - [Project website](https://www.openstudio.net/) - [README](https://github.com/NatLabRockies/OpenStudio/blob/develop/README.md) - [Releases](https://github.com/NatLabRockies/OpenStudio/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/natlabrockies-openstudio