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

OpenStudio: Create window with nothing but offset from floor and offset from ceiling?

My windows are basically from 1' off the floor until 3' from the ceiling and span the surface width of the surface.

The existing method is setWindowToWallRatio (double wwr, double desiredHeightOffset, bool heightOffsetFromFloor): it doesn't accept TWO offsets, and you must specify a window to wall ratio, and this window to wall ratio MUST not be too large to fit on the surface after the offset is done (and offset from floor of 1 meter and a wwr of 0.99 will not work).

So, using a (bad) while loop decrementing the wwr until the setWindowToWallRatio returns an initialized window, I can quickly put a window on my wall that will take the largest admissible wwr given an offset from the floor OR from the ceiling, but not BOTH.

Is there a method similar to surface.setWindowToWallRatio(double desiredHeightOffsetFromFloor, double desiredHeightOffsetFromCeiling) somewhere?

edit retag close merge delete

Apparently not. And it doesn't look like you can synthesize that behavior from other methods either. I would create a feature request on the uservoice site.

( 2016-01-20 06:37:41 -0500 )edit
1

Couldn't you do this with math and surface vertices? Like, get the min/max z-values of the surface vertices, increase/decrease them by your offset distance, and create a new subsurface with the new set of vertices. You'd have to figure out how to do a slight offset of the vertical edges (so you don't break up the base surface), but I think that's done in the WWR user script, so there's probably code there that could help.

( 2016-01-20 09:20:22 -0500 )edit

I'm sure you can do that. I've done similar stuff to resize existing windows around the centroid, it's a fun exercise that makes you refresh trigonometry and 3D geometry, but that requires time I don't have for now =)

( 2016-01-20 10:13:10 -0500 )edit

I agree it's fun to dust off those old math skills. But yeah, Dan's is the more elegant (and faster) solution.

( 2016-01-20 10:19:10 -0500 )edit

And how would you know wall height and rectangularity (rectangularness? rectanguaritude?) without looking at the vertices? I was trying to stay away from that kind of stuff. Given that most of the code already exists in the SDK, the full monty should probably go in there too.

( 2016-01-20 12:03:35 -0500 )edit

Sort by ยป oldest newest most voted

Assuming you know the wall height you can do something like this:

ft_to_m = 0.3048
wall_height = 10*ft_to_m # or whatever it is
window_height = (wall_height-1-3)*ft_to_m # subtract floor and ceiling offsets
wall_area = wall.grossArea
wall_width = wall_area/wall_height
window_area = wall_width*window_height
wwr = window_area/wall_area


Then you can pass that window to wall ratio into the setWWR methods.

more

If you don't know the height there is some code in the C++ that tries to find it but you also need to check that your walls are rectangular.

( 2016-01-20 09:24:35 -0500 )edit

That's not a bad idea at all.

( 2016-01-20 10:10:14 -0500 )edit

And why not use OpenStudio::convert(10,"ft","m").get. I dug that up not so long ago, can't remember where. I used to bother to create OpenStudio::Quantity objects and do the conversion... no more!

( 2016-01-20 10:11:33 -0500 )edit

FYI the documentation on OpenStudio.convert is here. Super helpful, but kind of buried.

( 2016-01-20 12:04:27 -0500 )edit

You may want to look at discrete window user script for SketchUp Plugin that Mohammad Heidarinejad made, it has window width and height, and number of window as arguments, along with offset. It looked very cool but I haven't had a chance to test it out. Looks like while there is wwr argument it currently uses the number of windows vs. the wwr.

more

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:

• add a single window/door (or an array of similar windows/doors)
• add a skylight, a 1D (or 2D) array of similar skylights, a (larger) skylight strip, etc.
• do something similar for (glazed) exposed floors
• keep existing (or previously added) sub surfaces (a first come first serve basis)
• ensure Frame&Dividers don't generate conflicts with base and/or siblings

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:

• 1x (centred) door
• 2x sidelights
• 3x transoms

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!

more