I saw some old posts for Revit Plugin, but not for Rhino Plugin.
It seems that there is no feature of modelling window frames in Rhino Plugin for now. OK, I’m going to add window frames (WindowProperty:FrameAndDivider) in idf files for EnergyPlus, but I’d like to offset aperture surfaces by the width of the window frame in advance in Rhino.
For ASHRAE 90.1, U-factors of the Baseline case already account for frames, so no need to model frames in the Baseline case. The Proposed case should be modelled by either 1) Separated glazing & frames or 2) Aperture only with averaged U-factor of glazing and frame.
For the option 1) avobe, can I offset aperture surfaces in Rhino? For example, if I have an aperture surface with 1m wide and 1m high and I’m going to model frames with 0.05m wide later, I’d like to change the aperture surface to 0.9m wide and 0.9m high (while keeping the center of the aperture).
Any nature Rhino command is fine, but I don’t know it. Offset and Scale are not suitable.
And I often have hundreds or thousands of apertures in one model, so I’d like to offset all the apertures at once.
Make sure to select the Transform objects individually.
NOTE: This command is not compatible with the Pollination Rhino plugin. That means, that you will need to make these changes on the Rhino geometry before adding them to the rooms as apertures.
@mingbo, it might make sense to provide a command to adjust the size of the apertures for window frames.
@mostapha Thank you for your reply. Yeah, BoxEdit is not applicable to multiple objects, and it is suitable for only surfaces along X-axis or Y-axis. I think I need to somehow offset apertures with GH script.
@mostapha I mean, I should not edit multiple aperture surfaces with Transform objects individually because each surface has different size and different coordinates.
I should not use Scale for multiple surfaces as well because I want to offset the same width and height (e.g., 0.05m), not the same scale.
Hi @mingbo, isn’t this value only used when then aperture is outside the parent face? In this case, @keigonomura wants to offset the existing valid apertures.
Hi @mingbo, isn’t this value only used when then aperture is outside the parent face? In this case, @keigonomura wants to offset the existing valid apertures.
Ha @mostapha, you are correct. I think the best way is creating correct geometries either in Rhino or Grasshopper before converting them to apertures.
I generally agree with this statement, but there is no easy solution with the Rhino native commands to achieve this. And using Grasshopper is not for everyone. In addition, I think @keigonomura provides a valid real-world problem that justifies adding a new command to OffsetApertureBoundaries.
I imagine we can use the same logic we use in the OffsetChildObjects command. The difference is that we use the aperture face itself as the reference for offsetting the aperture inwards.
… and make a note that we have full support for WindowProperty:FrameAndDivider in our model schema and core libraries. So it is possible to assign window frames to your pollination models right now. However, we have not finished exposing frames on the Rhino plugin UI so the way that you have to do this right now is a little convoluted.
Essentially, you would have to make the window construction in Grasshopper using the frame_ input of the HB Window Construction component like so:
Then, the next time that you open Rhino, the construction with the window frame will show up in the pollination construction manager and be available to assign to geometry and constructionsets. When this type of construction with a frame is assigned to geometry objects, it will automatically add an EnergyPlus WindowProperty:FrameAndDivider object for each geometry as it is translated to E+.
If this is something you think you might use a lot, perhaps we can bump the exposure of window frames in the Rhbino UI a little higher on our priority list.
Does the frame factor in the construction account for the reduced solar gain that would be expected between a window with say a 25% FF vs no frame applied in the construction?
I’m not sure if your definition of “frame factor” refers to shading from the projection of the frame out past the window or if you mean something else, like the area of the façade elevation that is occupied by frame vs. glass.
However, I can say that the way that the EnergyPlus WindowProperty:FrameAndDivider object works is that EnergyPlus expects the Aperture geometry to always be just for the glass part of the window (without any frame included in this geometry). Then, this frame is assumed to be an offset around this aperture geometry (given the _width of the frame that you specify). Other BEM engines may expect something different for the Aperture geometry but EnergyPlus always expects you to use Aperture geometry for just the glass part.
If, instead, you are asking about the impact of the frame projection on the solar gain through the window, then yes, this is always accounted for as long as you specify an outside_proj_ for the frame that you assign to the window construction.
Ok thats good to know, thanks Chris. As you mention, IES uses the full window dimension (including the frame), the window frame factor % is then inputted into the construction to determine the proportion of this geometry which is actually glazed. I am working with a gem file which has been imported into rhino as a HBSJON so I’ll have to scale the windows about their centroid to account for this. It would be great if there was a command to automatically offsett all apertures by a % area reduction or a frame thickness dimension, similar to the curve offset component in vanilla GH!
That’s good to know that IES expects different window geometry than E+, @milog . It makes me question a little how IES runs the solar calculation if the frames have a projection factor but I also know that E+'s solar calculation is probably more accurate than what is needed for many applications of energy modeling. So maybe it does not end up being all that critical.
In any event, the fact that IES wants different Aperture geometry than E+ probably ups the level of priority for having a Rhino command for PO_OffsetApertureBoundaries. I would wait to hear what Minbgo thinks but this is sounding a little more like a #recommendation than a #suggestion for the Rhino plugin. Also, If this ends up taking us a while to implement in the Rhino plugin, I can probably add a Honeybee Grasshopper component that does this Aperture offsetting pretty quickly so that you have a temporary workaround for it.
Correct, in IES you typically draw the full window geometry and define a frame factor % to indicate the actual glazed portion, you can also input a frame projection factor which is essentially a way of modelling reveal depths as opposed to physical geometric shades.
My only concern with scaling apertures in honeybee’ to account for frame factors is how you would maintain the correct free opening area of windows for natural ventilation? For example if a full window area in IES was 1m2 with a frame/glazing ratio of 20%/80% then the current aperture size in honeybee should technically be 0.8m2, however, modelling the window in this way would then underestimate the free area of the window? Does that make sense? An alternative solution I can think of is to model the full window size in honeybee to match IES, and then model some kind of fixed shade construction to reduce the SHGC by an equivalent amount that the frame would create.
I’m a little worried that we’re heading down a rabbit hole worrying about something that might ultimately not make our simulations more accurate given that both EnergyPlus and IES already assume things like window-opening schedules don’t affect solar gain or conduction (when they do in reality but it’s by a small enough amount that we usually don’t lose sleep over it). Especially because I see you coming around to the notion that a more complicated simulation that tries to account for more factors is not always better, it may be helpful to take a step back and consider that the ventilation opening might not differ that much from a glazed area fraction to make a meaningful difference for the abstracted way that we model airflow through windows in both E+ and IES.
Still, when I add the Grasshopper component that does the aperture frame offsetting, I will write it in a way that it preserves the currently-assigned window operable area, if it exists. So you can rest assured that running this offset before export to IES won’t fundamentally change the inputs you assigned.
And, if I am correctly understanding your concern here:
You just want some way to say that the operable area of a window can sometimes be in between the glazed area and the full window system area with the frame? I guess if you had a casement window that could open all of the way, the operable area might be a little bit larger than the glazed area, even though there has to be some frame that holds the whole system together and so the operable area is less than that of the whole window+frame system.
If this is your concern, why don’t I just allow you to specify aperture operable areas that are greater than 1 so that you can account for these cases however you wish? Would that address your concern here?
Hi Chris, if we are able to apply an operative area > 100% then I think that would solve this issue. As we could model the window as just the glazed part using the window offset approach you mention above, to ensure solar gains are consistent (at least in theory), and the free area is not reduced as a consequence. Here is a graphic to illustrate this idea just to ensure we are on the same page.
I just finished adding a component to LBT Grasshopper that will offset the Apertures according to a specified thickness of your frame:
You can use the component to offset the windows outwards OR inwards, letting you change your E+ window geometries to an IES version or vice versa. The component also has a repair_ option, which can help you fix the cases where the Apertures have been offset so far that the overlap with one another and/or extend past their parent face.
As you can see in the animation, the component tries to preserve the original opening area of the windows as you offset them. Of course, if you use the repair option, the areas might not match exactly because you are removing the parts of the window that overlap or extend past the Face. But the result should be close enough that your results are reasonably accurate.
And to that point, I understand what you are saying about the openable area assumed by E+ vs. IESVE but, if you run simulations with these, I think you will find that:
The change you get in the air flow through the windows by counting all of the frame in the ventilation opening area or not is likely not going to be that significant. I think you will probably see more of a difference in air flow by switching between the AFN and the simpler air flow objects than you will from including/excluding the frame.
Neither the E+ or IESVE methods match reality perfectly. If you look at a real casement window like in the picture below, you can say that maybe some of the overall frame area is part of the operable area but not all of it:
All of this is just to say that you might not want to lose too much sleep over this issue but I understand that you want to simulate it for yourself to be sure. So I’ll make the change so that you can assign a fraction of operable area that is larger than 1 but I’ll need a little more time to do this. I’ll post back here when the change is done.
