General Discussion

I completely agree, most of the time it’s bothering the data… would be nice to be able to toggle it off in the ITO column (and to define default preference in user settings)

@Solibrians
Is there any workaround for this problem?

@john-lipp thank you for helping me out. 😊

This solution is working fine for this situation, altough it is a bit difficult for me to understand the exact behaviour of this complex rule nr. 231, but it is a verry powerful one and I think I will use for other complex checkings also.
Also thank you for the nice tip for manual checking results, wich gives a more user friendly description to the issue.
Have a great day!
🖖

@Patric

If the components to check filters of your rules have an includes row that specifies their discipline:
fed9dae1-27b0-49eb-9e9a-49222842b3e6-image.png

Then those disciplines should be listed as tasks that can be added when you select the ruleset in the ruleset manager:

b41f5746-fd94-4c10-9a1e-278b5f3f4310-image.png

Instead of tasks, another alternative could be to use the manual rule to check all models that their disciplines are correctly set:
https://help.solibri.com/hc/en-us/articles/1500004610841-232-Manual-Checking-Rule

@john-lipp said in Nested Gatekeeper SOL222/226 not working properly?:

Is the Comparison Between Properties rule not able to be used as the parent gatekeeper with the “Referencing” relation to pass specific doors that have a backward reference to the Specific spaces?

Thanks for replying John, some time has already passed so I will try to quickly dive in and explain the problem again.

As I already wrote very briefly in my intro statement the checking constraints are the following:

I want to check if all the doors of a space which is next to a specific space (name) should have a certain fire rating.

I have now attached a quick sketch to illustrate the issue a bit better.

Context: I have multiple Spaces “A” but only the the doors of the "A Spaces which are also located next to a Space X (has nothing to do with orbital rocket launches or satellites 😉 must fulfil a higher critera - so just the two blue rectancles marked in blue in this case should be checked.

8404fdab-162c-4c8d-b11b-e45ab37c4ee2-grafik.png

So checking the door between the A and X is easy, but the other one(s) of A which don’t have any connection with X are tricky.
So this use case is one step more complex and afaik #231 won’t help me here much either as the relationship is Doors > Space A <> Space X which won’t give me the desired results as elaborated in detail above.

Probably there is another way to do or it’s possible with the existing rules but it seems indeed like rocket science as long as relationships are not available in classifications and the gatekeepers are always all dependent 😉

@john-lipp said in Rule SOL/226/3.1 and Spaces:

@BIM1337

Does Component Distance work to check a door within 1mm of a Space? This will allow you to control the allowed distance to be considered (rather than relying on the nearest space algorithm).

Solibri Building - Doors with 2 Spaces.smc

Already tried this, it’s like I said in the earlier post. It’ll also give results with spaces next to it if that’s closer than the space in front or behind the door.

So that’s not giving the desired results.

hi @pedro

The paint tool requires a license of site or office.

With Anywhere, you are limited to only changing colors of components based on their component type, type name, or system in the File > Settings > Discipline and Color Map settings.

@Matti-Kannala

Have you heard anything from those Trimble guys when they are going to deliver their new BCF implementation?

I should have asked in their forum, but seems there are already a lot of users over there asking about BCF but never got any meaningful responses.

Due to the fact that this thread is in my opinion already rather good summing up the shortcomings of the various property checking rules I will add another point here to keep the fragmentation of topics limited - but at the same time I will add another topc in the feature request section.
See here: https://society.solibri.com/topic/1902/a-flawless-property-checking-rule-with-a-full-configurable-import?_=1654094250323

The property requirements are given in tables based on the IFC Entity (+ Predefined Type) - so to keep it short, the result is that the the requirement list is differentiating elements way more precise than the Solibri component mapping does. Moreover sometimes it’s even necessary to use classifications to seperate and group elements even further (or to fix technical export issues of specific software).

So ideally we can simply use the excel import feature and load a long requirement list and check (at least categories) in a bunch.
Unfortunately this is not working out at the moment as this is not supported due to the simply fact that the column “Components” cannot be modified into e.g. a Classification name.

#9
d453a87f-4298-4c9f-892c-28d55d5ca2f0-grafik.png

#203
09b16031-205d-4559-a3d1-59bbd4196d06-grafik.png

#230
292cf8e5-9e93-4840-8c10-0ff3301df17d-grafik.png

