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.


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


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.


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.


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.


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.


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.


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.


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.


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


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


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


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


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


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


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.


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.


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.


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:


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:


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


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.


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


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.


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.


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.


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:


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


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


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.


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


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


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.


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.

Rooms to BCF

I am a huge fan of Tekla BIMSight. It’s powerfull, it’s free and very user-friendly. But like with many other project review solutions, I have difficulties to locate myself in the building while spinning around the 3D model.

It become even more tedious when you have to find a specific room in the model. There is no convenient way to retrieve its by a name or its number or zoom on it quickly.

A solution is to sort the Tekla BIMSight objects browser by Level and by Name to display every room in the model. You can then select a room and start create your clipping planes around it. This is not user-friendly. Furthermore, I haven’t always the luxury of working with IFC.

Object Browser

This is why I create a small application for creating a BCF note for every room of a building. This Revit plug-in save the location, the dimension and the name of all rooms to a BCF file.


When opening this file in Tekla BIMSight, we see every room neatly sorted by level in the Notes tab.


As you select one of these notes, Tekla BIMSight zoom on the selected room, and create nice clipping planes around it.

In Tekla

To do so, I am using XbimBCF, a great library for reading and writing BCF files. I just have to adapt it a bit since Tekla BIMSight does not support yet the second version of the BCF format.

This application is now more a proof a concept than an actual solution, but I will try to find the time to clean and share the code.

The BCF concept appears more and more appealing as I work with it. This format allow to develop small utilities like this one very quickly, and will be very useful for many tasks involving project review.