• image
  • image
07 Mar 2019

IFC (Industry Foundation Classes) – Part 05 – IFC Properties in Autodesk Revit

In the last blog post we looked at IFC attributes which allows you to add certain basic information about IFC entities. However, we need to be able to add much more information (such as performance) to entities, to do this we use properties. In blog post 01 we learned that the properties within the IFC schema are grouped in property sets which are then attached to the entity via the attribute HasPropertySet. Let’s break properties down into two groups:

  • IFC schema properties – these are already listed in the IFC schema (it includes the main element-based ones),
  • Custom properties – these aren’t present in the schema and are defined by the user.

Understanding this distinction is important in Revit as it changes the way properties are exported. For this blog I’m going to give a brief overview of the different methods of exporting properties which can be selected from the IFC Exporter under the Property Sets tab Image: IFC Exporter Property Sets tab (click to enlarge) The aim is to take Revit parameters and map (convert) them to the relevant/specified IFC property in the corresponding property set. This allows the data to move from Revit into IFC and be assured its related to the correct entity.


Export IFC common property sets Prior to IFC Exporter version 18.0.4 only property sets ending in the word ‘common’ were automatically exported, since then all element-based property sets automatically export, so technically speaking this needs rewording in the IFC Exporter. I’m currently reviewing the impact this has on the IFC export. Listed on the IFC schema website are many property sets (see blog post 01) the ones connected to construction elements (like an actuator, door or column etc.) will export automatically providing the box below is checked and the value of the parameter is populated. Image: Export IFC (common) property sets check box (click to enlarge) In some cases, this works with hardwired parameters. If a Revit element is classed as a certain entity and the hard-wired parameters for that element are equivalent to a predefined IFC property for that entity, these will export automatically (if populated with a value). Example:

  • A wall is correctly classed as an IfcWall entity (see blog post 02)
  • Wall elements in Revit contain the hard-wired type parameter Function
  • Depending on which option selected this will export automatically as the IFC property IsExternal to the property set Pset_WallCommon
  • There are several of these hardwired properties which export automatically for a wall these include (Revit parameter ->IFC property)
  • Function -> IsExternal
  • Heat Transfer Coefficient (U) -> ThermalTransmittance
  • Structural -> LoadBearing
  • Fire Rating -> FireRating
  • Manufacturer -> Manufacturer
  • Top is Attached / Base is Attached -> ExtendToStructure

However, there are more IFC schema properties which aren’t included above. If you add a parameter called the same name as the IFC property then it will automatically export (provided it’s populated with a value). Example: AcousticRating is an IFC common property for a wall. If you add a parameter called AcousticRating this will export with no additional mapping required. If you don’t want to use the hardwired parameters mentioned above simply add the equivalent parameter yourself e.g. if you do not wish to use the hardwired type parameter Fire Rating (because you want to use an instance parameter) add the parameter FireRating. This will take precedence during the export process. Note these properties will only export for the relevant entities. Example FireRating will not export automatically for IfcActuator. Export parameter mapping table In addition to this there is the ability to map any Revit parameter to an IFC common property using a separate mapping file loaded in the IFC Exporter as shown below, however I’m not going to focus on this in this blog, as so far I’ve never needed to use it and its very much a secondary mapping process. Image: Export parameter mapping table check box (click to enlarge)


User defined property sets IFC only contains a basic set of properties and this is far from covering everything. However, IFC allows users to add custom properties. Since these could be called anything, we don’t have the benefit of using the in-built mapping of the IFC Exporter, so we have to do it ourselves. This involves using the user defined property set mapping file. Simply put this file is a text file which needs to be configured and then the path recorded in the IFC Exporter (see image below). Image: Export user defined property sets check box (click to enlarge) It allows new property sets to be created and then within each property set you specify which Revit parameter maps to which IFC property. The set-up of this file is where you need to utilise the majority of your IFC knowledge. From what I’ve seen this is the file which is most misunderstood in the whole process. There’s an assumption that it exports all the information required for IFC (including information which should be in attributes). User defined property set text files First, I’m going to explain what files are available following the installation of Revit/IFC Exporter. By default, these can be found in the following location: C:/ Program Files (x86)/Revit IFC 2018/DefaultUserDefinedParameterSets.txt Note, this will depend on the version of Revit you are using To make life a little more complicated there are actually two files which can be used:

  • DefaultUserDefinedParameterSets.txt
  • IFC2x3 Extended FM HandOver View.txt

