Model Structure – SOL/176

Solibri Model Checker (SMC) has an extremely powerful QA/QC checking rule template named Model Structure (SOL/176).  This rule template is unique, as the parameters consist of simple check boxes for specific checks against the model.  This makes it one of the easier templates to setup; however, to get the best use of the template, it is important to understand the purpose of each of the various checks toggled on/off by these check boxes. You could simply mark all checkboxes, but for a complex model, the results view may contain many disparate results or ones that aren’t important for your use case.   Alternatively, you may wish to group certain checks together, for instance, checks regarding floors or checks regarding doors.  Furthermore, you may wish to use the template marking only a single checkbox to limit the check to that particular condition.

The purpose of this article is to familiarize you with each of the parameters of the rule template through examples so you can tailor a ruleset that uses this template to your liking based on what is important for you.  You can experiment with this template using the ruleset in the link below. This example ruleset has individual rule checks corresponding to each of the individual parameter check boxes.

Below are the rule parameters of the Model Structure rule template.

Model Structure - Parameters

Each section below will explain each of the parameters from top to bottom.


Like many of the rule templates in SMC, you are able to select the disciplines of models you want to check against or select ‘Any’ for all disciplines available in the aggregate model. Only the components in the specified disciplines are checked. The following article explains disciplines in further detail:

Disciplines in SMC

Check Containment Hierarchy

When this parameter is checked, the rule template checks that the model reflects the following hierarchy: model has building, building has floors and floors have components. In the image below, you can see the correct hierarchal structure of an IFC file.

Correct Model Tree Structure

Below is the model tree showing the hierarchy of an IFC with an incorrect structure loaded in SMC.  Notice that the building does not contain levels (building stories) that contain the components within the model.

 Incorrect Model Tree - No Floors

After running a check of the containment hierarchy, the results view reports the issue that no floors exist in the model.

Results - No Floors

Direct Relation to Floor

When this parameter is checked, the rule checks that all components in the model have a “Contains” relation directly to a building floor.  For example, furniture related only to a space (which is related to a building floor) will fail the check. In the image below, you can see two sanitary terminals are related to a restroom space, rather than directly related to First floor.

 Direct Relations to Floors - Model Tree

In the image below you can see the issue result displayed in the Results view.

Direct Relation to Floor - Results

NOTE: Your design software will more than likely relate components to space in which they are contained rather than directly to the floor.  You will likely wish to leave this checkbox unmarked, which is its default setting.

Check Empty Floors

When this parameter is checked, the rule checks that all floors contain at least one component. In the image below, the floor named “TOF Footing” is empty in the Model Tree view.

Empty Floor - Model

Below is an image of the Results view reporting the issue that TOF Footing doesn’t have components.

Empty Floor - Result

Check Floor Elevations

When this parameter is checked, the rule checks for multiple building floors located in the same elevation.  In the image below, the floor “Level 1” is selected and 0 is reported as its Global Bottom Elevation.

Floor Elevations

In the image below, a different floor named “Level 1a” is selected and its Global Bottom Elevation is also 0.

Floor Elevations

This issue is reported in the results view, which lists the elevation along with the names of the floors that reside at that elevation.

Floors have same elevation - Checking

Check Floor Names

When this parameter is checked, the rule checks if the model has multiple building floors with the same name. In the image below, there are two floors with the same name “First Floor” listed in the Model Tree view.

Floor Names are the Same

After running the check, the issue is reported in the Results view which lists the name of the floor.

Floor Names are the Same - Results

Verify Material Layers Thicknesses

When this parameter is checked, the rule checks all walls, slabs, and roofs in the model to ensure the sum of material layer thicknesses is the same as the thickness of the component itself.  Below is a wall that has a thickness of 4 7/8″, as listed in the Quanties tab of the Info view.

Wall Thickness

The Material tab lists the materials of the wall’s structure.  These tree materials add up to a total thickness of 4 1/2.”

Material Thickness

Since these two thicknesses differ, an issue result is returned for the wall stating the differences of thicknesses.

Material Thickness - Results

Doors/Windows in Same Floor AS Wall

When this parameter is checked, the rule checks to ensure the wall (or a roof/slab) and its doors/windows are included in the same building floor.  The model in the image below has a wall that is on the floor “Level 1” that has a height of 20 feet, which extends upward past Level 2, which resides at 10 feet.

 Wall on Level 1

