Dynamic Workflow
Autodesk® Navisworks® can read a wide variety of file formats and aggregate them together. The two different file types that can be saved from Navisworks are nwd and nwf. The nwd file type contains all the geometry, metadata, timeliner information, animator sequences, and markups. This file is a static file and does not update geometry when the original authoring file is updated. The nwf file type contains metadata, timeliner information, animator sequences, and markups. It does not contain any model geometry—the nwf file references the original authoring files and displays the geometry shown in those files. When one of the authoring files’ is updated, the nwf will update the geometry displayed in Navisworks.
NWF Workflow
Understanding the workflow of nwf is critical for success. The first activity you must perform is to obtain all the model geometry you wish to review in Navisworks. Often this is a collaborative effort and some sort of ftp site is used. One of the fundamental ground rules for exchanging files is that the files retain the same name version to version. Keeping the same name allows the local file to be overwritten by the new file. Because the nwf is based on filename and file path, overwriting the old file tells Navisworks that it needs to re-cache all the information in the new file.
I have heard significant discussions about version control with the names not changing to reflect a change in the version. Sophisticated file exchange sites such as box.com take care of versioning for you. The benefits that are gained by using the same name far outweigh the chaotic method of including a date or version in the filename.
Figure 1: Naming changes
Once the models have been aggregated and the old files overwritten by the new files, it’s time to open the nwf. Navisworks will automatically create new cache files for any files that were updated.
If you have Navisworks open and you update a model, simply click the refresh button on the quick access toolbar to refresh the geometry in Navisworks. If you get an error that says the file is in use, you need to change an option in Navisworks. Click the Application Button > Options>Model>Performance and click the checkbox next to Close NWC/NWD files on load. This will tell Navisworks to release the files in Windows Explorer after it loads the files into the system. You can then overwrite the files and refresh them in Navisworks.
Figure 2: nwf workflow
NWF Search Sets
Following the nwf standard workflow is critical to prevent loss of work. During the course of a project you will undoubtedly need to test a set of items against another set of items. Perhaps you might need to always hide a certain set of items. For example, suppose you receive a model from the architect that always contains a mechanical system. You want to maintain all the geometry in the architectural model except the mechanical system. You need a set to hide the mechanical system in Navisworks.
The two types of sets in Navisworks are selection sets and search sets. Selection sets create a group of selected geometry into a collection. In Navisworks 2014, if you group objects in a dwg into a selection set and update the dwg file, your selection set will no longer contain the previously selected geometry. This is true even if you do not change the geometry that was contained in the selection set. These sets should be considered temporary sets and should not be depended on over the iterative coordination process.
Search sets are dynamic in nature and will update as the geometry in Navisworks changes. Search sets are queries defined by the user to aggregate model geometry into a collection. A best practice is to use search sets for all clashes to maintain a dynamic relationship. For example, if you are clashing the mechanical system against the ceiling system, it is best to create a search set that contains the mechanical geometry and test it against another search set that contains the ceiling geometry.
Often, these sets will need to cover multiple files. In this example, suppose you had a file naming convention which stated that all mechanical filenames were to include the word Mech. You could easily create a search set with the definition shown in Figure 3. The ceiling search set is even more critical because often the ceiling geometry is contained in the larger architectural file. By creating the search criteria to find all ceilings, you are able to extract just the ceiling geometry for testing. When the mechanical and architectural models are updated, their search sets will find the geometry changes and the clash test can simply re-run to review the changes.
Figure 3: Mechanical search set
Some might wonder what is the point of setting up a search set that contains the mechanical files instead of simply selecting the mechanical filenames in the Select tab of the Clash Detective. The reason the search set is better is because it will capture any new models that are appended into the project.
Suppose you start out with six mechanical files on a floor, then midway through coordination a change order adds a new system to the mechanical contract and the mechanical contractor creates a new mechanical file for that system. If you used a search set, you simply append in the new file and re-run all your clashes. If you didn’t use a search set, you will have to open every mechanical test and add the new file in the Select tab.
Another reason to use search sets in the Clash Detective is so you can export your clash tests for use in other projects. If you define all your clash tests with search sets, you can export you clash tests from the Clash Detective in an xml file. You can then import this xml file into other Navisworks projects. When imported, not only will the Clash Test be populated, but all the search sets will be imported as well.
Clash Detective
The Clash detective can only truly manage files when an nwf file is used. Following a good workflow, you would set up all your clash tests with search sets and run the clash tests. Anyone who has used Navisworks knows that hundreds and even thousands of clashes can be found in a test. Part of good model management involves grouping clashes together into constructability issues.
A constructability issue can be defined as a localized area of clashing objects. For example, suppose you have a hallway with a cable tray that is running through the ceiling down the entire hallway. Navisworks would identify this as hundreds of clashes. The fix to these hundreds of clashes is the same, so rather than show hundreds of clashes, it is better to show just one clash representing the entire constructability issue. All the other clashes associated with this constructability issue will be reviewed by the nature of the containing clash.
To group clashes into constructability issues I recommend the following workflow. First, group all the clashes found into one large group. Using the Clash Detective display tools, click the Hide Other tool. All geometry that is not in conflict will be hidden.
Navigate to a problem area and select the geometry associated with the constructability issue. Click the filter tool and choose inclusive. All the clashes shown in your folder are clashes associated with the selected constructability issue. Mark one of these clashes up to represent the entire group. Move this clash to a folder named Constructability Issues. Mark the status of the rest of the clashes to Reviewed and move them to a folder named reviewed. Remove your filter and move onto the next constructability issue. Because you removed the clashes associated with the first constructability issue from the original folder, they will not appear in the scene view when you click Hide Other. This allows you to know with confidence you have reviewed every single constructability issue in the model.
Figure 4: Hallway constructability issue
The best part about the above workflow is that revisions become much faster. When model geometry is updated, you simply rerun your clashes. Group all the new clashes into a big folder. Go to your current clashes and select all the geometry associated with them. Click the filter button and move all the clashes in the new group that have been filtered into the reviewed folder, because you know your current clashes already contain the information displayed in the new clashes. This eliminates hours of work and makes your report extremely useful and accurate.
One note of caution about the resolved status: Navisworks will change the status of any clash to Resolved if the original clashing geometry is moved in any way. Because your clashes are representing many clashes as a constructability issue, you must review these clashes and change the status to active if the entire constructability issue was not fixed. Compact the clash test to remove any truly resolved constructability issues.
If you are following a workflow that establishes constructability issues and persists them until they are resolved, you can easily see which parties are not actively changing their models per the documentation in the Clash Detective. You can create variance reports by reviewing the date the clash was found. If you are commenting the constructability issue during the meeting and making assignments, you can manage the parties involved with the issue. In essence, by taking notes during the meeting you are generating a hot list. If you are really sophisticated, you can even use statistical regression to mark the changes in progression by graphing results from meeting to meeting.
Figure 5: Progression graphs
I have heard from many individuals that marking up files and grouping as described above takes too much time. To this, I always ask how they handle their workflows. Many say they simply load new models into Navisworks, create clash tests, and run the tests. They then eyeball issues and create viewpoints. This method is inefficient. When you simply eyeball issues, you tend to waste time and overlook critical issues. Even worse is when an individual runs the clashes for the first time during a meeting. This method wastes everyone’s time because no forethought has gone into what constructability issues need to be reviewed first.
The other issue with the eyeball method creating viewpoints is you lose the ability to simply generate viewpoints from the Clash Detective. If you do all the markups using the clash viewpoints, you can simply generate all your viewpoints from the Clash Detective. They will even be grouped into folders for each clash test, making it easy for the parties involved in a clash to know the constructability issues for which they are accountable.