Example: I have a list of parameters for various MEP classification categories (more than 100) and I currently see now way of importing them in just a hand full of rules without having to find out the greatest common denominator of each property first and find out the corresponding filters in laberous working steps before.

So I would have to create at least >100 rules for each category where I can load the applicable properties (0 to 20) simply because it’s not possible to change the component columns. “Any” can’t be used here because obviously not all properties have to be checked for every category. 😰

Edit: To illustrate my destiny: Instead of five rules I have to create more about 300 even when I am using the combined excel import.
3bdbaa50-4098-4f03-8ca1-e815c9d2db75-grafik.png

(I guess in the future there is also the chance to speed this up using the xml data of the csetx, but for now I am doomed …)

@Zeraxel

It appears the intention of the severity is to aid in handling issue creation rather than as a mechanism of reporting. In other words, as you manually create slides from results, you can focus on high severity results first by unmarking the others in the checking view. There is a priority field for results which serves the function that you can create your own names (“P1”, “High Severity”, etc). Alternatively, you could create a label.

If you mark a result as accepted or rejected, it can no longer be filtered in the checking view by the severity (unless you set it back to unhandled).

I do see the benefit of an enhancement to map severity to a label or priority field automatically either through a setting or perhaps through autorun etc.

I would suggest posting a recommendation on the https://society.solibri.com/category/18/feature-requests page and hopefully others can up-vote and comment on the functionality.

Dear @lasse-lindqvist ,

Unfortunately we’ve got another Java update and all Solibri settings are gone again. Do you have any suggestions how to fix this? Or any ideas how to save all Solibri settings to a seperate file and restore them easily. Setting up Solibri again takes quite some time.

e7b97680-36c1-4c56-af19-8429df145888-image.png

Don’t have any major issues on macOS. But when trying an autorun configuration, we experienced the problem that paths are os-specific, so my test configuration didn’t work for a colleague running on Windows.

@sander-Eikelboom

IfcAnnotations are not supported in Solibri.

I added the information regarding this society post to the existing enhancement requests in this regard.

@Ilona-C-T

I had a deeper dive into the calculation of the door height.

The equation is : Clear Height = Quantities.Height - Frame Thickness - Threshold Height.

If you didn’t specify a frame thickness or it is zero in the parameters, Solibri will look for the IfcDoorLiningProperties.LiningThickness of the door component itself as a Frame Thickness to subtract.

So the problem can arise if your IfcDoorLiningProperties.LiningThickness is wrong. Take for instance the Solibri Building example model with the required clear height set to 3m so every door fails and the door dimension parameters are all set to zero so LiningThickness will be used:
29e2e3c9-d7c6-4a45-b538-de5d9b184249-image.png

This first result is correctly finding the clear height based on the door lining accurately being reported as 32mm:
651949ad-10cb-4d1b-b27f-cf49c42cf91e-image.png

Looking at the lining property it is accurate, and 2100mm - 32mm = 2068mm:
03c96a59-b1c7-4742-b7a6-8434dcb4b207-image.png

Now look at this misreported clear height that is stated as 2.118m, where when measured it is seen to be 2.068.
22b1adf4-edc5-4f05-b04d-9be08d0eb1af-image.png

If you again look at the lining thickness, it was incorrectly set as 32mm, when in reality it was supposed to be 82mm:
d5fddf69-bd18-40e1-a5a1-025975fc3b7a-image.png
2150mm - 32mm = 2.118m as incorrectly reported.

Before running the check, I’d suggest a quick manual check of your lining thickness and other dimensions if you are using them in the parameters of the rule through by using an ITO: adf532e6-2109-4ec7-b5aa-e83d08976a76-image.png

I had a simalar issue.
The support in my case say that only the left side of Some rulesets react with the Gatekeeper.
It would be great to have a list of the rulesets witch only reacts with de lefrt columns

Is the Property Set correct?
The value conditions is searching for text?
Try this, it’ll search for any value. If it’s empty or the parameter doesn’t exist you’ll get a result.
0eba0d4b-49ad-4d3e-83ef-a3f2c94010a7-image.png

Good afternoon to everyone!
I’m also interested.
Thanks in advance!
kind regards,
Xavier Coll
EiPM

@Anees-Alomar , I’ve experienced this when a part of the model (or even every element) is on the “site” level. The IFC Entity of these elements is IfcSite in my case. These elements are only displayed with the Show all button.

Thanks a lot for your support @john-lipp !
I will check your solution using Solibri Api.

Thanks and kind regards!
Xavier Coll