Clash detection is the process of checking a BIM model — or multiple federated models from different disciplines — for conflicts before construction begins. A clash is anywhere two building elements occupy the same space, or where clearance requirements are violated. Finding clashes in the model costs a few hours; finding them on site costs days, money, and often structural damage.
Types of Clashes
Hard clashes are literal geometric intersections — a duct running through a structural beam, a pipe penetrating a wall in the wrong location. These are unambiguous and always need resolution.
Soft clashes (also called clearance clashes) occur when elements are too close together, even if they don’t physically intersect. Typical examples: insufficient maintenance access around plant, inadequate clearance between a sprinkler head and the underside of a beam, or MEP services running too close to structural members for fire-rated wrapping to fit.
Workflow clashes (sometimes called 4D clashes) are scheduling conflicts — two trades needing to occupy the same area at the same time. These require a 4D model linked to the programme to detect.
The Federated Model
Clash detection requires a federated model — a combined model that overlays individual discipline models (architecture, structure, MEP) in a single environment. Each discipline keeps its own model and retains authorship; the federated model is for coordination only. Navisworks, Solibri, and BIMcollab are the most common clash detection environments. They import models from Revit, ArchiCAD, and other authoring tools and allow rules-based clash tests to be run across all disciplines simultaneously.
A Practical Clash Detection Workflow
The workflow runs in five steps. First, all discipline teams export their models to a neutral format (NWC for Navisworks, IFC for platform-agnostic workflows) at an agreed milestone. Second, the BIM coordinator federates the models and runs clash tests — typically structure vs MEP first, then architecture vs structure, then MEP vs MEP. Third, clashes are exported to a clash report and distributed to the relevant discipline leads. Fourth, each clash is assigned to an owner, discussed in a coordination meeting, and resolved in the authoring model. Fifth, updated models are re-exported and the process repeats until the clash count reaches zero or all remaining clashes are accepted as non-issues.
Writing Useful Clash Rules
The default “everything vs everything” clash test produces thousands of results, most of them irrelevant (insulation touching a wall face, bolts overlapping anchor plates). Effective clash detection means writing targeted rules: structural elements vs MEP systems, with a 50mm clearance tolerance, excluding elements below a certain size. The time spent tuning rules saves hours of sorting through false positives in the report.
Clash Reports and Tracking
Every clash needs a unique ID, a status (new, active, resolved, approved), an owner, and a target resolution date. Platforms like BIMcollab and Autodesk Construction Cloud manage this natively. In Navisworks, clashes can be exported to BCF (BIM Collaboration Format) — an open standard that lets clash markers travel between different software platforms with the model coordinates intact.
Conclusion
Clash detection is one of the most concrete, measurable returns on BIM investment. A structured coordination workflow — federated models, targeted clash rules, BCF-tracked issues, and regular coordination meetings — routinely eliminates the majority of site conflicts before a foundation is poured. The process is straightforward once the discipline is established; the hard part is getting all parties to export on time.