Discusson About Clash Detection

Uncategorized
1

Discussion: How do you handle false positives in BIM clash detection?

Hello everyone!

I’m interested in learning more about the challenges BIM professionals face during coordination and clash detection.

For those working with tools such as Revit, Navisworks, or other BIM coordination workflows, I’d love to hear about your real-world experiences.

A few things I’m curious about:

  • How often do you encounter false-positive clashes that turn out not to be actual design or coordination issues?

  • How much time does your team typically spend reviewing and filtering these clashes?

  • How do you distinguish a genuine coordination issue from an acceptable geometric intersection or an intentional design condition?

  • What do you find most frustrating about your current clash-detection workflow?

I’m particularly interested in understanding how these challenges affect day-to-day work and what existing workflows do well or poorly.

I’d appreciate hearing your experiences, examples, and perspectives. Thanks!

2

Hello and welcome…with false clashes do you then mean buffer zone or clearance ? anyway the best thing with clashcontrol is dont make them at all, or so there are just a few when do these test…i would say many dont have to be there at all should at least be fixed in the modelled proces itself…thats my best advice imo :wink: and btw not much to do with dynamo

3

Look at the clashes, cant beat a visual check.

Build rule sets to make looking easier.

All the roboclash stuff out there in my xp is a bit snake oily, the best coordinators ive worked with do visual passes as well as clash runs, and find the key congestion points for services to keep an eye on. E.g. if you have heavy tray/duct overlaps near comms distribution you would make saved views to revisit regularly before even bothering a clash in my xp.

4
  • There is a lot more to a good design than zero clashes
  • Clash detection is really only useful as a final validation
  • It can’t replace a proper design process & design coordination
  • A common scenario is:

    design disciplines independently develop their design models, with little communication or design coordination
    the BIM manager runs. a clash detection process to see if it all works
    (of course it $*T&#$%3 doesn’t…!)
    the project or design manager freak out because there are 12 gazillion clashes, and blame the designers and BIM manager

  • It often converts a design coordination problem into a BIM problem

In summary

  • it can be beneficial if used properly.
  • I see many projects where it does not add any value- in fact it makes things worse
5

Thanks for sharing your perspective! That’s an interesting point about preventing clashes during the modelling process itself. In your experience, are there still situations where coordinators end up spending significant time reviewing clashes that turn out to be acceptable clearances or intentional design conditions, even with a well-coordinated model?

6

Thanks, this is really helpful. I hadn’t fully considered how much experienced coordinators rely on visual passes and saved views alongside automated checks. When reviewing clash reports, which part tends to require the most manual effort in your experience — filtering the results, understanding the context, or deciding what needs action?

7

Thanks for this detailed perspective. Your point about clash detection exposing an underlying design coordination problem is particularly interesting. When a project ends up with an overwhelming number of clashes, what do you think is the biggest bottleneck in getting the team from that report to actual resolution?

8

I can’t help but feel this question > answer > question > answer is an AI pattern. I come across it a lot in LinkedIn DM’s as well. Always the same, a brief observation on the answer, another question.

Answer always in the form of engage, observe, query:

image
image797×517 34.9 KB

Anyway last answer from me, but if its another question it confirms my assumption. We generally try to remove AI bots from forums, so answer carefully would be my recommendation on replies.

Please note these are the Dynamo forums as well as some have noted.

Clash reports are the outcome of a workflow, most people dont use them to understand the model. Meaningfully breaking clashes down into groups that represent as one clash/issue in the report is the key. That way the report reads as an actionable object vs a dump of issues that cant relate to realo world problems.

9

yeah clearence clashes can come in many forms, but i have spend hours and hours in meeting with all stackeholders or projectmanagers and sittiting and talk about it and drink coffee and look at navis image viewpoints together and not really much happend there as then its many times to late and can give much more trouble in the model…ex… we have a clearence clash between a wall and duct we move the duct with right distance, then pipes and cabletray has to move as well and then suddenly we doesnt have space enough and then its a new kind of routing…and sometimes we get anoter airterminal in the system and have resize the duct and again suddenly dont have space enough…what i mean here in my xp its best do it in the situation so other diciplines can fix it as well so fast as possible so we dont just model further in same direction…and then endup in many clashes in these test and if we talk mep one thing i see many times is the hangersystem/insulation gives issue as well as people dont have think about it and many times even had modelled before we go in fab. phase and again then the pre void coordinering with struc fail as well and maybe already in production and end up in expensive drill on site and can sometimes effect the static system…sooo..and again just IMO

10

Thanks for explaining this in detail. The example of moving a duct and then having to reroute pipes and cable trays makes the coordination challenge much clearer.

I’m curious about one thing: when these interconnected clashes occur, how do you currently identify which other elements or disciplines might be affected by a proposed fix?

Is that something your existing tools help you understand, or does it mostly depend on the coordinator’s experience and manual review?

I’d love to understand how this works in practice on your projects.