There is a window on Level 2 attached to the wall as seen below in its Floor property in the Info view.

Window on Level 2

Also, there is a window that appears to be on the same floor as the wall selected in the image below.  However, this window was originally placed on Level 2, and was later moved below using a negative number in the Sill Height parameter.

Window on Level 2 with negative sill height

In the image below, the Sill Height property lists a negative value of -7′ 6″ in the constraints in the Info view after selecting the window.

Negative sill height

Since both of these windows reside on the Level 2 and the wall, which wasn’t split at level 2 is a single wall that resides on Level 1, an issue is reported in the Results view listing these two windows after running the check.

Window same floor as walls - Results

NOTE: You are able to automatically split walls and columns by floor by marking the “Split walls and columns by story” checkbox in the exporter of Revit.  For more information on this, please see Exporting an IFC File from Revit to SMC

Check Maximum Polygon Number

When this parameter is checked, the rule checks the geometry of all components in the model to ensure those components do not consist of more polygons than the specified Maximum Polygon Number parameter.  Below is an example of a sphere that has a 50′ diameter.   This component fails the check, and the Results view lists this component along with the polygon count of 4446.

 Maximum Number of Polygons

Viewing the component in wireframe mode within another application, you can see the 4446 polygons that make up the geometry of the sphere.

If you find that your model is sluggish while navigating or other performance issues, this rule can check if there is a specific component with complex geometry causing the issue.  To help in performance issues, that component could be hidden in SMC, or edited in the original design software to make it less complex.  For information on performance issues can be found in the article Optimizing Performance in Solibri Model Checker

Check Space Boundaries

When this parameter is checked, the rule checks all spaces to ensure they have correct space boundaries.  A space (room) in a model is bound by components such as walls, windows, doors, etc.  Spaces can also reside next to each other without a wall that separates them using room separators.  In the IFC, a space boundary element exists for these boundaries.

In the image below, a result is listed stating that there are missing space boundaries for the Radiographic Room.  There is a wall inside the space, which can be seen as it cuts out the geometry of the space.  However, no space boundaries exist for this wall.  The boundaries that do exist are listed in the result and are colored blue in the 3D view.

 No Space Boundaries

In the image below, you can see space boundaries highlighted in red that only bind a single space and no components or other spaces. The Results view lists these three space boundaries.

Space Boundaries only bind one space

After selecting one of the space boundary elements in the result view, you can see in the Relations tab of the Info view that the space boundary only binds the corridor space, but no other space or construction component such as a wall.

Only binds corridor

Check Orphan Doors and Windows

When this parameter is checked the rule checks if the model has doors or windows without relation to a wall. In most design software, when a door is placed on a wall, it generates an opening component that cuts out the geometry of the wall for the door to fit.  In the image below, an opening component is selected.  The Relations tab of Info view lists the backward filling relation to the door, since it fills the door and the forward void relation to the wall which it cuts out.


The opening to the right doesn’t have a filling relation to the door as an opening was cut out of the wall, and a door was placed in the location without actually attaching it to the wall in the design software.

When the rule is run, this door on the right is returned as a result stating that it isnt related to a wall.

Check Door Opening Direction

When this parameter is checked the rule checks that all doors in the model have the opening direction defined. The opening direction, or door operation, is needed for the Accessible Door rule.  More information on this rule can be found in the article Enhanced in v9.6 Accessible Door-Rule SOL 208

You can view the door operation in the Identification tab of the Info view as in the image below. Also, notice you can see the swing in the footprint in the 3D view.


In the image below, the door on the right doesn’t have a door operation. Selecting the door and viewing its Operation property shows it listed as Undefined. Also, the swing is missing in the footprint n the 3D View.

After running the check, the door with the undefined door operation is returned as a result.

Allow Only One Site

When this parameter is checked the rule checks to ensure the model has only one site.  In the image below, there are two sites listed in the Model Tree: Site Name and Site Name 2.

After running a check, a result is returned of the issue which lists the multiple site names.

Check Whether Site has Geometry or Not

When this parameter is checked the rule checks to ensure the site in the model contains geometry.  In the image below, the site is selected in the Model Tree which highlights it green in the 3D View.

In the image below, the geometry of the site was removed.  It is selected in the Model Tree, but there is no existing geometry in the 3D view to select.

When this check is run, a result is returned that lists the site that doesn’t have geometry.

