High Performance Annotations

The method I use to annotate with BIM is to add a material AND its Specification Section Number to the annotation for vendor neutral materials that are not specifically called out. (06 11 00_2x4 Dimensional Lumber – Species as Noted in the Contract Documents) or (07 54 00_TPO Membrane – Thickness as Noted in the Contract Documents). I use the term "Contract Documents" here as there are changes happening in the industry, and while the contract document now would be the Project Manual, in the future, it may not be. One may reference a tabular specification, or formatted data sheet of some kind. The descriptions are very fluid and allow for modification based on the amount of information known…

A knowledge manager may handle the annotations for the Roof Membrane Layer in a section view of a roof like this:

• PP - (07 00 00_Roof as Noted in the Contract Documents)
  
• SD - (07 50 00_Roof Membrane – As Noted in the Contract Documents)
  
• DD - (07 54 00_Roof Membrane - Thermoplastic – As Noted in the Contract Documents)
  
• CD - (07 54 23_Roof Membrane –.060 TPO – Tan)
  
• Post Bid - (GAF EverGuard .060 TPO Membrane – Tan)
  

The idea is to give an appropriate description based on the amount of information known at a given time, and reference the Contract documents for the next pieces of information which may be necessary. This allows the annotation to always be correct, regardless of how much effort is put into the annotations, or if they never get updated past Schematic. I use phases as an example above, but I see phases as we know them disappearing to some degree with the growth of BIM. Because effort is recyclable in BIM, we can actually have detail views in Schematic Design that have merit. Standardized views can be moved from place to place within a template project, and only the annotations need be moved in order to create "Progress Drawings" at various phases of the project.

All in all, It's my belief that the concept of keynoting really only pertains to the drawings, which are ultimately viewed by the Contractor. With my background in General Contracting, I truly think that requiring them to reference information in a specification in order to get the BASIC information that they need to do their job to me is just plain LAZY! Drawings should follow the same CSI principles as Specifications (Clear, Concise, Complete, Correct) and the fifth C; Consistent. Keynoting makes incomplete drawings, as there is no single unified keynote structure, and there is no practical way to take into consideration EVERY possible component within a given specification section. It took over 1200 different BIM materials for a metal framing manufacturer to represent their Metal Stud offerings which consider dimension, yield strength, web depth and spacing.

Drawings are created before specifications, and BIM is the root of both. As information goes into the Model, it becomes a function of the drawing FIRST, and the attributed information becomes a tabular specification which can be used to develop a text based document. It is actually very simple (and very beneficial) to add the attributed information into the individual materials and components, as BIM provides not only the ability to TOGGLE between keynote, and annotation globally, but to actually concatenate attributes to create an accurate Callout.

The syntax for annotating a material goes something like this:

• Keynote Only: [MF Number]
  
• Keynote Only: [07 54 23]
  

• PP: [MF Number]_[Component] [Type]
  
• PP: [07 00 00]_[Roof] [as Noted in the Contract Documents]
  
• PP: [07 00 00_Roof as Noted in the Contract Documents]
  

• SD: [MF Number]_[Component] [Type] – [Material]
  
• SD: [07 50 00]_[Roof] [Membrane] – [As Noted in the Contract Documents]
  
• SD: [07 50 00_Roof Membrane – As Noted in the Contract Documents]
  

• DD: [MF Number]_ [Component] [Type] – [Material]
  
• DD: [07 54 00]_[Roof] [Membrane] – [Thermoplastic]
  
• DD: [07 54 00_Roof Membrane - Thermoplastic – As Noted in the Contract Documents]

• CD: [MF Number]_ [Component] [Type] – [Thickness] [Material] – [Color]
  
• CD: [07 54 23]_[Roof] [Membrane] – [.060] [TPO] – [Tan]
  
• CD: [07 54 23_Roof Membrane –.060 TPO – Tan]

• Post Bid: [Manufacturer]_ [Trade Name] – [Thickness] [Material][Type] – [Color]
  
• Post Bid: [GAF] [EverGuard] [.060] [TPO] [Membrane] – [Tan]
  
• Post Bid: [GAF EverGuard .060 TPO Membrane – Tan]
  

