Are You Breaking Revit?
Like it or not, Autodesk® Revit® has a certain way that it wants to function. First imaged as an architectural tool, it was six years before mechanical and electrical functions were added to the architectural base. Users still find there are constraints in Revit’s very DNA that limit the way an MEP designer might have traditionally worked. As Revit has evolved over the years, MEP users have not always been quick to adapt. The mindset of “set it and forget it” has left many firms with outdated processes yet again. The relationship between the MEP user and the software is a constant dance of power struggles, love, hate, disaster, success, and hopefully an acceptable mutual benefit.
In the heat of the battle of customizing the software, workarounds, and hacks, we may now realize that an awesome hack five years ago may be baggage today. Revit is fully mature software with 17 years of history. At this stage of the game, it is time to reflect why we chose to fight the way Revit wants to work and to question if how we modified it is still valid.
In the situation of investing in a brand new firm, would the preference be to seek cutting-edge technologies and processes or to fall back on tested and true? It’s not really “this or that?” in real life, but where on the spectrum is the balance between comfort and profitability?
During the initial transition to Revit, many firms chose to try and maintain as familiar an environment as possible. Not just familiar symbology and processes, but familiar output, i.e., traditional construction documents. Starting out with the goal of forcing Revit to conform to AutoCAD® standards and procedures, which mimicked hand drafting, many firms inadvertently dragged outdated concepts and baggage forward. This resulted in paying more and working harder to produce the same product as before, essentially sacrificing forward momentum for an easier transition.
Some examples of “breaking” Revit and missed Revit advancements should help illustrate the types of choices that users should be re-evaluating now that the transition is long over.
Spaces v Rooms
Early on, linked rooms could not be tagged. MEP users who wanted options on room tags for line weight and location could create spaces that linked to rooms in the linked model, and then those spaces could be tagged with the room information. If those spaces are not being used for any other purpose, the need for them expired with the ability to tag linked rooms. Questions that should be asked include: what is the firm using spaces for? And is there an advantage to tagging rooms even if spaces are required for other needs?
Figure 1: Space and Room schedules
Hosting
Face based, level based, wall, element based? With every implementation came a decision of how MEP elements should interact with linked architectural files. Looking at generic templates today, some may be surprised to find eight choices for generic models. Questions that should be asked include: why was the hosting configuration that was settled on selected? Is it still valid when considering individual elements? From a production standpoint, is there a better choice now?
Figure 2: Generic templates
Single Model / Linked Models
System requirements and the financial burden of not only acquiring new software, but upgrading all the hardware for Revit did not lend itself to supporting a single model system even in firms that housed architectural, structural, and MEP under the same roof. While all the BIM presentations used a single model, reality was not only hardware and cost prohibitive, but also the three flavors of designers didn’t necessarily want to know what everybody was up to every second of the design. MEP design methods are based off iterations, but not constant iterations. Seeing a wall shift and change over a day does not change the basic requirement of MEP design—it is just an additional detail to keep track of.
Today, using Collaboration for Revit (C4R) enables the initial promise of BIM, a single-source repository of design information that is searchable, assessable, and accurate. The additional social tools remove barriers to communication, further tightening the design and saving time while opening more design possibilities. Working together means more detailed exposure to work habits that aren’t always good. In addition to the technical framework, there is a level of trust that must exist for the single-model method to work.
Most firms likely find themselves with a foot on both sides of the line since the release of C4R. Questions that should be asked at this point include: can the benefits of switching to a single model outweigh the effort involved in making that switch? And what is involved in making a single-model environment?
Worksets
Worksets were invented to solve the problem of multiple users in a single model trying to share the elements within. By assigning all elements to functional worksets such as “East Wing,” “Lighting,” or “HVAC,” a user can check out a group of elements to work on, as one would check out a library book. Good for the element owner, but restrictive to the other users who might encounter elements not in their current workset. Just as folks were getting settled with standard ways to divide a model into worksets, Autodesk introduced element borrowing. Nearly overnight worksets lost their meaning. If checking out a workset is no longer necessary, why do they exist?
Well, the basic programming of Revit mandates that a workshared file has worksets. Clever users discovered that worksets could be excluded on open, resulting in project worksets that followed disciplines. Now users could choose not to load the structural workset, saving time to open while dropping the weight of unopened worksets. This was and is widely embraced, yet it breaks a fundamental reason for using Revit—a reliable complete model. Some may argue that a 3D silo of information is better than a 2D silo, but the third dimension is only required for interference mitigation. Not combining models is no better than the traditional design method.
Traditionally, BIM managers have believed that models should be broke into functional worksets, but too many worksets will cause trouble. Personal experience tells me this is not true. The 30 standard worksets in my template have produced no issues over 10 years of use. They are used as a visibility control to turn on or off large and varied groups of elements by their workset.
During our transition from AutoCAD to Revit, Visibility Graphics was a huge problem with linked files and individual view controls. Users got lost as to where elements actually lived and what was controlling their visibility. Users were told to treat worksets like AutoCAD layers. The template for a lighting view had the Lighting workset on and HVAC off. As long as users watched their active workset while placing fixtures and devices like they would watch the active layer in AutoCAD, it would be a no brainer. We had great success and equal failure at times equivalent to an AutoCAD drawing with everything on layer zero.
We also discovered that worksets were a fabulous way to allow for enlarged plans. In a small mechanical room we could call out an enlarged plan from the 1/8” that showed no equipment. The 1/4” enlarged plan would show all the equipment. All possible by adding a M-Enlarged workset.
Figure 3: Worksets
Somewhere along the line I started to realize no matter what my problem was, worksets could be part of the answer. I got carried away. Reflecting back on these decisions and being much farther down the line with users’ Revit confidence, I am not convinced this use of worksets is still completely valid. Questions that should be asked include: what are worksets being used for in my environment? Is that function valid or needed?
BIM Killers
Gathering information for this article, it became clear that the big common thread in transitioning to Revit for many firms was to maintain the non-BIM status quo. In doing so we inadvertently killed many BIM benefits that were the reason we transitioned. Some BIM killers came from Revit’s inability to produce traditional construction documents, and some came from users’ creative workarounds to get traditional construction documents from Revit. MEP users are well versed in examples of this, such as electrical fixtures and devices on sloped ceilings, the need to spread symbolic electrical devices in plan without moving the modeled elements, the ability to show two-line and single-line duct in a the same view for clarity, connectivity between modeled plumbing piping and schematics, stacked piping in the model versus side by side piping in plan, and many more.
Very early on in the development of Revit, the idea of a universal coordinate system was squashed. What did it matter where a model existed—only that it existed? Today, I think the creators would rethink that logic. Not only would it be better than the shared coordinates fix, but it would fundamentally improve Revit’s dislike of any element that slopes.
In the absence of clear standards and acceptable content, many spent the early 2000s building custom families, schedules, and templates specifically for their firms to match their processes and ease their Revit transitions. The result has been BIM silos. I think of it as intranets versus the Internet. My firm has a pretty awesome BIM intranet. It is specific to us and our clients’ needs and ends. Our families are near meaningless to our competitors because they are built on our unique parameters and processes. This was never the intent of BIM, but the reality is that my BIM and everybody else’s BIM are different because one size does not fit all. So will we ever have a BIM Internet? I say no, but it will be okay. We don’t have a single car manufacturer and that works. European cars are different than American cars and again, it’s okay.
In the end it helps to frame decisions on objectives. Be able to clearly define what the objectives are for your firm, for your clients, and how they fit in the larger BIM world. While we are still in the transition period between traditional construction documents and 3D deliverables, we will continue to break Revit to get what we need, but we must also be prepared for letting Revit be Revit when our process meets up with our tools.
