In the last blog post, I focused on why IFC export is important. There has been a great discussion on LinkedIn, partially about why do we even use IFC export instead of just continuing designing directly in the IFC model? Why is there still no reliable solution on the market?
Though I also agree that such a thing would be awesome, we have to stick to what we have at the current moment. And that is a workflow that requires frequent delivery of IFC file version 2×3. Although IFC 4 is getting more and more recognition, software producers are lagging behind with certification. This is quite unfortunate since IFC 4 solves many issues known in 2×3.
Back to this entry though! ! I’ve tried to build a comprehensive list, yet keep it on a general level – different companies and even different projects might have their specific export requirements. If you have a good rule to add somewhere below – just hit me on LinkedIn, email or comment below the article!
Table of Contents
General rules for IFC export and parameters
Dos
- Give a model a correct name according to the project/standard requirements (read about requirements in ISO19650 here)
- Remember about common project parameters such as IfcProject.Name, IfcSite.Name, IfcBuilding.Name, IfcBuildingStorey
- Define correct coordination point, level, rotation and True North
- Export your discipline zero-point object
- Define correct rooms and levels boundaries
- Objects should exist only on one level (with some exceptions, like longer columns supporting facade elements)
- Assign correct levels to all objects (heights)
- Use correct object types and assign correct classes to objects, even if they are modelled using a different object in the modelling software (a common example of stairs being modelled as slabs, and then exported as so. Architect should manually classify them as stairs)
- Objects have to have defined correct material layers with their thickness
- Use logical and consequent instance naming (especially doors, lighting fixtures)
- Remove placeholders for other disciplines (e.g. walls, sinks, switchboards, etc.)
- Export necessary parameters, both discipline-specific as well as project defined (for example – status codes)
- Clean out drafts, sketches, supportive lines.
Don'ts
- Don’t export IFC and import it again to another native programme (because of loss of data)
- Don’t export all objects in the model – set correct filters on exported objects (what categories should and what shouldn’t be there)
- Avoid deleting objects (especially if a project uses BCF workflow)
- Don’t export too fine geometry details – especially for the big models. IFC is not for visualisations or gaming
- Don’t export schedules or legends
- Never export all parameters – only those defined in the BEP
- Never export references (only your own objects).
Consequences of faulty IFC export
Depending on what has been done wrong, there may be the following consequences:
- Impossible to federate (wrong coordination points, rotation, levels)
- Impossible to coordinate (the wrong objects exported, lack of parameters)
- Hard to navigate (too heavy on details)
- Unreliable to use as a reference (exported references, drafts)
- A combination of the above – the model becomes totally useless 😉
Specific rules depending on the export purpose
Reference model
We might want to export the model to have it as a reference. This purpose is very specific, driven by what discipline it is meant for. It can contain numerous different setups and rules. I’ve listed a few of the most popular with some important points. A small process remark: those models serve as internal Work In Progress models for a design team and should be kept visible only to them (as a part of internal CDE or hidden by access permissions).
ARC to STR (Architecture to Structural)
- Eksport only raw construction model, including elements such as openings/black-outs, stairs, windows, doors, information about the material (concrete/wood/steel/masonry)
- Reference/Placeholders to places where the heavier load is planned, like heavy machinery
- Filter out unnecessary elements (landscape, furnishing, details)
ARC to MEP (Architecture to MEP)
- Correct export of spaces (MEP engineers need those for calculations)
- Placeholders for MEP equipment (air handling units, pumps, etc.)
STR to MEP (Structural to MEP)
- Bearing elements (to plan a path for services)
Consequences of faulty IFC export
Too many unwanted details in a discipline model shouldn’t be a catastrophe – however, it will generate some more frustration on the engineer’s side. Definitely more dangerous is the incorrect export of spaces for MEP – the volume of the space is a basis for the calculations (such as fresh air amount). Some unnoticed mistakes might lead to insufficient capacity of services or, on the contrary, over dimensioning of the system.
When to perform this IFC export?
This export is meant for designers as a Work In Progress stage. It is relevant during the design phases: Concept and Technical Design. The architect’s office collaborates with all other design offices and they exchange IFC files (using a Common Data Environment platform).
Multidisciplinary coordination
In general, the most important thing is to let the BIM Coordinator do his work – check models for clashes and parameters. The models have to be clean and tidy and have all designed objects exported. Some of the most important items to check:
- Export the zero-point object for your discipline
- Check if the model structure is compliant with BEP
- Divide model correctly
- Export all your discipline elements
- Export status codes
- Don’t export all parameters – only those needed
- Correctly classify all objects (slabs as slabs, stairs as stairs, etc.).
Consequences of faulty IFC export
When to perform this IFC export?
Quantity Surveying
In this type of export, the focus is on quantities and materials. Classifications (e.g. Omniclass, Uniclass or, in Norway – Norwegian Bygningsdelstabellen) are also very handy for surveyors to create their cost breakdown structures. A common challenge for QS is that different software provides information about quantities in different places. It makes it harder to execute correct take-off. It is therefore important to agree on and use common properties for quantities for the whole project.
Some other points to remember:
- Export quantities (Base Quantities)
- Correctly classify all objects (slabs as slabs, stairs as stairs, etc.)
- Export classifications (if used in the project)
- Export parts as building elements
- Check what view filters are set on and export correct categories and objects
- Export material layers
Consequences of faulty IFC export
When to perform this IFC export?
Model-based construction site
Performing the IFC export for contractors, the most important thing is to put attention on buildability from the model. That means in general to include parameters with responsibilities/companies (concrete construction, plumbing, etc.) and correct status codes (“For construction”). Oftentimes construction companies have their own specific needs for parameters or set up of the model.
Remember to include in your export:
- Status codes
- Discipline and responsible contractor
- Control Area parameter (the building is often divided into smaller areas)
- Discipline parameters necessary to build, such as installation height, fall, object type, reinforcement, etc.
Other handy parameters:
- Floor-height reference mark (to have an easily accessible and common measurement point across the whole building)
- Links to a database for delivery of Maintenance, Operation and Management documentation
- Links to drawings/place with additional information (mostly a CDE directory)
Extra tip! It can be valuable to have a kick-off meeting about the IFC export with relevant companies (contractors or suppliers) to discuss their expectations and needs. In the end, they know best what they will need to build. Furthermore, some small adjustments in the settings of IFC export can give huge final results!
Consequences of faulty IFC export
Missing a type object or property set might even lead to a stop of work on the construction site. And sometimes the reason is very obvious and is in the IFC export settings – for example missing the responsibility parameter that the contractor is setting filters after. Another possibility is that, on design and build projects, contractors also perform the collision control and they can send claims if the model is missing on parameters or correct coordination.
Other risks are incorrect work execution, due to the flaws in the design documentation aka model. If the model is too heavy and hard to navigate, it may lead to reluctancy in using BIM Stations on site.
When to perform this IFC export?
Facility Management
This is the ultimate stage for every design model. It is up to the project to specify the amount of data provided in IFC versus PDF/Excel documents. Some might require e.g. a manufacturer or product information as property sets, while for others it is sufficient to deliver PDF documents. In the end, it is inevitable to avoid Maintenance, Operations & Management documents in the form of PDF (in my mind it’s pointless to describe maintenance within IFC parameter 
). Hence, we have to aim for clear structure and easy-to-find attributes linking models with database.
In Norway, it is popular to use TFM classification (Tverrfaglig Merkesystem, which can be translated as “Interdisciplinary Labeling System”) to code and identify each object in the model with a unique, machine- and human-readable string. Afterwards, this string is exported to IFC and serves as a connection between the model and the database. Other possibilities are COBie format or other country-specific classifications and standards.
Personally, I would vote for minimum data in the IFC model. Instead, supplied with a unique key attribute that links every object with an external database containing both operational data (maintenance intervals, manufacturer information etc.) and documents (maintenance instructions, schemas, etc.).
IFC as a handover format includes:
- Links to storage for additional documents related to the object (can be replaced by the connection with external database)
- Unique identifier to connect a model object with external documentation database
- Objects classification supported by the chosen CAFM system (e.g. COBie, TFM, or other)
Consequences of faulty IFC export
When to perform this IFC export?
This IFC export is performed at the project handover to the Building Owner. Yet, the data that defines this export might be already present in the model beforehand. In Norway, many owners require to deliver facility management data and documents up to 3 weeks before the object is installed on-site. Thus they secure better quality data (fewer piles of documents at the very end of the construction phase).