Require Unique IFC GUIDs

This parameter is used to check if the Global Unique Identifier of components is unique in your model. The drop down that can be set to Unique in One Model, and the GUIDs of components are only compared within that single model.  When the drop down is set to Unique in All Models, GUID of a component is compared against the GUIDs of all components in ALL the loaded models.

In the image below, the beam on the left has a GUID value of 06pcgjPDbES92yHX6IVtf_.  This beam resides in the architectural model.

In the image below, the beam on the right also has a GUID value of 06pcgjPDbES92yHX6IVtf_.  This beam resides in the structural model.

After running a check for “Unique GUIDs in All Models” a result is returned for these two beams with duplicate GUIDs as seen selected in the image below.

The information provided in this article should provide you a better understanding of the Model Structure rule and allow you to custom tailor a ruleset using the this rule template to suit your needs QA-QC requirements.


Model Structure – SOL/176

Creating Presentations on-the-Fly in SMC

The core functionality of Solibri Model Checker (SMC) is to run rules-based checks on your Building Information Model (BIM), review the results of those checks, and generate issue slides of those results to create a presentation/report of issues.   The presentation and report can be generated automatically by selecting the “From Checking Results” option in the New Presentation dialog.

You can also create presentations manually during your coordination meeting by creating your own issue slides outside of a rule check.   The following article will demonstrate this simple function, which can be useful when you are getting started with SMC or if you want a quick way to create snapshots of your model on-the-fly.  You can follow along using the SMC Building.smc model that comes with SMC located in the Models folder in the program files.

After opening the SMC Building.smc sample model, you’ll notice in the Checking layout, that a rule check has already been run on the model and issue slides have been created for some of the results of the check:

You can tell a slide was created for this result as a slide icon  appears next to the result.

If you select the Communication layout, you’ll see there are two presentations listed in the Presentation view.  The “Issues (12)” presentation is a presentation created from checking results.  Below you see the issue slide previously seen in the Checking layout.

You can tell these slides were created from Results as there is result link icon  shown on each slide in the Issue Sorter view.

To create a presentation from checking results, after clicking the New Presentation button in the Presentation view, click the “From Checking Results” option and mark the Rules you want slides created for in the Presentation.

If you look in the Presentation view, you’ll see a presentation named “General Presentation (4)”.  There are no result link icons  shown on the slides in the Issue Sorter view.  This is because this presentation was created without the means of checking results.  To create a presentation of this sort, in the New Presentation dialog, mark the first option “New.”

You can then add issue slides manually by right-clicking on a slide in the slide sorter, and select “New Issue” option.

Below, we selected the 4th issue of the “General Presentation” in the Issue Sorter.  We then zoomed out to the front wall, made the wall transparent and added some markup using the Markup tool stating that the water closet room needs a toilet:

After right-clicking the 4th issue slide in the Issue sorter, we select New Issue. A new issue slide is created in the presentation with the visualization saved and we can add a title to the slide.

From there, we can add more slides manually in this same way without the need of having an actual checking result.

Creating Presentations on-the-Fly in SMC

Forward and Backward Relations in SMC

In Solibri Model Checker (SMC), relationships exist between components and are reflected as “Relations”.  These are similar to properties and are grouped into folders within the Relations tab of the Info view. These relationships can be termed ‘forward, backward, or forward and backward’. We’ll explain what this means to you, as an SMC user.

In the previous article, Using the Decomposes Relation Property, we used the example of a stair to explain the forward and backward Decomposes relation between the stair assembly and the stair runs, landings, and railings that make up that assembly.

In this article, we’ll focus on some other relations and explain their forward and backward direction.

For more information on relations within SMC, please see the help topic:

SMC Help – Relations

The Containment Relation

As the name suggests, the containment relation is present when one component contains another component.  For example, a Building component contains Floors, Floors contain components such as Spaces, and Spaces contain other components.

Looking at the structure of the sample model (SMC Buildng.smc) that comes with SMC, you see that the Ground floor contains a space Men[104].  That space contains two Sanitary Terminal components, which are a toilet and a sink.

If you select the Men[104] space, in the Relations tab of the Info view, you’ll see the containment relation for the space.

