guide

IFC, Revit and You

July 28, 2015Ryan LenihanRevit GeneralArchiCAD, architecture, collaboration, coordination, guide, IFC, mep, revit

In Australia and likely elsewhere, a lot of people believe that BIM = Revit, however this is certainly not the case; there are many other software packages out there and if you need to collaborate with these software packages, chances are you will need to use IFC files.

IFC stands for Industry Foundation Class, it is a platform neutral file format that is not controlled by any of the software vendors.

For those that haven’t worked with IFC files before, there are a few things you need to keep in mind before you jump headlong into working on a project where IFC is used for collaboration. I will specifically be talking about my experiences working with IFC outputs from ArchiCAD.

You need time

Depending on the size of the project, the process of importing and IFC file into Revit could take a very long time. IFC imports can be anywhere from almost instant to a few days. You need to make sure that you clearly communicate this not just with your engineering team but with your architecture design team as well.

It’s very important to keep an open line of communication with your architect. Pick up the phone.. or more importantly answer the phone! Don’t let problems go unsolved sitting in someone’s inbox. 5 or 10 minutes spent on the phone with the architect might save hours of time for both of you down the track. They will be able to split large projects into smaller chunks or limit what elements are being exported from ArchiCAD so that the heavy lifting your hardware needs to perform is more manageable.

In all my testing, Revit appears to use 2 cores at most when importing IFC files. If you have a fast multi-core machine, you can set more than one file to import at a time. I highly recommend selecting each instance of Revit that you have open and setting the CPU affinity in task manager. This forces windows to spread the load across your CPU, maybe I’m imagining it but I found that if I didn’t do this all Revit processes seemed to share the same few cores; without doing this my 6 core/12 thread Xeon CPU sat at around 12% utilisation where as if I forced each instance of Revit to use certain cores I could push my CPU usage towards 80% utilisation. The problem you will face though is RAM. On some IFC files even 32gb is not enough.

For the Revit users on the team, push for the use of 2015 or newer; there really is no reason to dilly-dally in the comfort of older versions of the software. Revit 2015 brings to the table more efficient IFC imports through the Link IFC option. It is not a true IFC link, Revit actually converts the file to an RVT on the fly, in my testing using IFC Link instead of the open IFC method saves up to 60% on import times. The first iteration of architecture I received for the most recent project I’ve been working on took just on 3.5hrs to import a 286mb IFC file using Open -> Open IFC where as using Link IFC on the same file took only 24mins.

With some helpful splitting of models by the architecture team you can improve your workflows significantly.

I have worked on two hospital projects authored in ArchiCAD and we split the FF&E from the building fabric. The building fabric was always imported first and the FF&E flowed on afterward. We always requested up to date DWG exports of the floor plans that could be overlayed to reflect the FF&E as well.

You need DWG files

DWG files will play a very important role when working with IFC files, they will allow you to keep up to date quickly with furniture layouts but they’ll also help speed up your model. ArchiCAD seems to be able to handle higher polygon counts far better than Revit can which leads to glorious, highly detailed furniture models, trying to run a model with the 3D furniture models loaded in is going to slow you and your team down to a crawl. You don’t need to coordinate in 3D with a chair, but you may need to know where it is so you can place power and data outlets or other equipment. DWGs are the best way to do this.

Make sure you follow all the usual rules about DWG files. Keep them clean. Link them into their own host model, don’t insert. Never link or load them into your live model where possible. There is an article in the June 2015 AUGI magazine which goes into detail on best practice. Something they suggest that I’ve never tried before is to insert the DWG files into an *.RFA file and then stack the *.RFA files in the host model. If it means that it will be less problematic, go for it.

IFC files do not carry ceiling tile information

Don’t worry though, you asked for DWG files remember? Depending on what you want to show on your plans, you may need to link the DWG at certain heights so that they fall within the view range of your ceiling plan.

Again, follow best practice with linking in DWG files to a host model. Do not locate your RCP DWGs in your working model.

You need to understand coordinates

And you need to understand them well. When working with IFC exports from ArchiCAD, you will be working at the architect’s origin location, not shared coordinates. As much as it has probably been drummed into you to “always use shared coordinates” there is nothing actually wrong with using an origin to origin system.

