Ahhh, I think I understand now. I think I have just never gotten this deep into the weeds with using EnergyPlusâs WindowProperty:FrameAndDivider object.
Am I correct that this WindowProperty:FrameAndDivider is what you are referring to when you say âframesâ and, when you say âthe model will not runâ, you are taking to the following Fatal error that EnergyPlus throws if your glass + frame area exceeds the area of the parent Face?
** Severe ** ProcessSurfaceVertices: Base Surface="FACE_69159444",
** ~~~ ** Window Surface="FACE_69159444_GLZ0" area (with frame) is too large to fit on the surface.
** ~~~ ** Base surface area (-windows and doors)=[0.15] m2, frame area=[1.63] m2.
** Severe ** ProcessSurfaceVertices: Base Surface="FACE_E634D5D4",
** ~~~ ** Window Surface="FACE_E634D5D4_GLZ0" area (with frame) is too large to fit on the surface.
** ~~~ ** Base surface area (-windows and doors)=[0.15] m2, frame area=[1.63] m2.
** ~~~ ** For explicit details on each unused construction, use Output:Diagnostics,DisplayExtraWarnings;
** Fatal ** Errors found in Building Input, Program Stopped
...Summary of Errors that led to program termination:
..... Reference severe error count=2
..... Last severe error=ProcessSurfaceVertices: Base Surface="FACE_E634D5D4",
************* Warning: Node connection errors not checked - most system input has not been read (see previous warning).
************* Fatal error -- final processing. Program exited before simulations began. See previous error messages.
If so, Iâm glad to meet someone using this object in professional practice. I exposed the WindowProperty:FrameAndDivider object in our Pollination schema ~2 years ago but I wasnât sure if I and a few other researchers/hardcore IDFEditor people were the only ones making use if it. More often than not, I get people asking how they can just simplify the window geometry to something that doesnât account for frames at all and then people just want to account for frames in the U-values and SHGC they assign with a WindowMaterial:SimpleGlazingSystem object. But Iâm all for making use of the FrameAndDivider object. Itâs clearly a much more robust way of modeling the windows, though you really need to model the window geometry right in order to make use of its improved accuracy.
I guess I always expected people using this FrameAndDivider object to model the window glass geometry exactly as it is on the real building, which would mean that this would not really be a concern:
The researchers I know doing this right now use the Rhino plugin for this since it gives you the freedom to edit the window geometry to be anything you want. We can certainly implement some Model Editor routines that get you close to this freedom but youâre looking at a steeper learning curve in order to be able to get more freedom to change the window geometry. At a certain point, it may just be easier to learn a little Rhino.
In any event, let me start by just adding a âparent offset distanceâ variable into the Model Editor âRebuild Windowsâ command so this never blocks you from making a simulate-able model with the FrameAndDivider object. I feel like the program you proposed might be changing the window geometry a little too much from the original window glass geometry that youâll lose much of the improved accuracy that the FrameAndDivider object offers over the WindowMaterial:SimpleGlazingSystem approach. For one, the area of center-of-glass to edge-of-glass could get messed up. Iâm not against adding something like it but letâs just make sure that none of the other options we have implemented would work for you first before we do something so custom.
We are almost there!
See step 4.
Let me make sure that I understand this correctly. This might deserve its own separate command.
I sent you a private message. It looks like this is a case that we should debug together over a call and report back here.
