Window on IntWall

[GoogleCodeExporter]

What SDD Object:Property(s) are relevant to this issue?
IntWall
Win

Explanation of addition, revision, or clarification:
Currently, Windows are only a valid child of ExtWall, where as, Doors are valid 
children of both ExtWall and IntWall.  The Standards include the following 
definition for Demising Partitions:

DEMISING PARTITION is a wall, fenestration, floor, or ceiling that separates 
conditioned space from enclosed unconditioned space. 

I believe that Windows should be added as a valid child of IntWall.  There are 
standards requirements for demising wall insulation... Haven't done enough 
research to know what the fenestration requirements are; Luke is reviewing now.

Addition of this will likely lead to the need for clarification of ACM language 
and rule updates, but demising partitions (incl. windows/doors) are a component 
of most every building project I have worked on, so suggest we should address 
this now.

Proposed resolution:
Add Window as child of Dr, update ACM to and rules to reflect demising 
partitions.

Please provide any additional information below.

Original issue reported on code.google.com by da...@360-analytics.com on 18 Apr 2013 at 12:09

[GoogleCodeExporter]

Trying to close out issues; looks like this one was never discussed.  Any 
comments on this?

Original comment by da...@360-analytics.com on 24 Sep 2013 at 5:01

[GoogleCodeExporter]

I assume Proposed Resolution should read "Add Window as child of IntWall" (not 
"child of Dr").

What about OpenStudio forward/reverse translators?  Does Sketchup plugin allow 
for windows on IntWalls (which would enable the forward translator to include 
those items) and does OpenStudio allow for wins on IntWalls in terms of 
simulation in EnergyPlus?

Original comment by scriswel...@gmail.com on 24 Sep 2013 at 5:15

[GoogleCodeExporter]

I'm sure that the ACM does not address windows in demising walls, we are just 
now adding demising surfaces to the ACM.  For completeness, I agree that 
allowing interior windows makes sense.  

OS and EnergyPlus allow windows on interior walls, I have included them in 
models in the past.  

Do we care about light transmission through an interior window?  If so, do we 
want to also include the children of exterior windows (ExtShdgObj and 
IntShdgDev) for interior windows as well.  I think only IntShdgDev is really 
applicable.   

Original comment by rhedr...@archenergy.com on 24 Sep 2013 at 5:21

[GoogleCodeExporter]

Visible light transmission through interior windows is automatically accounted 
for if the host thermal zones include daylighting.

Solar and thermal impacts are automatically accounted for.

However, I don't think shading devices are allowed on interior windows.

Original comment by RJHitchc...@gmail.com on 24 Sep 2013 at 6:17

[GoogleCodeExporter]

Can we have context specific limits on children of objects in Sharepoint or 
BEMBase, i.e. can an ExtShdgObj be a child of Win when located in an ExtWall, 
but not an IntWall?  I didn't think we could do that.  

I believe the ExtShdgObj is more appropriately defined as a child of a ExtWall 
or the Bldg, at least when it comes to energy modeling. In the OS, these 
objects are not associated with specific windows.  Right now, i believe the 
forward translator makes shading objects a child of the "first" window on a 
wall. 

Original comment by da...@360-analytics.com on 24 Sep 2013 at 7:03

• Changed state: Discussion

[GoogleCodeExporter]

I propose something relatively simple to treat interior windows:

Interior windows are allowed in the compliance model, and subject to the 
following rules:

1. Interior window area for standard design matches proposed design, no area 
limit.
2. Interior window standard design construction is a single-pane, metal-framed 
window with clear glass.
3. Demising window standard design construction is a double-pane, metal-framed 
window with thermal break with clear glass. Fixed U-factor and SHGC independent 
of climate zone.  (Note that some “demising” windows may see solar gain, 
but the assumption here is that the majority of windows of this type will 
receive little solar gain.)
4. There are no area limits for demising windows for the proposed design 
(standard design area = proposed design area).  

Original comment by JohnJArent on 24 Sep 2013 at 7:05

[GoogleCodeExporter]

5. No shading devices allowed on interior windows or interior glazed doors.

As David points out this may not be possible to enforce in the model, it would 
have to be a rule.

I have not looked at the OS translation of shading devices, but why would it 
just associate shading objects with the "first" window rather than the specific 
window they are a child of?

Original comment by RJHitchc...@gmail.com on 24 Sep 2013 at 7:34

[GoogleCodeExporter]

Maybe Dan can chime in to clarify, but from what I recall, there is no 
reference or parent/child relationship between shading objects and windows in 
OS.  

Therefore, the translator doesn't know which window to associate it with.  The 
first pass was to associate the shading object with one of the windows in a 
wall; the "first" one if there is more than one.  Depending on how the shading 
object is defined in OS, there may be a many:1 relationship between windows and 
shading objects (imagine a single shade across an entire facade shading 
multiple windows), which doesn't seem conducive to parent:child.

Original comment by da...@360-analytics.com on 24 Sep 2013 at 7:51

[GoogleCodeExporter]

E+ has a variety of shading types including detached shading surfaces (e.g., 
trees, other buildings) and attached shading surfaces (e.g., fins/overhangs) 
that do not need to be associated with specific windows.

But, shading devices like blinds, shades, drapes or screens are associated with 
specific windows using the WindowProperty:ShadingControl object.

To my mind, the NR SDD ExternalShadingObject should be translated to the 
former, while the InteriorShadingDevice should be the latter.

That said, I don't think we ever fleshed out the property details of 
InteriorShadingDevice in the SDD.  So I'm not sure they are ever used.

Original comment by RJHitchc...@gmail.com on 24 Sep 2013 at 8:11

[GoogleCodeExporter]

Revising priority to Low, but leaving issue for future discussion.

Original comment by da...@360-analytics.com on 15 Feb 2014 at 7:32

• Added labels: Priority-Low
• Removed labels: Priority-High