Clash detection is the automated search for conflicts between elements in a federated model. Coordination software compares two sets of elements (for example ductwork against structure) and reports every place where they conflict according to a rule. The rule is the clash type, and almost every tool offers the same three.
At a glance
| Type | Finds | Typical use |
|---|---|---|
| Hard | Elements that physically overlap | Services through beams, pipes through walls |
| Clearance (soft) | Elements closer than a set distance | Access zones, insulation, maintenance space, fire separation |
| Duplicate | Identical or near-identical elements in the same place | Copied elements, linked models loaded twice |
Hard clashes
Two solids intersect. A tolerance is usually set so that tiny overlaps (a few millimetres, caused by modelling precision or by elements meant to touch) are ignored. Some tools distinguish conservative hard tests, which also report elements that only touch, from normal hard tests.
Clearance clashes
An element comes within a set distance of another without touching it. The distance represents something the model does not show: insulation thickness, a maintenance zone in front of a panel, the swing of a door, the space needed to install a pipe. Clearance tests produce more results than hard tests and need careful settings.
Duplicate clashes
Elements of the same kind occupy the same space. They usually signal a modelling error: an element copied twice, a link loaded in two models, or the same discipline modelled by two teams. They inflate quantities and confuse coordination.
How tests are organised
Projects write a clash test matrix: which discipline pairs are tested, with which type, tolerance and priority, and who resolves each kind of result. Typical priorities:
- Structure against architecture and against major services.
- Major services (ducts, cable trays, drainage) against each other.
- Smaller services and clearance zones.
Plan the tests, run them on shared models, group the results and track them as issues.
Results are not issues
A single duct run crossing five beams produces five clashes but one design problem. Coordinators group raw results by location, system or cause, then raise one issue for each group, usually as a BCF topic with an owner and a due date. Counts of raw clashes are a poor measure of progress; counts of open issues are better.
Common misunderstandings
- Raising the tolerance to reduce the numbers hides real problems.
- Testing work in progress wastes effort: test shared models at an agreed cycle.
- Treating every clash as an error. Some are intended (a pipe through a sleeve, a beam seated on a wall) and are approved, not fixed.
- Clash-free is not buildable. Tests only find what the model contains; missing elements, wrong levels of detail and installation space need other checks.
Where to read more
The coordination section of the project's BIM execution plan sets the tests actually run. Software documentation (for example Navisworks or Solibri) explains each tool's settings; the concepts are the same across tools.