Revision history [back]

@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 of developed measures to a wider public, e.g. private-sector modellers, (... doesn't work so well with scripts)

Inversely, I'd suggest the following as justification for a purely SDK-gem based approach:

• expediency (once accustomed, far quicker to write up a script/fix than to develop a measure)
• mutability (annually upgrading some of the input data, like costing?)
• robustness/reproducibility (deployment of a custom, organization-specific scripted QAQC approach, where one systematically tests the crap out of new proposed changes ... think of utilities, policy makers).

My 2-cents. Hope this helps.