These files perform the same function, so it doesn’t matter which one you use. The properties in both of them are based around COBie but I don’t want us to get bogged down with this, for now they are just examples of custom properties. Apart from the properties the difference between them is the supported data types list. In the images below you can see the difference between the two files. This is because the Extended FM Handover View file was developed first, when only a few data types were supported, then when the list was extended the Default User Defined file was created. Again, you can use either file and all the data types will be supported. Image: IFC2x3 Extended FM HandOver View.txt (click to enlarge) Image: DefaultUserDefinedParameterSets.txt (click to enlarge) Note, The IFC2x3 Extended FM HandOver View text file is intended to work with COBie Extension parameters, this workflow is however different to what we are discussing in this blog series. But if you do use this file it does need checking as there are some errors in it. I will cover COBie in a later blog post. User defined property set text file set-up For the rest of the blog we’re going to take a tour of the DefaultUserDefinedParameterSets text file. Since this is a text file and there is no way of configuring it within Revit we need to open it up in a text editor. I always use Notepad++ when working in text files. Open up the file and you will see this. Image: User defined property set text file (click to enlarge) This isn’t as scary as it looks. The first thing to understand that the symbol ‘#’ means that anything on that line will be ignored by the IFC Exporter. This is to allow notes to be added that explain how to use it. As it stands the IFC Exporter will ignore everything. The second thing to explain are the orange symbols, this is just how I have notepad++ set up. An arrow represents a tab and a dot represents a space. This comes in very handy as getting the delimitation (separator) correct does matter. It can be broken down into the following parts: A – This tells us how to set up the file B – These are the data types which can be exported C – This is where the actual mapping is defined and what the IFC Exporter reads Looking again at part A I’m to going to break this down into line 1 and line 2. Line 1 In more detail the first line tells us how to set up a new property set. Through my testing the ‘I/T’ part (green) doesn’t really make much difference to the export, it’s getting the entity part (blue) correct which is critical and this is where you need the basic knowledge of IFC from blog post 01. In blog post 01the‘basic overview of the IFC2x3 schema’image shows that most entities fall under ‘element’ within the IFC schema, so you can either use IfcElement when applying it to occurrence entities or IfcElementType when applying it to type entities. However there are entities which don’t sit under Element like IfcBuilding and IfcSpace for IFC occurrences and IfcDoorStyle and IfcWindowStyle for IFC types, therefore these need listing as well. Line 2 The second line explains how to set-up the properties within the property set. There are two things to point out here:

  • If the Revit parameter (red) is named the same as the intended IFC property, then you don’t need to include it. My preference is to always try and name Revit parameters the same as I want them to be in IFC, this just helps removes any confusion and ensures consistency.
  • The data type (dark blue) is the IFC data type (taken from the list in part B). It’s worth noting that these sometimes aren’t compatible with the ‘Type of Parameter’ assigned when creating Revit shared/project parameters.

Applying what we have learned to section C we have the following (I have removed the COBie properties) Image: Updated example user defined property set text file (click to enlarge) For Revit parameters which export to IFC properties I use the NBS shared parameter file, as it not only has every IFC schema property it has many more. If there isn’t one suitable there, then as a last resort I will create my own. Just bear in mind sometimes the data types might not suit your needs.


Export schedules as property sets This basically creates a property set from a schedule (which is called the same name). All the parameters for the elements in the schedule are put into the property set. This is activated using the check box below. The other check box allows you to filter which schedules are exported and there is a further option to filter this by the parameter IfcExportAsusing the value Don’t Export. Image: Updated example user defined property set text file (click to enlarge) This method an alternative to using the text file and may work in some cases, but some points to bear in mind:

  • Generally, you will need multiple property sets per entity, so you may need many schedules setting up, which could get complicated to manage. The text file would be easier to set-up and manage in this regard.
  • The user has no control over data types, these export as per the in-built settings of the IFC Exporter.
  • There are some bugs with system families and property sets, example for IfcWall actuator and chiller property sets were also assigned.
  • It doesn’t work for spaces.

Export Revit property sets There is the option to export all Revit properties which are put into property sets based on the parameter groupings within Revit. Image: Export Revit property sets (click to enlarge) As far as we’re concerned you should NEVER CHECK THIS BOX! It goes against the principles of using IFC as it just basically takes all the parameters in Revit (some of which don’t need to be exported) and just dumps them in the IFC. There is little control over what’s exported, where its exported and there is a big risk that some of the information will be incorrect. The other check box is Export base quantities I feel this will be a future blog post.


Conclusion We now know the different methods for exporting IFC properties from Revit and that these workflows differ to that of IFC attributes. While there are many options for exporting IFC properties the method(s) chosen must help to deliver the required project requirements. There are pros, cons and many nuances in each method so it’s very important to always keep testing and checking the results. One way is to build test files, that way you will be assured that the mapping will be set-up correct. In the next blog post we will look at more ways of organising information within the IFC schema and that’s through classification and layers.

Emma Hooper, Associate Director, Bond Bryan Digital Ltd

Terms and conditions

All content provided on this Knowledge Hub is for informational purposes only. The owner of this Knowledge Hub 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 Digital Ltd will not be liable for any errors or omissions in this information nor for the availability of this information.
Bond Bryan Digital Ltd 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 Knowledge Hub pieces through all social media platforms. You may include links to the original blog pieces and use part of the Knowledge Hub 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 Digital Ltd.
 

This policy is subject to change at any time.