In fact when importing an IFC file you don’t get a choice of how to bring the file in, Revit will automatically import at origin to origin. This poses a problem if you’re also collaborating with a civil team, but this is pretty easy to overcome, you just need to make sure that it’s part of your workflow.

You can’t host families to an imported IFC

Unless you’re going to draw hundreds or potentially thousands of reference plane, forget about using those face hosted families that you’ve become so accustomed to.

As you’re probably aware, all elements in Revit have a unique identifier, also known as an element id or global unique identifier (GUID). For whatever reason, Revit does not have a consistent way of applying GUIDs to imported IFC elements. This means that today the wall on ground level at grid intersection D5 might have an element id of 654321 and next week, it could be 751155 and as a result your hosted families will become orphaned. Or worse yet, maybe now a different wall from level 10 has picked up that original 654321 identifier and now your data outlets have been automatically moved to that new location by Revit.

At least this was the case in earlier versions of Revit. In newer versions of Revit you simply are not even allowed to host a family on an imported IFC face at all.

My advice would be to develop a suite of unhosted families. IFC is going to become more prevalent in the future especially as some governments around the world are mandating the use of IFC so you’re going to have to deal with it more in the future, you might as well be prepared.

Never ask the architect “Can’t you just do it in Revit?”

Unless you want the architect to ask “Well can’t you just do it in ArchiCAD MEP?” then don’t; and yes in case you were wondering there is an ArchiCAD MEP. Seriously, show a little respect. Sure Revit has a larger market share than ArchiCAD but that is not the point. BIM shouldn’t be and is not restricted to a single piece of software.

At the end of the day it’s not actually that hard to work with IFC files. Sure you have to think about things a little more but that’s OK because how boring would life be if every day was exactly the same? The most important thing if you’re on your way to higher levels of BIM is to make sure you get the rooms imported from the IFC file, that way you can still create MEP spaces and in turn perform all your MEP calcuations quite successfully. Otherwise if you’re still finding your feet in BIM and Revit is primarily a 3D documentation and coordination tool, working with IFC isn’t as hard as you might think it is.

Taking a Return Trip From Revit to Excel Using Dynamo

June 16, 2015Ryan LenihanRevit Families, Revit Generalannotation, clockwork, dynamo, excel, guide, mep, notes, revit, revit schedule, schedule, specification, training

Last week I wrote about using note block schedules to create specification sheets and I explained how you can use addins such as BIMLink, custom macros or C# addins or Dynamo to get the data out to Excel so that it can be edited by an engineer and then re-imported to Revit from Excel.

Problem is, you don’t have a BIMLink licence, you don’t know how to code in C#, the most accessible method for you to achieve this workflow is Dynamo but you don’t even know where to start; never fear! In this post I explain how to create a bi-directional link between Revit and Excel using Dynamo using the as the note blocks from my previous post as an example.

I’ll be using Dynamo 0.80 which can be found on the Dynamo BIM download page.

Exporting from Revit to Excel

The export to Excel process is pretty simple, you just need to think about the logical steps that you need to take. You want to select the family you wish to export data from, select the parameters to export, organise them in a list and then write it to the Excel file itself.

To step through the process, first select the family type and push that into an All Elements of Family Type node.

From there we start our first step in taking care of the family unique identifier by using the Element.UniqueId node, this will export the family’s GUID. Simply link the All Elements of Family Type node to this one. You need to export each individual family’s unique identifier as well, if you don’t, as the BIM Troublemaker discovered you may end up importing the wrong data to the wrong family.

Next, you need to select each of the parameters you want to export, for this you need to use the Element.GetParameterValueByName node. Link the All Elements of Family Type node through to this node and you will also need to add a String node which is where you input the name of the parameter. Because I’m using the annotation family from my note block post, the parameters that I will be exporting are NUMBER, NOTE, CATEGORY and REGION. Note that the value that you enter into the string is case sensitive and that you need to repeat this for each parameter you are wanting to export.

Now you need to push the output of each of our Element.GetParameterValueByName nodes through to the List.Create node. This will actually create a list that will run the parameters across the page with each parameter being spread across a row instead of being arranged in columns. If you exported the data to Excel at this point, you would end up with something that looks like this:

However this isn’t how we want to work, we like our data arranged in columns. To do this, use the List.Transpose node which swaps the rows and columns in the created list.

