Discovering structural steel clashes during field installation causes severe project delays, crane downtime, and expensive site modifications.
Utilizing BIM platforms like Tekla Structures, detailers overlay the structural steel 3D model onto architectural, concrete foundation, and MEP (Mechanical, Electrical, Plumbing) models.
Steel beams directly intersecting MEP ductwork, piping, or concrete walls.
Insufficient space for bolt wrench access, beam deflection clearance, or maintenance access.
Resolving spatial clashes digitally before shop drawing generation ensures that every piece arriving at the job site fits into its designated space without field cutting or modification.
Clash detection only works as well as the federated model behind it. That means every trade — structural steel, MEP, architectural, sometimes precast — needs to be publishing coordinated model exports on the same schedule, ideally weekly during active coordination, so the clash run is checking current geometry rather than a duct layout from three revisions ago. A clash matrix that defines which trade takes priority in which zone (structural steel typically wins over ductwork, but loses to a fire-rated shaft) heads off a lot of back-and-forth about whose model has to move.
Clearance tolerances matter as much as hard clashes. A duct that physically fits past a beam with zero clearance still fails in the field once insulation, hangers, and installation tolerance are added, so the clash detection settings should apply a buffer distance around MEP elements rather than checking geometry-to-geometry contact alone. Who owns resolving a given clash is worth settling in the coordination meeting rather than the model: as a rule of thumb, whichever trade is cheaper and faster to reroute moves first, and structural steel is usually the trade that moved last.
A clash resolved once tends to resurface if the fix isn't documented somewhere other than the updated model geometry itself. Keeping a simple clash log — the clash, which trade moved, what changed, and the date — gives the coordination team a reference when a similar conflict appears in a different zone of the same building, or on a future project with a similar MEP layout, instead of re-solving the same category of problem from scratch every time it appears.
This log is also what protects the steel detailing team when a resolved clash reappears late in construction because someone reverted a model element — having a dated record of who agreed to move what removes ambiguity about whether the current field conflict is a new issue or a regression.
The value of a clash run depends heavily on timing relative to how settled each trade's design is. Running clash detection too early, while MEP layouts are still in schematic design, generates a large volume of clashes that will resolve themselves as MEP design matures — wasting coordination time on conflicts that were never going to survive to construction documents. Running it too late leaves too little schedule float to actually resolve what it finds. Most coordination teams settle into a rhythm of lighter, informal checks during schematic design and full, tracked clash runs once each trade has reached design development, which balances catching real conflicts early against not drowning the team in noise.
Finally, it's worth setting a shared definition of "resolved" before coordination begins — does a clash count as resolved once a model is updated, or only once the responsible trade has confirmed the fix in writing? Teams that leave this ambiguous often find clashes marked resolved in the clash software that were never actually confirmed by the trade responsible, which resurfaces as a field conflict months later.