Understanding how to use IFC

/in /by

I have often read discussions on LinkedIn where many criticize the IFC format as complicated and useless, preferring proprietary data formats from various companies. I agree that the IFC format is more complicated than it should be, but many participants in these discussions misunderstand how the official IFC file should be used. While I understand why the confusion occurred, I want to clarify how to-date the IFC model is generally used.

Many view IFC as an exchange format that allows a colleague to continue working on a model e.g. modeling in Revit (Autodesk) and shares this to Allplan (Nemetschek) to continue modelling. However, with official finished IFC standards, this is not the case.

IFC is an open standard for exchanging model information. It is similar to how a non-editable PDF document can be exported from a Word document. Using a BIM authoring tool is like working with Word, and exporting to IFC is like creating a PDF. The IFC model is not meant to be edited but to be placed in a Common Data Environment or linked in another authoring tool for further analysis, such as collision detection or quantity takeoffs. The intention is to share the model without allowing others to modify it, which is why it is called IFC4 Reference View or Coordination View. Details are described in buildingSMART. Here, key characteristics and workflows as well as use cases are described and show how it was originally intended.

Key Characteristics:

  • BIM Information Source: Remains with the originator.
  • Intellectual Property: Full parametric behavior and intellectual property stay with the originator.
  • Model Ownership and Accuracy: Responsibility remains with the originator.
  • Model Publication: Published as an IFC4 Reference View, reflecting its as-is status.
  • Receiver Access: Full access to the IFC4 Reference View content.
  • No Modifications: The receiver is not supposed to modify the model.
  • Analysis and Extraction: The receiver can analyze and extract model information.
  • Change Requests: Must be communicated to the originator.
  • BCF Support: The buildingSMART standard BCF supports these change requests efficiently.

Common Workflows and Use Cases:

  • Coordination Planning: Combining discipline-specific IFC models for visual checking.
  • Clash Detection: Identifying clashes between different discipline-specific IFC models.
  • Background Reference: Loading an IFC model from a different discipline as a linked model.
  • Quantity Take-off: Determining quantities of model elements.
  • Construction Sequencing: Associating the IFC model with a construction schedule.
  • Visual Presentation: Presenting the IFC model to a broad audience.

But still, editing an IFC file would be ideal for collaboration, allowing colleagues to assist each other when needed. There have been experiments with IFC4 Design Transfer View to enable model modification, but this cross-platform approach was not finalized and is not officially available, so you have to be lucky if your authoring tool supports IFC4 Data Transer View. And because some softwares support it but some don’t, it is understandable that there is much irritation. It would be beneficial for development to continue, allowing the choice between sharing an editable “Word” document or a non-editable “PDF” model being more widespread.

Of course there are possibilities to modify IFC (Reference Models) with IFCopenshell or BlenderBIM, but these are not yet user-friendly enough for the entire community to easily utilize them, but they are improving! Luckily buildingSMART has noticed that the solutions proposed are not widely spread due to the complexity and non-user-friendliness and they have a strategy to improve it.

I hope this comes soon and finally makes planning processes easier.