If you already do this for a living: Tolerance and grouping. Most teams set a tolerance once and never look again, and then report clash counts instead of issues.
- Watch out
- What it costs
- Experienced readers
- Remember
- In BIMpedia
The first clash run on a project is often a shock: thousands of results, most of them meaningless. The fix is not a better software setting. It is a plan: a clash test matrix agreed with the team before you start.
The coordinator runs every model against every other with default settings and emails a 3,000-row report to all disciplines. Each team scrolls for a minute, finds nothing obviously theirs and closes it. Two months later a main duct and a transfer beam meet on site.
The team agreed six tests, with tolerances and owners, in the clash matrix. The run gives … clashes; grouped by location they are a handful of issues. Each issue has an owner and a date in the log. The duct and the beam are issue 3, solved in the model in a week.
Decide what to test
Not every pair of disciplines needs testing at every stage. Ask: where would a clash cost real money or time on site? Structure against services is almost always critical. Architecture against structure matters for openings and stairs. Electrical against plumbing matters for safety clearances.
Write the pairs down as a matrix: disciplines across the top and down the side. Each cell is a test (or deliberately empty). The diagonal holds self-clash tests, for example a mechanical model checked against itself.
Choose the test type
- Hard tests find elements that physically overlap.
- Clearance tests find elements that are closer than a required distance — for access, insulation or maintenance.
- Duplicate tests find the same element modelled twice, often after copying or linking.
Set a sensible tolerance
A tolerance tells the software to ignore overlaps smaller than a given distance. Without one, you will chase pipes that touch a wall by a millimetre. Too large, and you hide real problems. Typical starting points are around 10–25 mm for hard tests and the actual required distance for clearance tests. Write the values into the BEP so everyone uses the same ones.
Clashes that overlap by less than this are not reported.
Depths in the sample report range from … to … mm.
Reading the sample clash report…
Give every test an owner and a priority
A test without an owner produces a report that nobody reads. For each cell, name the discipline expected to resolve clashes. Often that is the more flexible system: ducts usually move before beams do. Add a priority so the meeting starts with what matters most.
Plan the tests, run them on shared models, group the results and track them as issues.
From clashes to issues
Before the coordination meeting, group raw clashes into issues: “Level 3, gridline C–D: main supply duct runs through the transfer beam” is one issue, even if it produces 40 clash points. Assign each issue an owner and a due date and record it in the issue log. People resolve issues, not clash counts.
These are your own example figures, at €75 an hour. Whatever numbers you use, the pattern holds: each issue that slips through to site costs about 12 times what it would in the model.
Key takeaways
- Decide in advance which discipline pairs are tested, with what type, tolerance and priority. Write it down as a clash matrix.
- Choose tolerances that ignore modelling noise but catch real problems.
- Every test needs an owner who is expected to resolve its clashes.
- Group raw clashes into issues before a meeting. People resolve issues, not clash counts.
Your notesSaved locally
Related tool
Define which disciplines are tested against each other, with tolerances, priorities and owners.
Open Clash Test Matrix →