BIM Clash Detection: How to Find and Resolve Coordination Problems Before Construction
Clash detection finds hard, soft and workflow conflicts in BIM models before they become site delays. Learn how Navisworks and IFC-based reviews work, how to set tolerances, and how to turn clash reports into resolved, coordinated models.
BIM clash detection is the systematic search for conflicts in federated models before those conflicts become site instructions, delays, or silent field compromises. A clash is not only two solids overlapping. It can be a duct that leaves no access to a valve, a switchboard that opens into a stair, or a sequence that asks electricians to install trays after a drywall ceiling is closed. Finding clashes is a software operation. Resolving them is a project operation. This guide keeps those two acts separate.
A hard clash is geometry occupying the same space: a steel beam and a chilled-water pipe, a concrete wall and a cable tray, a duct and a downstand. Software can find these if the geometry is real. Generic placeholders, 2D symbols dropped into 3D, and missing insulation will hide or invent hard clashes.
A soft clash is a clearance or access rule: code working space, filter withdrawal, hanger zone, insulation envelope, a maintenance aisle. Software can find these only if you model the clearance as an object or a defined distance. If you do not, you are not “missing a software feature”; you skipped a modelling rule.
A workflow or 4D clash is a time problem: two trades in one space, or a permanent element installed before a temporary access route is needed. That requires a programme linked to elements. Without a programme, 4D clash is a video. See 4D and 5D BIM.
People also talk about “duplicate clashes” (the same hit reported every week) and “tolerance clashes” (grazing contacts from modelling precision). Both need rules, not indignation.
What clash detection needs before the first test
You need a federated set with a proven origin. If architecture and structure miss by 250 mm, every wall-to-frame test is junk. You need a clash matrix: which categories against which, at what stage. You need tolerances. You need a zone (a floor, a plant room, a grid band). You need owners for issues. You need a tool that can save viewpoints: Navisworks is common; Solibri and IFC-based checkers are used where openBIM is the review language.
You also need authoring quality. Ducts should be ducts. Pipes should be pipes. Beams should be beams. Clash detection on generic models painted to look like services will report pretty nonsense. Reject the drop; do not “run it anyway” to show activity.
Level of Development bounds what a clash means. Two LOD 200 placeholders overlapping is a scheme issue. Two LOD 350 ducts overlapping with hangers is an installation issue. Do not treat them as the same KPI. The LOD guide is the vocabulary.
Building a clash matrix that people will use
A matrix is a table. Rows and columns are disciplines or systems. Cells say “test / no test / later.” Example order for a building:
Structure versus architecture (slabs, cores, stairs)
Large mechanical air versus structure
Gravity drainage versus structure
Electrical busducts and large trays versus mechanical air
Hydronic mains versus structure and air
Small pipes and conduits versus the rest
Equipment clearances versus occupancy paths
“Everything versus everything” is how you get 80,000 results and a PDF that is never opened. Suppress tests that cannot yet be meaningful: sprinkler heads versus lighting if neither is coordinated; furniture versus ducts if furniture is schematic.
Tolerances should be written next to the cell. A 0 mm hard clash on steel versus concrete might be right. A 0 mm clash on insulation versus a tray might be noisy if insulation is a coarse envelope. A 25 mm tolerance can be honest for certain masonry joints and dishonest for a fire damper that must fit a rated wall. Record the reason in one sentence.
Selection sets in Navisworks (or equivalent search sets) should match Revit worksets or parameter filters. If the mechanical modeller dumps all air into one workset called MEP, you cannot test supply versus return against each other when they share a riser. Authoring structure and clash structure are the same problem.
Running tests in Navisworks and IFC checkers
In Navisworks, clash detective tests are saved with the federated model. Good practice: one file per publish date, tests copied forward, results grouped, viewpoints named with issue IDs. Batching by floor reduces RAM drama on large jobs and matches meeting zones. Do not append duplicate models; replace versions with a naming rule from the BIM Execution Plan.
IFC-based checking matters when native files cannot be shared, or when a regulatory path uses IFC. Geometry that looked fine in Revit can vanish or thicken after export. Run a sample export clash early. For Singapore, BIM submissions through CORENET X use openBIM IFC with local additions where BIM submission applies; that is a mapping and validation problem as well as a clash problem. See BIM in Singapore and official sources, and do not invent extra tests as if they were law.
Rules-based checkers (clearance to stairs, door swings, required headroom) are not the same as clash detective. They can be more valuable and more arguable. If you buy a “model check,” say whether you mean geometric clash, information completeness, or a code-like rule set. Mixing them in one PDF confuses owners.
From raw hits to resolved issues
Raw hits are not issues. Group them. A pipe sleeved through a wall twenty times is one issue if it is one rule (“sleeves not modelled”). A single duct hitting five beams along a run may still be one routing issue. Assign an owner who can actually change something. Due dates should match the next publish, not a fantasy.
Resolution options are limited and should be named in the log:
Move the service (reroute, drop, split)
Change the structure (opening, haunch, member size — engineer’s act)
Change the architecture (ceiling, riser, door)
Change the equipment (selection — engineer’s act)
Accept residual with a site method
Hold until a freeze date
A freelancer must not pick a structural opening as if it were a modelling preference. They can propose it. The engineer of record decides. Write that in the brief when you hire.
Retest is the only closure. Status “closed” means the next run is clean for that group, or the residual is accepted. Status “will fix” is still open.
Tolerances, false positives and false negatives
False positives come from overlapping insulation envelopes, from CAD underlays left in the model, from duplicate linked files, from doors swinging through furniture that is not in scope, and from coordination models that still contain demolished phasing displayed incorrectly. Clean the inputs.
False negatives come from missing geometry (unmodelled hangers, unmodelled insulation, 2D-only fire dampers), from tests that forgot a category, from IFC exports that dropped small pipes, and from “approved” groups that were hidden rather than resolved. A residual list that is empty because tests were narrowed after the meeting is a governance failure.
Clash detection will not find specification clashes: the wrong fire rating, the wrong acoustic treatment, a duct material that cannot be installed in that space. Those need people. AI tools in 2026 may group hits or suggest clusters; they do not own the specification.
Practical examples by discipline pair
Architecture versus structure: a stair that cuts a beam, a facade bracket that misses a slab edge, a lift pit that disagrees with foundation thickness. These are often early clashes and should not wait for MEP.
Mechanical versus structure: primary ducts versus transfer beams, plant bases versus slab set-downs, chimney or generator flues versus steel. Openings need a reserved-void object.
Electrical versus mechanical: busduct versus main supply duct in a corridor, tray crossing a fire damper actuator, switch room heat rejection versus a ceiling void that was given to air.
Plumbing versus everyone: stacks in a corner that architecture used for a cupboard, buried drainage versus raft thickening, roof outlets versus steel purlins.
None of these examples are statistics. They are the ordinary geometry of buildings. Your log will be a local version of the same list.
Commercial scope: what to buy as a clash package
A marketplace clash package should state: software, incoming file types, matrix, zone, number of cycles, meeting attendance yes/no, and residual list format. Cycle count matters more than a promise of “zero clashes.” Design will move. Buy cycles.
Do not buy clash detection on PDFs. Do not buy it on a single uncoordinated architectural model with MEP sketched in overlay CAD. The specialist should be allowed to reject inputs. That rejection is a deliverable.
Price factors follow BIM service cost: number of models, density of services, how often architecture publishes, and whether grouping is included (it must be). A cheap raw export of 10,000 clashes is not a saving.
Site: when clash detection is too late — and when it still helps
If construction has started, clash detection still helps for remaining floors, for prefabrication, and for change impact. It will not undo installed work. Scan to BIM of the installed condition can feed a new federation; see Scan to BIM. Do not pretend a design model is as-built.
Shop drawings should be issued from a coordinated state. If shop drawings and the clash log disagree, the drawing is the thing the site will trust unless you stop it. Align them; see shop drawings.
Quality checklist
Origin validated on a known grid intersection
Tests saved; matrix matches tests
Tolerances recorded
Results grouped; IDs stable
Viewpoints locatable (level, grid)
Owners and due dates
Retest before closure
Residual list with acceptance
Incoming model versions listed
No duplicate file appends
Clash detection in plant rooms versus typical floors
Plant rooms fail by equipment envelopes and access. Typical floors fail by ceiling sandwiches. Do not use the same test list for both. In a plant room, clash against housekeeping pads, door swings, coil pull spaces, and the structural frame that carries the plant. In a typical floor, clash against beams, downstands, ceiling bulkheads, and the lighting layout if it is real. A test that only runs “duct versus beam” will miss a chiller that cannot be maintained and will still produce a green report.
Basements add another pattern: drainage inverts versus raft thickenings, car-park headroom versus duct crossings, and exhaust plenums versus structure. Headroom is a soft clash against a datum, not against another solid, unless you model a headroom box. If the brief cares about a 2.1 m parking clearance, model the box. If you do not, Navisworks cannot invent the local parking standard for you.
Facades and plant screens generate clashes that look like architecture versus MEP but are often a louvre free-area problem. A generator intake that clashes with a decorative screen is not solved by moving a duct 50 mm. The coordinator should label that issue as a performance issue, not only a solid overlap.
Clash reports that executives can read without lying
Executives ask for a percentage. Percentages of raw clash counts are easy to game: hide a test, increase a tolerance, or model less geometry. A better one-page report is: number of open grouped issues by severity, number of residuals accepted, number of tests skipped and why, date of last origin check, and which models were in the federation. That page can be ugly and still honest.
Severity needs a definition before the first run. Critical might mean a hard clash on a primary system that blocks a freeze. Medium might mean a typical-floor repeat that can be solved once and copied. Low might mean grazing insulation. If severity is assigned in a panic the night before a client meeting, it will reflect politics, not geometry.
Screenshots should be repeatable. A specialist who cannot return to the same viewpoint next week is not coordinating; they are decorating a PDF. Save viewpoints with issue IDs. If the buyer’s leadership wants a slide deck, generate it from the same IDs, not from a parallel set of crops.
Prefabrication, hangers and the contractor clash set
When Mechanical, Electrical and Plumbing contractors prefabricate, clash detection must include hanger zones, seismic braces where the project requires them, and spool connections. Design-stage tests that ignored hangers are not wrong for design; they are incomplete for installation. Say which set you are running.
Multi-trade racks are a special case. The issue is often not a single clash but a packing problem: the rack is 50 mm deeper than the void. Group that as one rack issue with a section, not as forty pipe-to-tray hits. The resolution may be a wider corridor, a dropped ceiling, or a smaller duct with higher velocity — all of which are design or contractor choices, not modeller preferences.
Clash detection as a weekly habit, not a pre-tender event
The first useful test is early and small: one plant room, one typical bay, origin proven. The last useful test is after submittals and before spool freeze. Between them, tests follow the publish calendar. A single heroic clash run at the end of design is a documentary of missed months. When you hire, buy cycles. When you schedule, put the cycle on the same day every week so authors can plan.
Suppress tests that the LOD table says are meaningless. Activate tests when a system matures. The matrix is allowed to change if you version it. Silent matrix changes to make a dashboard green are not allowed.
Viewpoints, BCF and the meeting pack
A meeting pack of ten grouped issues, each with a viewpoint, a proposed option, and an owner, will close more work than a 200-page appendix. BCF is useful when Revit, Navisworks, and a web tracker must see the same issue. Excel is useful when that is what leads will open. Pick one primary. Duplicate IDs across two tools without a master is how issues fork.
Photograph the decision in the minutes: “beam opening 400x400 at grid C/4, structural engineer to confirm reinforcement, mechanical to hold duct.” Then the next clash run either closes it or it stays open. No new ID.
Trade psychology without turning the coordinator into a referee of egos
Mechanical will often be asked to move first because ducts are large. That is a habit, not a law. Sometimes the cheapest fix is a beam opening, a ceiling drop, or a switchboard relocation. The coordinator’s notes should present options with who pays as a commercial question for the project manager, not as a hidden choice inside a “MEP to resolve” dump. Freelancers should propose options; they should not allocate cost unless appointed to.
Electrical working space and plumbing gravity are constraints that look like stubbornness. They are physics and code. A clash log that treats them as optional will be ignored by those trades, correctly.
When to stop testing a zone
Stop when residuals are accepted and the freeze date has passed, or when the zone is issued to site with a residual list attached to the shop drawings. Do not stop because someone is tired of meetings. Do not continue forever because someone enjoys Navisworks. The residual list is the adult stop condition.
Is a clash-free model a requirement? A model with an accepted residual list is a requirement. Zero raw hits can be a sign of missing tests.
Navisworks or Solibri? Use what the team can open and what the BEP names. Method first, logo second.
How often should we run tests? On the publish cycle, at least. Extra runs after a major plant change. Not every hour.
Who attends the clash meeting? People who can decide. A modeller without a lead is a scribe.
Can we clash 2D DWGs? You can overlay them. You cannot call that BIM clash detection of systems.
Do hangers have to be in the test? At contractor LOD, yes if they are modelled. At design LOD, often no — and that exclusion must be written.
What about AI auto-resolving clashes? Auto-rerouting without an engineer is a risk. Use AI to cluster, not to sign.
Sources and reference notes
Autodesk Navisworks documentation describes clash detective, grouping and viewpoints. buildingSMART BCF describes issue exchange. BIMForum LOD Specification discusses how much geometry can be relied on. ISO 19650 covers information management, not clash algorithms. Singapore CORENET X validation is a regulatory model-check path distinct from project clash detection; read BCA/URA material at https://info.corenet.gov.sg and https://www.ura.gov.sg. No clash “industry average reduction percentage” is cited here because such figures are not a universal measurement.
Image brief
One Navisworks-style clash viewpoint: duct versus beam, with a red clash highlight and a grid bubble. A second graphic: a simple clash matrix table (not a fake dashboard). No invented “clashes resolved this week” counters.