Clash detection

Two weeks after the team models were federated, the coordination tool reports 1,342 clashes between the architectural, structural and mechanical models of the mixed-use building. Ingrid, who is the team's coordinator, looks at the number in horror. Professor Ferreira is unimpressed. 'Most of those are not problems,' she says. 'They are the same problem counted many times, or things that touch by design, or settings that were never thought about. Clash detection is not about the number. It is about finding the twenty real conflicts that would cost money on site, and getting the right person to fix each one.' By the end of the afternoon the team has reduced the list to thirty-one groups, of which eighteen need design changes.

What clash detection is

Clash detection is the automated search for conflicts between elements in a federated model. It is one of the most widely used and most valuable BIM uses, because conflicts found on site are expensive: a duct that cannot pass a beam may mean a lowered ceiling, a redesigned duct run, a hole cut in a beam with an engineer's approval, or days of delay. Contractors and coordinators commonly report that coordinating models before construction prevents a large share of the conflicts and changes that would otherwise arise on site. The software finds geometry that overlaps or comes too close; people decide what it means and what to do.

Kinds of clash

Clashes are usually grouped into three kinds. Hard clashes occur when two elements occupy the same space, such as a duct through a beam, a pipe through a column or a door swinging into a wall. Clearance clashes, often called soft clashes, occur when an element comes within a required distance of another without touching it: insulation space around a pipe, access space in front of an electrical panel, working room for maintenance of mechanical equipment, or headroom under a stair. Workflow or time-based clashes occur when the construction sequence conflicts, such as a delivery scheduled before the structure that supports it is in place, or two crews scheduled in the same space at once; these require a model linked to the schedule, sometimes called 4D.

The tolerance and clearance settings decide what counts. A hard clash test with zero tolerance reports every element that touches another, which includes thousands of intended contacts, such as walls sitting on slabs. A small tolerance, such as ½ in, ignores touching and minor overlaps. Clearance tests need values from codes and manufacturers, for example the working space in front of electrical equipment required by the National Electrical Code, or the access space a manufacturer specifies around a boiler.

A clash test in miniature

Coordination tools test the actual geometry of elements, but they usually begin with a fast check of bounding boxes, the smallest boxes aligned to the axes that contain each element, and test exact geometry only for pairs whose boxes overlap. The script below performs the bounding-box step for a few elements above a corridor ceiling in the mixed-use building. It ignores pairs in the same discipline, reports a hard clash when boxes overlap by more than the tolerance, and reports a clearance clash when they come within the clearance distance.

# Clash detection between axis-aligned bounding boxes, with a tolerance for hard clashes
# and a clearance for soft clashes (ft).
elems = {"beam B3": ("structure", (0.0, 13.0, 9.35), (20.0, 14.0, 10.8)), "supply duct": ("mechanical", (6.5, 12.0, 9.7), (8.5, 20.0, 10.65)), "sprinkler main": ("fire", (0.0, 15.0, 10.0), (20.0, 15.33, 10.33)), "ceiling": ("architecture", (0.0, 10.0, 8.85), (20.0, 23.0, 8.92)), "light fitting": ("electrical", (3.3, 16.5, 8.92), (5.3, 18.5, 9.3)), "column C2": ("structure", (19.33, 19.33, 0.0), (20.67, 20.67, 10.8)), "drain pipe": ("plumbing", (13.0, 20.75, 9.5), (21.0, 21.08, 9.85))}   # name: (discipline, (xmin, ymin, zmin), (xmax, ymax, zmax))
tol, clear = 0.04, 0.17
def gap(a, b):
    # largest separation along any axis (negative means the boxes overlap on every axis)
    return max(max(a[1][i] - b[2][i], b[1][i] - a[2][i]) for i in range(3))
def overlap(a, b):
    return min(min(a[2][i], b[2][i]) - max(a[1][i], b[1][i]) for i in range(3))
names = list(elems)
for i in range(len(names)):
    for j in range(i + 1, len(names)):
        a, b = elems[names[i]], elems[names[j]]
        if a[0] == b[0]:
            continue                                   # same discipline: not in this test
        g = gap(a, b)
        if g < 0 and overlap(a, b) > tol:
            print(f"HARD  {names[i]:14s} x {names[j]:14s} overlap {overlap(a, b):.3f}")
        elif tol < g < clear:                          # touching within tolerance is intended
            print(f"SOFT  {names[i]:14s} x {names[j]:14s} gap {max(g, 0):.3f} < clearance {clear}")

HARD  beam B3        x supply duct    overlap 0.950
HARD  supply duct    x sprinkler main overlap 0.330
HARD  ceiling        x column C2      overlap 0.070
SOFT  column C2      x drain pipe     gap 0.080 < clearance 0.17

