(I hope I don't miss anything, no tests seem to fail and performance is increased significantly) but because `subelement_queue` initiated with the `traverse` all `element`'s subelements will be traversed inside `while` loop twice - once as a part of initial queue and another time when `element` is traversed inside the loop and all those elements added to the queue again.
Now we just initiate the `queue` with the `element` and it will be traversed inside the loop like any other element.
1) `do_not_delete` performs best when it's set
2) also_consider when `element` related elements go first, so there will be no need to traverse all other elements to see if they cover `element`'s inverses.
1) replaced walk with traverse(max_levels=1)
2) early return if there total_inverses == 0
3) early return if also_considered_inverses is enough to cover total_inverses
It's a naive implementation and very inefficient. Moreover there may be false positives because it's testing overlapping the evaluated mesh element with all openings applied.
Got report that there was an issue with get_parts not returning all parts if there are multiple IfcRelAggregates involved though it is valid ifc. Fixed the same possible issue for ContainsElements, IsNestedBy
Noticed working on #5596 and #5708 a few issue when pset template is changing the prop types.
E.g. prop had string data type and now template suggests that it should be a float.
Previously, it might error trying to cast a string to a float. Now it will show a float until user will set it to null, then next time it will be loaded from the template data type.
Another example - prop was a string and now it's a boolean. Previously, it would be cast to boolean implicitly. E.g. "test" -> bool("test") -> True. And if user wouldn't be paying attention then enabling pset editing and saving it would make them lose "test" value.
Now - https://imgchest.com/p/na7ke99wb78
Before - https://imgchest.com/p/5xy23rr3z4l
I guess by accident in d443c5e I've made this method too strict and it broke get_references using it for IfcPropertySets. Maybe it's a good idea to make it more strict in the future, for now just restoring the previous behaviour.
In IFC it's possible for a property set to be assigned to multiple elements and which may lead to confusing behaviour when you edit a pset on one element and other element seems to get edited too.
Which makes it worse is that that it is possible that some software is might be doing this unintentionally when exporting IFC (as some sort of optimization as storing 1 is more optimal than n copies of it).
So now there are some tools in Bonsai and in IfcOpenShell to handle the shared psest:
1) Indication that property is shared - https://imgur.com/a/9dd3jST (similar to how Blender indicates ID data-block users). You can click on it to "unshare" the pset - a new copy for the pset will be created and it's going to be linked only to the active object.
2) api pset.unshare_pset method that does the same. And util.element.get_elements_using_pset method that encapsulates schema differences and different approaches for occurrences/types.
3) ifcpatch recipe 'UnsharePsets' that's making all property sets in the IFC file to have just 1 element that's using them. You can limit the affected elements by providing query.
ifcpatch recipe is also available in Bonsai - https://i.imgur.com/aOCx7HI.png
Previously if product had no types it would still run through all element.IsDefinedBy and check if they are IfcRelDefinesByType even if it's not IFC2X3.
Andrej730
