Clash Detection Rules and Datasets

Version 11 of 12d Model introduced a much faster, more powerful and flexible clash detection routine. The greater flexibility is provided through the ability to create multiple rules for checking elements against one another. The rules allow strings to be filtered by model and string name, so simple and complex clash combinations can be easily created. In this post, I’ll explain how the filters are applied to the dataset to select which strings are checked against which to get you your clash results (hopefully no clashes!). The clash detection rules can be created via the Design→Check-Clash→Clash detection or Utilities→A-G→Check / clash→Clash detection menus. I won’t discuss how the rules are created in the panel or how the clash detection is actually run since the 12d Model help explains that. Instead, I’ll be explaining the concepts behind the rules and how they are used to select datasets for checking clashes.

Clash Rulesets and Rules

In order to actually run the Clash Detection, you must first select a ruleset for the check.  The ruleset defined the rule/s that 12d will use to determine whether there are any clashes.

There must be at least one clash rule in a Clash Rule Set; otherwise, there is nothing to do. If such a Clash Rule Set is used (i.e. no rules) then no results will be reported. A ruleset can, however, contain more than one rule. In such a case, when the Clash Detection is run with the ruleset, each rule will be processed separately, reported to the same, single file, but in different sections (unless the report template has been customized).

The rule defines two separate datasets for each rule – the source dataset containing the elements being checked, and the target dataset containing the elements being checked against. Elements cannot exist in both. They are in either one or the other or neither.

In order to select which elements are in the source dataset and which are in the target dataset, each rule has several filter fields. The filter fields are grouped in pairs- one for the model name, another for the string name- and there are two pairs- one for the source dataset, the other for the target dataset.  These filter fields can contain wildcards and wild characters (*, ?) and blank fields will match all elements. That is, blank fields are interpreted as the wild character * , which selects all data.

Clash Detection Rules panel showing the rulesets, rules and filter fields for the source and target datasets.
Clash Detection Rules panel showing the rulesets, rules and filter fields for the source and target datasets.

When the clash detection is run, a dataset of objects is selected by the user by using the Source Box at the top of the panel. This can be called “Dataset A“. Typically, this would contain all the modelled utilities and objects that you want to check for clashes. The source dataset and target dataset are extracted from this overall dataset. The source dataset can be called “Dataset B” and the target dataset called “Dataset C“.

Service clash detection panel showing the user's selection of the overall dataset.
Service clash detection panel showing the user’s selection of the overall dataset.

The “Model to check” filter is applied first to select models from the overall dataset, Dataset A.

Examples of model name filters for source datasets
Models in overall dataset Model to check filter Matching models in source dataset
ABANDONED GAS

ELECTRICITY EXISTING

ELECTRICITY PROPOSED

GAS EXISTING

GAS PROPOSED

SEWER

STORMWATER

WATER PROPOSED

GAS* GAS EXISTING

GAS PROPOSED

*GAS* ABANDONED GAS

GAS EXISTING

GAS PROPOSED

*PROPOSED* ELECTRICITY PROPOSED

GAS PROPOSED

WATER PROPOSED

The “Object name to check” filter is then applied to all elements matching the “Model to check” filter. So, only strings matching both “Model to check” and “Object name to check” filters will be selected for the source dataset (Dataset B).

Examples of string name filters for source datasets
Strings in source dataset models Object name to check filter Matching strings in source dataset
GAS-300

ELEC300

300RCP

375RCP

225PVC

150DICL

*300 GAS-300

ELEC300

*300* GAS-300

ELEC300

300RCP

*RCP 300RCP

375RCP

So, the combination of “Model to check” filter and “Object name to check” filter is applied to the overall clash detection dataset (Dataset A) selected by the user to select the source dataset (Dataset B).

5 thoughts on “Clash Detection Rules and Datasets

  1. The Clash detection creates a list in the output window that allows the user to click on the clash in the output window and 12d will show the clash in the current view. Is there a way to export this to another 12d project without needing to re-run the clash detection?

    1. Chris, no, not at the moment. The log lines in the Output Window are pretty much just the same results as produced in the report.

      It would be possible to write a macro to read a clash report in any project and produce log lines in the Output Window so you can locate those clashes. It wouldn’t be able to do the grouping/collapsible log lines (not possible in the 12d Programming Language), but it would still write out the message and highlight the location (crosshairs) on screen.

      I could look at writing a macro for you, if you’re interested.

  2. Another thing worth noting (I think) is that the Rules only appear to be read by Service_Clash_Detection when the panel is launched (or duplicated) so beware if editing rules you will need to re launch the panel for the changes to Rules to take effect.

    1. Yes, that’s right. I believe it’s the same behaviour for any panel using the new XML reporting. The list of clash rules (or report templates) is only populated when the panel starts.

      One thing I haven’t tried is if the list of rules is updated if you duplicate the panel. Any one tried?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.