If you move a wall, and that wall has features (e.g. openings), it's
desirable to also move those openings (because they are invisible). This
is a special exception to `should_transform_children` because the
definition of the feature (opening) is inherently tied to the parent
(wall).
What wasn't considered is that this would typically then also move
subchildren of the features (e.g. fills like doors). I'm surprised
nobody caught this earlier.
I did also consider another approach where if you move a wall, it moves
all unfilled openings, and if you move a door which fills a opening, it
moves the opening too. Intuitively it sounds nice, but it doesn't work
because:
- Openings can have multiple fillings. If you move all fillings, they
all fight to move the openings.
- All logic about children goes one way: a placement may have child
placements relative to it. This breaks the convention (if moving a door
instead moves its opening) which can make brains explode.
- It starts to conflate rules about relative / referenced placements
with spatial decomposition. We assume all IFCs are valid and follows the
convention of relative placement but we cannot guarantee this. This also
leads to brain explosion.
E.g. in #5890 pset was shared by 2 elements and they it worked is
1) it appended first element and it's rel to pset
2) it appended second element and skipped updating it's rel as it was appended before. Now it's going to update it to ensure it encludes second element too.
I believe, issue occurred after 8c28f52 when we stopped duplicating inverses and started to reuse them.
Full error traceback:
Error: Python: Traceback (most recent call last):
File "\ifcopenshell\entity_instance.py", line 361, in __setitem__
self.method_list[idx](self.wrapped_data, idx, entity_instance.unwrap_value(value))
File "\ifcopenshell\ifcopenshell_wrapper.py", line 9271, in setArgumentAsInt
return _ifcopenshell_wrapper.entity_instance_setArgumentAsInt(self, i, v)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: in method 'entity_instance_setArgumentAsInt', argument 3 of type 'int'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "\bonsai\bim\ifc.py", line 443, in execute_ifc_operator
result = getattr(operator, "_execute")(context)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "\bonsai\bim\module\pset\operator.py", line 142, in _execute
ifcopenshell.api.run(
File "\ifcopenshell\api\__init__.py", line 92, in run
return usecase_function(ifc_file, should_run_listeners=should_run_listeners, **settings)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "\ifcopenshell\api\__init__.py", line 258, in wrapper
raise e
File "\ifcopenshell\api\__init__.py", line 252, in wrapper
result = usecase(*args, **settings)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "\ifcopenshell\api\pset\edit_qto.py", line 135, in edit_qto
return usecase.execute()
^^^^^^^^^^^^^^^^^
File "\ifcopenshell\api\pset\edit_qto.py", line 149, in execute
self.update_existing_properties()
File "\ifcopenshell\api\pset\edit_qto.py", line 166, in update_existing_properties
self.update_existing_property(prop)
File "\ifcopenshell\api\pset\edit_qto.py", line 180, in update_existing_property
prop[3] = float(value)
~~~~^^^
File "\ifcopenshell\entity_instance.py", line 363, in __setitem__
raise TypeError(
TypeError: attribute 'CountValue' for entity 'IFC4X3_ADD2.IfcQuantityCount' is expecting value of type 'INT', got 'float'.
tuple(resource) was resulting in (GlobalId, OwnerHistory, Name, ...) instead of (resource,), so the check never passed and orphaned IfcRelAssignsToResource was never removed.
That way all assigned resources will be added as cost values to cost items and it will be more apparent what resources were used for the last calculation and what costs/quantities they had at the time.
Traceback
```
Error: Python: Traceback (most recent call last):
File "\bonsai\bim\ifc.py", line 443, in execute_ifc_operator
result = getattr(operator, "_execute")(context)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "\bonsai\bim\module\pset\operator.py", line 126, in _execute
ifcopenshell.api.run(
File "\ifcopenshell\api\__init__.py", line 92, in run
return usecase_function(ifc_file, should_run_listeners=should_run_listeners, **settings)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "\ifcopenshell\api\__init__.py", line 252, in wrapper
result = usecase(*args, **settings)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "\ifcopenshell\api\pset\edit_pset.py", line 166, in edit_pset
return usecase.execute()
^^^^^^^^^^^^^^^^^
File "\ifcopenshell\api\pset\edit_pset.py", line 176, in execute
existing_props = self.update_existing_properties()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "\ifcopenshell\api\pset\edit_pset.py", line 225, in update_existing_properties
prop = self.update_existing_prop_enum(prop)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "\ifcopenshell\api\pset\edit_pset.py", line 251, in update_existing_prop_enum
primary_measure_type = prop.EnumerationReference.EnumerationValues[
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'EnumerationValues'
```
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
Bruno Perdigão