Revit – a "Shade" too green - Revealed !

Well the shades are still there but thanks to Revit’s management and development team, the explanation for their occurrence was given promptly. In this instance Revit’s team (I just do not like to call them the factory as in my view programming is anything but a metaphor for Modern Times), has proven once again that they pay the attention to their product and the people using it. So “Shades”, here we go. From now on you can think of them as a “negligible” artifact that is the result of overlapping polygonal geometry when host and hosted elements interact.

(image courtesy of AutoDesk)

Think of this “negligible” factor within gbXML file as your comfort level threshold when it comes to the accuracy of GBS simulation results. As illustrated these shade surfaces are formed from the centerline of Revit’s wall to the exterior surfaces of either walls or roof eaves.
Their depth depends on the construction type and the amount of overhang, meaning the thicker the exterior wall the deeper the shade surface, and the wider the overhang the larger area of that roof's surface will be designated as the Shade surface.

(image courtesy of AutoDesk)

Therefore the difference in the amount of applicable shading will be different with respect to the construction method as a 12” wide wall over 10 feet will produce an additional 5 SF of shading, and a 24” thick wall over the same distance will generate 10 SF of shading surfaces. For now, if you seek for a no questions asked simulation model, go ahead and get rid of all of the Shade surfaces that are not functional from the designer's perspective by manually deleting them from the gbXML file.The good news is that Revit's team is working hard to streamline the gbXML translation tool even more by increasing its accuracy and flexibility.
It is also important to emphasize the relationship between the Room object and its upper boundaries.
This subject is covered in Revit’s MEP white paper and it deals with a limited range of roof forms and the required relationship with Room objects.
To make this long story short, one should ensure that the Room object’s upper boundary extends above the highest vertex of the roof. The analytical volume that is reported to gbXML file is not the one that reflects Room object's volume but the one that is encapsulated by the boundary surfaces of the adjacent building elements.I would encourage everyone to open their gbXML file and examine its content from time to time and verify that all of the model elements are correctly exported from Revit’s model. If reading XML is not one’s cup of tea, the GBS client has a convenient tool that translates the gbXML file into a VRML model and indicates the potential conflicting analytical surfaces. This model can be easily shared online and in order to visualize it the user should install a VRML viewer such as Cortona by Parallel Graphics.




In the next post I will illustrate some basic building forms and the best strategies for schematic design zoning in order to achieve quick and usable comparative results from GBS simulation.

Revit – a "Shade" too green !

Over the last few years we have used a variety of the available tools to conduct basic energy analyses of our designs. At the scale of building components a valuable tool of the trade has been LBLN’s Therm 5.1 (6.1), which was able to relatively accurately predict the thermal transfer relationship among various building components and materials. On the whole building scale the two tools of choice were Ecotect and Green Building Studio.
Recently, due to its format’s legibility, it became evident that Revit Architecture has some issues when it generates the gbXML file.
The first one is that if a user attempts to poke through the Light Fixture schedule this somehow partially triggers Revit’s MEP mode where it starts outputting Light Fixture and Equipment Loads in a room, but does not assign value to those and they are being reported to GBS as zero values, making your building internal loads no believable.

The second issue that we ran into was the inaccuracy of the gbXML file in terms of additional building components being added by Revit. I am taking about “Shade” devices that are showing as part of the gbXML file for every Wall and Roof object within the Revit model. It is interesting that the same Object ID from Revit’s model is used on both Polygons describing Wall and Shade respectively.

As a result the output from your simulation can be skewed as being more or less energy efficient depending on the building’s location and construction method.
The only way to circumvent this problem is to manually open a Revit generated gbXML file and look for “Shades” that are not supposed to be here as the part of the original design. Identify them, delete them and rerun the simulation and compare your results.

Here is the example of what I am talking about. This extremely simple model where the generic 8” wall, Generic 12” Slab and Generic 12” Roof are used with the Room volume calculation enabled and with the Room object having enough offset to be picked up by Roof planes.

The output file was than examined and the intriguing addition of the addition surfaces is quite evident. The additional “Shade” surface type enumerators are not part of the original design as they do not relate to any “floating” wall geometry.

What is even more intriguing is that when Object IDs are compared throughout the gbXML file, one notices that a single Revit object was interpreted twice: once as a building object designated by surface type enumerator whose value = "Exterior Wall", "Roof" "Slab on grade" etc.) and simultaneously as the non design existent “Shade” object.
To check the validity of the object's ID number I have used the number from the same gbXML file to select an object within the Revit model.

In this day and age when so much focus is directed toward BIM compliant software ‘s ability to be used as an appropriate analytical tool it is quite disconcerting when these glitches occur. Most of the results that are obtained from these models might have embedded errors that were not design envisioned but software altered, and the confidence that architects can have in their design by expressing it in an quantifiable way should not be compromised by launching software that claims more than it can deliver.

Furthermore, it is high time for software developers to start thinking as architects and engineers do, and unlocking the potential that BIM has as the methodology should extend beyond visual aspects of those applications. A unified library of materials with their real physical properties including embedded energy, carbon content, and thermal conductivity coupled with the ability to quantify building materials in addition to the assemblies, should be top priority if any of these tools want to reclaim their analytical competency.

The conclusion is that when one accounts for all of the complexity associated with the realization of the built environment, we all have the responsibility to critically examine the tools and methodologies that software companies present as “their” best solution and maybe, just maybe this will make them think less about marketing and more about delivering stable and reliable products.