Clerestory - or not so clear....

It is undisputable that glazing is a crucial element of a building's envelope and from that perspective the kind of glazing that is implemented on a project can greatly contribute (or not so) to the overall thermal and day lighting characteristics of a building.So what do we have to do within Revit in order to be able to depict the most accurate aperture configuration of one’s preliminary design? First we need to take a look at the way Revit is interpreting objects like Windows, Store Fronts and Curtain walls when embedded within a wall opening and exported to a gbXML file. When you start modeling in Revit, do yourself an enormous favor and forget about anything else bur Generic Family types, and for all the practical purposes stick with generic walls, slabs, roofs, windows and doors, as none of their construction characteristics are conveyed to GBS via gbXML. One of the undocumented idiosyncrasies of Revit’s interpretation of openings is that any glazed component of a buildings skin is being exported to gbXML as an OPENING of a “FixedWindow” type, and nothing would be wrong with that at the schematic design analysis if that interpretation was modeling style (family) independent. Well it is not.While modeling a series of case studies for future training material based on several past projects, the quintessential architectural element the clerestory window became a point of confusion for Revit’s gbXML translations.Take a look at these two models. In both cases the overall size of the structure and the relative position of the building objects was unchanged, but in the first case the clerestory glazing has been represented by an object from Store Front Curtain Wall family ands in the second case it has been represented by an object from Window family.
When the Store Front Curtain Wall object is used in the same location it is ignored by gbXML translation and the host surface does not contain the opening child element associated with it.

Launch this VRML model file to highlight and examine its surfaces in order to visualize clerestory inconsistency.


In the second model I have replaced the Clear Story element with a window object and it has been correctly translates as the child opening surface to the hosting exterior wall



Launch this VRML model file to highlight and examine its surfaces and see that clerestory is reported correctly.

The recommendation of this finding is to use the Window Family objects as often as possible in order to represent the glazed openings in building skin, and the only modification that I would suggest is to modify the generic window family and assign height and width as the instance parameters. This will allow you to manipulate a stretchable element within the walls as a very good modeling alternative to Store Front style curtain wall.
It is worth mentioning that the first floor store front was in both instances reported correctly as 4 different glazed surface which also can be used as an additional argument to use the Window object , as none of the mullions are exported to gbXML, and the more analytical surfaces are pushed to GBS simulation site the more complex and slower simulation will be.
A very good reference for anybody that is building a model suitable for the preliminary energy analysis is the GBS manual and following the best practice procedures that are outlined there one should, from the start, avoid building intricate models with complex skins, as well as most of the geometry such as overhangs, brise de soleil, or double skin facade.
In the next post I will explain how to modify gbXML file in order to compensate for Modeling Software shortcomings when shading elements are the essential part of a building envelope.