Because of this structure, I use ONLY the 6 digits of MasterFormat, with no following enumeration that corresponds to a construction or specific material. A keynote is great if a machine needs to read it, but we are not machines. We are humans who want to see the information that we need, not have to follow a path in order to reference a different document. The BIM database already does this for us, and by mapping the information in such a way that it is no additional effort to create the more detailed information, there is no reason NOT to use full text callouts. We are all collaborating on a project, and should consider the needs of the individuals who are actually using our deliverables.

I do understand that you can only put so much information on an E sized plot, however, with the on screen digital world right in front of us, changing scale, and creating additional sheets which apply to specific trades at a more detailed scale is a simple Duplicate w/ Detailing Command.

All of this information is searchable within the model, and allows for analysis, so by adding a few attributes to each material, an annotation is automatically created, and can be globally updated based on the status of the project, or who needs the information. Whether or not keynoting is relevant and useful is no longer an issue in my estimation; That ship has sailed already. I think the idea is how detailed the annotations need to be in order to suit the needs of EVERY member of the project. If BIM can automate the annotation and keynoting process by leveraging attributes from within the material, assembly or component, the bigger issue is the accepted taxonomy and structure for the information which needs to be managed.

No More Shared Parameter Confusion - Omniclass Table 49

There is a format in existence called Omniclass, that has been around for years without a practical purpose. It is a series of tables which organize information the same way MasterFormat™ does. In fact, MasterFormat™ is based on one of the tables in the series. For those using Revit 201 or newer, you may have seen references to Omniclass Table 23 embedded in the families. This is the table that organizes products into logical categories. I'm not going to go into great depth in this post on the value of Omniclass to the success of BIM, but I will say that it is THE most effective way to organize and homogenize all of the data that you are accumulating.

During its redevelopment and update (Which is still ongoing), a few active CSI volunteers and I, were responsible for updating Omniclass Table 49 "Properties". This table is a series of attribute names that are slated to become the standard naming convention or taxonomy for attributed data within Building Information Models. Upon finishing the update to the table, it occurred to me that the best way to implement this into practice was to create a Revit Shared Parameter File. I just finished the effort moments ago with tremendous success, as my custom Shared parameter file works like a charm.

A beautiful aspect of this file is that I customized the GUIDs (Globally Unique Identifiers) so that they align perfectly with the exact location of a parameter. Just as you drill in from Division to section to Part to Article using the CSI formats, This allows me to actually create similar Shared parameter files based on specific needs (one for SPie, one for Windows, one for Doors, one for Wall, one for HVAC, etc), so you can pick and choose which SP file you use without sacrificing data organization. One irritating point about shared parameters is that even if you name the parameters identically, they don't schedule together unless they are form the same shared parameter file. This is based on the GUIDs being different. if I enumerate them and keep the data organized. it should all work out nicely.

If you're interested in, or know someone who is interested in taking this Industry standardized 923 parameter Revit SP file for a test drive, reach out to me and I'll send you a Beta version.

BIM Content and File Size - 6 Points to Making a Faster Family

When Dealing with BIM Content, size is an essential element of its success or failure. While most look only at the overall size of the file, there is another type of size in this respect; computational size, or how quickly the software can load, process, and refresh the file. I have developed components that are 250KB that are slow as molasses on the load, and others that are 1.5MB and lightning fast on the refresh. Always consider BOTH aspects when determining which components you put in your project. Unfortunately, there is no way to quickly quantify and qualify what the computational size of a models is, there are a few ways to determine whether or not a piece of content will be fast or slow.

• Family Types vs. Type Catalogs - Each family type in a component requires Revit to churn through the regeneration process every time its loaded, changed, accessed or reloaded. I try to limit the number of family types that are pre-loaded into a model to five. Any more than that, the model bogs down trying to refresh. Type catalogs are the most appropriate solution as they make the models fast on the load/reload, give the user the ability to sort and filter through choices based on data in the model, and also allow ONLY the types that are needed to be placed in the model. This is a tremendous help when trying to stay organized within your model.
  
