Wall openings

I came back from the first meeting of the Paris Revit User Group. Julien Benoit give us great insights on how to use Dynamo for data management and Revit automation.

His point of view give me some ideas to feed my current obsession, wall openings.

Modeling opening where ducts, pipes, cable trays or conduits intersect walls or floors can be a tedious business. Anyway, it always relies on the same underlining principle: we place a face-base opening family on the wall at the intersection with the duct, the pipe or the cable tray. We also respect a few rules of thumb when placing these openings to keep a structurally sound wall.


There is a handful of plug-in for placing them automatically but they all need a fair amount of work to replace them properly afterward, so I decide to stick to a more “manual” solution.

First of all, I use Navisworks to find where I have to place these openings. It gives me a list of walls. Then, I use Dynamo to create an elevation in front of each of these walls. These elevations ease the process for placing the opening family in the concrete model.

The entire process can be sum up like this:


The Dynamo definition use the wall bounding box and normal to create the section view coordinate system. I fumble around with Min and Max points to set the proper crop box for the final view. I also use a few nodes from archi-lab.net package to retrieve walls from their ids. You can find the entire Dynamo definition here.

“A problem well defined is a problem half solved”, and displaying a view of each problem is my first step toward the solution, even if I haven’t find yet any way to automate the entire wall opening thing.

Revit categories and classification systems

Standards for classifying building elements have been around for some times, but building information modeling gives us new perspectives for using them.

There is a handful of these classifications currently in use. The Construction Specifications Institute produce the MasterFormat and UniFormat, used in United States and Canada. The Construction Project Information Committee in the United Kingdom provides Uniclass and Uniclass 2. And the “Catalogue des articles normalisés” was used in Switzerland even before computers were able to manage it.

Revit provides two built-in type parameters to manage such classification systems, the Assembly Code and the Assembly Description. These parameters allow us to link any Revit type to an existing classification system.


This classification system can be loaded in Revit through the Assembly Code interface.



Autodesk provides us with the Uniformat classification, through the UniformatClassifications.txt. This tab-separated values text file define the classification structure with four columns:

Classification Code - Description - Rank - Revit category Id
  • The Classification Code is the number associated with each item in a given classification. It is linked to the Assembly Code in Revit.
  • The Description is the text associated with each item of the classification. Once we add an Assembly Code to a Revit type, this description appears in the Assembly Desciption.
  • The Rank define the hierarchy of the item in the classification. This allows Revit to display any linked classification in a tree view.
  • Finally, the Revit category Id allows us to create a first mapping between classification items and Revit categories. This allow us to filter by Revit category while assigning Assembly Code.

To create such a mapping, we need the list of Revit categories. To extract this, I run a small routine to write every built-in Revit category to a .csv file. Along the way, I find some interesting properties of these categories. For example, the IsCuttable property list cuttable categories, something I was talking about in a previous post.

But most important here is an exhaustive list of all Revit categories, along with their Id, a prerequisite to create relations between Revit categories and classifications items.

These relations allows us to filter by category while assigning Assembly Codes.

You can find here the .csv file with all Revit categories, along with the code used to create it.

public void Categories()
	Document doc = this.ActiveUIDocument.Document;
	Categories categories = doc.Settings.Categories;
	List<string> categoriesList = new List<string>();
	foreach( Category c in categories )
		//Retrive sub categories
		foreach (Category subc in c.SubCategories) {
	string path = @"C:\categories.csv";


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.