A new version of Group Clashes

I just updated my Clash Grouper plugin for Navisworks.

The main purpose of this update was to solve some issue encountered by early adopters. The plugin should now be more stable. Many thanks to the users who contributed to this release with their feedback and test models.

I also add some new features to the application, that I will showcase with this example. Detecting clashes in this simple layout of ducts (Selection A, in blue) and pipes (Selection B, in red) yield 8 clashes, spread like this:

An example of a clash test

Creating subgroups

Grouping with two condition will now create a first group per the first rule. It will then divide this first group into subgroups, following the second rule.

If we group this example by Selection A (the ducts), we get the following groups, named after the item used to create the group. All clashes involving the same item from selection A are grouped together:

Grouping by Selection A

If we add a new group rule, say, by grid intersection, the plugin will break these groups into subgroup, according to this new rule. Here, it will rename the existing group by adding the nearest grid intersection name, and break the group {Clash 7, Clash 8} into two, each one belonging to a different grid intersection.

Grouping by Selection A and Grids

Keep existing groups

You can now keep existing groups, so the Group Clashes will run only on the remaining clashes. This open more possibilities for complex workflows to group and sort clash results.

For example, you can group by status, explode the “Active” group and keep this “Approved” group. After running again the grouping function by level, it will only take into account the clash result, and keep the “Approved” group intact, allowing you to focus on “Active” group

Another example, if we create manually the following group in our previous clash test:

An existing group

We can then run a Group by Grid intersection on the remaining clashes to create the following groups for the remaining clashes, without disturbing the existing group.

Remaining clashes are grouped

Batch grouping

You can now select multiple clash tests to apply the same grouping rules to all of them

Batch processing

Along these new features, a few corrections have been made. Some groups where not properly named, this is now corrected, and these groups names should now be more meaningful. Handling missing grids or levels is now better managed, and the application should be generally more stable.

As usual, you will find this new version of Group Clashes on the Autodesk App Store. If you want to develop your own grouping rules, you can also find the entire source code on Github.

Happy grouping!

Linking documents to a model

These days, there is a lot of ideas around using a building information model for facilities management. Among these ideas, a recurring theme is to integrate documents, mostly technical sheets, directly into the model.

Aside from the fact that I don’t see how a model build to design, analyse, and coordinate a building could be use directly in facilities management, there is also some non-trivial technical problems to overcome to have any documents properly linked to your model, whether you are using Revit, Navisworks, or an IFC viewer.
Below is a list of these technical problems, and some though on how to solve them.

Adding a link in Revit

Adding a link in Revit is fairly straightforward, you just have to use a “URL” parameter (shared or built in), and type in your link. Since a technical sheet is generally the same for every building element of a given type, it makes more sense to me to add it in a type parameter.

Door Type URL parameter

Door Type URL parameter

As you can see, I type in a relative path to my technical documentation, this allows me to move around the entire “As-built documentation” folder (models and technical sheets in PDF) without breaking the links. I end up with a pretty simple folder structure, with a model at its root, and the technical sheets nicely ordered in one folder per category.

The folder structure

The folder structure

If you click on the small “…” button in Revit, your linked technical document will immediately open in the associate viewer, here, Acrobat Reader.

How to open the linked technical sheet

How to open the linked technical sheet

Adding a link without Revit

Selecting equipment and material is generally done through spreadsheets or building economy software, and by people who could not be proficient with Revit. Therefore, I have searched for solution to do it outside Revit.
The new Flux Scheduler is an application based on Flux, which allows us to create online schedules from data uploaded through the Revit Flux plugin.

The Flux Scheduler

The Flux Scheduler

By using this Flux Scheduler, I could upload my doors on Flux, create a door schedule directly on Flux, use Excel to add the URL link, and upload back these values in Revit

Type the URL in Excel before uploading them in Revit

Type the URL in Excel before uploading them in Revit

Delivering a Navisworks model

Once exported to Navisworks, the “Link” button will display a small link button on every linked object, which open the linked technical sheet.

The link in Navisworks

The link in Navisworks

However, you must keep your Navisworks model in the same location in your “As-Build Documentation” folder structure as your initial Revit model to keep the relative links functional. In our case, we end up with the following folder structure:

The folder structure with a Navisworks model

The folder structure with a Navisworks model

Delivering an IFC model

If you export this Revit model to IFC, and open it in Solibri Model Viewer, you can display the link, but not click on it. However, by writing a “\” before the link in Revit, Solibri Model Viewer recognize it as link and you can open the technical sheet with a click. This could obviously become problematic in Revit, since when you add this “\”, Revit doesn’t recognize the link anymore.

The clickable link in Solibri

The clickable link in Solibri

Tekla BIMSight, on the other hand, couldn’t recognized any of those links as a clickable item.

