Question-and-Answer Resource for the Building Energy Modeling Community
 | 1 | initial version |
The question was asked quite a few years ago, and the solutions/suggestions put forth at the time remain suitable IMO for most cases. Similar methods have since made their way into other OpenStudio SDK derivatives. The question remains relevant today (and somewhat open-ended), as expressed here. To cover as many bases as possible including modelling of existing fenestration (where for instance WWR ribbons aren't necessarily good matches), the latest release of the OSut Ruby gem offers a new addSubs method, which allow users to:
Somewhere, there's a window/door/skylight schedule as part of the original architectural plans, a sort of dictionary describing a (limited) number of sub surface types and heights/widths. One may no longer have access to the original document, but there would have been one. With that in hand (or something similar), one may rely on the method to distribute scheduled fenestration as observed, e.g.: Surface X has a front entrance, comprised of:
Dimensions and left/right/top/bottom positioning can obviously be reused (shared widths, shared sill heights), see similar example here. Once that collection of one-liner instructions is set, it can be reapplied multiple times in the same project (or recovered for future projects) ... without ever having to determine base/sub vertices.
The method can be applied to slanted/rotated and/or irregular base surfaces. As the number of options and possible combinations is somewhat significant, an illustrated user guide (or a GitHub gist) with examples might be warranted - the commented/illustrated PR will have to do for the moment.
Future enhancements (some planned) include generating related structures, e.g. an added virtual opening (or an array of openings) auto-generating one or more skylight wells and/or roof monitors (or even dormers). These are more ambitious, as they involve adding/modifying space surfaces. For the moment, addSubs is offered as a Ruby module method, not as a measure (or multiple measures). That may eventually happen, but it is not obvious how to package all available options as a single set of measure inputs. I typically use the method in a series of base surface loops (e.g. add French doors to all north/south-facing walls of housing units in a model, and so on).
If anyone comes across any bugs (or has suggestions), I'm certainly keen on making the method as robust as possible and expanding functionality (within reason). Merci!
