-
Notifications
You must be signed in to change notification settings - Fork 20
Rearranging Attics #105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rearranging Attics #105
Conversation
<xs:enumeration value="gable"/> | ||
<xs:enumeration value="knee wall"/> | ||
<xs:enumeration value="other"/> | ||
</xs:restriction> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What other enumerations should I have here? These are walls that go between an attic space and something else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noel, I like what you've done with the Attic. Breaking out the Roof/Floor/Walls seems like a good way to go.
For the walls, would it help to indicate whether the wall is exposed to the environment or to a conditioned space? My understanding is that the Gable would separate the attic interior from the outside, and a Kneewall would separate the attic interior from the bottom triangle of the roof, where the triangle could be insulated at the kneewall or at the slope/flat. I'd assume the gable is exposed to the environment, but the kneewall may or may not be. Does this matter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you add InteriorAdjacentTo and ExteriorAdjacentTo elements than this designation becomes pretty unimportant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For foundation walls and above-grade walls, the WallType enumerations are things like WoodStud, DoubleWoodStud, DoubleBrick, Solid Concrete, etc,. It'd be nice to have similar options here too. I agree with @GamalielL that the *AdjacentTo elements would be a preferable way of designating whether it's a gable, knee wall, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume it's a bug that the AtticWallType element is required.
I like Gamaliel's idea of using separate attic nodes for each vertical slice of the attic. So any section that has a sloped or horizontal surface gets put in the attic either as a roof or floor. However, I also like having the walls in there too. Even though we can describe them in the Walls element and reference them in the attic, it seems confusing to separate them. |
schemas/BaseElements.xsd
Outdated
@@ -517,80 +517,138 @@ | |||
<xs:element name="AtticAndRoof" minOccurs="0"> | |||
<xs:complexType> | |||
<xs:sequence> | |||
<xs:element minOccurs="0" name="Roofs"> | |||
<xs:element minOccurs="0" name="Attics"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It feels a little silly to have both AtticAndRoof and Attics within it. Perhaps remove the AtticAndRoof element?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True that could be pretty easily collapsed.
@brandongallagher The use I was suggesting includes the walls. Each unconditioned buffer space would get it's own instance and include all boundaries, inside and out. Surfaces that have no buffer space, but directly separate conditioned from ambient would also get their own instance. |
I'd also be fine with continuing to use the exterior wall node to specify
these and linking them via idref. At the very least, we should replicate
that entire structure here.
…On Thu, Aug 3, 2017 at 10:52 AM, Scott Horowitz ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In schemas/HPXMLDataTypes.xsd
<#105 (comment)>:
> @@ -1663,6 +1664,13 @@
<xs:enumeration value="other"/>
</xs:restriction>
</xs:simpleType>
+ <xs:simpleType name="AtticWallType">
+ <xs:restriction base="xs:string">
+ <xs:enumeration value="gable"/>
+ <xs:enumeration value="knee wall"/>
+ <xs:enumeration value="other"/>
+ </xs:restriction>
For foundation walls and above-grade walls, the WallType enumerations are
things like WoodStud, DoubleWoodStud, DoubleBrick, Solid Concrete, etc,.
It'd be nice to have similar options here too. I agree with @GamalielL
<https://github.com/gamaliell> that the *AdjacentTo elements would be a
preferable way of designating whether it's a gable, knee wall, etc.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#105 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AJQHDPjhAfVoyHNFaX948RWLbXs8BMJGks5sUd66gaJpZM4OraKW>
.
|
@GamalielL , thanks for clarifying. If each space gets it's own instance and includes all boundaries, would adjacent spaces both reference the wall separating them? For example, if the triangle buffer space gets a roof, floor, and kneewall defined, would the adjacent conditioned attic also reference that same kneewall? |
@brandongallagher, I wouldn't give the conditioned space it's own instance. That's the key distinction I was trying to make with my interpretation. From an energy perspective, it doesn't matter which elements border the conditioned attic, because it's theoretically at the same temperature as the rest of the conditioned space. The configuration of the buffer spaces is most important. The buffer spaces are also what you change with an attic or knee wall space conversion. You replace the buffer space and associated surfaces, with just the exterior surfaces. |
@brandongallagher @GamalielL Well my head is spinning now. I see your point about separating them into separate attics, but I wonder if there's a way we could more holistically describe a cape cod attic that would make it so we wouldn't have to resort to that. It seems like it could be hard to piece together if they were all broken up like that. |
@nmerket I wouldn't be able to do that with OptiMiser, because we don't
collect the information in that way. We wouldn't know if a user was
describing a cape cod attic, because we only collect individual surfaces
that are bounding conditioned space. We differentiate between surfaces
that have ambient exterior and those with attic buffer space exterior and
we allow users to link attic floor and knee wall sections that are
connected to the same buffer space.
We need to get some implementers involved in this discussion so we can be
sure we are setting up something that will be usable in incentive
calculations.
…On Thu, Aug 3, 2017 at 5:57 PM, Noel Merket ***@***.***> wrote:
@brandongallagher <https://github.com/brandongallagher> @GamalielL
<https://github.com/gamaliell> Well my head is spinning now. I see your
point about separating them into separate attics, but I wonder if there's a
way we could more holistically describe a cape cod attic that would make it
so we wouldn't have to resort to that. It seems like it could be hard to
piece together if they were all broken up like that.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#105 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AJQHDBADEYsJWtEPy4tNwMJg2jx48ZMXks5sUkJJgaJpZM4OraKW>
.
|
@GamalielL Fair enough. No matter where we land, before we merge we should work up some examples of different kinds of attics and measures including those kinds of attics and save them in the examples directory in the repo just to make sure it can be done. They could serve as a kind of unit test for this change. Actually unit testing might not be a bad idea in general here. We could at a minimum have a suite of tests that goes through the example files in the repository and validates each against the schema. |
…a element). Attic areas can be stored in Attic/Floors/Floor/Area.
…. More consistent with Foundation/FoundationType and allows more flexibility. It also makes AtticType required, consistent with FoundationType being required.
Whatever happened to the subgroup that was supposed to review this? Have you guys worked up examples of different measure scenarios to see how they fit into this new scheme? |
Good question, @GamalielL. I will let @nmerket speak to the subgroup question. I certainly look forward to having a more detailed discussion at some point. We've mostly been trying to prototype this out first for a few of the more challenging use cases. For example, we have a working implementation based on this attic refactor branch where we can describe in HPXML this level of complexity for the Weatherization program: |
@shorowit Are there HPXML samples of this configuration available for review? |
They have some interface quirks in how they describe finished attics that make the resulting HPXML a bit weird, so you wouldn't want to see it. But we can certainly plan to provide good example HPXMLs for this configuration and others. |
@shorowit Do you have any examples yet? |
@GamalielL Here's an example. The building has a 50' x 70' footprint, conditioned attic with 4' high kneewalls and an collar beam ceiling 8' from the floor. The example HPXML file is organized as follows:
The HPXML file includes all surfaces (not just thermal boundary surfaces) for completeness, but that's obviously not a requirement. It also has the insulation running from outer ceiling joist to kneewall to collar beam, but other insulation configurations can be accommodated.
Let me know if you have any feedback. |
@shorowitz
This is pretty close to what I had initially imagined/proposed, but I
hadn't considered describing both conditioned and unconditioned attic
spaces this way. I can see the usefulness in providing a more clear
picture of the geometry, but it also can make things more confusing
(particularly with respect to elements that bound two spaces. I would have
gone the other way with the placement of the knee walls and included them
in the unconditioned-attic space. The most important spaces to capture are
the unconditioned attics. The dynamics of these buffer spaces depends on
all of the surfaces and the UA ratio between surfaces that bound
conditioned space and surfaces that bound the outdoors. It doesn't really
matter which conditioned space the knee walls are attached to, because they
are all the same temperature.
The other problem that I see is with the AdjacentTo elements. You haven't
used them consistently. In the unconditioned attic behind the knee wall,
you have the floor adjacent to living space, but the gable wall adjacent to
attic-unvented. So one surface is described relative to what's outside the
space and the other is described relative to the space itself. We need to
codify how these are determined.
If I was going to describe the space behind the knee wall from a modeling
perspective, I would include all surfaces that bound the space. For each
surface I would include assmbly R-value (including roofs) and I would use
AdjacentTo to describe what is adjacent to the bounded space. This
provides the most complete information of the modeling dynamics. However, I
can see how it makes things more difficult for a user who just wants to
identify all thermal boundary surfaces and characterize them more
generally.
Here's my take on the space behind the knee walls
```
<Attic>
<SystemIdentifier id='Unvented_Attic_Behind_Kneewall_North'/>
<AtticType>
<Attic>
<Vented>false</Vented>
</Attic>
</AtticType>
<Roofs>
<Roof>
<SystemIdentifier id='Roof_K'/>
<Area>625.0</Area>
<Azimuth>0</Azimuth>
<Pitch>6.0</Pitch>
<Insulation>
<SystemIdentifier id='Roof_K_Ins'/>
<AssemblyEffectiveRValue>3.3</AssemblyEffectiveRValue>
</Insulation>
</Roof>
</Roofs>
<Floors>
<Floor>
<SystemIdentifier id='Floor_G'/>
<AdjacentTo>living space</AdjacentTo>
<Area>560.0</Area>
<Insulation>
<SystemIdentifier id='Floor_G_Ins'/>
<AssemblyEffectiveRValue>39.3</AssemblyEffectiveRValue>
</Insulation>
</Floor>
</Floors>
<Walls>
<Wall>
<SystemIdentifier id='Wall_I'/>
<AdjacentTo>outdoors</AdjacentTo>
<Area>16.0</Area>
<Azimuth>90</Azimuth>
<Insulation>
<SystemIdentifier id='Wall_I_Ins'/>
<AssemblyEffectiveRValue>3.3</AssemblyEffectiveRValue>
</Insulation>
</Wall>
<Wall>
<SystemIdentifier id='Wall_I_Opposite'/>
<AdjacentTo>outdoors</AdjacentTo>
<Area>16.0</Area>
<Azimuth>270</Azimuth>
<Insulation>
<SystemIdentifier id='Wall_I_Opposite_Ins'/>
<AssemblyEffectiveRValue>3.3</AssemblyEffectiveRValue>
</Insulation>
</Wall>
</Walls>
<Wall>
<SystemIdentifier id='Wall_D'/>
<AdjacentTo>living space</AdjacentTo>
<Area>280.0</Area>
<Insulation>
<SystemIdentifier id='Wall_D_Ins'/>
<AssemblyEffectiveRValue>23.0</AssemblyEffectiveRValue>
</Insulation>
</Wall>
</Attic>
```
ᐧ
…On Tue, Apr 2, 2019 at 5:40 PM Scott Horowitz ***@***.***> wrote:
@GamalielL <https://github.com/GamalielL> Here's an example. The building
has a 50' x 70' footprint, conditioned attic with 4' high kneewalls and an
collar beam ceiling 8' from the floor.
[image: image]
<https://user-images.githubusercontent.com/5861765/55436641-13da4500-555a-11e9-991d-dde8e94e94c1.png>
The example HPXML file is organized as follows:
- 1 conditioned Attic
- 2 insulated Roofs (A and B), 2 insulated gable Walls (C and
opposite), 2 insulated knee Walls (D and E), and 1 uninsulated Floor
(F)
- 2 unconditioned Attics behind kneewalls
- Each with 1 insulated Floor (G/H), 2 uninsulated gable Walls (I/J
and opposite), and 1 uninsulated Roof (K/L)
- 1 unconditioned Attic under roof ridge
- 1 insulated Floor (M), 2 uninsulated Roofs (N and O), and 2
uninsulated gable Walls (P and opposite)
The HPXML file includes all surfaces (not just thermal boundary surfaces)
for completeness, but that's obviously not a requirement. It also has the
insulation running from outer ceiling joist to kneewall to collar beam, but
other insulation configurations can be accommodated.
<Attics>
<Attic>
<SystemIdentifier id='Conditioned_Attic'/>
<AtticType>
<Attic>
<Conditioned>true</Conditioned>
</Attic>
</AtticType>
<Roofs>
<Roof>
<SystemIdentifier id='Roof_A'/>
<Area>885.0</Area>
<Azimuth>0</Azimuth>
<Pitch>6.0</Pitch>
<Insulation>
<SystemIdentifier id='Roof_A_Ins'/>
<AssemblyEffectiveRValue>25.8</AssemblyEffectiveRValue>
</Insulation>
</Roof>
<Roof>
<SystemIdentifier id='Roof_B'/>
<Area>885.0</Area>
<Azimuth>180</Azimuth>
<Pitch>6.0</Pitch>
<Insulation>
<SystemIdentifier id='Roof_B_Ins'/>
<AssemblyEffectiveRValue>25.8</AssemblyEffectiveRValue>
</Insulation>
</Roof>
</Roofs>
<Floors>
<Floor>
<SystemIdentifier id='Floor_F'/>
<AdjacentTo>living space</AdjacentTo>
<Area>2380.0</Area>
</Floor>
</Floors>
<Walls>
<Wall>
<SystemIdentifier id='Wall_C'/>
<AdjacentTo>outside</AdjacentTo>
<Area>260.25</Area>
<Azimuth>90</Azimuth>
<Insulation>
<SystemIdentifier id='Wall_C_Ins'/>
<AssemblyEffectiveRValue>23.0</AssemblyEffectiveRValue>
</Insulation>
</Wall>
<Wall>
<SystemIdentifier id='Wall_C_Opposite'/>
<AdjacentTo>outside</AdjacentTo>
<Area>260.25</Area>
<Azimuth>270</Azimuth>
<Insulation>
<SystemIdentifier id='Wall_C_Opposite_Ins'/>
<AssemblyEffectiveRValue>23.0</AssemblyEffectiveRValue>
</Insulation>
</Wall>
<Wall>
<SystemIdentifier id='Wall_D'/>
<AdjacentTo>attic - unvented</AdjacentTo>
<Area>280.0</Area>
<Insulation>
<SystemIdentifier id='Wall_D_Ins'/>
<AssemblyEffectiveRValue>23.0</AssemblyEffectiveRValue>
</Insulation>
</Wall>
<Wall>
<SystemIdentifier id='Wall_E'/>
<AdjacentTo>attic - unvented</AdjacentTo>
<Area>280.0</Area>
<Insulation>
<SystemIdentifier id='Wall_E_Ins'/>
<AssemblyEffectiveRValue>23.0</AssemblyEffectiveRValue>
</Insulation>
</Wall>
</Walls>
</Attic>
<Attic>
<SystemIdentifier id='Unvented_Attic_Behind_Kneewall_North'/>
<AtticType>
<Attic>
<Vented>false</Vented>
</Attic>
</AtticType>
<Roofs>
<Roof>
<SystemIdentifier id='Roof_K'/>
<Area>625.0</Area>
<Azimuth>0</Azimuth>
<Pitch>6.0</Pitch>
</Roof>
</Roofs>
<Floors>
<Floor>
<SystemIdentifier id='Floor_G'/>
<AdjacentTo>living space</AdjacentTo>
<Area>560.0</Area>
<Insulation>
<SystemIdentifier id='Floor_G_Ins'/>
<AssemblyEffectiveRValue>39.3</AssemblyEffectiveRValue>
</Insulation>
</Floor>
</Floors>
<Walls>
<Wall>
<SystemIdentifier id='Wall_I'/>
<AdjacentTo>attic - unvented</AdjacentTo>
<Area>16.0</Area>
<Azimuth>90</Azimuth>
</Wall>
<Wall>
<SystemIdentifier id='Wall_I_Opposite'/>
<AdjacentTo>attic - unvented</AdjacentTo>
<Area>16.0</Area>
<Azimuth>270</Azimuth>
</Wall>
</Walls>
</Attic>
<Attic>
<SystemIdentifier id='Unvented_Attic_Behind_Kneewall_South'/>
<AtticType>
<Attic>
<Vented>false</Vented>
</Attic>
</AtticType>
<Roofs>
<Roof>
<SystemIdentifier id='Roof_L'/>
<Area>625.0</Area>
<Azimuth>180</Azimuth>
<Pitch>6.0</Pitch>
</Roof>
</Roofs>
<Floors>
<Floor>
<SystemIdentifier id='Floor_H'/>
<AdjacentTo>living space</AdjacentTo>
<Area>560.0</Area>
<Insulation>
<SystemIdentifier id='Floor_H_Ins'/>
<AssemblyEffectiveRValue>39.3</AssemblyEffectiveRValue>
</Insulation>
</Floor>
</Floors>
<Walls>
<Wall>
<SystemIdentifier id='Wall_J'/>
<AdjacentTo>attic - unvented</AdjacentTo>
<Area>16.0</Area>
<Azimuth>90</Azimuth>
</Wall>
<Wall>
<SystemIdentifier id='Wall_J_Opposite'/>
<AdjacentTo>attic - unvented</AdjacentTo>
<Area>16.0</Area>
<Azimuth>270</Azimuth>
</Wall>
</Walls>
</Attic>
<Attic>
<SystemIdentifier id='Unvented_Attic_Under_Roof_Ridge'/>
<AtticType>
<Attic>
<Vented>false</Vented>
</Attic>
</AtticType>
<Roofs>
<Roof>
<SystemIdentifier id='Roof_N'/>
<Area>445.0</Area>
<Azimuth>0</Azimuth>
<Pitch>6.0</Pitch>
</Roof>
<Roof>
<SystemIdentifier id='Roof_O'/>
<Area>445.0</Area>
<Azimuth>180</Azimuth>
<Pitch>6.0</Pitch>
</Roof>
</Roofs>
<Floors>
<Floor>
<SystemIdentifier id='Floor_M'/>
<AdjacentTo>living space</AdjacentTo>
<Area>630.0</Area>
<Insulation>
<SystemIdentifier id='Floor_M_Ins'/>
<AssemblyEffectiveRValue>39.3</AssemblyEffectiveRValue>
</Insulation>
</Floor>
</Floors>
<Walls>
<Wall>
<SystemIdentifier id='Wall_P'/>
<AdjacentTo>attic - unvented</AdjacentTo>
<Area>20.0</Area>
<Azimuth>90</Azimuth>
</Wall>
<Wall>
<SystemIdentifier id='Wall_P_Opposite'/>
<AdjacentTo>attic - unvented</AdjacentTo>
<Area>20.0</Area>
<Azimuth>270</Azimuth>
</Wall>
</Walls>
</Attic>
</Attics>
Let me know if you have any feedback.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#105 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AJQHDH7doZfYEBnTsHCPSj0NPIxJ_j7Yks5vc85jgaJpZM4OraKW>
.
--
Gamaliel Lodge
OptiMiser LLC
www.optimiserenergy.com
|
@GamalielL Thanks for reviewing and providing feedback. I think we're mostly on the same page. With regard to placement of the kneewalls, I think software should be able to handle it either way (as part of the conditioned attic or the unconditioned attic). Another example is a foundation wall between conditioned basement and unconditioned basement, In both situations, I would think software could associate the element with either attic/foundation (but not both, right?). Maybe this is something that needs better clarification in HPXML? With regard to the AdjacentTo elements, you're right, I messed up a couple in my example. Indeed Wall_I and Wall_I_Opposite should be "outdoors" and not "attic - unvented". The AdjacentTo element should always point to the boundary condition on the other side of the attic that the surface is within. I'm going to update my example to fix this. And I agree that the non-thermal boundary surfaces could have assembly R-values specified. I simply left them out for simplicity. If they are not included, the software could assume the values. |
@shorowit What do you mean by "I think software should be able to handle it either way"? Which software? My concern is that having this flexibility in the schema will either lead to extra work for those building parsers or lead to programs choosing different variations as requirements, which places significant burden on HPXML generating software. I think it's better to establish one convention. |
@GamalielL I was thinking of software that imports HPXML files. If you wanted to propose a convention, that would be great. But if a software tool wants to include all surfaces in an HPXML file, and then has to describe interior walls (e.g., between two attics or between two basements), I don't see how such a convention is possible. It seems to me that the interior surface could be included in either attic/basement. |
Replaced by #181 |
I went ahead and threw together a straw man for rearranging attics based on feedback I've received. This definitely breaks current implementations and would go in the next major release. It treats attics more as a space with attached surfaces.
(click on the image to see it larger)
Closes #28 and #102.
It also replaces the optional
AtticType
enumeration with a requiredAtticType
element w/ sub-elements, consistent withFoundationType
.All old attic type enumerations can be mapped to the new approach:
<Attic><CapeCod>true</CapeCod></Attic>
<CathedralCeiling/>
<FlatRoof/>
<Attic><Vented>false</Vented></Attic>
<Attic><Vented>true</Vented></Attic>
<Attic/>
<Other/>