Four results appear. The duct passes through the beam and also through the sprinkler main, two hard clashes that need design decisions. The ceiling is reported against the column because it was modeled as one board across the corridor and never cut around the column, a modeling error rather than a design problem; fixing the ceiling clears it. The drain pipe runs within the clearance distance of the column, which may leave no room for insulation or pipe supports. The light fitting sitting on the ceiling is not reported at all, because touching within the tolerance is treated as intended contact.

The clash matrix

Not every pair of disciplines needs to be tested against every other, and some pairs need different settings. A clash matrix sets out which tests run, with what tolerance or clearance, and who is responsible for resolving each kind of clash. Structure is usually tested against everything, because structure is hardest to move. Mechanical ducts, the largest services, are tested against structure and the architecture first; smaller services such as plumbing, sprinklers and electrical conduits are then tested against ducts and each other. A priority order, sometimes summarized as gravity first, then large before small, then flexible last, guides who moves: drainage pipes that must slope come before pressurized pipes, which can bend, and cable trays and conduits, which are most flexible, usually move for everything else.

From thousands of clashes to a few decisions

Raw clash reports are long because one real problem produces many clashes: a duct crossing ten joists produces ten clashes, and a pipe running along a beam produces one clash for every segment. The first step in reviewing results is grouping, by element, by level, by zone or by system, so that each group represents one design issue. The second is filtering out false positives: intended contacts, elements that will be field-routed, temporary objects and elements modeled at too low a level of development to be checked. The third is assigning each real issue to the person who must resolve it, using the priority order and the responsibility matrix from lesson 10, with a due date, usually as a BCF issue with a viewpoint.

Clash detection is a cycle. Teams run tests on the latest shared models, review and group the results, assign issues, revise their models, share again and rerun. Issues that are fixed close automatically when the clash no longer appears. The trend matters more than any single count: a steady fall in real issues from one cycle to the next shows that coordination is working.

Tools and rule-based checking

Navisworks, with its clash detective tool, has long been the most common coordination tool in North America; Solibri, the coordination modules of cloud platforms such as Autodesk Construction Cloud and Trimble Connect, and tools such as Revizto offer similar functions, increasingly running clash tests automatically every time a model is shared. Many BIM authoring programs also run basic interference checks within one model or with linked models.

Geometry is only one thing to check. Rule-based model checking tests the model against rules: every door has a fire rating where the wall requires one, every room has a name and number, corridors are at least the required width, every space is enclosed, every element has the required properties for handover. Solibri is built around rule sets of this kind. buildingSMART's Information Delivery Specification, IDS, approved as a standard in 2024, lets a client write its information requirements in a computer-readable form so that a model can be checked against them automatically. Automated code checking, testing a model directly against building code requirements, is an active area of research and early practice, and some authorities have begun to accept models for parts of permit review.

Coordination in construction

After design, coordination continues. Trade contractors produce fabrication models of ductwork, sprinkler piping and steel connections at a higher level of development than the design models, and these are coordinated again, often in weekly meetings run by the general contractor's virtual design and construction team. Prefabricated assemblies, such as multi-trade racks of pipes and ducts built off site, depend on this coordination, because they must fit exactly. On site, laser scans and photographs are compared with the model to check that work was installed where it was coordinated, and the model is updated to record what was actually built.

Exercise 11: run a coordination cycle

This exercise takes about five hours.

• Using the team's federated model of the mixed-use building, define a clash matrix with at least five tests and appropriate tolerances and clearances.
• Run the tests and record the raw number of clashes for each.
• Group the results into design issues, mark false positives, and assign each real issue to a team member with a BCF viewpoint.
• Revise the models to resolve at least five issues and rerun the tests.
• Deliverable: the clash matrix, a table of raw clashes and grouped issues before and after, and three issue reports with before and after views.

Self-critique checklist

• Do my tolerances ignore intended contacts without hiding real problems?
• Did I group clashes into issues rather than counting each one?
• Is every issue assigned using the priority order and the responsibility matrix?
• Did the rerun confirm that my fixes worked?

Reporting coordination progress

Coordinators report progress with a few simple measures: the number of open issues by discipline and priority, the number opened and closed since the last cycle, the average age of open issues, and the areas of the building that are coordinated and signed off. A floor or zone is often declared coordinated when all disciplines have resolved its issues and signed a coordination sign-off; trade contractors then use that zone's models for fabrication. A chart of open issues falling over time, with each zone turning from red to green as it is signed off, tells the owner and the team far more than a single number from one clash test.