Clash detection
An automated geometric test that compares discipline models and flags every overlap or clearance violation before construction, distinct from a human design coordination meeting.
What is clash detection?
Clash detection is an automated geometric test that compares two or more discipline models and reports every place where elements physically overlap or violate a required clearance. It is one of the checks that makes coordinated BIM work at the scale of a real project: software running a rule set against a federated model, not a person looking at drawings, producing a list of named clashes tied to the two objects involved and their exact location, ready to be assigned and resolved.
The test needs a federated model to run against: separate discipline models, brought together through IFC model exchange, aligned to the same origin and units. Run it too early, before the disciplines have modelled to a usable level of detail, and it reports mostly noise; run it on schedule against a current model, and it becomes the fastest way to find a real problem before it is built.
What is the difference between a hard clash and a soft clash?
A hard clash is two solid objects occupying the same space: a duct through a structural beam, a drainage pipe inside a wall with no chase for it. Either the geometries overlap or they do not.
A soft clash, or clearance clash, is different: the objects do not overlap, but one sits closer to another than its function allows. A boiler with no service space in front of it, a duct routed hard against an element that needs an insulation zone around it, a manifold cabinet with no room for its access door: none are geometric overlaps, but all are unbuildable or unmaintainable as drawn. Clash-detection software tests for soft clashes by defining a clearance zone around an object and checking whether anything else has entered it.
| Clash type | What the software tests | Residential example |
|---|---|---|
| Hard clash | Direct geometric overlap between two solids | Waste stack routed straight through a structural beam |
| Soft clash | Violation of a required clearance or maintenance zone around an object | Underfloor-heating manifold cabinet with no space left for its access door |
| Workflow (4D) clash | Conflict in the construction sequence rather than in the finished geometry | Ceiling closed off before the electrician's recessed-lighting rough-in is signed off |
Are there other kinds of clashes besides hard and soft?
Yes: a workflow clash, or 4D clash, is a conflict in time rather than space. Two trades scheduled to occupy the same zone in the same week, or a finish scheduled before the rough-in behind it is inspected, are workflow clashes: nothing overlaps in the model, but the sequence as planned cannot happen on site. Detecting these requires linking the model to a schedule, so residential projects, which rarely build a full 4D schedule, mostly rely on hard and soft clash tests and manage sequencing through ordinary site coordination instead.
What are the clashes that keep showing up in residential passive-house design?
A handful of conflicts recur so often in tight, well-insulated residential builds that a clash-detection rule set is normally written specifically to catch them:
- A waste stack routed through a load-bearing beam or ring beam, because the plumbing layout was fixed before the structural grid was finalised.
- An MVHR (mechanical ventilation with heat recovery) duct crossing a reinforced ring beam at a point with no sleeve or opening allowed for it.
- An underfloor-heating manifold positioned against a load-bearing wall with no room left for its connections or its access panel.
- Recessed ceiling lighting fixtures sitting inside a joist zone that has no depth to spare once insulation and a service void are accounted for.
Every one of these is buildable in the model right up until someone tries to install it, at which point it becomes a site improvisation: a beam notched where it should not be, a duct rerouted through the insulation layer, a manifold fitted proud of the wall. In an airtight envelope, that improvisation is exactly what breaks the air barrier or creates an unplanned thermal bridge.
How is clash detection different from a design coordination meeting?
Coordination of professions is the human process: the architect convenes the structural engineer, the MEP specialist and the contractor to compare drawings, negotiate trade-offs, and agree who moves what. Clash detection is the machine step that feeds that meeting, producing the list of specific, located conflicts the meeting then has to resolve instead of finding them by eye on overlaid drawings.
| Clash-detection run | Coordination meeting | |
|---|---|---|
| What it produces | An exhaustive list of geometric and clearance conflicts | An agreed resolution for each conflict raised |
| Who is involved | Software, run by whoever manages the model | Architect, structural engineer, MEP specialist, contractor |
| When it runs | At every model issue | At key coordination stages, informed by the latest run |
Neither replaces the other: the software finds conflicts quickly and exhaustively, and the meeting decides which fix is actually right, since not every clash has one obvious resolution.
Where does clash detection sit in the project sequence?
It belongs after the disciplines have modelled to a usable Level of Development, not before: running it against a still-schematic architectural model and a barely-started MEP model produces a flood of meaningless clashes and trains the team to ignore the report. It belongs before the coordinated construction documentation is issued for tender, so whatever the contractor prices and builds from has already had its major conflicts resolved. And it is not a one-time gate: a disciplined project reruns the test at every model issue, since a fix in one discipline routinely creates a new clash somewhere else.
How does a clash-detection run actually work, rule sets and tolerances?
A run compares selected sets of objects, structure against MEP, MEP against architecture, rather than testing everything against everything, because an unfiltered test buries genuine conflicts under trivial ones. The rule set defines which categories are tested against which, and a tolerance setting decides how close is too close: near zero for a true overlap test, wider for a clearance test where the required gap is the point of the check.
Getting the tolerance wrong defeats the exercise either way: too tight, and modelling imprecision generates thousands of false clashes; too loose, and a real conflict slips through. Tuning the rule set for the project, rather than accepting the software's defaults, separates a useful report from a wall of noise.
What happens to a clash once it is found, and how are false positives triaged?
Each reported clash is assigned to whichever discipline is responsible for resolving it, given a status such as open, in review, resolved, or approved as-is, and tracked until closed, ideally inside the same Common Data Environment the models live in, so the resolution is recorded against the model revision that produced it.
Not every reported clash needs fixing. A duct grazing a beam's edge inside the tolerance band, or two objects overlapping only because one is drawn slightly oversized, are false positives: real in the geometry, irrelevant on site. Triage is the step where someone experienced reviews the raw list and separates clashes needing a redesign from ones that can be closed. Skipping it one way wastes time on non-issues; skipping it the other way is how a real conflict survives into the tender documents.
Frequently asked questions
- Does clash detection replace the need for a site supervisor?
- No. It resolves conflicts inside the model before construction starts, but questions that only arise once work is under way, such as a substituted product or a change the contractor proposes on site, still need ordinary site oversight and sign-off.
- How many clashes is normal to find on a residential project?
- There is no fixed number, and a first run on a project that has never been checked before typically returns far more than a run against a model that has already been through one or two coordination cycles. What matters is that the count drops toward zero as issues are resolved and rechecked, not the raw figure at any single point.
- Who is responsible for fixing a clash once it is reported?
- Whichever discipline's element can be moved without breaking its own requirements, decided in the coordination meeting the clash report feeds into. A duct usually moves before a structural beam does, but not always, since some clashes only have one workable resolution.
- Can clash detection be run on a single-family house, or is it only for larger buildings?
- It can be run on any project that has separate discipline models to compare. The value is smaller on a simple single-storey layout with little building services, and larger once ventilation, underfloor heating and a tight structural grid are all competing for the same wall and ceiling zones, which is the normal case for a passive house.
- What happens if a clash is only found after the walls are already built?
- It gets resolved on site, usually by whichever improvisation is fastest rather than whichever is correct, and in an airtight envelope that improvisation is the most common cause of a broken air barrier or an unplanned thermal bridge that no one accounted for in the energy model.
- Does every design tool run clash detection the same way?
- No. Some authoring tools include a basic clash check, while dedicated coordination software runs more configurable rule sets and tolerances across models from several different authoring tools at once. Which is appropriate depends on how many disciplines and how many separate software packages the project actually involves.