Clash Management – the step beyond Clash Detection

One of the core benefits of working in 3D is the ability to be more confident that not only can everything fit but that it can all be easily accessed for maintenance. After years delivering complex projects in hi-tech industries, this basic benefit is a key component to a successful delivery, so it is with surprise that so many teams have dropped clash detection in the face of the difficulties of making the technology work for them.

Clash detection has several core challenges:

Most technologies are model focused, you take one or more files, establish or use existing selection sets and process the clashes only to get an extensive list of ones that need to be reviewed, logged and filtered.  While there is often a lot of “noise” generated, use of selection sets pre-supposes the form of the clashes. Of course, once all the hard work has been committed, new model files can make it necessary to repeat the task.

How do we solve it?

First, normalising the data on import means that any pre-set views on object clashing are already enabled.

Second, undertaking the clash detection and committing it to a structured data environment provides the basis to manage the clashes, either by semi-automating how they are classified (e.g. single discipline, multi-disciplined or builderswork for site implementation), prioritised, as well as being marked by the system to determine when they have re-appeared. For example, when a new model is loaded, any existing clashes that haven’t changed don’t need to be reviewed but they may need to be chased for resolution if they are critical. Inter-discipline clashes, providing that they are small and localised can probably simply be highlighted to the relevant trade and left for them to address.

The process of recording the clashes in a central repository allows a more comprehensive review, analysis and action process to take place following the initial clash detection. But where such an approach comes into its own is when the process is repeated time and time again. At each iteration those clashes that have changed can be highlighted, updated and reviewed as necessary while those clashes that remain unchanged can be left to be addressed when their timeline for resolution is near to expiring or when they themselves are updated and found by the system to have changed.

Managing clashes in this way is not only more efficient, it is also more effective and if it helps the fundamental task of clash resolution to take place then projects will have a lot less issues to address in the field, notwithstanding the benefits in operation that due consideration in design will have supported.