To finish off we need to use the Excel.WriteToFile node in which we pass through a File Path node, a String which names the Excel sheet and a few Numbers which gives the starting row and column of our excel sheet.

The result is a nice, easy to read export of all the data relevant to our note block schedules ready to be modified by an engineer.

At this point you can use the Sort function in Excel to sort your Excel file into a usable list. In this instance I have chosen to sort by Column D and then Column B so that I am sorting first by category and then by note number.

Importing back into Revit from Excel

Once the engineer has finished modifying the Excel sheet, we’re ready to bring the data back into Revit from Excel. This process is slightly more cumbersome but overall not a whole lot more difficult than the export process.

First we need to pick up our Excel file, start with the File Path node that we used before, before we go to the Excel.ReadFromFile node though we need to pass the file path through the File.FromPath node otherwise it will not work. We also need to add a String so we can tell Dynamo which sheet to read. Next, pass the data back through the List.Transpose node to get the data back into a format that Dynamo and Revit are happy to work with.

Remember earlier I mentioned during the export process that to make sure we’re writing the correct information to the correct family we need to index our list and the families by their GUID? Thanks to the BIM Troublemaker, we know how to select each element from our Excel file based on the GUID. First, start with a List.GetItemAtIndex node and connect the List.Transpose node to it. Next, add a Code Block node and enter the text 0; this passes through the number 0 as our row index. Finally, add a Code Block node and insert the code ElementSelector.ByUniqueId(id, true); this is case sensitive, so make sure that you enter it correctly or it will not work!

Finally, we need to push the data through to each parameter for each individual family. To do this, use an Element.SetParameterByName node. We need to feed the ElementSelector Code Block that we created into our node, along with a String node that matches our parameter name, remember this value is case sensitive and finally we need to link up our value via a List.GetItemAtIndex node.

The List.GetItemAtIndex node needs to be told which row to use to pull it’s data from, this is as simple as adding a Number node. Don’t forget though that the first row is at index 0, which is where we are pulling our GUID from, so we want to pull our first series of parameters from the row which is at index 1.

In this instance our index 1 is our number list which you may not need to import this so you could skip this step, but if you do need to populate the number data and you try to feed the parameter from the List.GetItemAtIndex node directly to the Element.SetParameterByName node Revit will throw back an error stating that “The parameter storage type is not a number”. Originally I tried to overcome this by using the node String from Object but this gives a number to 3 decimal places and we don’t want to see this on our specification sheet. The solution in this instance was to first use the Math.RoundDownToPrecision node from the Clockwork package which you can download from within Dynamo itself or from dynamopackages.com. We need to pass a number to the Math.RoundDownToPrecision node to indicate the precision we want, which in this case we want a precision of 1.

The number conversion is the only oddball of the parameters that we’re working with, the rest of the parameters simlpy feed the List.GetItemAtIndex node directly to the Element.SetParameterByName node. Repeat for each parameter that you want to populate.

And to finish up, our results:

Navisworks Clash Detection 101 – Part #3

March 23, 2015Ryan LenihanNavisworksclash, clash detection, clash report, coordination, guide, mep, navisworks, revit, training

Part #3 – Understanding Clash Types and Tolerances

One of the most misunderstood parts of Navisworks clash detection is the settings for the clash type and the tolerances. Using the model from my hydraulic pipe sizing article I have put together an example of the different clash detection types at varying tolerances. I’ve added some columns to the model which are progressively offset at 25mm intervals. You can clearly see that there are columns that clash, and columns that do not clash with the drainage pipework.

I’ve then created two selection sets as explained in the 2nd part of my clash detection series, one for columns and one for the drainage pipework. I have then created a series of clash detection rules that clash the columns selection set against the sanitary drainage selection set, the clash reports repeat at different intervals.

For the hard and hard conservative clash reports, I have selected tolerances of 10, 20 and 50mm and for the clearance clash report, I have selected tolerances of 20, 50 and 100mm. When running the clash reports, I get the following results:

As you can see, as you increase the hard clash tolerance, the clashes reduce and as you increase the clearance tolerance, the clashes increase.

Hard clashes are as the name implies – a hard clash but as you adjust the tolerance, the clash is ignored within that tolerance range. Allowing for a 50mm hard tolerance means that two items need to intersect or clash by 51mm or more before they are reported on. The clash shown below has been reported in our 10 and 20mm tolerance reports, but completely ignored in our 50mm report.

