Solibri Model Checker allows arguably the most comprehensive set of Model Validation tools on the market at the moment, and leveraging the intelligence and power of the Industry Foundation Class (IFC) is really giving it’s users the ability to validate almost anything. Whilst reading this blog in no way replaces the need for in depth rules creation training and workshops, it will go about showing and explain how one of the more complicated rule setups work.
The IFC format understands all of the relationship that exist within the model, and Solibri allows users to tap into this to check and even compare property values along a relationship chain.
Let’s set the scene. You have an external wall and would like to check this wall to ensure that it has been given a fire rating. Alongside this, you also want to ensure that any external door or window hosted on this wall also has an adequate fire rating. In essence, this is actually a pretty simple check, one that you could actually perform in less in depth tools like the free Revit Model Checker. However, let’s imagine that actually those doors and windows that are hosted on that wall do not contain the correct IFC properties to identify whether they are externally facing or not (psetwindowcommon.IsExternal=true). This is more common than you would expect, and what this means is we actually have to follow a slightly different method:
- Identify all walls which are external.
- Check the wall’s relationships to find any associated doors.
- Compare the IsExternal status of the wall and compare it to it’s related doors.
- Highlight any doors which are incorrectly identified.
- Check all of their fire ratings against requirements.
- Compare the fire rating of the wall vs the door if necessary.
This means using the complicated compare property values rule inside of Solibri. If you ever looked at, or attempted to use this rule you may already know how easy it is to overthink, or even under think what parameters are needed to get the results you intended. Actually, despite its appearance this rule is relatively straight forward so long as you follow its logic closely.
Let’s cover those first 4 steps now, showing you how to tackle this type of rule inside Solibri.
Preface
Using the filtering tool in Solibri, isolate all of your external walls, note the openings/door locations.
Re-filter the model to show all external doors and windows. Note any potential differences.
What are we doing and why?
In this model, my external curtain wall contains a door which is not defined as external. This is incorrect. I want to be able to automatically validate this moving forwards. We need to identify all external walls, find their connected doors and windows and check their external status flagging any issues. After this, we can then check all of these components for their fire rating. The reason for running the pre check is to ensure that we capture every single component and we don’t miss any and therefore void the Validation.
Ok, back to the steps…
Select an external wall and check its relationships. Find the type of relationship it has to a door and the relationship direction. As a rule of thumb, a parent will be a backwards connection and a child will be a forwards connection. For instance, a wall is hosted on a floor (level) meaning the wall cannot exist without the floor. This means the floor is a backwards relationship. The door is a child of the wall, meaning it cannot exist without it. This makes the door a forwards relationship.
As previously mentioned, in the example I am using a curtain wall that contains 2 doors. The doors and decomposites (individual parts of) the curtain wall as seen to the left.
Now we know where we stand and have noted relevant relationship details, we are ready to head over into the rule set manage to build the rule.
Within the Ruleset Manager, get your workspace linked to the Rulesets that you have open inside of Solibri. Find the “Comparison Between Property Values” rule from your library. Add this into your Workspace.
Highlight the rule to access its properties. Let’s quickly change its name and description to note what the rule will be doing for future reference.
Let’s head over into the parameters. Firstly, we need to ensure we filter to isolate
the external walls we would like to check. If you save the filter created earlier, load it in here.
In the Target Value area, we have to specify which property within
this selection we want to compare. We want to use
Pset_CurtainWallCommon.IsExternal, as this will allow us to compare the external facing status of the components.
We now need to tell Solibri what we would like to compare against
the original component, and in our case we want to make sure the
intelligent IFC relationships between the components to find the
hosted doors. Use the relationship type, and director a noted earlier for this, before filtering for a door component.
We now need to quantify how many instances we want to check,
and naturally the answer here is going to be all of them, or “Each” in Solibri terms. We choose the compared property, namely
Pset_DoorCommon.IsExternal, and look for a match.
Finally, we categorise our results. I will simply go with a by type
categorisation to see all types of failing doors.
Return to Solibri Model Checker, and go ahead and run this rule. In my model, we will see that the failing door has been highlighted. Again, This door is invalid because it is externally facing, hosted on an external wall but with a data model that is stating it is internal (IsExternal = False).
So there you have it. The rule is working, and comparing property values to components relating to the wall. We would then build on this to run a standard model property check against the fire rating values, and if we wanted to, take a copy of the above rule but pointing towards the fire ratings of both the wall and its doors to ensure they are either the same, or as specified.