BIM coordination: nine rules we follow in clash reports in BIM design

A clash report is the most tangible product of BIM coordination and modelling (Building Information Modelling, the digital modelling of building information). It shows where the elements of different disciplines intersect in the model, before they intersect on site. In theory this is simple. In practice a single report may contain four thousand clashes, most of which can be considered irrelevant from a construction point of view, and a project may generate more than a hundred reports.

Below are selected rules that our BIM team follows consistently, written down after coordinating a public building of complex geometry. Some of them may seem obvious, but it is precisely their consistent application that keeps the model in order and allows clashes that could prove very costly to be resolved at the design stage.

Part one: modelling

1. We check every layer of every partition, because one inaccuracy produces several false positives

In a large model it takes just one layer of plaster extended beyond the wall core for the clash report to start showing intersections that result from modelling, not from design. One such element automatically generates clashes with the adjacent wall, with a beam, with the floor slab. A single oversight produces a dozen or more entries in the report: information noise that the BIM coordinator then has to review and either accept or return to the design teams as feedback.

We do not rely on scripts that automate joins and clean up the model to do this job for us in full. Automation does not replace accurate modelling, and correcting things afterwards costs more time than keeping the model tidy from the very first stage. The responsibility lies with the people who model, and that is how we work.

We carry out internal coordination while the model is being built, so that inaccuracies are caught as they arise. We generate clash reports by storey or at a fixed interval, instead of one report at the end that produces several thousand clashes. The rhythm depends on the pace of work: when the model develops quickly, we generate reports at the end of each day so that the design team can start corrections the next morning; when it develops more slowly, once a week. Generating a report takes little time, so the cost of this discipline is low.

2. We model separate floor slabs, not a single instance made up of several slabs

A tempting shortcut in modelling: one command, several slabs drawn as one element on one level. When clicked, the whole object made up of several parts is highlighted, and assigning a clash to a specific element becomes difficult.

When we model the same layout as separate slabs, the number of clashes may be the same, but each one is assigned to the correct element and the model stays in order. The general rule: a shortcut at the beginning often means the real goal, correct clash detection, is not achieved. This applies equally to residential and mixed-use buildings. It may sound like a truism, but it is worth remembering and repeating.

3. We check clashes with opening families only in internal coordination

An opening in the model is a virtual object. It does not exist in reality, so checking clashes between elements such as building services and opening families produces only false positives. Opening families are useful when the contractor or the Client can read from them the quantity of material removed from slabs and walls. We check the consistency of openings between the discipline models in internal coordination.

4. We agree the level of detail before setting the test tolerance

For example, with a low clash tolerance, balusters intersecting the handrail and the bottom rail of a balustrade are reported as clashes, although in reality they are not a problem. Eliminating such a clash mechanically, by shortening the balusters so that they do not reach the handrail, gives a balustrade with hanging balusters, which affects the visual perception of the model and may raise the Client's doubts about its accuracy.

This is why we agree the level of detail when preparing the BIM documentation. If the model is delivered at LOD 3 (Level of Detail, the level of detail of the model) according to the BIM STANDARD PL guidelines, exact geometric infill of balustrades is not required. Before we set the test tolerance, we check which level of detail has been agreed.

Part two: documentation and contract

5. We keep the BEP consistent with its appendices

We prepare the BEP (BIM Execution Plan) on the basis of the Client's requirements, and we are responsible for its consistency. An example of a discrepancy we catch: the BEP allows clash reports in Excel or HTML format, while an appendix to the BEP mentions HTML only. Such an inconsistency later raises the question of what is actually to be delivered, and asking the Client during the work does not build trust. This is why we check the alignment of the BEP and its appendices at the contract and BEP preparation stage.

6. We clarify the phrase “report split by storey” with an example

A general provision about splitting the report by storey, without explaining what that split should look like, is a common trap in BEP appendices. Each party may interpret it in its own way, and each will be convinced that the other understood the same thing. We use two elements: a description of the clash test settings and the output or a diagram of a sample report. With this in place, both parties agree from the start.

7. We define in the contract what “a report” is and what “reports” are

In project documentation these words are often used interchangeably, yet they mean two different products: a single multi-discipline report as one file, or a series of cross-discipline reports (architecture against structure, structure against building services, and so on). Without a definition, each party may picture a different deliverable while believing they are talking about the same thing. This is why our contract definitions describe “a report” and “reports” separately, each with a template showing what the final product looks like. The template saves both parties time on explanations during the project, because it is clear from the start what to expect.

8. Relevant and irrelevant clashes: a contract definition and separate streams

Where the contract divides clashes into relevant and irrelevant, the division needs careful thought. An example: the clash between the door swing of a staff locker and a wall is treated as irrelevant, but at the same time the locker itself is in clash with that wall, which is relevant. Given the locker layout adopted for the changing room (which depends on the number of staff), the room has to be redesigned and enlarged. Pulling on the thread, a seemingly minor clash leads to the need to enlarge the changing room. What counts as relevant must be thought through at the clash matrix stage and written into the contract.

Operationally, we run two separate streams and do not mix them. The Client has the right to change their mind during the project and move a type of clash from irrelevant to relevant, or the other way round. We then agree this as a change of scope. We include a provision for such a reassignment in our contracts, so that both parties know how to make the change without stopping the work.

9. We agree the delivery format of reports before sending them

Clash reports from Autodesk Navisworks can be generated as an HTML file with a folder containing image files for every clash. With a large number of clashes per report and, for example, more than a hundred reports in a project, this adds up to a considerable number of files. Dragging that many files at once into cloud storage such as SharePoint may end with an application error. This is why we pack reports with their image files into a ZIP or 7-Zip archive. One caveat: we agree the archive format with the recipient in advance, so that the other party is able to unpack it.

What this means for a client commissioning BIM coordination

Most of the cost of coordination does not arise in the clash report or reports, but before them: modelling discipline, an agreed level of detail, clash tolerance, contract definitions, a consistent BEP and an agreed delivery format. A team that takes care of these things delivers to the Client a design that meets their expectations.

SRDK STUDIO provides BIM coordination for its own projects and as an outsourced service for other design practices and clients.

In order to select the right partner, it is worth carrying out a detailed analysis of their experience in the construction industry, including residential construction, and checking the technical aspects of cooperation: the data exchange standard, the way changes are introduced so that they are automatically reflected in quantity reports, and work based on scanning and point cloud data for existing buildings. Thanks to BIM, all participants in the investment use a single model that improves the coordination of disciplines, meets the client's requirements and, after completion of construction, serves the maintenance of the building.