10 common IFC Export Mistakes

10 Common IFC Export Mistakes to avoid – part 1

In my career, I have seen many IFC files and witnessed many IFC export mistakes. I was lucky to work with various different projects – from houses, through blocks of flats, office buildings and ending on the huge hospital project. BIM focus on those projects was also different – from almost non-existent (we got IFC delivered to the construction site, but nobody bothered) to extremely high, building directly from the BIM models. Therefore, I want to share with you the 10 most common IFC export mistakes I have encountered. How to check whether they exist and how to avoid making them.

To underline the versatile ways to achieve the same results, I used screenshot examples from a range of software programs as well as different projects, models and disciplines.

Table of Contents

Opening IFC file after export - a few words about IFC viewers

So, you have happily exported a model and are ready to upload it on the project’s CDE. STOP!

There are a few things to address. Please open your file before moving it to the shared state on the project’s CDE. Where should you open it? Literally in any free IFC viewers available on the market. Nevertheless, some choices available are better, some are worse.

“Solibri Anywhere” then? That is the first choice for many. I reckon this is great software, though it is not the best to view IFC file structure. Let’s say that Solibri is too kind for an end-user – it manipulates how the IFC structure is presented on the screen. The software doesn’t show a full IFC hierarchy. Moreover, it changes the names of IFC entities. Have you ever seen IfcNumber in the schema? Me neither. We have only IfcName and IfcLongName. The first becomes a “Number” in Solibri, the latter “Name”. That makes the initial control of the IFC structure a little bit harder. Unnecessarily.

What do we recommend instead? I prefer using BIM Vision (download), the tool created by Polish company Data Comp.

Ignacy, on the other hand, likes DDS-CAD (download), a Norwegian based software company Data Design Systems.

Lately, I tested BIM Collab Zoom (download) and it also looks promising.

All three are good, and none of them do any changes to the IFC schema. They might look a little corny but work well. And that’s the most important.

There are also loads of other software available on the market. If you have your favourite and it works for you – just stick to it, no point in trying new, if old works fine.

Why should you even bother about IFC tree and naming? That’s coming in the next chapters.

Most common IFC export mistakes

Below comes the list of 5 most popular mistakes while performing IFC Export. The next 5 comes in the part 2.

Incorrectly named project IFC properties

IfcBuilding
Incorrectly named values.

Every project has its name, number, site number, etc. Those are the values required by the building owner and that we put into drawing tables. Why do we even need them? Let’s imagine an easy situation, in which your project is the first stage of the building complex. And afterwards, the Building Owner would like to merge all buildings into one master database. Wouldn’t it be handy to give each project, site and building a unique, yet logical numbering and naming? It gives data good structure, makes it easier to manage.

Ifc structure - correct
Example of correctly named properties.

How to check and avoid this IFC export mistake

In your IFC viewer (the one that shows IFC structure, as you know now), click on the top three properties (IfcProject, IfcSite, IfcBuilding) and check their number (IfcName), name (IfcLongName) and other properties, if required (Phase, Address, etc.).

To avoid this error check if those properties exist in your BIM Authoring software. Check properties mapping in IFC export. Tips on how to do it in:

Wrong object classification

That one is everyone’s favourite one. It is mentioned in every BEP, BIM Coordinators are always shouting about it. And still, objects are classified incorrectly.

The problem here is two-fold and I will deal with them one after another:

  • Incorrectly assigning categories/classifications/properties in the IFC mapping table (or more commonly: not doing it at all).
  • Creating model components using inappropriate model categories e.g: terrain as a slab, stairs as a beam. And then not associating them with a correct IFC entity. (class)

Ad.1

Different software programs have different capabilities of translating their native categories/classifications into IFC classes. Many are also “by default” not set. The problem becomes even greater if you want to introduce new properties into existing property sets. If you don’t clean up the mapping table, you will end up with a pile of IfcBuildingElementProxy. This IFC class has little value, especially if set to objects that have an existing IfcClass.

A long list of Building Element Proxies. They all could - and should - have been avoided.

Ad.2

This originates from software limitations – not all objects are equally easy to model using correct tools. For instance, sometimes it’s easier to model terrain with a slab tool or stairs with a beam tool, etc. As a result, we get a huge unsupported slab around the whole building. Or a row of short beams in the staircase. Both of which generating multiple issues for a BIM coordinator and limiting the trust of a quantity surveyor.

IfcSlab as terrain - incorrect export
Terrain (marked blue) classified as IfcSlab.

How to check and avoid this IFC export mistake