As you can see, they are many ways to link documents to a model and retrieve them in a viewer, and a few things could go wrong along the way. So, before starting anything, I would recommend to make sure you can link or embedded documents in your deliverables and structure these deliverables accordingly.

Why I am now a bimsync fanboy

Those of you who know me know that I recently changed my employer and I am know working for a real estate developer, with a different scope of work than in my previous position. This lead me to put aside Revit and Dynamo for a while, and think more about a project-wide collaboration platform.

Alongside with the ubiquitous BIM 360 platform from Autodesk, there is a lot of more confidential solutions from various developers. Every large BIM editor has its own, and many other companies propose one. Among them, bimsync is a rather discrete application from Catenda, a Norwegian company. Having eared about it at the French Revit User Group, I had to give it a test, and I was not disappointed.

What immediately caught my attention is the web viewer, which is the best I have ever tried. They develop their own IFC web-based viewer, and it is not far from perfect. The viewer is extremely easy to use with the left mouse button and the wheel, and include every needed feature. Sectioning the model is also quite well implemented and do a very good job. My only wish here is to have a filled pattern to highlight the difference between fill and void while sectioning.

sectionnningwithdiff

The viewer is also quite powerful, I tried it with 1 Go worth of IFC files, it run “almost” smoothly on my iPad.

onipad2

bimsync does a good job at uploading, viewing and managing versions of various models, and provides a thoughtful way of managing revisions.

You start by creating a “model” which on bimsync is a placeholder where you will upload the various versions of an IFC file. Once this file is processed by the platform, it will be available for review along with the other models. The processing part can be rather slow, it takes more than one hour for a 500 Mo IFC file, but happen entirely online, you don’t even have to keep your computer open.

models

A key feature of bimsync is the ability to easily extract Excel schedules from the uploaded models. Having the ability to show data from a model in a nice spreadsheet is priceless, and this is something that is generally overlooked by their competitors.

The issue tracking solution integrated in bimsync is also very efficient and well-thought-out, with a lot of nice features.

You start by creating an issue directly on the model, can assign someone responsible for solving this issue, add a due date and write a few lines of comment.

issues

These issues are grouped by boards, and you can create as many board as you want. You can also keep track of the resolution of these issues with a few statistical tools and filters, and save reports in Excel.

statistics2

You know that I am a big fan of the BCF concept, and bimsync doesn’t disappoint me in this regard, by providing a first-class BCF 1 and 2 support. You can export your issues in BCF to display them directly in your authoring platform of choice.

Catenda was kind enough to provide me with an access to their API, and after a few tests, I found them quite easy to use and powerful. I think this enable very interesting workflows, like automatically displaying key metrics in an easy to consume Power BI dashboard.

I yet have to explore all the features, especially the libraries, but bimsync is now my top choice among the web-based BIM collaboration platforms, and I am eager to explore more workflows with it.

Group Clashes

If you have already run some clash detection, you have probably ended up with thousand of clashes, and wondering how you could find something interesting in this mess.

neuro

Furthermore, finding clashes is not really useful in itself. The purpose of clash detection is to be able to find and hopefully solve issues in the design. And we quickly realize that a clash is not an issue in itself, but can be the symptom of an issue. Being able to extract a real issue from a meaningless bunch of clashes is what we are looking for. This is how we can gain some return from clash detection.

To do so, I tend to focus on specific subjects. Instead of running useless clash detections between entire model, I rather focus on specific issues and know beforehand what I am looking for.

For example, instead of running a clash detection between an architectural and a structural model, and end up with thousand of clashes, we can run a clash detection only between architectural rooms and structural concrete beams. As we know which type of element are involved in the clash detection, we can understand what a “clash” mean. Here, it means that there is a beam below the ceiling height. Furthermore, we can also group these clashes by room, and immediately highlight the problematic area where we can focus our efforts.

clearheadroom

To help in this regards, I created a plugin for Navisworks Manage to automatically group these clashes. After a beta version published last year, I finally take the time to properly develop a full-fledged application and publish it on the Autodesk App Store. It is a fully redesigned Group Clashes Navisworks plugin, with a new interface that integrates seamlessly into the Navisworks interface.

interface

The grouping rules have also been redesigned, and now include the following methods :

  • Group by Level: This rule will group clashes according to their nearest level, and name the group after the level.

bylevels

  • Group by Grid Intersection: This rule will group clashes according to their nearest grid intersection, and name the group after these grids.

bygrids

  • Group by Selection A: This rule will group all clashes belonging to an element of the selection A, and name the group after this element. As an example, if a room in Selection A has many clashes with beams in Selection B, all these clashes will be grouped.

byselectiona

  • Group by Selection B: This rule will group all clashes belonging to an element of the selection B, and name the group after this element.

byselectionb

  • Group by Assigned To, Approved By, and Status: These three rules will use various properties of the clash to group them. As an example, you can use this rule to group all clashes assigned to you.

