IFC (Industry Foundation Classes) – Part 02 – Understanding Entities in Autodesk Revit
In the last blog I had a bit of moan and we learnt about some basic IFC principles. In this blog we’re going to take what we have learnt and apply it to the world of Revit. Therefore, if you haven’t read it please do so.
I wanted to start by giving a friendly warning – this isn’t for the faint hearted. In fact, I’ve heard it described as black magic, performed by wizards with the patience of saints.
It shouldn’t be this difficult and long winded. There is some work going on to improve the process, but we really need this simplifying and integrating into Revit as much as possible without the need for more addons and additional files.
My last lot of testing was in Revit 2018.2 and IFC exporter version 18.4.0. This is what I’ll be using for the blog series. The export from Revit 2019 may have different results.
THE REVIT ENVIRONMENT VS THE REST OF THE WORLD
In my previous blog I said the construction world doesn’t start and end with Revit, don’t get me wrong it’s an important tool in the information ecosystem but, for this blog series I want us to think of Revit in terms of this diagram.
Image: Revit environment vs the rest of the world
The green circle is the Revit environment, this needs to be set-up to get the best out of Revit. So the programme knows where to find things and modellers can model as efficiently as possible making use of all its in-built functionality. It’s about all the Revitisms that don’t make sense outside of Revit things like categories, families, view filters or worksets. Even though its software specific it’s very important to maintain discipline to this regard as there is a correlation with the health of models compared to how useful the model will be.
However, I’m not going to talk about the Revit environment in this blog series. I’m going to talk about the pink overlap in the diagram – preparing information within Revit for export so that other software can use it, sharing information with the rest of the world using one consistent IFC data structure.
Revit – IFC comparison
When we export an IFC from Revit it is crucial the entities are exported correctly as this sets up the functionality of the IFC schema, remember the tree diagram in the last blog.
We know that IFC entities are split into occurrences and types, think of these like Revit instances and types. The equivalent of IFC entities are Revit categories and before we get into the detail let’s spend a little time understanding them.
Categories are the backbone of Revit, they are Revit’s primary element taxonomy (a list, to order information) and they tell Revit what an element is and how it functions in the Revit database. However, from a logical perspective, it’s not a great list because in some places it encompasses lots of elements (Mechanical Equipment) and in others it is very specific (Nurse Call Devices), the balance isn’t quite right.
So, when we compare this to IFC entities we find that sometimes Revit categories align one to one, like Walls to IfcWall, but in some cases a single category will map to multiple entities, like Mechanical Equipment can export to many IFC entities such as IfcBoiler, IfcCondenser or IfcChiller.
When I created the BBD Revit test file I wanted to explore this alignment further, so I created view filters to look at the mismatch.
In the file each element represents an IFC predefined type and the groupings of these are grouped by the corresponding IFC entity. The Revit categories used represent what would be used in real life modelling (so for a boiler I’ve used the mechanical Equipment category). The colours represent Revit categories, in a nice ordered world you would want to see one colour per group, but you can see how misaligned it all is.
Image: BBD Revit test file categories view [Click to enlarge]
To get something in Revit to become the correct equivalent in IFC we have to use a process called mapping; taking something and applying a rule to automatically change it into something else. This is what we need to do to enable elements associated with Revit categories to become associated with the relevant IFC entity.
There are two ways of doing this in Revit; at category level or family level.
ENTITY MAPPING – CATEGORIES (GLOBALLY)
It’s useful to map at a category level because it reduces having to apply the mapping to each individual family type. This method tends to work better for system families and most structural elements, as the alignment is more one to one.
This mapping takes place in the IFC Export Classes dialogue box
Application Button/File > Export > Options > IFC Options
And is carried out via a text file which is loaded in using the load button.
Image: IFC Export Classes dialogue box [Click to enlarge]
By default, this table takes its mapping from the following text file:
Image: IFC Export Classes mapping file [Click to enlarge]
Don’t get hung up on the fact the default table uses the word “layers”, this process has absolutely nothing to do with layers. It’s just that the text file we’re using just happens to be structured the same way as the one used in the Modify DWG/DXF Export Setup dialogue box, but both files are different in their content.
From the IFC Export Classes dialogue box image we can see that there are several columns:
- The first column is the Revit category in bold and all the corresponding sub-categories are shown in lighter text.
- The second column is IFC Class Name this is the IFC entity value. I believe that the behind the scenes mapping doesn’t mind if its at type or occurrence level. Start with the type entity first and if there isn’t one then use the occurrence as a general rule.
- The third column IFC Type is meant to be for the Predefined Type however I have never managed to get this column to work, even now I have just tested the Telephone Devices mapping and it didn’t work. Due to the varying nature it really needs to be applied at element level anyway, more about this in the third blog post.
I would highly recommend creating your own mapping file as I have found parts of the default one that are incorrect or could be mapped better. Some examples why I choose to create my own file are listed below:
- I stick to this rule of thumb, I use IFC types first then if there are no types I use the IFC occurrence. Example I would use IfcPipeSegmentTyperather than IfcPipe It doesn’t matter which way you approach this as both create a correct export, so you can leave them as they are, but I find using the types a more consistent approach. Note, always use IfcDoor and IfcWindow for doors and windows.
- Make sure capitalisation is correct, example in the default it says IFCCableCarrierSegment rather than Ifc I have found that sometimes this does matter and when you’re trying to balance many different variables when testing, it’s important to remove any potential issues.
- Refine categories as much as possible, example Structural Framing by default all maps to IfcBuldingElementProxy but some of these subcategories are predefined types like Joist (which is IfcBeamType) and Purlin (which is IfcMemberType).
- Remove incorrect mapping like:
- Curtain Wall Panels by default export to IfcCurtainWall this should IfcPlateType
- Curtain Wall Mullions by default export to IfcCurtainWall this should be IfcMemberType
- Plumbing Fixtures by default are mapped to IfcFlowTerminal which is a high-level entity. I understand why this has been used because plumbing fixtures can be exported to IfcSanitaryTerminalType or IfcWasteTerminalType but this creates an incorrect export. I would use IfcBuildingElementProxyType for any situations like this (there are many) just to follow one consistent rule and you know that you have to find all these and change them. These have to be overridden at element level.
- If there are some elements you don’t want to export this is a good opportunity to exclude them using the value Not Exported.
A word of caution when creating your own mapping file. Work in the dialogue box rather than the text file. I found strange things were happening to my text file once loaded in. This could have been partly due to the fact that subcategories make up the list structure (so its dynamic rather than static) and there is an automatic parent child relationship between categories and subcategories. Also note if you make a change in the dialogue box and you press OK that change is made to the text file.
Once you have created the mapping in the dialogue box save the file for use on other projects but keep an original back-up and keep an eye on it.
Once this file is set-up it creates a high-level mapping strategy. However, going back to the test file, the colour misalignment highlights the majority of the mapping isn’t one to one between Revit categories and IFC entities and you will end up with many IfcBuildingElementProxy objects. For this you need to go down to the second level of mapping, the family level.
ENTITY MAPPING – FAMILIES (ONE TO ONE)
I prefer this method as it gives you much more control and you don’t have to start getting entwined in complex category/subcategory permutations which only work in certain situations. It’s much simpler, you map family type A to IFC entity B, however because it’s done on a more granular basis it does involve more work.
For this method you need the override parameter IfcExportAs,you may have seen this and wondered what it does. It basically performs the same function as the second column of the IFC Export Classes dialogue box from the first method. The text parameter can be added to families or the project and I always bind (add) it as a type property under the IFC parameters group.
When I talk about binding parameters these should always be shared parameters to maintain control. It’s very important that you manage family and project parameters carefully. Those in charge of Revit models should know exactly what parameters they have in their models and where each and every one has come from to avoid duplicates due to different GUIDs.
I try and take my shared parameters from other sources. I generally use a combination of NBS and Autodesk.
Note, always double check these before you use them as sometimes data types might not align to your purpose.
I only create my own shared parameters when I exhaust all other options.
Once you have bound the parameter you need to add a value.
- For a boiler family IfcExportAs is IfcBoilerType.
- For a floor finish modelled using the floor category you can use IfcCoveringType
- For a pile (because there is no type in IFC) use IfcPile, note even though IfcExportAs is a Revit type parameter it can still be used. I have found no benefit in having IfcExportAs as both type and instance parameters, this process is complicated enough.
As mentioned earlier you can also get away with not using the “type” part even if the occurrence part doesn’t exist in the schema and it will export correctly, however I like to be as compliant as I can.
For elements you don’t want to export you can use the value DontExport.
To help the manual process of adding values you can use the Classification Manager for Revit and configure it to populate these values by selecting the correct one from a list. We’ll cover this in the next blog post.
CHOOSING THE CORRECT ENTITY
You’re probably now thinking “that’s all well and good but how do I know what the entity should be?” I’ve not managed to find a definite list and for me this has just come from spending a lot of time in the buildingSMART website and hours arguing with myself. Probably the best resource is actually one of our old blog posts.
- Blue text refers to the occurrences
- Green text refers to the types
- Purple text refers to some of the predefined types
We are currently in the process of updating it to include more elements.
If anyone knows of such a list or has comments regarding our list then please get in touch it will help to make the list much more useful for everyone.
When you have successfully set-up the entity mappings and completed an export (export will be part of a later blog post). When you view the exported IFC in an IFC viewer, rather than only seeing a few entities listed (with most elements exported to IfcBuildingElementProxy) you will get a beautifully defined list like below.
Image: Object tree from DDS CAD [Click to enlarge]
The name of the game is to have as few IfcBuilidingElementProxy entities as possible!
You may notice in the above image that the structure is based on occurrences and that sometimes high-level entities like IfcFlowContoller have been used, as mentioned earlier this is because some IFC type entities do not have the equivalent occurrence, (like IfcValveType). As long as you map to the correct lowest level entity the export will create the correct occurrence.
The way the Revit IFC exporter works is you are limited to certain category to IFC entity export combinations.
Example, you cannot export an element which is on the roof category to IfcFurniture or a Revit curtain wall to an IfcWindow. This rigid approach does have its benefits, it pushes modellers to use the correct category, so if they are modelling a window they should use a window family. But it does mean that every permutation exists in its own right and sometimes when you do have to model something slightly off track it might not export correctly.
If you do come across anything which doesn’t work then let Autodesk know, they are continually updating the exporter to capture any bugs.
You can post issues at https://github.com/Autodesk/revit-ifc/issues
IFC Entities are the equivalent of Revit categories and these should be the first item that’s set-up when exporting an IFC. There are two ways of doing this; the first is high level at the category level and second is more granular at family level using the parameter IfcExportAs.
Having this set-up means that in the exported IFC all elements know what they are and what they are connected to.
It’s important that this set-up is done for all IFC exports regardless of purpose as this sets the basic functionality of the data structure. If you don’t get this right the IFC loses its usefulness.
In the next post we will look at predefined types.
Emma Hooper, Digital Information Specialist, Bond Bryan Digital
Terms and conditions
All content provided on this BIM Blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. Bond Bryan will not be liable for any errors or omissions in this information nor for the availability of this information. Bond Bryan will not be liable for any losses, injuries, or damages from the display or use of this information.
We are happy for others to share our blog pieces through all social media platforms. You may include links to the original blog pieces and use part of the blog to then provide a link to the original content. However we would appreciate it if the content is not reproduced in full on other sites or publications without written consent being granted by Bond Bryan.
This policy is subject to change at any time.