Class Description - file · Web view2/7/2015 · The source models were used...

Session 2.3

RVT, IFC, RCS, and an NWF to Clash Them AllTom Whitehead, SERA Architects, Portland

Class DescriptionWith 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 AllTom Whitehead, SERA Architects

Figure 1: an overview of the job

The ProjectThis 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

of 14


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 NeedsThis 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 SetupAs 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.

GroundworkFor 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 construction. Along with multiple shared parameters we built into

of 14


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 filesGiven 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 building. The reasoning was that the partners

of 14


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 NWDFor 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.

MechanicsWithout 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 ThingsAs 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 a predetermined directory. This also allowed for quickly locating and checking on when we last received an updated file.

of 14

http://www.imaginit.com/software/imaginit-utilities-other-products

http://www.imaginit.com/software/imaginit-utilities-other-products

http://www.rtvtools.com/rtv-xporter-pro/


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 PlanningFor 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.

Plan, meet RealityThe 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

of 14


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 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

of 14


were involved. We leveraged the client’s extensive naming standards to keep everyone on the same page.

Generating the Search SetsYou 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 StepsXML 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 termsBecause 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.

ExportPretty simple here, just export. It is a transitional file but you’ll need it later.

of 14

http://danielgijsbers.blogspot.nl/2013/11/navisworks-searchset-creation.html


Open XML in Text EditorWhat 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

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.

of 14


Populate Excel with dataThe 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),"-",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.

of 14

http://stackoverflow.com/questions/14990236/how-to-create-a-guid-in-excel

http://stackoverflow.com/questions/14990236/how-to-create-a-guid-in-excel


Add Place Holder Text and OrganizeThere 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 textThis 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 ReplaceOpen 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

ImportChange 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 assetsOnce 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 TemplateMany 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 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

of 14


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\

ExportFor 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.

ConclusionsBy 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.

CreditsI 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

of 14


very excellent advisors when I needed to bounce ideas off of someone. And all of the blog posts listed below as references were invaluable.

of 14

i 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.htmliv http://stackoverflow.com/questions/14990236/how-to-create-a-guid-in-excelv http://forums.autodesk.com/t5/navisworks-general-discussion/where-are-clash-rules-stored/td-p/5301917

Class Description - file · Web view2/7/2015 · The source models were used...

Documents

Transcript of Class Description - file · Web view2/7/2015 · The source models were used...