You can also group with two rules, the first one will rename the clash group created by the second one. This enables various possibilities, like having clashes grouped by a given selection and renamed according to the one assigned to.

Group Clashes can have difficulties in managing clash reports with more than 10 000 clashes. Be smart when you set up your clash tests, and everything will be fine.

Group Clashes is now out of beta, and you will have to pay $10 to download it on the Autodesk App Store.

Yet, Group Clashes is also open-source. You can find the entire source code on Github, build your own plugin, and develop your own grouping rules.

Time Stamper, the Add-In

There is no easy way to override the color of an entire Revit link. Since most of my work involves linking Revit model from various subcontractors, this is something I miss badly.

Until recently, I was still using some workset hack to create filters on linked models. These filters were allowing me to display linked model with my color of choice.

But relying on workset leave much to be desired, and I have to find another solution.

I recently came up with a different solution, where each model element know where they came from.

The idea is to add file name, date and version in shared parameters on every model element. I created the corresponding Revit Add-In, and it is now available on the Autodesk App Exchange.

This application will:

  • Ask for identification information
  • Create four shared parameters on every category
  • Fill these shared parameters with identification information

The code itself is pretty easy, but there is a lot of applications.

First, it becomes easy to create filters on linked model. These filters allow us to display each linked model with a different color.

ColorsByModel

But it also enables us to tag the origin of every element, like we can see in the following screenshot.

IdentifyElements

You can create a linked models schedule, with date and version.

LinkedFilesSchedule

To help you create filters and tags with these parameters, you will find here the shared parameter text file. Please also note that the application uses a list of categories to create the four shared parameters. You will find this list here.

I hope this application will help you in your work, don’t hesitate to share your suggestions in the comments.

DynaWorks

During my researches for improving clash detection, I stumble upon DynaWorks, a great Dynamo package built by Adam Sheather (@Gytaco).

For those who haven’t heard about Dynamo (Is there is any left?), it is a visual programming interface for Revit, pretty much like Grasshopper. Just like Grasshopper, you can improve upon the built-in features with packages from third party developers. DynaWorks is one of these packages, and provides a set of Dynamo nodes for interacting with Navisworks.

After installing it through the package manager, it presents itself with a set of nodes exposing Navisworks main functions.

Along with the package, some examples are provided. The NavisClashesElementUpdate.dyn contains a definition for retrieving clash results from Navisworks, I use it for my first steps with DynaWorks. If, like me, you want to use these definitions with Navisworks 2016, don’t forget to use Adam Sheather’s trick for updating your Dynamo definitions

To use DynaWorks, you first have to create a Navisworks file, and prepare your clash detections. Here, I create a basic detection between Walls (First Clash Item, in Blue) and HVAC elements (Second Clash Item, in Red), and load the resulting NWF file in my Dynaworks definition.

TestSelection

Basically, this definition retrieves every clash result in every clash test, selects one side of the clash detection, gets the involved element, extracts its id and uses it to update the Comment parameter in Revit.

process

Simple, but the result is pretty impressive. Instead of painfully getting element Ids in the Navisworks report, DynaWorks retrieves them for us, and updates elements in Revit accordingly. When applying a filter in the Revit view, we get this:

result

With some tweak to this initial definition, I was able to implement some king of dynamic clash detection, with a live update of the Navisworks file as we update the Revit model, but converting an entire Revit model in NWC is way too slow to implement this solution in a production environment. Please feel free to use it if you want to try it by yourself.

DynaWorks contains many other functions to retrieve Navisworks views or selection sets in Revit, and I think this can be the beginning of a great work flow intertwining Revit and Navisworks.

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.

BCF Reader Update

This post is long overdue, but I finally take the time to update my BCF Reader.

BCFReader-Logo_small

First of all, I have tested it on a larger set of BCF files, and I hope these will make it more robust, especially if something is wrong within the BCF file. My experiences include files coming from Tekla BIMSight, Matteo Cominetti’s BCFier and Kubus BIM Collab.

I have to remove the support for Word 97-2003 Documents (*.doc), since the library I use does not support them. I will see how I can integrate them back in a future release.

Among the change, I add a small progress bar to allow you to pour yourself a coffee when dealing with huge quantities of notes.

I also add Status and Verbal Status to the report, just after the date. A more subtle change, the default path to save your report is now the same than the BCF file itself.

I improve the Readme file to include a small explanation on how to use the BCF Reader.

I spotted some problems with styles in the Word template. To be sure to have all of them available in the BCF Reader, you must write a few lines in your Word template, apply your styles to them, then delete them. This will ensure that you have created these styles in your Word template before using it.

Finally, I want to thank Julien Benoit and François Lahouste for their comments and their files.

As usual, you can download the BCF Reader here, and check the code here.