There is no denying that this is a clash, yet it’s not reported in the 50mm tolerance test at all.

Clearance clashes are the exact opposite of a hard clash. Clearance clash reports check elements for minimum clearance requirements. In a clearance clash test with a 50mm tolerance, two elements will need to be 50mm apart or closer to be reported as a clash. This is particularly useful when you want to allow additional clearance for pipe, cabletray or duct hangers and brackets that have not been modelled.

As you can see in the reported clash below, the two elements do not intersect at all, yet they are still reported as a clash due to the minimum clearance not being met.

But What if my Elements are smaller than my tolerance?

That’s actually an interesting question and can prove useful or troublesome in clash detection reports. I’ve added a 20mm gas pipe to my example model which in plan intersects with my 15mm cold water droppers that run to each basin. Again, you can clearly see that the newly added gas pipework clashes with the existing cold water pipework.

I’ve in turn created a series of clash tests, this time I have only created hard clash tests with tolerances of 0, 10, 20 and 50mm.

The reports give interesting results. Only the report with a 0mm tolerance has reported any clashes at all. Results like these have the chance to run you into trouble if the clashes can not be resolved on site – say for example a 65mm vent pipe rising inside a 90mm stud wall and a 32mm chilled water pipe running horizontally in the wall cavity; there is no way the two services will ever fit and yet they’re not reported in Navisworks.

These settings though can also be used to your advantage. For example if you have modelled all the hot and cold water pipework to the individual fixtures, you would never be expected to coordinate pipework of that size and how can you when the architect doesn’t model the studs within the walls? Using the tolerances to your advantage you can avoid having essentially false positive clashes reported.

Navisworks Clash Detection 101 – Part #2

March 16, 2015Ryan LenihanNavisworksclash, clash detection, clash report, coordination, guide, mep, navisworks, revit, training

Part #2 – Sets

Sets are a big part of clash detection in Navisworks, they can make the difference between a great clash report and one that is a waste of time. Simply clashing one model against another is not going to give you great results in most instances. Say for example you clash an architectural model against an electrical model, that’s all you need to do right? Wrong. Every electrical item that is recessed into either the wall or ceiling will be reported as a clash which this actually isn’t a clash, you end up with a time consuming administration overhead to manually approve clashes that shouldn’t have been reported on in the first place. This post will help you get your head around sets and how to make them work for you.

Selection sets are a group of objects selected either from the view window or from the selection tree window. You can manage sets from the sets window, if your sets window isn’t visible on screen, head to the View tab, and from the Windows button, select Set from the list.

The Sets window allows you to manage your search and selection sets within Navisworks.

Below is a description of each of the buttons in the Sets window.

	Save Selection is used to save the current selection.
	Save Search is used to save the current search.
	New Folder allows you to create a new folder to group sets under.
	Duplicate is used to create a copy of the saved items.
	The Add Comment is used to add comments to the saved sets.
	Delete is used to delet the selected set.
	The Sort button is used to arrange the saved sets in alphabetical order.
	The Import/Export button is used to import and export the saved sets.

When you run a search in the find items window, the search results will be highlighted in blue in the view window, as well as in the selection tree window.

When you select an object or a group of objects, they will be displayed in the Selection Inspector window along with their properties.

	The Show Item button is used to view the selected object in the display window. The display will zoom in on the selected items when you click this button.
	The Deselect button is used to remove objects from the selection inspector window.
	The Export button will export the selected item to a *.CSV file.
	Save Selection allows you to save the selected objects as a selection set.
	Quick Properties Definitions allows you to add properties to the selected objects in the view window.

Now that I have explained the functions of each of the window elements, I’ll show you how to put them to use.

Using the Find Items window, you can search for elements based on specific information. In this instance, I have searched for all air terminals located on level 1. The find items window will allow you to search for elements based on the element properties which includes user parameters.

Once I have the correct elements selected based on my search, I can create a selection set in the Selection Inspector.

I now have a selection set named Level 3 – Air Terminals in my Navisworks model.

Following the same method, I have created a selection set of all the lights on level 3. In the next installment, I’ll explain tolerances and how they affect your clash results.

Navisworks Clash Detection 101 – Part #1