Notice there are arrow icons in front of the listed relations that denote the direction of the relation.  A forward direction is denoted by the  forward (pointing to the right) icon, and a backward direction is denoted by the backward (pointing to the left) icon.  Since the Space is a sub-element of the Ground floor, this containment relation has a backward direction, and since the Space contains the sanitary terminals, these containment relations have a forward direction. Essentially, as you get more granular, you have forward relations, and as you refer to those elements ‘upstream’ you are expressing backward relations.

If you select the ground floor, it will have a  forward containment relation to the Mens[104] space.

So logically, if Component A has a forward relation of some relation type to Component B, then Component B has a  backward relation of that same relation type to Component A. The result is a hierarchy of the related model components.

Relations are used in the rule Comparison Between Property Values [SOL/171], by selecting “Related Component” in the Components to Compare drop-down.

In the example of this rule below, the parameters are specified to check that there is at least 1 toilet on each floor.  Since we are checking floors, Floor is set in the Components to Check table.  We are using the Containment relation, so Related Component is selected in the Components to Compare dropdown, Containment is set as the type, and the Forward direction is selected.  The Follow Relation Chain checkbox is marked because there isn’t a direct containment relation to the floor and the Toilets. Instead, a floor contains the space and the space contains the toilet.  Lastly, since we are looking for at least 1 toilet on each floor, components classified as Toilet Seat is listed in the Components to compare using a count quantifier greater than or equal to the target value 1.

The only result returned is for the Roof floor which logically doesn’t require a toilet.  This floor could be ignored in the Components to Check table in the rule parameters or the result can simply be approved.

Doors, Openings, Walls and the Void/Filling relation

Rather than a direct containment relation, doors, and walls have a Filling and Void relationship to an opening component respectively.

If you select a door in a model, you’ll find that it has a  forward Filling relation to an opening component, since the door “fills” the opening.  However, there is no direct relation listed between the door and the wall.

If you double-click the opening listed in the Info view it will become selected. You’ll see the    backward Filling relation to the door and also a  forward Void relation to the wall.

Since there are two different relation types, a single Comparison Between Property Values [SOL/171] rule cannot be used to compare walls to doors.  Instead, a gatekeeper rule can be used to return the opening of a wall, which passes those openings to a sub-rule to check the door that fills the opening.

We’ll use a simple check to ensure that 1-hr fire rated walls have 1-hr fire rated doors. This example can be found here:

Fire Rating – Relations.smc

The file consists of 4 walls that have doors attached:

Below you can see which walls and doors have a 1-hr rating as those without a rating are hidden.  Only the third wall from the left is a 1-hr fire rated wall that doesn’t have a 1-hr fire rated door:

After running a check, only that wall/opening is listed as a result:

To create the ruleset, the “Gatekeeper: Openings in 1-hr Walls” has the following parameters filled in to return as results any openings that do not have a forward void relationship to a wall with a 1-hr fire rating:

Since only openings that fill 1-hr fire rated walls pass this check, “Check only passed components” is marked for this gatekeeper rule in the Ruleset Manager.

Those openings are passed to the sub-rule “1-hr Components must fill Openings.”  This rule checks that those openings have a backward filling relation to a door that has a 1-hr fire rating.  Notice this is a backward relation since the door fills the opening.

The result is any opening that creates a void in a 1-hr wall that does not have a 1-hr door filling that opening.

Decomposes Relation in Information Takeoff (ITO)

Relations can be used in ITO to group components by their related component.  In the example below, there are beam assemblies that group multiple beams.  The total lengths of these grouped beams are listed for each assembly along with their counts. For example assembly with id 185923 has 7 beams that have a total length of 192′- 3 7/8″.

The Decomposes relation is used for components such as stairs, beam assemblies, and curtain walls that are can be made up of differing components. For example, stairs can be made up stair runs, landings, and railings.  Beam assemblies can be made up of multiple beams. Curtain walls can be made up of panels (windows) mullions (members), and doors. These examples are a subset of commonly found components that can be assemblies with a Decomposes relation.

To create this ITO we create a new ITO Definition to report only Assembly components.

Right-click on the Type column and select New Column to group and report assemblies by their Building Authoring Tool (BAT) ID.

As we don’t wish to report the Type, this column is edited by right-clicking the column and selecting Edit.  We select Relation as the Column type, Decomposes as the relation, Forward as the direction, and Grouping to group the beams to find their total length.

Right-click the Count column, and select new column to create a column that reports the total length of the beams in each assembly.  Select Quantity for column type, Length for the Quantity, leave grouping unmarked and Sum for the Function.