• Calculations - While helpful, they can slow down the speed of the model by forcing Revit to constantly recalculate when the value is more efficiently placed in a family type or type catalog. Calculations have their place though. Instance parameters are perfect for calculations. I wrote a calculation that returns if and in which zones a window will meet ENERGYSTAR based on the U Factor and Solar Heat Gain Coefficient that is inserted by the user. Since those values are determined based on which glass is used, it is better suited to allow the user to insert the values, else the type catalog can become unbearably large.
  
• Void Geometry - I'm not going to say not to use void geometry, but I will say to use it sparingly. for whatever reason, it seems that voids slow down BIM content. Avoid creating hollow solids where the inside of a component is not visible (Water is not really going flow though that pipe), and join multiple solids where possible.
  
• Really Small Polygons - This applies to both solid and void geometry; don't bother with the 1/16" just and jogs in the profile of a window frame. While this type of detail is great on Engineering drawings, nobody is going to export the family file for machining.
  

  Rule of Thumb: If you can't see it from 10 feet away in its installed position, think carefully about its relevance.
  

• Arrays - Again, use them, but use them sparingly. Arrays are a computational HOG. In many cases there is no way around them, but use simpler geometry, and array nested families instead of solids where practical.
  
• Nesting a Nested Nest - I am a true believer in the use of nested families, especially shared nested families. The streamline everything and allow you to create some powerful tools, but that is another blog entry. It's important not to nest items too deeply though. If you nest twice, three times or more, each step requires computation. If you nest everything into the host and align reference planes accordingly, you'll end up with a faster model with less fat, not to mention less chance of errors in forgetting to link parameters together.
  

Generally speaking, I like to keep content to roughly 600KB with a load/refresh of less than 5-10 seconds, unless its a very detailed component that's only being used once (Like a entire ice hockey rink in one family). There is more to content size than the number of Kilobytes it takes up. How quickly it computes is just as important as how big it is in terms of the file size. Many of these points speak to both file size and computational speed, so go forth and find that delicate balance between size and speed. It's a fine line, but it's important that we walk it.

BIM and Roof Systems

In developing a BIM roof system, it is important to understand that the actual materials are what determine the performance and construction of the overall roof. The type of roof covering used is considered based on not just aesthetics, but roof slope and local weather conditions. The secondary roofing materials are determined based on their individual merits as well; substrates are based on the building’s overall design, structural properties and locale; a vapor barrier is selected when or if certain moisture vapor properties merit its need; insulations carry specific R-Values important to the energy performance and code compliance of a building; the roof system attachment method is typically based on requirements of local codes. It is not necessary to understand how and why to use the specific materials when developing a BIM roof object. Realize though that the roof system is not just a slab that stops water from coming in. The appearance of the materials used in the roof system will determine how the details turn out. Use an appropriate surface pattern to convey the basic appearance of the upper most layer of the roof. Layers embedded inside of the roof will never be visible, and have little or no value to the model’s success. Cut patterns assign a symbolic appearance to various types of materials. The Uniform Drawing Standard (UDS) and National CAD Standard (NCS) have uniform symbolic patterns assigned to various materials. Using industry accepted patterns allows existing technology to be implemented into BIM technology without the need for reinventing a perfectly useable process. Each material has the ability to carry its own set of performance values which can be leveraged for model analysis and quantity estimation. A model calculates the length, area, and volume of a roof or roof material, but does not consider the unit by which the material is sold (Roll, Pail, Gallon, Cartridge, etc.) Where unit coverage rates are specified for given materials, an accurate estimate of the number of necessary units can be derived from the model, considerably decreasing the amount of time required to estimate a project. Later in this chapter, we will discuss in more depth the types of calculations that are possible from roof materials which carry a substantial amount of information. Roof System Components There are five main components that make up the basis of design for a roof system. In some cases others may be added and some omitted, but the primary components that should be considered for roof systems will allow others to be built from them and easily reused. § Substrate - The roof substrate is the structural component associated with the roof system. Functionally, it is the deck on which the thermal and waterproofing products sit. There are several types of substrates which may be used, the most common being Wood, Concrete and Steel. Unless the framing members are placed individually as described in chapter 28, roof systems should contain a material layer for the structural framing in order to consider the overall thickness for potential clash detection analysis.

