Clash
detection.
Finding a thousand clashes is easy. The hard part is turning them into twenty decisions with an owner and a date.
Every clash is paid for once.
In the model it costs moving a line. On site, demolishing, ordering another part and waiting.
Two objects, one place.
A clash is a pair of elements that intersect, or that are closer than allowed.
Hard, clearance and sequence.
They intersect, get too close or clash in time. And a fourth case: the same object twice.
One number decides what is a clash.
In a hard clash, the minimum penetration that counts. In a clearance clash, the free distance required. Same word, two meanings.
What is not modelled does not clash.
Insulation, maintenance, door swings, installation. If that space is not a volume, no test protects it.
Detection needs a model that is ready.
Generic boxes produce clashes that do not exist and miss the ones that do. Each stage has its level and its test.
Not everything against everything.
A matrix decides which disciplines are tested against each other, with what type of test and what tolerance.
Thousands of clashes, few real ones.
Up to six in ten results are not problems: parts that touch on purpose, duplicates and uncleaned models.
One problem, a hundred clashes.
A badly routed duct clashes with every beam it crosses. Group by element, level, zone or system and decide once.
Whoever can move, moves.
Large, permanent and gravity-driven elements have right of way. Flexible ones are rerouted. Agreeing this beforehand avoids arguing over every clash.
A clash is not a task.
It becomes an issue once it carries a view, elements, an owner, a date and a status. That is how it travels between teams.
Federate, detect, decide, repeat.
A fixed cycle, with a meeting: detect, group, assign, fix in the source model and test again.
Each team, its own container.
The standard does not say how to detect. It says how the model is split, who delivers each part and who coordinates the whole.
3D coordination is already mandatory.
The Spanish central government's BIM Plan defines it as detecting and resolving collisions, and requires it in levels.
The issues travel, not the model.
BCF is an open format for commenting on models: view, snapshot and flagged elements. The model stays where it is.
A zip with one folder per topic.
Each issue carries its record, its views and its snapshots. The root says which statuses and types are allowed.
2.1 still rules.
3.0 tidies up statuses and types and separates authentication. But many tools only read 2.1: set it in the execution plan.
22 characters that must not change.
The issue flags elements by their IFC identifier. If the element is deleted and redrawn, the issue points to nothing.
Four tests and five statuses.
The de facto standard for federating. Tolerance changes meaning with the test type, and it does not export BCF without an add-in.
For checking your own work.
Compares categories of the model and of a link. No tolerance, no rules and no saved tests: useful before delivering, not for coordinating.
- Hard intersections
- HTML report
The clash as a rule.
There is no detect button: there are parametric rules on the IFC, with tolerances per component and a matrix edited in Excel.
Almost all detect something.
They are for cleaning your own model before delivering it. Names, tolerances and BCF support vary.
Detecting without the source program.
IFC viewers and open tools cross-check models from any source, group results and export BCF.
Detect on publish.
In the cloud, the test runs by itself every time a new version arrives. You gain consistency and lose fine control.
Some detect, others manage.
Some platforms compute clashes and others only receive issues. What they should all speak is BCF.
From viewer to model, and back.
The coordinator marks the issue in the federated model. The author opens it in their program, which jumps to the elements by GlobalId, fixes and replies.
No files to send.
With the API, every program reads and writes the issues on one shared server. No BCF versions circulating by email.
What does not reach the other side.
Each program reads a BCF in its own way. Before the first meeting, test a round trip with the project's actual programs.
First, a model fit for purpose.
Running detection on an uncleaned model manufactures noise. Five prior checks, which an IDS can automate.
- Same shared coordinates
- Stable units and GlobalId
- No duplicates
- Systems and classification filled in
- Insulation and clearances modelled
The curve has to come down.
Open issues per discipline and average time to close, week by week. The total number of clashes only measures noise.
“Resolved” is not “fixed”.
A clash disappears if it is fixed, but also if the element is deleted or the test selection changes. Someone has to look.
From your own model to the federated one.
Each level has its tool. An error caught upstream does not travel to everyone else.