This example can be found through the link below:

Decomposes – ITO.smc



Forward and Backward Relations in SMC

Correcting Widely Scattered Models

When bringing models into SMC, you may find some components being displayed outside the normal 3-D View. These components can be the result of accidental placement of components outside the building, or simply legacy objects that are left behind from previous model versions.

In SMC, these components cause issues with navigation because they generate such a vast 3-D View. A single misplaced object may be miles away from the building in the 3-D view, which results in SMC trying to accommodate for the single misplaced object by creating much more navigable space then is needed. You can correct for these issues in SMC when importing a file.

When first bringing in a model, if there is an issue with a component that is far away from any other relevant model components, a pop-up window will appear suggesting that the models are “widely scattered.”   Again, this is implying that the amount of space that will be generated in SMC’s 3-D view will be extremely large, and will almost certainly affect performance and navigation in SMC.


In the screenshot above, there are 553 components in one location, and one component in another that is several miles away.  Obviously, the single component is likely to be an error.

You can select the Zoom To Components zoom_to_components  icon to ‘zoom in’ to that object to see what it is.

Select the object in the 3D window to see the Info about the object and make a determination about what should be done.

If it is determined that you would like to ‘remove’ the item from the model, you can do so by clicking the Set to Selection Button Set to Selection Basket  to place that object in the Selection Basket.

From the Selection Basket, choose the Component Hierarchy COMPONENT_HIERARCHY icon, then right-click on the object and choose ‘Remove from Model.’


This will remove the object so that it is no longer in Solibri Model Checker.  It does not remove the component from the IFC file, however, so it is best to go back to the original design software at some point and correct the issue for future versions of the model.  By removing the component in SMC, you are temporarily removing the issue so that you can proceed with your model review.

Correcting Widely Scattered Models

Creating Your Own Custom Disciplines Through Classification

In the previous article Disciplines in SMC, we explained how the discipline of a file opened in Solibri Model Checker (SMC) is useful in the color mapping of components and use in rule filters. Currently, these disciplines are hard coded and limited to those in the list below:


The discussion of disciplines arises during coordination when checking for intersections between systems. Namely, what discipline to set files to as they are added to the federated model and what disciplines to check against each other using the general intersection rule in SMC.  Classification within SMC makes it simple to automatically map your files using your own naming convention to any custom discipline you would like to create.

For example, you may have a different naming convention of disciplines and use the term “Mechanical” rather than “HVAC”.  Also, you may have a “Communications” model that is differentiated from the “Electrical” model(s), for which a discipline doesn’t exist within SMC.

For more information on classification see:

Creating Classifications in SMC

Using Advanced Classification in ITO

You can follow along as we create a “Discipline by File Name” classification for use in interference checking using the example model linked here:


This example model was created by exporting the Architectural, MEP, and Structural versions of the advanced sample project that comes with Revit 2016.  For the MEP sample project, we also isolated components during each IFC export based on the discipline of Mechanical, Electrical, and Plumbing to further divide the entire federated model into 5 IFC files based on each discipline.

When you first open all 5 IFC files, the Ensure Model Disciplines window will open to allow you to set the short name and discipline from a set list in SMC.

Short names are always manually entered or left to their A-Z defaults. However, the discipline can be automatically mapped based on the application that created the file, or the file name.  The file was exported from Revit 2016, which is a building authoring tool that can contain components from any discipline, unlike other applications that specialize in a specific discipline, such as Tekla Structures, Revit Architecture, Revit Structure, etc.  As such, it simply defaults to the Architectural discipline. The out-of-the-box File Name mapping is left as *.* and to ignore the file name, as it is up to the user to define their own mappings based on their own file naming convention.


We’ll manually set the short name to the first letter of the discipline and set the discipline to one of the hard coded disciplines in SMC. For instance, we map the Mechanical file to HVAC and the Fire Protection model to Sprinkler. This will allow you to use the out of the out-of-the-box interference detection rules that come with SMC to check discipline against discipline.


For example, one such rule checks all Building Services components that intersect with beams and columns from Structural models.  Below, we see in the results view there are 207 intersections with beams and 30 with columns.  In the Checked Components view, these intersections occur in the electrical, mechanical, plumbing, and structural models.


