Session 2.3
RVT, IFC, RCS, and an NWF to Clash Them All
Tom Whitehead, SERA Architects, Portland
Class Description
With large and complex projects with multiple participants from varying trades and
platforms, it becomes critical to keep everyone working. In this class, I'll discuss
strategies for managing all of the data, producing relevant clash reports, and
keeping your Navisworks running through the process.
About the Speaker:
In the past 20 years, Tom Whitehead has worked with rocket scientists, commercial
art directors, network engineers, web developers, architects, mechanical, electrical
and structural engineers. He started with Revit in 2008 and has been a BIM
evangelist ever since. Currently he is BIM Manager for SERA Architects in Portland,
Oregon. In 2013, he was selected to participate in one of Autodesk’s Revit
Gunslinger events and is active on RevitForum.org. Tom is an avid camper, loves
live music, and lives with his wife and two young children in Portland, Oregon.
RVT, IFC, RCS, and an NWF to Clash Them All
Tom Whitehead, SERA Architects
Figure 1: an overview of the job
The Project
This work was all done on a project that consisted of an elevated pathway or
bridge between three buildings that provided a cleanroom corridor and additional
work across eight other supporting buildings in a portion of a larger manufacturing
facility. The NWC and NWD files were updated daily throughout the project with
the NWDs being delivered to the construction trades, client and distributed within
the design team. The source models were used for piping fabrication, precision
steel and foundation layout, reinforcement quantity and prefabrication of structural
elements. Our work encompassed at least 10 buildings with 13 different disciplines
internally and 4 outside consultants providing some sort of model data. File types
included RVT, IFC and RCS as inputs. Revit files came from our work and from two of
the consultants, IFC from fire protection and RCS files for existing condition
information.
By The Numbers


8gb of Revit model data (~102 model files)
200mb of IFC data
Page 2 of 13
RVT, IFC, RCS, and an NWF to Clash Them All
Tom Whitehead, SERA Architects

475gb of point cloud data
-or



