90.1-2010 App. G - Self shading & adjacent bldgs

asked 2017-09-15 16:09:36 -0600

I'm working on a model for an urban project that has two adjacent buildings that will definitely have a shading impact on the walls and glazing of my project. I'd like to take this into account for my proposed model so that the recommendations I'm providing will more accurately represent the actual conditions (i.e. appropriate SHGC to save energy, not just get LEED points). It looks like I am technically allowed (even encouraged), but I'm not sure how to actually do that and still follow the rules for the baseline model..

Per 90.1-2010 App. G, Table G3.1.14.a Shading by adjacent structures and terrain - Paraphrasing, it says "model adjacent structures that will shade your project." It also instructs for the baseline to be "same as proposed design." Okay, great. This means I modeled the adjacent building for the proposed, and leave it in the baseline model.

However, G3.1.a for the baseline building says, "the building shall be modeled so it does not shade itself."

The question is, how the heck can I model shading by an adjacent structure while NOT modeling the building's self shading?

My model is in IES-VE so VE-specific solutions are welcome, but I feel like this is a universal issue, unless a software tool can differentiate between shading by "self" and shading by "other."

edit retag flag offensive close merge delete

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2017-12-12 20:31:20 -0600

bbrannon4
1727 ●1 ●2 ●18

I don't believe there is a way to do this in IES (or any other tools I'm familiar with) without some difficult post processing. To be honest, I typically just ignore that rule and allow for self shading for the baseline, based on what Cory said. As the example Rsunnam provided points out, this should be conservative (unless you're in a really cold climate). If the adjacent shading structures allow the baseline to be rotated, then the process of rotation effectively averages out any self shading, so to me those two requirements in App G are redundant.

The only thing I could think of in IES would involve a lot of post-processing. You would need to run a simulation without the adjacent buildings and without suncast, and then run a simulation with the adjacent buildings and with suncast. If you compare the solar gains (and also exterior conduction, though I suspect that will be smaller), you could then manually calculate what the cooling load should have been by subtracting the difference and recalculating the cooling energy. Of course that gets very complicated very quickly, because fans and pumps should be reduced too, and by that point you've basically modeled the entire HVAC system by hand in a spreadsheet or something, which is why I just ignore it.

It might, however, be possible to trick suncast into it, though I haven't tested it. You could do the same runs as above, and then compare the .shd files and manually edit it (telling suncast to run even though it thinks it's out of date). That again would take forever because those files are huge.

edit flag offensive delete link

add a comment

answered 2017-09-18 09:37:41 -0600

rsunnam

960 ●2 ●9 https://rmi.org/our-wo...

The user's manual for ASHRAE 90.1-2010 clarifies the difference between self-shading and shading by other structures that are described in Appendix-G Table G-3.1.5a (Building envelope - Orientation) and Table G-3.1.14 (Exterior Conditions).

To quote the user's manual -

If the proposed building has a shape that shades itself during portions of the day - such as a donut or "L" shaped building - the self shading is ignored in the baseline building. Such features are modeled in the proposed building. Shading of the building by surrounding structures and topography should be modeled identically in both the proposed and baseline buildings.

Further Example G-B explains how proper orientation is rewarded by the Performance rating method:

With the Performance Rating Method, the baseline building has the same shape and orientation as the proposed design, but the baseline building is modeled four times. After the initial simulation, it is rotated 90,180, and 270 degrees and the baseline building performance is taken as the average of these results. The overhangs (south facing in the example) are also credited, since the baseline building is modeled with no exterior shading devices and with windows flush with the outside surface of the exterior walls. Furthermore, if the building is configured in such a way that it is capable of shading itself (for example, "L" or "U" shaped building), this self shading is not modeled in the baseline building.

Although it does not explicitly say it, my understanding is that the simulation runs in four orientations results in the baseline building not taking advantage of the "self-shading" caused by the shape of building.

Having said all of that, since your building is located in an urban area, your project can probably take advantage of exception 1 for the orientation rule if you are able to demonstrate to the satisfaction of the program evaluator that your project is eligible. The user's manual interprets the exceptions as:

There are two exceptions to the orientation rule. When either of these exceptions are met, the baseline building need be modeled only in one orientation:

1. When the building orientation is strictly dictated by site considerations, such as a lot in an urban area with neighboring buildings on one or more sides.

2. When the vertical orientation on each facade varies by less than 5%.

edit flag offensive delete link

Comments

Rsunnamm,

Thanks for your response. You definitely clarified the language and requirements of the standard, and I do agree it makes sense to prevent rotations of the baseline as per exception 1.

However, I still don't have a way to turn "off" self shading while leaving "on" shading from adjacent buildings. I also don't agree that the baselines rotations (if they were to be used) would counter the effects of self shading. For an easy example, consider a donut shaped building...

Greg Collins ( 2017-09-18 10:03:36 -0600 )edit

That's right, The language is slightly confusing. I was also wondering about a donut shaped buildings. I do not see a way to reasonably minimize (if not completely exclude) the impact of self-shading due to the shape of building (while also maintaining identical thermal zones in baseline and proposed design) other than by rotating the baseline model in the four suggested orientations (or more, may be?)

rsunnam ( 2017-09-18 10:29:26 -0600 )edit

The narrative for baseline envelope requirements does talk about modeling the exterior envelope components with "Equivalent dimensions". But in order to meet the baseline requirement related to thermal blocks, I would interpret that the baseline rotations are a way to minimize the impact of self-shading. I would be interested to know if you have a more creative way to take advantage of this. In any case, I hope that your initial question about the definition of self-shading is answered.

rsunnam ( 2017-09-18 10:34:53 -0600 )edit

Im curious if any program has the ability to separate the effects of the building shading it self from the building being shaded by adjacent structures. It seems doable since most programs classify those separately. I believe in IES, it is with suncast or without though. The 90.1-2010 navigator runs suncast on the baseline if there are adjacent structures.

crduggin ( 2017-09-18 11:44:40 -0600 )edit

In general, there is no way to "triangulate" this using multiple simulations. The shading calculations have to fundamentally distinguish between detached surfaces and building surfaces. EnergyPlus will be adding this capability in V8.9 in March 2018.