General Discussion

In this specific case, rather than using the lining, the casing thickness should have been used in the equation.

https://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/TC1/HTML/ifcsharedbldgelements/lexical/ifcdoorliningproperties.htm

However, the casing thickness 50mm is still incorrect and should actually be 77mm:
ab68d749-b56d-4f7c-be73-10c0a9fc8b5a-image.png

As you stated, overriding the complete transparency, you can see its geometry:
9cf00121-417f-478b-8927-0f3cf2cdc907-image.png

So, you are correct, that these doors aren’t modeled correctly and can’t accurately have their accessible width checked based on how the opening was modeled. The opening should have only gone to 1m without that extra portion for the casing that isn’t actually cutting/voiding the wall.

@Ricardo

I reproduced this with the officebuilding.ifc model that comes with Solibri:
3904a78f-c9b7-4516-8504-e98d08171653-image.png

I’ve logged this issue with our R&D to investigate for a fix.

Hi @Victoria-Volina ,

you have two options as far as I know,
first comes with each rule set, some of which give you the ability to categorize the issues.
For example, SOL/230/1.1, if I use GUID as cathegory I would have each component as a single category issue.9ddce14e-5a57-4b80-80c8-25efc625b9e0-image.png

Your second option is using Autorun “maxsnapshotsincategory”, please check out the Autorun Documentation
assuming your ruleset categories are setup the way you want, you can set a high limit to the category to force autorun to generate a presentation slide on each issue.
<autocomment zoom=“TRUE” maxsnapshotsincategory=“1000”/> would probably give you plenty

I would advice you to consider carefully your methodology and how you are communicating issues back to your team. Too many single issues can be overwelhming and can aslo cause you too loose sight of what you are trying to achieve.

Have fun, Cheers

@tonigyllenberg said in BCF Live insights and explanations:

Filtering
Currently, the following issues are known about filtering. Using unsupported filters will result in cancellation of the filter (and all issues to come through).

Bimsync: Filtering Undefined, in addition to other values is not supported (however filtering Undefined values alone is).
Aconex: Currently, filtering is not yet supported.

Hi,
how about the filtering with Dalux? It seems to works sometimes, sometimes not… this is quite annoying. I wish I could filter the list in Solibri.

@Victoria-Volina said in Issues to Takeoff:

But i still can’t take it to Takeoff anyway?

Correct, afaik you can’t utilize the marked information of the Issue tab in an ITO.

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.