Opening the rule parameters of this rule, in the component filter table for Component 1, only beams and columns from disciplines related to Structural components (Prefab Concrete, Steel Structure, Structural) are checked.  For Component 2, any component excluding Covering, Space, Cable from disciplines related to Building Services (Air Conditioning, Building Services, Cooling, Electrical, etc.) are checked.


Listing all the various disciplines that fall under the category of Structural vs Building Services models leaves flexibility for users for what they select as their disciplines when they first load their models.

You are able to isolate the results by discipline though selecting the file(s) of that discipline in the Checked Components view, setting the file(s) to the selection basket, and selecting Filter with Selection Basket (some) in the Results view.  Below, we see there are 169 intersections with beams and 16 intersections with columns between the HVAC model and the Structural model.


The intersections between just the electrical model and structural model can be viewed using this same method as seen below:


Depending on the number of files, disciplines, and naming conventions, you may find that you wish to fine tune your interference detection checks to individual disciplines and/or even disciplines, such as “Communications,” that are not included in the hard coded ones.  This can be achieved through the use of classification.

Open the Classification view by clicking Add View ADD_VIEW > Classification SMC Classification Icon.  You’ll find a “Discipline by File Name” classification is loaded.  If you expand the classification, you’ll find that components in the model are classified by their discipline:


Open the settings of the Classification by selecting the classification and clicking the Settings Settings button. In the Components filter parameters table, you see that all components are to be classified.  In the Default Classification Names, you see a listing of various disciplines.  You can add to or remove these depending on your own requirements.  Show Unclassified is marked to make it easy to see if any components in the model haven’t been classified to a discipline.


Click the Classification Rules tab to view how the file name is used to map to a specific discipline.  Every component has a Model parameter in the Identification property group, which is the short name and file name of the model that component resides in. For example, if “ELEC” appears anywhere in the file name, the components in the model are mapped to Electrical. This is achieved using “*ELEC*” to match the value of the Model parameter. If you specify the discipline in the file naming using a single character separated by underscores (_) or dashes (-), such as in the name “01_A_RME_Advanced_Sample_Project,” those components are classified as Architectural using “*_A_*” to match the value of the Model parameter. Lastly, you can specify the discipline in the file name using a single character at the beginning of the file name preceding a dash or underscore. However, since the short name of a file precedes the file name in the Model parameter, “(*) P-*” is used to match the value “(P) P-rme_advanced_sample_project” to Plumbing.

Depending on your own naming convention and disciplines, you can modify the values in the Model column to match your file names accordingly.


In the Checking view, if you select the rule STRUCT vs MECH, the same results are listed for Beams and Columns in the Results view as the out-of-the-box rule “Building Services and Beams and Column” when filtering by selection basket after selecting the HVAC model, seen in the prior screenshot.


Likewise, if you select the rule STRUCT VS ELEC, you’ll see the same results as previously seen in the “Building Services and Beams and Column” after selecting the Electrical model and filtering by the selection basket.


If you open the rule parameters of the STRUCT VS MECH rule, you’ll see that rather than using the Discipline parameter, the “Discipline by File Name” classification is used to filter what components to include.


Creating your own discipline classifications can make it easier when setting up your coordination rules based on disciplines if you have disciplines outside the ones available out of the box in SMC.  Using classification rules, you can automatically map your files based on their filename to those disciplines.



Creating Your Own Custom Disciplines Through Classification

Why Result Counts can vary in the General Intersection Rule

The Results view in Solibri Model Checker (SMC) organizes issue results by category and provides the number of how many results within a category have been handled by approving or rejecting them and the total count of results for that category.  When running a check of the General Intersection rule, the categories of the results are grouped by components, systems, and types.

The following article demonstrates how the results are grouped and also explains why different counts of results are listed depending on what you have specified in the Component 1 vs the Component 2 filter parameters tables.  The model below consists of 3 files: an HVAC, Structural, and Electrical model with general intersection rules checking each model against one another.  You can download this sample model to follow along through the link below:

General Intersection Rule – Comp1 vs Comp2 Tests.smc


In the Checking view, you’ll find that the Structural vs Electrical rule has been run and result counts are listed. For instance, there are 40 unhandled results of Beams intersecting components in the Electrical model.


The Rule Parameters (below) have any component from the Structural model listed in the Component 1 filter parameter table and any component from the Electrical model listed in the Component 2 filter parameter table.


If you select the Electrical vs Structural rule, you’ll find that there are 62 unhandled results listed.