120 RVT Model Files
*Not all RVT files produced NWC data
70 NWC Files
207 RCS files
2 IFC Files
Goals and Needs
This plan was to provide an all encompassing, fabrication level model for design
through to construction. Revit provided most of the design data including
fabrication drawings with point clouds and ancillary formats coming from outside
specialty consultants. But we needed to provide a format for the construction
trades to use for visualization, the client to use for review, and for our internal use for
clash detection and coordination. Navisworks provided a lighter weight version of
the model and a way to efficiently handle coordination.
Due to the size of the project we couldn’t just rely on standard clash methods as
the results would be too overwhelming and wouldn’t be focused to the immediate
needs of the team. This was not set up to clash one model or discipline against the
remainder of the trades. Instead it was designed to focus on particular areas or
scopes so that the team could manage problems as they needed to be resolved
instead of all at once.
Project Setup
As with any job of this scale the real work starts long before the first model is
created or populated. In this case it was coming up with ways to manage the
clashes in a logical fashion and in a way that everyone could understand.
Groundwork
For this client all the work was subdivided into scopes that roughly related to the
schedule and packages that would be delivered. Due to their nature it didn’t
really follow normal conventions but you could think of it as dozens of projects
running from SD to DD to CD and permit concurrently. For each package it would
be ideal to only focus on problems just as the package was released for
Page 3 of 13
RVT, IFC, RCS, and an NWF to Clash Them All
Tom Whitehead, SERA Architects
construction. Along with multiple shared parameters we built into the projects we
also added scope indicators to every object category as an instance parameter.
This shared parameter was used for many things inside of the RVT file but for
Navisworks we would later use it to prioritize clashes.
This particular client had very strict and well-documented standards for naming
conventions, which was a great advantage. This allowed everyone involved to
quickly identify what area or discipline a file covered and, based the format, what
its intended use was. As with anything in this world, not all participants followed the
rules but those outliers highlighted how important those standards were. For every
instance that someone didn’t follow the rules, it
had a cascading effect of generating rework
throughout the project. With any system like this
it will be your biggest and in some cases most
important point to drive home the necessity for
consistency. Sometimes this can be resolved by
data formatting in the parameter itself but we’ll
come back to that trade off shortly.
Base NWF files
Given the end users of the files, we created base
NWF files for each building plus an over-all
campus type NWF that brought all bits and
pieces together. This wasn’t as simple as it might
sound. For the Master.nwf we brought all data
together, all from source NWC, RCS and IFC files.
This was created as the file for clash detection
and overall visualization if needed. But we
didn’t append the building NWF files as it would
have added some unnecessary complexity to
the hierarchy. In hindsight that may have
worked out better in some cases but all in all it
worked well for what it was intended to do.
For the building NWFs we only included NWC files
from the revit models associated with the
Page 4 of 13
RVT, IFC, RCS, and an NWF to Clash Them All
Tom Whitehead, SERA Architects
building. The reasoning was that the partners
wouldn’t want or need that master.NWD file
for general viewing. Also, since these building
files only had the design data, they were
faster to load and navigate for the users that
only need to look at one building vs the entire
project.
Published NWD
For handoff to all parties we published NWD
files, a total of 11, every day. The NWD
worked multiple purposes for all members of
the team. Since some of the NWF files were actively being edited (QTO, Clash
Reports, etc) the published NWDs provided a very safe way to get a snapshot of
the building or project without accidentally tinkering with what the BIM department
needed for deliverables. For the trades and client this was a daily update of design
progression for review. We also archived all these so that later down the line it was
also used to resolve arguments about who did what, when.
Mechanics
Without some automation none of this would have been very possible. Luckily we
had a developer build a custom application that offloaded the nightly builds to a
remote workstation loaded with memory. But there are other solutions out there
that will effectively do the same sort of things from a variety of vendors. Here are a
few examples:
RTVTools Xporter Pro http://www.rtvtools.com/rtv-xporter-pro/
Imaginit Clarity http://www.imaginit.com/software/imaginit-utilities-other-products
Standards for All the Things
As I’ve mentioned the standards were very important for a number of reasons.
Obviously clarity but beyond that all of the data had to match up and be easily
located. With the automation system we were using some of the job of appending
new files, new files from a vendor as an example, only required me to put the files in
Page 5 of 13
RVT, IFC, RCS, and an NWF to Clash Them All
Tom Whitehead, SERA Architects
a predetermined directory. This also allowed for quickly locating and checking on
when we last received an updated file.
For some of our files they were segregated out due to IP restrictions. The client
didn’t want any of the scan data to be handed off to anyone that wasn’t cleared.
As a result those files (rcs) were on a separate drive and not published into the
NWDs.
Along the same lines the parameters we were using had to be coded properly. In
other words the scope of work had to be consistently formatted in every model.
Going back to the comment earlier, some of this could have been solved by
creating the parameter differently. Please learn from this mistake, this caused huge
amounts of rework due to a change well after we had the project up and running.
The Importance of Planning
For the scope of work there had been much discussion on how exactly they would
be identified and how they would be grouped into “packages”. Each package
would be delivered whole as its own “construction set”. Multiple scopes of work
would be attached to A package according to the design phase. The scope
would only occur in one package but multiple scopes could be bundled into a
package. There was some concern about exactly how the scope of work would
be identified, along with the package identifier so the only option was to create
both parameters as text parameters. This is what generated two very large
problems.
Because of the assumption that a scope would only occur in one package the
“package parameter” (PKG)i was applied to only sheets and a few other objects
while the “scope parameter” (WS) was applied to all modelled objects. Since the
WS wasn’t standardized it was the best we could do at the time, gave us the most
flexibility. In reality it was a 3 digit number, like “123” that ranged from 001 to 350 or
so. Each package would have a search set created in the NWF that would search
through all WS numbers that fell into that package. Those sets would be clashed
against the rest of the model. This way, the team could focus on the urgent and
most developed packages when necessary instead of worrying about ALL clashes,
even those in areas that weren’t nearly complete.
Page 6 of 13
RVT, IFC, RCS, and an NWF to Clash Them All
Tom Whitehead, SERA Architects
Plan, meet Reality
The reality is that not all the team knew about this structure. As a result many
scopes (WS) ended up traversing multiple packages, resulting in no way to identify
which objects needed immediate attention without looking through all clashes in a
scope. Some of those clashes, and in a few cases most, didn’t apply to the most
urgent package. In hindsight I’m sure you can see the problem and multiple ways
to resolve. We could have coded the WS parameter to include package
information from the beginning. Scheduling could have followed through on the
plan as set out. I’m sure you even see more yourself.
But with even the most meticulous planning there has to be some standards set to
make this work. iiBecause of the vernacular of the site there initially was confusion
on how the scope (WS) was named. The reality it was a 3-digit number. But the
entries ranged wildly based on interpretation. For example: WS-1, WS001, 1, 001,
WS-001, WorkScope-001. You get the idea. Due to the formatting of the parameter
being set to generic text, it meant all of these were viable. We luckily saw the issue
early in the project and solved the problem with a very clear set of communication
that the format was always and only 3 digits.
CLASH ALL THE THINGS!! Or not…
As you saw above there were lots of Revit files and disciplines to deal with and due
to the speed and size it just wasn’t possible to clash all pipes against everything else
as an example. So we used the above scheme to break it down into manageable
chunks as if the packages were individual projects.
Along the same lines we had to limit what was involved in clashes. Due to the sheer
size point clouds were segregated into their own clash tests. We also limited our
scope to only to the design models for the most part. The point clouds reflected
the existing conditions without requiring us to model every element and allowed
greater accuracy of those conditions compared to legacy DWG files.
For reporting purposes I didn’t want to overwhelm people with the mountain of
clashes that came out of the model. Every week I would go through and group
new clashes into logical collections, name them and provide indicators where the
clashes were in a saved viewpoint. Those clashes were reported out in a number of
ways but the viewpoints were also utilized directly in the resulting models. Because
some of the parties didn’t have Navisworks Manage we needed to relay that
Page 7 of 13
RVT, IFC, RCS, and an NWF to Clash Them All
Tom Whitehead, SERA Architects
information as best as possible and the saved viewpoints provided that function to
them. Again we utilized a standard that relayed when the clash was found, which
disciplines were involved and what type of objects were involved. We leveraged
the client’s extensive naming standards to keep everyone on the same page.
Generating the Search Sets
You might have gathered above that given this structure we needed to generate
about 300 search sets to match all the different scopes (WS). There were ways to
group them together but many users wanted to isolate down to a particular scope
and look through the model or to verify as they were designing. And to increase
flexibility each scope should have its own search set to allow for moving a scope to
a different package or used in other ways.
Creating a search set isn’t hard but when faced with creating 300 (the reality is
there were quite a bit more than that) the job becomes a tedious slog of clicks and
editing tiny fields. I hate that so I cobbled up a better system.
I started by running across this iiiblog post by Daniel Gijsbers. But I found a couple of
problems with it. I didn’t want to copy and paste a few dozen times and I didn’t
think my Notepad++ skills would be up to the task. Not to mention that list of scope
numbers wasn’t consecutive. There were random gaps throughout it. So I fired up
Excel and built it there.
300 Search Sets in X Easy Steps
XML is a great format that allows pretty much anything that can save .txt files work
as an editor. There is much more to the format and structure but essentially it can
be manipulated with something as simple as notepad or TextEdit, no fancy XML
editor needed. The strategy is a bit clunky and I’m sure there are better ways to do
this but this does work with little more than some Excel formulas and fancy find and
replace.
Create initial set with parameter and terms
Because I’m not an XML guru and can parse the file structure automatically I used
a crutch. I created a search set example in a blank NWF with just one model
loaded. The search set was configured with all the proper settings, then I exported
it to an XML file.
Page 8 of 13
RVT, IFC, RCS, and an NWF to Clash Them All
Tom Whitehead, SERA Architects
Export
Pretty simple here, just export. It is a transitional file but you’ll need it later.
Open XML in Text Editor
What you are looking at is similar to HTML. The trick is to see the patterns needed to
recreate hundreds of search sets and even group them quickly without dealing
with the UI in Navisworks. Specifically we are looking for this:
Figure 2: Raw SearchSet Export
Page 9 of 13
RVT, IFC, RCS, and an NWF to Clash Them All
Tom Whitehead, SERA Architects
The items I’ve highlighted in yellow are variables. And if you look closely I’ve
actually exported two search sets. These are what we want to generate in Excel as
it is pretty easy to iterate through numbers and generate the GUID field there.
Populate Excel with data
The trick here is Excel will increment and allow lots of little tricks to make this fast.
We’ll start with three columns as we have three variables really:
So our first column is Set Name, or the name of the search set as shown in
Navisworks, second is GUID, third is the search term. In my case I did a little
concatenation to generate the name based on the search terms. Each scope was
a different search set.
Generate GUID – the magic sauce
I’m sure you’ve all dealt with a GUID in some way. What I didn’t know is effectively
they are random generated hex numbers. You could just randomly place
characters from 0-H but why not have Excel do it for you. Well you can and here’s
the formula:
=CONCATENATE(DEC2HEX(RANDBETWEEN(0,4294967295),8),"",DEC2HEX(RANDBETWEEN(0,65535),4),"",DEC2HEX(RANDBETWEEN(16384,20479),4),"-
Page 10 of 13
RVT, IFC, RCS, and an NWF to Clash Them All
Tom Whitehead, SERA Architects
",DEC2HEX(RANDBETWEEN(32768,49150),4),"",DEC2HEX(RANDBETWEEN(0,65535),4),DEC2HEX(RANDBETWEEN(0,4294967295),8))
Now I didn’t think of that on my own, I ran across it in this little post, “How to create
GUID in Excel” at Stackoverflowiv.
Add Place Holder Text and Organize
There may be a way to do this utilizing Word’s Mail Merge function but I went with a
simpler way. I saw the pieces between the variables repeating so I added markers
to represent text I’d replace later. This allowed me to not only generate the
required search sets but also pre-group them into folders. See “SetsWGroups.xlsx”
as an example.
Save as text
This ends up being a two-step process. You can’t just save your excel file as a CSV
(which is text effectively), because it will take the formulas and keep those in the
cells, you want the resultant data. So Copy the three columns you need (set name,
GUID, and search text) and paste as just test (no formatting) into a new
spreadsheet. Then save that as CSV. Then change the csv to txt
Find And Replace
Open our newly minted TXT file in your favourite text editor. All you are going to do
is replace items like “prefix” with "> <selectionset name=" working your way through the
file. See the files textfromXLS.txt and aftersearch-replace.txt
Import
Change the file extension to XML and import into your search sets in Navisworks.
Congratulations, you just created 252 search sets in about 20 minutes.
Leveraging your assets
Once you’ve put all this effort into your Navisworks models you’ll want to reuse the
settings as much as possible. Most of this is easy once you know the various
limitations. NWF files don’t have a template file and all of the various tools have
their own exported configurations, except those that don’t!
NWF as a Template
Many of the users on this job wanted to create their own versions of the files,
appending or removing data as needed. Which is great except most weren’t
Page 11 of 13
RVT, IFC, RCS, and an NWF to Clash Them All
Tom Whitehead, SERA Architects
familiar with all the ins and outs of the program and really shouldn’t have been
tweaking any of our production files. The clever fix was to create a NWF that only
had one file appended to it but retained all the search sets, clash rules and tests,
appearance overrides and some basic navigation tweaks. This allowed them to
get started quickly without feeling as if they were starting over from scratch.
It also was used to provide very narrow scope clash tests with vendor files that were
not meant for public consumption. Those were then published to NWD for the
vendor to illustrate problems.
Rules Rule… and can be a painv
Navisworks won’t allow you to export rules though. And rules don’t necessarily
follow the NWF file. They live in your local machine. Theoretically they move
whenever a clash test utilizes a rule it will stay in the NWF but normally those rules just
live here: C:\Users\<username>\AppData\Roaming\Autodesk Navisworks
Manage 2015\clash\
Export
For everything else, export a copy of your settings. You will be surprised how useful
these things will be as you work through your projects. Appearance profiles can
get altered or lost fairly easily. Quickly resolved by importing them again. UI
settings are the same way. Clash Tests, Search Sets all can be exported and reused
if needed in other files and will save you loads of time setting up files.
Conclusions
By no means do I claim to know everything about Navisworks. I will say that with
the tools outlined here I did make this project function through most of its
completion with little complaint or failure. In some cases we pushed Navisworks too
hard and some systems not mentioned here did fail. I hope that you found
something useful but I don’t think for an instance that someone couldn’t find better
ways to do some of this. I used the tools I had and got results. I hope my efforts at
least gave you ideas to use the next time around. The point is, don’t take this as
gospel. I did the best that I could with the tools I had.
Page 12 of 13
RVT, IFC, RCS, and an NWF to Clash Them All
Tom Whitehead, SERA Architects
Credits
I couldn’t have done what I did in this project without guidance and at least
consultation from my co-workers at SSOE. Matt Nelson originally set these files up, I
just took them over after he left. Jason Rostar and Chris Ridder were my very
excellent advisors when I needed to bounce ideas off of someone. And all of the
blog posts listed below as references were invaluable.
Never use such generic names for your parameters. We had a very particular
coding for all our shared parameters and this is just an example.
ii Yes, I’m being very obtuse here. The client is very particular about their IP, I’m
doing my best to obscure it as much as possible.
iii http://danielgijsbers.blogspot.nl/2013/11/navisworks-searchset-creation.html
iv http://stackoverflow.com/questions/14990236/how-to-create-a-guid-in-excel
v http://forums.autodesk.com/t5/navisworks-general-discussion/where-are-clashrules-stored/td-p/5301917
i
Page 13 of 13