Log spatial coordination

Finding and solving issues is at the heart of the spatial coordination process. But since we don’t know in advance how many issues we will have to find and solve, it is difficult to measure the result of our efforts.

Case recently presented a very interesting solution for this problem. Using Jira, an issue tracking product used in the software industry, they were able to keep track of every problems found during the design phase, and display them thought nice visualizations.

Inspired by this idea, I displayed over time the results of a general clash detection in a graph. Like so, we can see the evolution of the number of clashes in our model, and the progress of the spatial coordination.

To do so, we have to set up a general clash matrix, something like this:

matrix

  • A: Architecture
  • S: Structure
  • H: HVAC
  • P: Plumbing
  • E: Electrical

You can see that the lower-left of the matrix is left blank, we don’t need to run symmetrical tests.

We don’t include architectural elements in our detection, since resulting clashes are generally not relevant enough to add value to the report.

We test for intersections between every trades, create a report combining all clashes, and export it from Navisworks.

This report is not very useful per se. In fact, there is generally too much clashes to sort them into something useful. And if by chance you haven’t that much clashes, you probably don’t need clash detection in the first place. But this clash report do nevertheless represent the state of our coordination at a given date. The less clashes we have, the better.

Furthermore, once these tests are set up in Navisworks, it become easy to export a large clash report every day, a rather bulky summary of every problems we can find in our model.

Day after day, these reports create the raw data for a journal of our spatial coordination. Periodically, we compile them into something more visual.

To do so, we create a single table (in .csv) listing every clash reported during the project.

We use to compile them through an HTML (tabular) report from Navisworks.

exportReport

Using the Data -> From Web Excel function, we create a large database of every clash, with its history.

We now have a custom application for extracting the same information from Navisworks XML reports. The process is somehow automated, but the result is the same, a large database of every clashes detected during the design.

Once we have every clash in a handy (and pretty large) .csv file, we use Tableau to create a nice visualization out of it, and let everyone in the office follow the progress of the coordination.

visualization

“What gets measured improves”, and we are now able to increase our efforts when we see the spatial coordination staggering. But with precise data about the coordination, I also hope to be able to better understand what makes a coordination process successful and how to reproduce it.

Improve clash detection

Automatic clash detection produces way too much clashes. Even when running test per level or area, I always end up with thousands of useless clash points.

Tired of painfully grouping and sorting these clashes into something usable, I put aside the whole clash detection subject for a while.

I was drove back to Navisworks while working on specific coordination problems. Instead of clashing entire models one against the other (say, HAVC against Structural), I select only a subset of these models to solve a particular problem. Focusing only on the elements involved in these problems, I was finally getting something out of automatic clash detection.

Solving one problem at a time is of course the solution for an efficient clash detection.

Checking required headroom is a good example of a useful clash detection. The idea here is to highlight every room where a structural framing end up below the vertical clearance set up by the architect. This example suppose than the “Limit Offset” property of the room is set to the required value by the architect.

clearHeadroom

The entire process is based on running a clash test between selections sets created in Navisworks.

My fist selection contains some of the room of the architectural model. The first condition retrieve every room, and the second remove technical area from our selection.

SelectionSets

The second selection set retrieve structural framing from the structural model.

Once these two selections are saved as Search Sets in Navisworks, we use them to run a clash test. Since we are focusing on headroom, the Tolerance value is really useful here. We can set it up to 2 cm without regret, knowing than any clash below this value is not an issue in this phase.

This clash test yields 78 results for the entire project. I use the Clash Grouper to group them by room (Selection A), and end up with 55 groups. The best part here is that every one of these groups is a real issue, and do not need any further sorting.

The last part is to export these issues in something practical for the Revit user.

I export the report in HTML (Tabular) to be able to import it in Excel afterward. I use the Get Data From web, and open the report in a nicely formatted Excel spreadsheet.

With some PivotTables, I get the Revit ID of every problematic room, and paste them in the Select By ID function of Revit. I can add a specific value on these rooms and highlight them with a Color Scheme in Revit.

RoomHightLight

From thousands of meaningless clash point to a nice plan highlighting problematic area for a specific problem, I finally find some improvement over my traditional clash detection process. I’m still working on it, and hope to share my progress, as long as there is any to share.

Grouping clash results

In any given building model, there is a number of issues to be addressed. A large part of these issues are what we call “hard clashes”, when a building component physically penetrate the space occupied by another building component. In these case, two or more building elements compete for the same volume.

Finding these clashes is now quite simple thanks to clash detection software that detect geometrical interferences between elements of a building model.

But after having a hard time finding these issues through coordination sections hand-drawn from plans, we now face the inverse problem and end up with too many clashes in our models. Running a simple clash detection can quickly yield thousands of clashes, making the entire process nearly useless.

Furthermore, a clash only represent a geometrical intersection between two elements, and is more a part of an issue than the issue itself. We have to group these clashes to be able to extract meaningful issues from the meaningless clashes.

Grouping these clashes is generally a manual task, and the user have to run through thousands of clashes to sort them in relevant groups.

While trying to automate this tedious task, I run across the examples provided as part of the Autodesk Navisworks Software Development Kit. These examples include a nice Clash Grouper plugin for Navisworks, enabling various method for grouping clash results.

groupClashes

As an example, I run a clash detection between the blue Selection A and the green Selection B, and get seven clashes, shown here as red dot:

Ungrouped

With the Clash Grouper, I can group these clashes by grid intersection:

groupByGrid

I can also group them by cluster analysis, where we search for the optimum grouping solution given the expected number of groups:

groupByCluster

I also add my own method for grouping clash against a specific set. I use this to group all clash belonging to a single element in one of the two selection sets.

grouplashesEdited

Here, I group by element from the Selection A (blue)

groupBySelectionA

Here, I group by elements from the selection B (green)

groupBySelectionB

If elements from one set are more relevant for the end user, the final clash report is clearer for this user when clashes are grouped against this set.

This plug-in enables a lot of possibilities for sorting clash detection results in a meaningful report, and will become a full-time member of my coordination toolbox.

To install this plug-in, you can copy-paste the ClashDetective.ADSK.dll file available here in a new ClashDetective.ADSK folder in C:\Program Files\Autodesk\Navisworks Manage 2016\Plugins. You can also see my edited version of the example code here.