IFC (Industry Foundation Classes) – Part 07 – IFC Exporter Settings and Modelling Workflows in Autodesk Revit

INTRODUCTION

Welcome back everyone. It’s been awhile! ☺

The past six blogs were about implementing the structure of IFC within the functionality of Autodesk Revit and talking about IFC in its conceptual data model form.

It’s now worth noting that we need to package up the data model so that it can be exchanged. IFC can be exchanged in several different formats which can be viewed here. The most commonly used format is STEP (SPF) and when we say ‘IFC file’ we actually mean a STEP file.

For this post we will look at the remaining items which are needed to be configured before you hit the export button to create an IFC STEP file. I’m not going to go through all the settings of the IFC exporter just the ones I have tested and use. A list of all the settings can be found here.

This blog post together with the next one have been based on the testing done in Autodesk Revit 2019 and we are still using IFC 2×3. Autodesk have been working hard to improve bugs therefore there could be changes/improvements in later versions.

IFC Exporter

The IFC exporter is now part of the initial Autodesk Revit install, however it does get updated several times a year to improve functionality so it’s worth checking that you have the latest version.

Updates tend to be released on GitHub first https://github.com/Autodesk/revit-ifc/releases and then on the Autodesk app store https://apps.autodesk.com/en (search IFC).

To access the IFC exporter go to File > Export > IFC

There you will see the first dialogue box where you can either select a pre-made set-up or you can configure a set-up yourself. I always opt for the latter as I’ve had very little success using the pre-made set-ups. There is the option to create and save your own set-up which saves a json file, bear in mind this only saves which boxes have been checked.

If you select Modify set-up… you have the following tabs to configure:

General Tab

I usually change very little on this tab.

• IFC Version – I always use IFC 2×3 Coordination View 2.0 as I find this is more stable.
• File type – IFC (this is IFC STEP).
• Phase to export – This will depend on the project and the container breakdown strategy of the models.
• Space boundaries – I’ve never had use for this or tested if it does anything.
• Project Origin – We’ll talk about coordinates below. I have stated to test this but it is extremely complex. On projects I’ve been part of using Shared Coordinates has always sufficed.
• Split columns ducts and walls by level – this is to split the model up by levels – this can get messy where elements are not constrained by storey levels and I recall issues with structural elements not being assigned to the correct storey level. It’s a setting I don’t tend to use but if you do further testing would be required.
• Include steel elements – This setting was introduced in 2019 and I have checked by default. It’s meant to export steel connections however I’m not sure how much it is needed if the IFC export classes dialogue box from blog post 02 is set up correctly to export steel connections (by default they are not exported). Again would be worth having a test.

File Header Information…

This populates the main file header information of the IFC STEP file. It also populates IfcTelecomAddress with the email address.

There used to be a bug which would only export the email address if the authors name also contained the email address, I’m glad to say that it looks like it’s now been rectified.

Project Address…

This will populate IfcPostalAddress for the building and site. The check boxes at the bottom do not appear to work as it doesn’t matter which one you check both IfcBuilding and IfcSite will be given the address.

I would rather see this built into the Project Information dialogue box so it lives within Autodesk Revit but there is a check button to update the Address parameter in the Project Information dialogue box.

Additional Content

• Export 2D plan view elements – helps to export objects such as the grid or door swings.
• Export linked files as separate IFCs – personally I never used this as I would always create the export from the main model file and other consultants should always export their own models.
• Export only elements visible in view – Allows you to only export what can been seen in the view. It’s a case of balancing which elements aren’t exported through entity mapping with what’s not visible in the view.
• Export rooms in 3D views – this needs to be checked if you require rooms exporting and the above box is checked.

Property Sets

This was mainly covered in blog post 05

The other setting which could be needed is ‘Export base quantities’ which is discussed further in this blog.

Level of Detail

I have never tested this. If anyone has had success with this would be good to hear from you.

Advanced

I don’t tend to use many of these settings however the most useful is ‘Include IFCSITE elevation in the site local placement origin’. The elevation section below it explains why this is useful.

---

MODELLING WORKFLOWS

Coordinates

Coordinates seem to be the single most painful problem in the history of computer aided design, this is particularly exasperated when different software is used on a project and if IFC models are exchanged.

Autodesk Revit has two coordinate systems, I call one ‘local’ and the other ‘real-world’.

• Local is the relative distance from the internal origin to the model, these are small numbers and don’t mean that much;
• Real world is overlaying the real world on top so it can be located on the Earth. These are big numbers, governed by shared coordinates and the survey point.

I always say Autodesk Revit is selfish with coordinates as it puts its own local coordinate system first above the real-world.

The main problem with using IFC models within Autodesk Revit is due to the fact there isn’t an option to change the coordinate system on import – by default IFC models always import using the local system, therefore if the model has been exported using real world coordinates when imported it’s always far away.

The sure fire way to ensure that models from other software import in the correct location especially IFC models is to establish the location of the internal origin point right at the start of a project before any modelling takes place. This is because it is difficult in Autodesk Revit to move the model in relation to the origin once modelling has proceeded. The internal origin was hidden pre Autodesk Revit 2020 but now it is visible.