*While the roof deck is arguably not a part of the roof system, it is not appropriate or effective to create one roof for the structure and deck and another roof above for the waterproofing system. It creates a conflict when placing components on the roof that are designed to cut a hole in the roof on placement.

§ Air/Vapor Barrier - Vapor barriers are very thin membranes typically placed between the substrate and the insulation. Even though the thickness is negligible, it is important to represent them in the model with a thickness appropriate enough to graphically display the material in a section view. Without giving the air/vapor barrier a thickness, providing call-outs or annotations of the material in detail section views is made more difficult.

§ Thermal Barrier - Roof insulation provides the thermal barrier between the building and the outside world. Just as a hat protects your head, since hot air rises, insulating a roof keeps the building’s heat from escaping. In some cases the insulation may be placed below the roof deck, and in other cases, it may be placed above the deck. In either case, its thickness should be easily adjustable and carry its R-Value in order to determine qualify the appropriate thermal protection used in a project. In addition to thermal properties, roof insulation may also provide slope, so the ability to taper the insulation independent from the roof structure is important.

§ Waterproofing Material - Shingles, membranes, metal and sprayed elastomeric coatings are all types of waterproofing. In most cases, this is the uppermost layer of the roof, and should carry some type of surface pattern to differentiate it from other roof types within the model view. Often, the roof covering is selected based on its appearance, and since there are so many options for roof coverings, it is important to have a good sample image swatch available for rendering the roof’s final appearance.

§ Roof System Attachment - Regardless of the type of roof, it needs to be attached in one fashion or another. Because it can affect how the roof performs or whether it meets the local building code’s requirements, it is important to add it as a layer in the roof system. Having it in the roof system as a layer allows the attachment method to be quickly called-out or switched if necessary.

The Ever-Evolving Specification

BIM has two main parts to it; graphics and information. It is the responsibility of the Architect to ensure the graphics are correct and appropriate for construction, and the role of the specifier to ensure the project information is correct on the behalf of the Architect. It seems only natural then to place the responsibility of BIM information management in the hands of the specifier. Over the years, the tools of the specifier have improved. Beginning with the pen, and moving to the typewriter, followed by the word processor. Once again, the specifier is experiencing a process improvement which inevitably leads them to the database.
Databases house the salient parts of a specification for easy and repetitive retrieval while maintaining the consistency of the final delivered specification. The “Office Master” is the most common example of this. Most specifiers and architects offices have guide specifications which are used over and over in order to simplify the task of specification writing this is a rudimentary, but effective method of making a database of project information for reuse. The shortcoming of the office master is that it needs constant maintenance as products, building codes and design requirements change over the years.

AIA MasterSpec, ARCAT SpecWizard and other similar online “guide specification” libraries allow for the simplified creation of project manuals on an individual basis, by providing ready-to-use formatted specifications which can be easily implemented into projects based on either required performance values, industry standards or actual products. Which type to use is dependent on the project delivery method used on a given project. These online libraries are giving way to the concept of integrating the information from a BIM model with the project manual by providing a single database where product information is stored for multiple products. Where a specification and BIM object are sourced from the same location, and driven by the same database, there is a level of consistency not easily attainable by other means.
The possibility exists to create a short-form or outline specification, a long form specification and a BIM component all using the same series of dropdowns. Rather than a printed document being the only deliverable of a specifier, consider just how critical the responsibility of selecting the most appropriate component for a given project is. If the ability to review and select products and systems for a project extended to formatting a BIM component based on the required performance and appearance characteristics, the final project documentation and specification would be simplified considerably.

The concept of a specification is to provide documentation of specific elements of a project. It expands upon what is selected to explain why it is used. If you think of a specification in terms of what it is designed to do, much of it is broken into pairs of Attribute and Value, where the attribute is the “what” and the value is the “why”. This is the baseline concept for creating a specification from a database. Some examples of attribute and value pairs are:

§ Color: Green
§ Length: 12 inches
§ R-Value: 19
§ Tensile Strength: 1000 ksi
§ Warranty: Ten (10) Years

While not all aspects of a specification can be broken into these pairs, it can encompass most if not all of the critical aspects of product selection and implementation. The balance of the specification can be formatted through development of a pre-formatted guide specification which would act as a form which the data would be filled into.