Clash detection in practice

What the software does

It compares the disciplines’ models and flags where elements intersect. The result is a list — often hundreds of items.

Why the list is not the result

Because most of the hits are not real problems: two elements touch deliberately, or modelling inaccuracy causes an intersection.

The value rests on the filtering: which hit matters, who resolves it, and what the decision was. Clash detection.

Our sequence

1. Rules: which groups of elements are compared, with what tolerance.
2. Run it.
3. Filter: pick out the real clashes.
4. Owner: who resolves it.
5. Record the decision: how it was resolved.
6. Re-run on the next round.

Steps 4 and 5 are what make it useful — without them all you get is a list.

Where it brings most

Services and structure

Pipe penetrations, web holes, soil stacks. The most common and most expensive type of clash. Web holes and service openings.

Structure and architecture

Openings, ceiling heights, the position of finishes.

Disciplines against one another

Mechanical against electrical, sprinklers against ventilation.

Timing

It is worth most when it happens before manufacture and there is time to resolve. Run a week before manufacture it is only damage assessment.

With a prefabricated structure this is especially strict: coordination has to close before manufacture. Coordination between disciplines.

What it does not solve

It finds the geometric problems. Wrong actions taken, missing restraint or an unmet requirement are not geometric — those need professional review.

The point

Clash detection is a tool, not a result. The machine finds the intersections; which one matters and who solves it is an engineering decision.