Even if it’s an all Autodesk Revit project I would still say this is a good habit to get into because you never know what other software or exchange files will be used in the future.

We do this as standard on Bond Bryan projects which has now reduced the amount of queries with regards to coordinates and the interoperability between Autodesk Revit and Graphisoft Archicad.

For export to IFC there are several options. Current shared coordinates uses the real-world system and Internal coordinates uses the local system. Personally I’m not sure why you would need to use the other two but the options are there.

Elevation

A problem we see frequently is when IFC models are federated in programmes such as Solibri Office the models do not align vertically (across the Z plane). The reason for this is the base level where the modelling has been taken place.

In Autodesk Revit it’s best practice to model at project level 0 and use shared coordinates to give the real world elevation (See image below). However models are sometimes created ‘up in the sky’ so they are physically modelled at the real world height which causes the issue.

To overcome this when exporting an IFC model from my experience I have found that checking the ‘Include IFCSITE elevation in the site local placement origin’ box in the IFC Exporter ensures that the IFC models are federated using the real world value and this overcomes the Z height problem.

Levels

To export Autodesk Revit levels to IFC as IfcBuildingStorey they must have:

• the ‘Building Storey’ parameter checked. If they don’t they won’t be exported;
• they have to contain some geometry;
• they also need switching on in the 3D view where the IFC is exported from.

When exporting levels to IFC it should only be the main building storey levels – you don’t want all the levels exporting.

Grid

To export grids to IFC as IfcGrid you must ensure:

• Grids are mapped to IfcGrid in the IFC Export classes dialogue box (see image below);
• ‘Export 2D plan view elements’ is checked in the IFC Exporter (Additional content tab).

Note, I have found that ‘Export elements only visible in view’ if ticked does stop the grid from exporting, so you will have to have a play with the settings to find which works best. This used to work in earlier versions (pre 2017).

Site

Update to blog post 04 – The parameter SiteDescription now works in the Project Information dialogue box as long as a toposurface is not modelled.

Spaces

To export rooms to IFC as IfcSpace you must ensure:

• Rooms are mapped to IfcSpace in the IFC Export classes dialogue box;
• that ‘Export rooms in 3D views’ is checked in the IFC Exporter if ‘Export elements only visible in view’ is checked.

Systems

In IFC a group of elements which all share the same function can be classed as an IfcSystem. Duct and Pipe systems in Autodesk Revit will export automatically as an IfcSystem, however it’s worth noting electrical circuits currently do not, there will be more about this in the next blog post.

Data Types

This has been one area which has had numerous issues, however Autodesk are aware of them and are fixing them as part of their updates. It is something to be aware of and if you think there is a problem report it to Autodesk.

The problem occurs when you create a parameter in Autodesk Revit and use a certain data type and that data type isn’t compatible when exporting it to a certain IFC data type (using the custom property set mapping file see blogpost 05). The combination of the two creates a problem when converting the value.

For example, if you use the piping flow data type when creating a parameter and the value is 100, when this is exported to IFC using IFCVOLUMETRICFLOWRATEMEASURE the value becomes 3.53146667214886.

IFC Base Quantities

These are a set of measurements about an element (e.g. the length of a beam or area of a roof). The setting to export this is found under the Property Sets tab in the IFC exporter. Again I have had mixed results when exporting these to IFC and it’s a topic which needs a lot of improvement. It’s really important to bear in mind that any values exported from Autodesk Revit to IFC should be checked before they are used.

There are three scenarios.

• Some values will be automatically exported but others not.
• If they do export the conversation factor can be incorrect (E.g. volume is not derived from the rooms computational volume but instead during the export process the room area is multiplied by the rooms unbounded height – there used to be a bug where the room area in m² was multiplied by the height in mm. This meant the resulting volume in m³ IFC was three decimal places out).
• There are override parameters for base quantities but these don’t seem to work apart from IfcQuantityNetHeight (more about this in the next blog post).

Again any issues you spot report to Autodesk as this will help improve the exporter going forward.

Modelling tips

Some handy tips for when modelling for IFC export.

• Avoid using edit profile for walls – sometimes these won’t export.
• Only draw one element per sketch.
• Try and use categories which match what the element will be in IFC. E.g. using curtain walls rather than windows when they should be windows.
• When using nested families make sure they are created and ‘shared’ in relation to how the elements need to be scheduled. Example an accessible WC family will need all the components shared so the basin, cistern, pan, grab rails and fittings schedule and export as separate components.
• Think carefully about what an element actually is before assigning it a category in Autodesk Revit and an entity in IFC – for example just because a mirror is in a bathroom doesn’t mean it’s a Plumbing Fixture, a mirror could be in any other room.

---

CONCLUSION

The next blog post will be the final one in this series and it will take everything we have learnt so far and apply it to specific model view definitions. We will use the Construction-Operations Building information exchange (COBie) as the example.

Emma Hooper, Associate Director, Bond Bryan Digital Ltd

Terms and conditions

This policy is subject to change at any time.