6.4 Exporter Behavior Across Major Tools — Comparative, Evidence-Based

Introduction

Every file in this series conforms to the same IFC standard. Not every file was produced by the same tool. This lesson asks a narrower, more answerable question than "which exporter is better": given the same schema, do different export paths exhibit characteristic failure patterns, or does the same handful of failure types simply recur regardless of which tool produced the file? Seven files isn't enough data to rank software. It's enough to sort findings into three honest categories: failures that show up everywhere, meaning the cause probably isn't tool-specific at all; failures that recur under the same rule but look different each time, meaning the rule name hides more than one real problem; and failures that belong to one export path specifically, meaning they're worth checking for by name if you know which tool produced a file.

Dataset and Method

Seven files, four tool and schema-version combinations, checked through the same buildingSMART Validation Service, using the same three-stage method from 6.2 and 6.3.

Four families in total: Revit IFC4 (three files), Revit IFC2X3 (one file), ArchiCAD IFC4 (one file), Allplan IFC2X3 (one file, plus File 3's unidentified IFC2X3 export as a second data point for that schema version). Every comparison below states plainly how many files support it. A pattern appearing in three of three files within one family is a real signal. A pattern appearing in one file is a file-specific observation, not evidence about the tool that produced it, a distinction this lesson holds to deliberately.

A Failure That Crosses Every Family: IFC106

IFC106, orphaned resource entities unreferenced by anything in the file, geometry-support leftovers like stray IfcCartesianPoint or IfcAxis2Placement3D instances, appears in six of the seven files: ArchiCAD IFC4, all three Revit IFC4 files, Allplan IFC2X3, and Revit IFC2X3. The only file without it is File 3, whose own report came back with zero Industry Practice warnings entirely, the sole fully clean file in the dataset on that layer.

This is about as close to universal as seven files can demonstrate. It shows up regardless of tool, regardless of schema version, at a consistent occurrence count each time, roughly 9 to 10 entities per file. The likely explanation isn't a shared bug across four unrelated codebases, it's that leftover, unreferenced geometry-support data is simply a normal byproduct of how IFC export pipelines build and edit geometry, independent of vendor. Findings this widespread are the wrong place to look for exporter-specific insight. They're evidence about the general nature of IFC export, not about any one tool.

The Same Rule, Genuinely Different Failures: PSE001

PSE001 checks that a Property Set matches buildingSMART's own standard definitions, correct name, correct properties inside, attached to a permitted entity type. It appears in three files, spanning three separate tool and schema combinations, ArchiCAD IFC4, Revit IFC4, and Revit IFC2X3, and each occurrence is a meaningfully different kind of mistake.

In the ArchiCAD file, two distinct sub-patterns appear under this one rule: a Pset named Pset_FireRatingProperties, which isn't a real standard name at all, and separately, a correctly-named standard Pset carrying a non-standard property inside it, SpaceTemperatureSummer, not on the official list for that Pset. Fifteen occurrences total, a naming-level failure and a content-level failure bundled under one rule.

In the Revit IFC4 file, the failure is different in kind entirely: a real, correctly-named Pset, attached to the wrong level of the spatial hierarchy, expected on IfcBuildingStorey, found instead on IfcBuilding one level up. Three occurrences. Nothing wrong with the Pset's name or its contents, the problem is which entity it's hanging off of.

In the Revit IFC2X3 file, a fourth distinct shape: property sets attached to IfcGroup, a pure organizational container with no geometry of its own, instead of a real product entity. Ten occurrences, three of them specifically expecting IfcReinforcingBar.

Four distinct failure shapes, under one rule name, across three files that share nothing in common except the rule that caught them. That's the real finding here: a recurring rule name is not evidence of a recurring underlying mistake. Each occurrence needs reading on its own terms, exactly the discipline 6.3 already established for reading any single violation.

A Failure Characteristic of One Export Path: CorrectItemsForType

IfcShapeRepresentation.CorrectItemsForType checks that a representation's declared type matches what it actually contains, a representation labelled 'SweptSolid' should never contain a Boolean-result entity. This one shows the opposite pattern from PSE001: identical failure, three for three within a single family, zero anywhere else.

All three Revit IFC4 files hit it. File 2: nine occurrences, 'SweptSolid' labels wrapping IfcBooleanClippingResult entities. File 4: three occurrences, the more general IfcBooleanResult. File 5: fourteen occurrences, a mix of both subtypes. Same underlying story every time: a beam or column starts as a clean extruded solid, gets a piece clipped out of it later, a notch, an opening, a connection, and the export process updates the geometry Items to reflect the clip but never updates the RepresentationType label from 'SweptSolid' to 'Clipping'. Zero occurrences in the ArchiCAD file, zero in either Allplan file, zero in the Revit IFC2X3 file.

This is the cleanest exporter-characteristic finding in the dataset. It's not a schema-version story, since Revit IFC2X3 doesn't show it. It's specifically a Revit IFC4 export-path habit: a label that stops being updated once boolean clipping enters the geometry pipeline.

What the Dataset Cannot Prove

Three patterns look tool-characteristic on the surface but don't survive scrutiny, and belong here specifically so they don't get promoted into claims the evidence doesn't support.

IfcMaterialProfileSetUsage.AssociatedTo, a missing material relationship, appeared in all three Revit IFC4 files and nowhere else. But the rule only fires on elements with profiled steel members, and the dataset doesn't contain equivalent profiled-steel content across every exporter, File 7's Revit IFC2X3 file is a pure RC frame with nothing capable of triggering the check at all. Its absence there could mean the exporter handles it correctly, or could simply mean nothing in that file could have failed it either way. The observation cannot cleanly separate exporter behavior from model-content differences.

OJT001, redundant PredefinedType values, appeared across every IFC4 file and zero IFC2X3 files, which looks like a schema-version story. It isn't one, at least not demonstrably: a real buildingSMART changelog entry confirms the rule was updated to "exclude checks for IFC2X3 models." Its absence from both IFC2X3 files in this dataset may simply mean the rule never ran on them, not that IFC2X3 exporters behave better. GRF003, missing coordinate reference systems, shows the identical pattern, present in every IFC4 file, absent from both IFC2X3 files, but no equivalent confirmation of a scope exclusion was found for this rule specifically. That doesn't mean GRF003 is a genuine IFC2X3 characteristic either, it means the question is genuinely open and unconfirmed rather than settled in either direction, and it's presented that way here rather than assumed.

GEM001 and GEM111, real geometric defects, closed-shell edge errors and polyline closure failures, appeared in scattered, inconsistent combinations: two tools, two schema versions, no file-count pattern clean enough to generalize from. These are exactly what file-specific findings should look like: real, worth reporting to the specific modeler who produced that specific file, and not evidence about the exporter as a category.

Rule applicability itself is a confounding variable a comparison like this has to account for. A rule appearing only in IFC4 files is not automatically an IFC4 exporter characteristic, it might be a rule that was never designed to run on IFC2X3 files at all.

Practical Implications

Three tiers, three different responses. A universal finding like IFC106 is worth a standard check on every file regardless of source, since it isn't telling you anything about which tool produced the file. A rule like PSE001 that recurs but changes shape needs its specific occurrence read fresh each time, never assumed from a prior file that hit the same rule name. And a genuinely exporter-characteristic finding like CorrectItemsForType is worth checking for specifically the moment a file is known to come from Revit IFC4, since three for three within one family, zero everywhere else, is a real enough signal to build a habit around, checking whether any element in the file underwent a late-stage boolean clip, before assuming its RepresentationType labels can be trusted.