Adjusting categories/classifications in the mapping table is a crucial part of preparing a project for delivery. If a project is introducing new properties they also have to be mapped. When it comes to modelling, the rule is to always remember to assign objects to correct classification if you used a different tool than designated. If you don’t do it straight away, you’ll forget!

To check if the export is correct, simply open any IFC viewer and expand the IfcBuildingStorey position. Check if there are not too many (preferably none) IfcBuildingProxy classes. Check what type of object has those. Can you correct them? When it comes to the wrong classification – check for typical objects, namely stairs, terrain, and complicated shapes. Leave the rest for the BIM Coordinator, he/she has the correct tools to do it.

Exporting too many objects

During the design process, you will probably use additional objects. Be it supporting lines, generic families or other elements. After months of work, our models are full of such. One thing is to keep the model clean by purging it, but a whole different story is to export only those objects that are actually needed and required in BEP.

How to check and avoid this IFC export mistake

The key to success here is to create a separate view containing only elements that are meant for the export, whereas filtering out all the others. Then, during the export process, choose an option to export only elements visible in the view. Check the export-view settings beforehand to reassure yourself that the filters are set correctly. I don’t know any fast method for the after-export check without using coordination software. Which only put emphasis on export view setup.
ARCHICAD-IFC export window
Export window in ArchiCAD. “Export Visible elements” is the option to choose.

Exporting placeholders or other’s objects

Any model should be free from any duplicates and placeholders (temporary objects drawn by one discipline but in the end belongs to another. Often used for prefabricated elements). It is pretty easy to maintain within one discipline. But it is often a challenge in federated models. There are numerous interferences between disciplines. Should an architect model this wall or a structural Engineer? And this sink – again the architect or maybe a plumbing engineer? More often than not, designers duplicate different objects, thus creating hundreds of clash issues.

Doubled IFC object in viewer
A colourful object is a good indication that elements are duplicated.
Sanitary object
And indeed, the toilet exists in architectural and sanitary models. Notice, that washbasin exists only in the sanitary model, which is correct.
Until the given point in project development, it is ok to use placeholders. But afterwards – designers have to remove them. The final responsibility for a given object is presented in the model development matrix – a table describing requirements for IFC objects depending on the project stage.

How to check and avoid this IFC export mistake

Create a project model development matrix where you describe the final responsibility for the model objects within interfering disciplines. Then, everyone has to remember to use “placeholder” objects and filter out this category from the IFC export view (see chapter above).

Before the export, check the view if you don’t have visible elements that belong to another discipline. If you are not sure which are those – check the abovementioned matrix. If such a matrix doesn’t exist, it is worth starting a conversation about it. After the export, verify that those objects haven’t come up anyway. Look for bearing walls, sanitary elements and others that often are in the interface of disciplines.

Here is an example of such model development matrix:

Wrong amount and naming of storeys

Sometimes designers have to create additional levels to make their life easier. However, it is important to exclude them from IFC export. Since all IfcBuildingElements (walls, slabs, doors, etc.) belong to IfcBuildingStorey, an error here causes an error on every object. The IFC structure is going to be faulty and interoperability with other programs may fail.
Additional levels in the model
Additional levels in the model. Take a look at the Building Storey parameter. If this one is ticked, it creates IFCBuildingStorey. In this example, Roof Lev. 3 should not come as a building storey (more about this in Ignacy’s post: https://bimcorner.com/exporting-ifc-from-revit-part-2-top-level-ifc-entities/).
Exported model - too many building storeys
Incorrectly exported levels. All roof elements have been checked as “Building Storey” in Revit, which means that they come as floors in the IFC tree. In this example only 1st, 2nd floor and Roof - main should come as storeys in IFC.

How to check and avoid this IFC export mistake

In a BIM authoring tool, check if nobody ticked supportive levels as building storeys. After IFC export, just open the file in a viewer and check the IFC tree structure. Correct building storeys and their heights are usually described in BEP.

Summary

This part describes the 5 most common IFC export errors. You can solve most of them by creating quality project standards: mapping tables, export views and IFC exporter set-up. In the next part, we will take a closer look into properties, geometry and IFC schema. Stay tuned!
10 common IFC Export Mistakes - Infographics
5 most common IFC Export mistakes

Did you like that post ? Share it with others !

We spend a lot of time and effort creating all of our articles and guides. It would be great if you could take a moment to share this post !

Share:

Share on facebook
Share on twitter
Share on linkedin

Comments:

Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments

Author:

Download BIM Salary report:

  • BIM specialists’ salaries from 24 countries from around the world,
  • Information about the maturity of BIM adoption in each of these countries,
  • List of websites where you can find BIM job in a given country. 
BIM Salary Report

Newest articles: