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.
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.
1. Incorrectly named project IFC properties
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.
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:
2. 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.
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.
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.
3. Exporting too many objects
How to check and avoid this IFC export mistake
4. 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.
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:
5. Wrong amount and naming of storeys
How to check and avoid this IFC export mistake
Summary
