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

edit

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.

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%.