Monday, September 27, 2010

Organizing BIM Content by how it is used

Implementing the Component: Primary, Secondary, and Tertiary

Components which are added to an architectural model can be categorized as primary, secondary, and tertiary. Exactly which category a specific component fits into depends largely on the individual or discipline. In addition to the architectural components, a series of structural, mechanical and specialty components are used to further detail the model for design and analysis through specialty consultants and contractors. For architectural purposes, it is not always necessary to add each structural element, mechanical equipment, or specialty components unrelated to the design intent. In many cases taking into consideration only basic dimensions and locations is acceptable to allow other contractors and consultants to design based on the spaces allotted. While this is a disjointed approach and in no way collaborative, it is not an uncommon practice, and as such should be taken into consideration when thinking about how to organize the various types of components used in modeling.

Primary components are made up of the core elements used to enclose and access spaces; floors, walls, ceilings, roofs, and openings. These elements of the project are the first to be added, often during schematic design. They divide spaces, create layouts, and enclose the overall building. Walls are added into a project and used to enclose and divide spaces. It is important to maintain a consistent reference point within the wall so that they align properly. Because walls have several materials within them, from structural, to surfaces, to finishes, and determining the reference point is often specific to the needs or type of project at hand. When creating exterior walls, using the exterior edge of the structural member as the reference plane may prove to be the most effective, where when creating interior walls, the center line of the wall may be most effective. Using a consistent strategy for aligning walls minimizes the risk of errors through design development. In many cases the number of layers and thickness of materials within the wall is unknown until well after the original walls have been placed. A great deal of time is spent manipulating these elements such that they may become permanent as design development progresses. Once the design begins to consider secondary components, it is common for errors to occur should the primary components need to be moved or changed. Developing a strategy for creating, maintaining, and organizing wall assemblies will allow walls to be swapped out at any time without the risk of moving walls due to differing reference points.

As Bim technology improves, the number of components which may be defined as secondary is increasing. Before they were made readily available, components like toilet partitions and fixed furnishings were not always graphically modeled. This is largely due to the amount of effort required to create a graphic representation of a component. As more manufacturers make their components available, the number of designers wanting to place them in their model increases.

Secondary components are essential to the design, but made remain largely unknown or undecided until later in design development. They rely on the dimensions and locations of the primary components for decision-making and product selection, and are generally non-structural in nature. The most common secondary components on projects are stairs and railings, fixtures and fittings, casework and cabinetry, specialty partitions, and certain types of fixed furnishings and storage. These types of components are essential to the understanding of spatial relationships, and the conceptualization of many aspects of the project. It gives the owner an understanding of what the space is used for. The walls may define the boundary of a kitchen, but the cabinets determine what it is.

If we think about different components in relationship to the overall size of the project, we can make the determination of how graphically accurate they need to be. Secondary components are those that are integral to the design, but not integral to the structure. In most cases these types of components are selected based on their appearance as much as they are based on their performance. When component is selected partially or entirely based on its aesthetic, how it is represented within the model becomes more important. The frequency at which these components are placed in the model is also a consideration when determining the graphic accuracy. If a component is placed in the project only once but is selected solely based on its aesthetic, it is reasonable to put more effort into its graphic accuracy, as maintaining its performance and file size is not as relevant as a component such as a door which may be placed hundreds of times throughout a single project.

Component size and location also come into play when considering the graphic accuracy of an object. A good rule of thumb is if you can't see it from 10 to 15 feet away in its installed position, don't spend a lot of time on it. This is a typical distance which is used for up-close rendering. Since the primary reason for making close representations of products is to improve the rendering aspect of the model, if it's not being rendered, it might as well be a cube. There are many components in a project that are actually very small. Whether it is a light switch, a drawer pull, or a window crank, deciding how accurate these components must be is important undertaking. While every manufacturer wants to think that their components are the most important, we have to look at the model in terms of scale. Ask yourself how important a window crank is to a 1,000,000 ft.² building, and what purpose it serves if it is not visible in rendered views. The answer lies in its ability to be quantified and qualified. If a component needs to be quantified or qualified, it can add value to the model. Let's go back to window hardware as an example and look at three possible scenarios: 1.) If a manufacturer offers several hardware options, and it will likely be visible in many rendered views, it should be added to the model graphically and have the ability to select options. 2.) If a manufacturer offers several options for the type of hardware used but it will not be seen in a rendered view, it is more effective to list the hardware as an attribute of the window without graphically modeling it. 3.) If only one type of hardware is available from the manufacturer, is perfectly acceptable to omit from both the graphics and the information contained in the project. If there are no choices which may be made, and the component is not commonly used for selection or specification purposes, then adding it to the model offers little value to the architect, specifier, or contractor.

Bob's BIM Tip: If you can't see a component from 10 to 15 feet away in its installed position, don't spend a lot of time on it.

Tertiary components are those which are added during detailing, or not at all. While it is my belief that every component that is used on a project should be brought into the model in some way, shape, or form, that does not necessarily mean it should be done graphically. There are ways to embed information regarding components without actually placing them in the project, and there are ways to simplify how a tertiary component is placed in a model as well. Hopefully this will minimize the number of tertiary components within a project, and increase the number of secondary components. Over time this could translate into more accurate models, and a greater demand for as-built models as a final deliverable to the owner.

A component like door hardware is an essential element within a project, is found in hundreds of locations, and even has its own special schedule, yet it is arguably a tertiary component which is often overlooked or omitted. Most architects choose not to deal with door hardware for the amount of effort necessary versus the benefit received from placing it in the model. Components like this are often better represented in context. Door hardware is a function of a door, and as such should be placed and controlled from within that door. Rather than attempting to place door hardware components at each location within the project, making door hardware a function of the door itself can allow it to be a graphic aspect of the model, and carry the important information to its respective schedules.

Accessories, movable furnishings, and equipment are tertiary components. Because they may be relocated at any time, and are more commonly used for conceptualization and space planning, these types of components are typically not modeled. As a general rule, when the placement of a component is not integral to the structure or the design of a project, the component can be considered "tertiary". Another way to look at it is if there is no specification section for the component within the project, it is probably a tertiary component.

Saturday, September 11, 2010

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.

Wednesday, June 2, 2010

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.

Tuesday, June 1, 2010

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.