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.