Solar Heat Gain control in Revit's gbXML model

As some of us have ventured down the road of Building Performance Analysis (BPA) it is to clients' benefit that we fully understand that the path between BIM compliant, or want to be a compliant model and the simulation model doesn't have to be a black box. Thanks to the visionary (read common sense) approach in interpreting virtual building objects and to the creation of a standard language of building, one can regard gbXML format as the first line of defense against inaccurate modeling or translation results.

When exporting a model into an ASCII compliant XML file or examining the same model via its VRML incarnation, one can quickly validate the integrity of the model translation, or manually modify the same file with a very basic text or XML editor. This to a certain extent can compensate for the current software shortcomings or one's unwillingness to purchase another $5K software package.

Let us see what the average user can do to enhance the quality of the preliminary model interpretation, and what are the basic elements of the gbXML file that we as architects should understand in order to approach schematic design modeling with realistic expectations. To do this, knowledge of BIM compliant model structure is the key component, and reflecting on how this model is put together will yield to greater appreciation for the simplicity of its analytical counterpart. The BIM model as such, appropriately so, is distilled down to its basic analytical geometry by treating each major construction component as a 2 dimensional surface (plane) with its associated information, and this associated information is what really distinguishes the building's components in their analytical environment.

The purpose of this geometrical interpretation is the functional and data rich translation of the somewhat superfluous BIM supporting platform geometry, and to emphasize the irony of information modeling, only the spatial components and functional labels of BIM model objects are conveyed to the simulation software. So instead of true information modeling that incorporates usable physical and temporal data ,the grunt work is done after the model is submitted and from that perspective that famous "Information - Cost" BIM diagram becomes somewhat questionable.

Once we establish this common understanding of BIM's model capacity we should find a way to manipulate the purpose built model and its information after it is being exported to gbXML.
Now let's get to the very basics and learn what are the "building blocks" of a gbXML file. Not to be surprised, but the basic Euclidean surfaces are what defines the space and consecutively the building within the analytical model, and those surfaces are defined as follows within the gbXML schema;

• InteriorWall
• ExteriorWall
• Roof
• InteriorFloor
• Shade
• UndergroundWall
• UndergroundSlab
• Ceiling
• Air
• UndergroundCeiling
• RaisedFloor
• SlabOnGrade

One could ask why even mention these surface types as your BIM application can easily translate any model into a comparable gbXML file that can be sent for analysis. Therefore through a simple iterative process, the architect/designer should be able to optimize a design toward finding the most viable sustainable solution. Or is it so?

The short answer is not at all. Yes, indeed the basic building geometry focusing on slabs, roofs and walls will be generated as it defines the spatial boundary conditions, but several of the quintessential passive sustainable strategy elements get entirely neglected.

Shading devices, constructed or planted, exterior or interior, can be approximated in Revit's BIM model via the persnickety use of a variety of modeling objects, but within Revit Architecture there is no identifier that designates any such improvisation as a valid gbXML compliant Shade surface. Someone might ask, but what about using a roof or a slab family to create exterior shading devices? Sounds like a good idea, but unfortunately to export such an element, the same one should be a part of a room bounding enclosure, and besides extending slabs beyond the buildings envelope, the aperture shading definition does not comply with Revit Architecture's capacity for model translation to gbXML.

Following is the technique I use to circumvent the above described deficiency and append my own shading surfaces to the analytical model, and for its implementation a good XML editor and any VRML browser are must have tools. The editor I prefer (read free) is XML

Marker , and the VRML browser I prefer is Cortona by Parallel Graphics.

As indicated in the previous article that was dealing with the ambiguous interpretation of different glazed opening types, in this one we will also rely on the gbXML surface type and its child object opening.
In order to manually indicate the location of a shading device, it is important to locate the surface which is hosting an opening, bringing us to an interesting modeling concept in which we assume that main building elevations are perpendicular to coordinate axis substituting for sides of the world and where by the convention we assume that North is in the positive Y direction. We can certainly model any structure to reflect its true site orientation and this would not pose a particular problem, but explicitly specifying building's orientation angle is something I like to avoid at this point, especially when considering the fact that GBS can rotate the world around any structure.
So go ahead and export your Revit Architecture model and make sure that all openings are properly translated by verifying their location within the VRML file. If you adapt the translated VRML file so that it can be used within the VRML client as shown in this example, it is quite easy to identify which opening's location will be used to manually place the new shading devices.

To find the appropriate surface and the associated opening one should parse the gbXML file and look for the Surface-Opening Parent-Child pair. To verify its association with the original Revit's entity one should always compare CADObjectID value of the surface with the entity ID value in the model. Once you find this, look for the Cartesian point that determines the location of the child object in relationship to its parent.

As indicated in this code example

This same point will be used to intentionally place the shade surface in relationship to the opening object. As we are examining the opening object ,it is worth taking a second look at Revit Architecture's translation of its window families into the gbXML file as some inconsistencies will become apparent. It is always up to the user to double check the interpreted definitions and manually modify the gbXML file in order to assure for the correct window operational type translation. One major improvement to Revit's gbXML output would be the ability to to pick the appropriate gbXML type definition and have it as a parameter within the relevant family, but circumventing this problem is a topic for the next post.
Confirm the type and the location of an opening with its vertices and its parent exterior wall surface. When this is done, adding a shade object is a relatively straightforward exercise, which consists of appending desired number of shading surfaces at the end of the gbXML file and naming them incrementally as shown in the example below.
While parsing the gbXML you will notice several definitions within the surface element such are "RectangularGeometry", "PlanarGeometry", "Azimuth", "CartesianPoint", and "Tilt" where the explanations for all of them are given within the gbXML schema, and the accompanying documentation.
So whether a shade device is aligned with an opening or located relatively to an exterior wall surface, all you have to do is to identify the opening vertices within a surface or the vertices of the surface itself, and use those to locate, orient and size the corresponding shade surface.

Save your gbXML file and submit it to the GBS web site under the same project name as the original file and compare the results. You will notice that specifying windows' operability value, as well as introducing the correctly placed shading device will make a difference in the total energy picture of your project.
As I mentioned in my previous article, it might be prudent to eliminate all of the unwanted shading surfaces that are artifacts of Revit's model to gbXML translation, and then introduce a new set of deliberately placed Shading Surfaces / Devices whose syntax is described below. Make sure that you assign an unique Surface ID and associated surfaceType as "Shade".

As indicated in this code example

Unfortunately the lack of an existing native gbXML editor makes this process labor intensive but the insight into the future performance of a new design, in my opinion, makes this entire exercise quite valuable.