Question-and-Answer Resource for the Building Energy Modeling Community
Get started with the Help page
Ask Your Question

How to efficiently use OpenStudio for parametric analysis?

asked 2024-05-31 10:52:53 -0500

codygillmore's avatar

updated 2024-06-06 08:56:56 -0500

I am struggling on how to use OpenStudio and PAT to analyze energy efficiency measures coming from eQuest.

For example, I want to run a daylighting measure combined with adding skylights to a warehouse building. In eQuest, I can add a "whole building measure" in the wizard, and add the skylights and daylighting controls to the model. In OpenStudio, I believe the only way to run this measure would be to manually add in the skylights as a different model

Another example, I want to run a measure for electrification of gas-fired unit heaters and replace them with electric unit heaters. In equest this is simple to add a measure to replace the fuel type to electricity. In OpenStudio, I would need to make a secondary model with electric unit heaters.

Am I missing something with my assumptions above? I realize that OpenStudio has a lot of advantages in terms of automating analysis, but writing measures in Ruby for all the measures not covered in the BCL seems like a big hurdle. I am hoping I am wrong, because I want to work to move my organization to use OpenStudio instead of eQuest, but I think this may limit my ability to get engineers to adopt it.

edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted

answered 2024-06-03 08:43:39 -0500

@codygillmore, not a definitive answer by any means, so expect alternative view points from others.You seem to be already familiar with the pros/cons of using either OpenStudio measures or straight SDK-based scripts (e.g. Ruby, Python). So I'll jump right in, restricting my 2-cents to adding skylights.

Context matters. If your organization is more R/D-oriented (e.g. lab, think tank), usually working off of a limited number of predefined building stock models/geometry (e.g. 16x US DOE Benchmark/Prototypes), then one of your options ("manually add in the skylights as a different model") is not a bad idea at all, especially if some of the predefined models have non-convex roof surfaces (or even worse, plenums). And in any case, you'd have to make some hard choices at some point, such as:

  • layout (arrays of 4'x4' units vs double-ridged skylight "strips")
  • size (4'x4' vs more industrial 8'x8')
  • near-optimal placement (e.g. away from sidelit areas), and so on.

Once these are established, there is little value in automating such geometry alterations when dealing with a limited set of predefined models, IMHO.

If your organization is instead gravitating towards a more general solution, to possibly apply against (future) 3rd-party (bespoke) model geometry (!), then the above is obviously too cumbersome. Yet automated alterations to bespoke OpenStudio geometry is no walk in the park (think Frank Gehry buildings), regardless if one approaches the challenge from the SDK vs the Measure route. In fact, there can be very little difference between these two approaches ...

A year ago, we added a (fairly general) addSubs method in OSut, dropping in (arrays of) sub-surfaces (including skylights) onto OpenStudio surfaces, without a priori knowledge of the latter's vertices. An UMH overview here + pull-request comments. We recently extended the solution, automating the generation of skylights + wells (through plenums or attics). There is currently a bug when an occupied space (to toplit) doesn't share the same relative space coordinates as its overhead plenum - hoping to release a fix soon. Otherwise, it seems to work for other (tested) cases. You're free to test it out for your needs, but it remains limited to a Ruby SDK-based (development) environment - not (yet?) a measure.

90% of the effort behind those 2 methods boils down to managing bespoke (or even broken) geometry, and dealing with conflicting user inputs. That effort would be the same IMHO, whether putting forth gem methods or corresponding OpenStudio measures. I'd say the only remaining challenge of wrapping up gem methods as OpenStudio measures is designing the measure API (e.g. pull-down lists, check boxes, etc.), and offering some online guide material/training. These are non-negligible efforts.

So when is it better to upgrade gem methods into OpenStudio measures? A few end-use cases come to mind, which I have experienced:

  • an organization explicitly chooses to circumscribe all of its work within an OpenStudio/Measures/PAT sandbox (deliberately setting aside custom scripts)
  • an organization insists on sharing its library ...
edit flag offensive delete link more


So if I am understanding this correctly, eQuest may be a better application for my use-case if my organization is less R&D oriented and are energy engineers consulting with building owners and recommending energy efficiency measures?

I was trying to utilize some of the measures for creating typical buildings, etc in order to expedite the creating of a baseline model, make some refinements to the model, then run measures. But it seems the approach to measure analysis in OpenStudio, requiring scripted measures, has a barrier to entry if you don't have a programming background.

codygillmore's avatar codygillmore  ( 2024-06-03 13:10:55 -0500 )edit

No, not stating that. I'm suggesting that if your organization can't find BCL measures that fit your specific needs (e.g. automatically inserting skylights), then you're left developing your own. In such cases, and per your initial question on efficiency, an organization would typically pick a path: the Measure route, or straight SDK. There's no right/wrong: it boils down to familiarity, preference, organizational targets, etc.

Denis Bourgeois's avatar Denis Bourgeois  ( 2024-06-03 14:54:41 -0500 )edit

I have been using OpenStudio for almost 10 years now. At first just the application, then PAT, then Ruby SDK and lately Python SDK (much more powerful). There is little that cannot be accomplished that way, but it is always daunting to do so under production pressure. I have used eQUEST in the past, and its measure configuration is undeniably neat. BCL does have some goodies for OpenStudio, though they can be hit or miss, and if you get lucky, PAT is OK, too. If you don't care about elegance, flexibility or super-high accuracy, I'd stick with eQUEST when working in a pressure cooker.

mattkoch's avatar mattkoch  ( 2024-06-04 20:38:02 -0500 )edit

This is an incredibly helpful perspective Matt. I think that’s what I was coming to the conclusion of and the big decision maker is working under a pressure cooker. That being said, I want to continue working with OpenStudio and learn more about it and writing measures.

I am also more experienced with Python but found some of the processes for writing measures not super clear but I think that will just take time. Thanks again for your response.

codygillmore's avatar codygillmore  ( 2024-06-04 20:44:07 -0500 )edit

... that said, if you are not with a quick and dirty overnight outfit and do mostly high-quality custom work where the client is tolerant of some extra time, OpenStudio cannot be beat, and I would recommend investing heavily in Ruby or Python - sooner or later you'll need it to implement something the application does not have (yet) or that cannot be found on BCL. Teach a man to fish ...

mattkoch's avatar mattkoch  ( 2024-06-04 20:46:16 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Training Workshops


Question Tools

1 follower


Asked: 2024-05-31 10:52:53 -0500

Seen: 197 times

Last updated: Jun 03