March 9, 2015Ryan LenihanNavisworksclash, clash detection, clash report, coordination, guide, mep, navisworks, revit, training

Part #1 – The Clash Detective Window

To the average engineer or modeller, Navisworks and clash detection go hand in hand, some people think that they are one and the same. If you’re not familiar with the terminology, clash detection is a process that identifies interference between elements in your model where as Navisworks is an Autodesk product that facilitates automated detection of the interferences between modelled elements. These interferences, or clashes may be between different models or within the same model, they could be between disciplines or within the same discipline.

The concept behind clash detection during the design process is that you can identify and fix problems before construction begins, therefore saving time and money down the track. Provided that it is configured correctly, Navisworks can help to speed up the process and reduce human error during model inspection by running automated clash reports.

The problem with Navisworks however is not everyone knows how to use it effectively. Maybe you’ve been to training with a reseller in the past and you walked out the door still scratching your head. After spending a whole day working on 4D timelining, 3 hours showing you how to animate an automatic door in Simulate and less than an hour spent learning the very basics of clash detection in Manage or maybe you’ve had no training at all? Either way you’re only just barely making your way through your clash detection sessions.

Over my next few articles I will outline a few of the clash detection basics to get you more confident in your adventures into clash detection, I’m not going to claim to solve all your clash detection woes, but whatever your experience, it’s always good to have something to refer back to.

In this first installment, I’ll explain each of the parts of the Clash Detective interface.

The Clash Detective window allows you to specify rules and options for undertaking clash tests. In this window you can view results and generate clash reports.

The Test Panel is where you will find all of your clash tests. The test panel isn’t displayed by default, you need to click on the Add Test button in the clash detective. When you select the Add Test button, a new clash test will be created and added to the test panel.

Under the Rules tab, you can define rules in which Navisworks will use to ignore clashes, by default there are four pre-defined rules shown under the rules tab.

In the lower half of the clash detective window we have a section with a few tabs, the Select tab is the default view in the clash detective window. In this tab you can define the clash test by selecting multiple sets of items at a time. You could clash a whole model against a whole model, however this would be a very inefficient process, instead you can test clashes between different selection sets of elements in the model.

The Selection A and Selection B areas display all the items in a hierarchical list that replicates the selection tree window. You can select objects from these areas that will be tested against each other during a clash test.

Beneath the selection windows are a group of buttons which allow you to change what geometry is clashed in the test.

	When Surfaces is selected, surface geometry is included in the clash test. Surfaces is selected by default when you create a new clash test.
	When Lines is selected, line geometry is included in the clash test.
	When Points is selected, point geometry is included in the clash test
	Self Intersect is used to test the selected object against itself for clashes
	The Use Current Selection button is used to select objects directly in the scene view for clash tests
	The Select in Scene button is used to highlight the elements selected in the clash test. They will appear in blue when selected.

The Results tab is where you view the clash results. This tab is divided into three parts, the Results pane, Display Settings panel and the Items panel. By default the Display Settings and Items panels are hidden. They can be accessed by clicking on the panel title which is highlighted in the image.

The Results area displays a list of clash results in a tabbed format showing the name of the clash, the clash status, the date found and the description of the clash. If the clashes have a saved viewpoint, then the viewpoint icon will be displayed in the viewpoint column as well.

After expanding the Display Settings panel, you are provided with options to change which clash is highlighted, choose not to highlight the clashes at all, dim the other elements within the model so you only see those that are related to the particular clash as well as adjust basic viewpoint and simulation settings.

Hidden at the bottom of the results tab is the Items panel. Once expanded you can view information on the clashing objects. The clash information displayed will depend on the select clash configuration.

Finally, in the Report tab you can adjust options for generating clash reports. The generated report will contain the details of all the clash results for the selected test. The report tab has three sections; Contents, Include Clashes and Output Settings.

In the Contents section, you can select the contents of the report, such as the date found, item numbers, grid locations, coordinates of the clash among others.

The Include Clashes section allows you to filter by new, active, reviewed, approved or resolved clashes.

The Output Settings section allows you to select the output format of your clash reports. It allows you to select either the reports from the current clash test or from all clash tests either as a combined or separated format. You can also choose from HTML, XML or recorded viewpoints as your clash report format.

In the next installment, I’ll build on what I’ve shown today and explain how to create selection sets to get better results from your clash tests.