In the Rule parameters, Component 1 and Component 2 were swapped, and any component from the Electrical model is listed in the Component 1 filter parameters table while any component from the Structural model is listed in the Component 2 filter parameters table.

Rest assured that even though the result counts differ, no results were missed in the Structural vs Electrical rule. When you expand the categories of the Intersections of Beam to the first result, you see that three light fixtures (2.108, 2.217, and 2.218) are grouped along with Beam.1.100, which those light fixtures intersect.

This is due to having the Structural model listed as Component 1 in the rule parameters.  In the rule parameters of the general intersection rule, components listed in the Component 2 filter parameter table will be group together under a result with the component from Component 1 that they intersect.


When you expand the results under Intersection of Beams for the Electrical vs Structural rule, you see that there is an individual result for each light fixture that intersects Beam.1.100.

Generally, you find lower result counts and more grouping of components when the components listed in Component 1 are larger than those in Component 2.  Components in Structural models such as beams, columns, and slabs are larger than components in an Electrical model such as light fixtures, electrical panels, and electrical outlets. Therefore, it is more likely that a single component from the Structural will have intersections with multiple components from the Electrical model, which explain why we see 40 results rather than 62.

You may also find a mixture of grouped and ungrouped components. Below is a check of HVAC vs Electrical. Since HVAC components are listed in the Component 1 filter parameter table, each duct and duct fitting intersecting with Cable Carrier 1.15 has its own result.


If you swap the Component 1 and Component 2 filter parameter tables as in the rule parameters of Electrical vs HVAC, then the three results are reduced to one.


However, recall that light fixtures are relatively small in size and duct in the HVAC model is similar geometrically to the beams found in the structural model. Hence, grouping by HVAC components allows for a single result where two light fixtures intersect Duct.1.16.


Therefore, having HVAC components listed in the Component 1 filter parameter table may yield more result counts for intersections of long sections of cable tray, but less for individual light fixtures.


Having a general idea of how results will be grouped depending on what is listed in the Component 1 and Component 2 filter parameter tables can save you time when reviewing results.

Also, you don’t need to check everything in one discipline against everything in another in just one rule.  For instance, you could check only cable trays against everything in your HVAC model in one rule, and then check everything in your HVAC model against everything in the Electrical model, excluding cable trays. As seen in the results above, this will reduce the number of results.

Lastly, there are tips and tricks for coordination and issue management such as right-clicking a component to show all component issues and viewing issues a component has in the Info view.  These topics are discussed in the article Solibri Model Checker (SMC) Workflow Tips & Tricks.


Why Result Counts can vary in the General Intersection Rule

Isolating and Managing Issues Based on their Space in the Model

Solibri Model Checker (SMC) is designed to support a workflow that results in a model (single or federated) that is of the highest possible quality. You must find which co,ordination processes work best and incorporate them into your current workflow.   When considering the most effective and efficient way to identify, group and then manage issue results, one common method is to use issue proximity to a grid location as the main point of focus.

In SMC, you can go beyond the basic XYZ coordinate information and group results by the Space where they are occurring.  Since coordination sessions are usually very focused on specific areas (floors, quadrants or even individual rooms) of the structure, this capability aligns very smoothly with how your project team operates. This unique feature provides the flexibility to isolate any/all issues by their location inside the designed building spaces rather than just finding the approximate location relative to columns and/or grids, or their X/Y/Z coordinates. That is both tedious and time consuming.

*This article assumes a general knowledge of how to run checks for issues in SMC, and will begin with a check having already been run.  For more information about how to run a check in SMC, please follow this link to a related article on our WordPress site:


Start by running a check in Solibri Model Checker.  Once the results have been generated, hide everything in the model in the 3D view.


Then, select the Show/Hide Space option to show only the spaces.


Right click while hovering your mouse over any space.  Select the ‘sectioning’ option, then choose “Section Box Around Space.”


You will now see only the chosen space.   Move to the ‘Results’ window, and change filtering from ‘No Filtering’ to ‘Filter with Sections.’


Now, as Checking Results are reviewed, only issues relating to, or within that space will be displayed.  You can quickly assess the situation in particular rooms (such as electrical or utility rooms, or laboratories) without having to review or sift through other less relevant results.   The issues for a specific space can be reviewed and then reported as a group, before other areas of the building are dealt with in broader coordination sessions.


Isolating and Managing Issues Based on their Space in the Model