buildingSMART Forums

IFC files that reference one another

In the following screenshot, two IFC files are loaded into the same program. The first IFC file contains a lot of architectural elements, and the second IFC file contains a structural element (a single slab).

This is a very common scenario, where multiple IFC files are created by different disciplines, different roles, responsibilities, and timeframes, but all merge together to create a federated BIM model. The ability to split and combine files is vital and common in many other industries (software, CG, VFX), yet I get the impression that the BIM industry still tends to create a single, big, unwieldy 2GB IFC files :wink:

We should expect them to provide a collection of neatly segmented IFC files that reference each other to build a federated BIM model. This allows you to apply version control much easier, implement model servers easier, and do analysis faster. If I modify a single wall, or just add a few properties (e.g. as part of a digital twin sensor output), I should not need to rewrite an entire 2GB IFC file. There could be hundreds of IFC files that create a building - some may contain as little as purely CRS definitions, some may just contain PSets related to a discipline, and others may contain geometry.

In the screenshot below, both project, site, building, and storey share the same GlobalId, and therefore a referring to the same element. However, you can see that the IfcProject.Name of the second IFC file is My identical project, which is different to the IfcProject.Name of the first IFC file, which is My project. In this scenario, which data should the BIM tool consider to be the master of truth?

I can think of a few approaches:

  1. Establish a convention where the master of truth IFC file defines the element in its entirety. Any IFC file which merely references the same element should have blank attributes ($).

Here is an example of it:

building-structure.ifc - used to define spatial hierarchy:
#30=IFCPROJECT('0ovDN8c9v9xABetj5G4Toz',$,'My project',$,$,$,$,(#28),#19);
#193=IFCBUILDING('0tjzSZIM97xO19qEfAUfEt',#5,'My building',$,$,#192,$,$,$,$,$,$);
#195=IFCBUILDINGSTOREY('0GelCcLR9Cf9zvW$jhWkTS',#5,'Ground floor',$,$,#194,$,$,$,$);

surveyor.ifc - used by surveying discipline to define GIS CRS, inherits building-structure.ifc

architectural.ifc - used by architectural discipline, inherits building-structure.ifc and inherits surveyor.ifc:
  1. Put owner history to good use and somehow use it to determine who is the most recent owner and have that be considered the master of truth.
  2. Create a mechanism where IFC files can actually reference each other, like #123=IFCREFERENCE('0ovDN8c9v9xABetj5G4Toz', 'relative/path/to/foo.ifc') rather than matching GlobalIds.

Ideas? How do you split and merge your IFC files?

I would like to bump this thread with the answer that STEP does indeed support referencing files, and they also support the bulk distribution of multiple IFC files in a zip with a root “entry” IFC file, although I have never seen a vendor support it.

See here for details:

1 Like

The anchor method in STEP has also another aspect: you can give entity ids a name. This is already possible in ifcXML (because id is a string) and is helfpfull for code-generated ifc-files or better ifc-based generated code.

Absolutely! It allows people to build little IFC files that using anchors provide a list of agreed upon names, much like an “interface class” in programming. This can allow for very smart building files.

Let’s implement it!