Exit door width checks: IfcOpenShell vs Solibri Model Checker — 32-inch pass or fail

How Each Tool Measures Door Width

IfcOpenShell measures door width at the geometry level because it is a Python library for IFC: a script can open the model, select IfcDoor or IfcDoorType entities through the Python API, and read the width from the model's actual representation, such as the OverallWidth attribute or the extruded profile. That value comes from the represented door geometry and attributes, not from a rules engine, so the same script run against the same file should produce the same measurement.

Solibri Model Checker approaches the same door through rule evaluation. It compares door parameters against thresholds in a loaded rule set, such as egress or IBC rule templates, and flags components whose parameters violate the configured limits. The resulting pass or fail verdict therefore depends on which rule set version is active and how that rule set interprets the door data.

IfcOpenShell also includes ifcopenshell.validate, which checks an IFC model against EXPRESS schema rules, including data types and WHERE rules. That is model-conformance validation, not a door-width measurement, so it complements rather than replaces the geometry-level width check.

The two mechanisms answer different questions: IfcOpenShell returns a measurement derived from the represented door, while Solibri returns a verdict derived from configured rules. How to sequence them for the 32-inch check is covered in the decision rules and checklist below.

When the two results disagree, inspect both the model representation and the active Solibri rule set before changing the design, because the discrepancy may come from geometry, attributes, or rule configuration rather than from the door itself.

The Evidence: What the Sources Show

The convergence of three independent sources establishes what IfcOpenShell can and cannot verify: DeepWiki’s testing and validation documentation, the DTU course 41934 materials, and the GitHub AI‑Assisted IFC Compliance Checker project each confirm distinct capabilities and limits of the library.

DeepWiki’s documentation (read May 2026) details the ifcopenshell.validate module, confirming it checks EXPRESS schema rules, data types, and WHERE rules. This low‑level validation provides the foundation for trusting attribute‑level width data, because it ensures the model conforms to the IFC specification before any geometric measurement is attempted.

The DTU course 41934 documentation (timmcginley.github.io) presents IfcOpenShell as a Python library for automated code compliance (ACC) workflows. By documenting scripted‑check patterns as an established teaching method, the course underscores that deterministic, repeatable measurements are a core competency of the tool, not an ad‑hoc addition.

The GitHub AI‑Assisted IFC Compliance Checker project combines IfcOpenShell with RAG‑based validation to automate rule checking against written building compliance rules. This open‑source effort demonstrates that IfcOpenShell’s geometry‑level access can be integrated into larger, AI‑driven compliance pipelines, reinforcing its role as a reliable data source for scripted checks.

Together, these sources create a sourced convergence: they independently verify that IfcOpenShell can enforce schema compliance, support scripted ACC workflows, and serve as the deterministic engine for downstream AI validation. This triad of evidence gives engineers confidence that measurements derived from IfcOpenShell are defensible, while also highlighting where rule‑based tools like Solibri can provide useful cross‑checks.

IfcOpenShell vs Solibri: Side by Side

For a 32-inch exit door, the decisive issue is which number you can defend, not which tool finishes first. The table compares five axes and names a winner for the check itself; it does not claim one tool is superior for every project or workflow.

IfcOpenShell wins on determinism and auditability because the measured value is a Python float you can print, log, and reproduce. Solibri wins on speed and out-of-box rule coverage, but its verdict is only as trustworthy as the rule mapping and model data behind it. The sequencing of measurement and cross-check is set out in the decision rules below.

On cost, IfcOpenShell is open source under the LGPL according to the SourceForge listing, while Solibri requires a commercial license. Do not assume a price; price it through Solibri's current quote page. The lower-cost path depends on the quote, scripting time, and review burden.

For batch work, the tradeoff is reproducible records versus speed. IfcOpenShell can produce deterministic, reviewable outputs across many doors, while Solibri can evaluate rule sets quickly. For a 32-inch check, speed does not replace a measurement you can defend.

Numbers That Decide the Check

For a 32-inch exit door, the number that decides the check is clear egress width, not the nominal leaf width. In US egress codes (IBC-style), 32 inches of clear width is a common minimum, but the exact governing value and whether the adopted code edition requires clear width (door opening minus stops and hardware projection) versus leaf width must be verified against your local amendments, not a generic source. Treat that 32-inch figure as the threshold to test for, but confirm it is binding for your jurisdiction before doing any subtraction.

That subtraction can be tight enough that small encroachments matter. For example, if the geometry shows a leaf that is wide enough in isolation, but the combined stop overlap and hardware projection remove more than the margin to 32 inches, the result falls below the confirmed minimum even if the leaf is marked above 32 inches nominally. Conversely, the margin is only what remains after subtracting both items. If the IFC representation does not include stops or the hardware geometry needed to quantify a projection, the 32-inch arithmetic cannot be completed by geometry alone, and that missing model content must be treated as a measurement gap rather than an automatic pass.

Keep the tolerance check explicit for each exit door: pull the leaf width from the swing geometry, quantify stop overlap for that frame, quantify any hardware projection into the path, subtract both, and compare to the confirmed governing 32-inch value. The decision is binary by that comparison, but its validity rests on using the actual swing geometry and on confirming the governing value for your local amendments. Without those two checks, the 32-inch threshold cannot be defended by measurement.

What This Comparison Cannot Prove

The only boundary this comparison cannot prove is the reach of the scripted check itself. To make that boundary explicit, use the limits table below as a go/no-go for any IfcOpenShell script before relying on it for a 32-inch exit door check:

Frequently Asked Questions

Which specific IFC attribute does IfcOpenShell read to determine door width from the model representation?

IfcOpenShell reads the OverallWidth attribute or the extruded profile from the model's actual representation to determine door width.

How does the active rule set version in Solibri Model Checker affect whether a 32-inch door passes or fails?

The pass or fail verdict in Solibri depends on which rule set version is active and how that rule set interprets the door data against configured thresholds.

What additional validation does IfcOpenShell provide beyond geometry measurement through its validate module?

IfcOpenShell includes ifcopenshell.validate, which checks an IFC model against EXPRESS schema rules.

Why would the same door file produce different pass/fail results in Solibri when using egress versus IBC rule templates?

Solibri flags components whose parameters violate the configured limits of the loaded rule set, so different templates like egress or IBC apply different thresholds.

What guarantees that an IfcOpenShell script returns identical width measurements when run repeatedly on the same IFC file?

The same script run against the same file should produce the same measurement because the value comes from the represented door geometry and attributes, not from a rules engine.

If a door's modeled geometry shows 32 inches but Solibri flags it as failing, what configuration difference explains the discrepancy?

The discrepancy arises because Solibri evaluates door parameters against thresholds in the loaded rule set, while IfcOpenShell measures the actual geometry representation directly.

Quick answers

Also worth reading: Solibri vs ACC: 38% Permit Review Cut Is Conditional: Solibri vs ACC: 38% Permit · High-rise exit width checks: Graph pathfinding vs manual review — 30% faster 2026 permits: High-rise exit width checks: Graph · Building Code Compliance: 2024 IBC Automated Check vs Manual Review: Building Code Compliance: 2024 IBC