Hi all,
After using the separate plenums command which it can sometimes lead to the error Duplicate Room2D Identifier. Before separating plenums, I made sure to have valid model and apparent zero gaps with a 0.01 ft tolerance. I am guessing that after generating the plenums, the plenum inherits the same ID from the original space. I cant seem to find a way to edit the ID manually.
I was only able to recreate the bug twice. What was also strange it does not happen every time. If I back track and try again with the same spaces in the same snapshot it sometimes will have zero errors
Towards the end of the log, I started getting the 2D error again, and I would undo the separate plenum and try again. When undoing and retrying the command on the same space it would work and sometimes it did not. At the end of the log the model would fail to validate even after undoing the changes.
Thanks for the logs. There are a couple of interesting errors in your log file that are not related to plenums at all but they are likely bugs or at least things that we should be handling more gracefully.
For example, it looks like you are trying to join some rooms together here and this fails:
2025.02.03 14:23:37.193|info|đ Join rooms script is running...
2025.02.03 14:23:37.291|error|join_rooms failed. Error message: Error: Traceback (most recent call last):
File "/lib/python311.zip/_pyodide/_base.py", line 573, in eval_code_async
await CodeRunner(
File "/lib/python311.zip/_pyodide/_base.py", line 393, in run_async
coroutine = eval(self.code, globals, locals)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "<exec>", line 28, in <module>
File "/home/pyodide/dragonfly/room2d.py", line 3774, in join_room_2ds
h_bnds = Room2D.grouped_horizontal_boundary(room_2ds, min_separation, tolerance)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/pyodide/dragonfly/room2d.py", line 4098, in grouped_horizontal_boundary
closed_polys = Polygon2D.gap_crossing_boundary(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/pyodide/ladybug_geometry/geometry2d/polygon.py", line 2129, in gap_crossing_boundary
ext_bounds = Polyline2D.join_segments(all_segs, tolerance)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/pyodide/ladybug_geometry/geometry2d/polyline.py", line 365, in join_segments
grouped_verts = _group_vertices(segments, tolerance)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/pyodide/ladybug_geometry/_polyline.py", line 18, in _group_vertices
base_seg = segments[0]
~~~~~~~~^^^
IndexError: list index out of range
From the message, I would infer that this happened because one (or more) of the rooms that you selected was degenerate (with zero volume). If this explanation is correct, then I should add something to scrub out degenerate rooms from the selection before trying to join them. Does this explanation sound right to you given what you remember about this session?
The other interesting error that doesnât seem to have anything to do with the plenums is this one:
2025.02.03 17:35:25.746|info|đ Validate script is running...
2025.02.03 17:35:25.804|error|validate failed. Error message: Error: Traceback (most recent call last):
File "/lib/python311.zip/_pyodide/_base.py", line 573, in eval_code_async
await CodeRunner(
File "/lib/python311.zip/_pyodide/_base.py", line 393, in run_async
coroutine = eval(self.code, globals, locals)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "<exec>", line 13, in <module>
pyodide.ffi.JsException: RuntimeError: memory access out of bounds
2025.02.03 17:35:29.987|info|[Put]: preferences success
2025.02.03 17:35:35.660|info|[Put]: preferences success
2025.02.03 17:35:48.690|info|â Snapshot opened!
2025.02.03 17:35:48.705|info|đ Import script is running...
2025.02.03 17:35:48.828|error|import_file failed. Error message: Error: Traceback (most recent call last):
File "/lib/python311.zip/_pyodide/_base.py", line 573, in eval_code_async
await CodeRunner(
File "/lib/python311.zip/_pyodide/_base.py", line 393, in run_async
coroutine = eval(self.code, globals, locals)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "<exec>", line 18, in <module>
pyodide.ffi.JsException: RuntimeError: memory access out of bounds
I might need @antonellodinunzio to help understand this one since it seems very deep and has something to do with how pyodide is managing memory. Thereâs no chance that you were maxing out your RAM in this session, right?
I would infer that, in your case here, you accidentally created plenums of the same base room twice, resulting in a plenum of a plenum. Both of those two plenums had the same ID so that could give you the validation error. You should be able to get rid of the error by deleting one of the plenums (I think the duplicates should be on the same story on top of one another). Then, you probably have to re-adjust the plenum room floor heights and/or floor-to-ceiling heights to get everything continuous along the vertical dimension again.
This all gives me some confidence that managing plenums through âceiling plenum depthâ and âfloor plenum depthâ properties was the right way to go. As long as you stick to managing plenums that way, you wonât ever accidentally create this situation where you have a plenum of a plenum. And I would say that, until we roll out the new workflow, you should use the âSeparate Plenumsâ command with caution - double checking whether you have already created a plenum before you run it.
Yes I do remember having some odd issues when merging rooms. There were 2 rooms that would not merge and I chalked it up to something that did not export correctly from a Revit space. I just redrew the room and continued on.
Regarding the other interesting error, I did not check to see if my RAM was maxed. I did not see any slow downs either, but I can double check if that is happening.
Back to the ID issue, I will double check but I am 99% sure that plenum being created for is for a single space and was not double cut. @chriswmackey I can send you a copy of my snapshot if I have it happen again.
Hi @srojas92, thank you for sharing the logs. This model seems to be a great one for debugging. It would be great if you could share the snapshot file with us privately so we can ensure we fix these issues so they donât happen in the future. Thank you!
I was very careful this time when selecting spaces and no errors! Ha! Maybe I did double select and did not realize. I will DM the snapshot over, please take a look!
Glad that you were able to get it to work by being careful with the âSeparate Plenumsâ command.
I think I have narrowed down what is likely causing the error you faced when joining rooms together. I have found that I can recreate it whenever I have two rooms that are overlapping in plan on the same story. This overlapping messes up the computation of a boundary around the whole set of rooms to be joined.
I am guessing that you created some of these overlap cases in your model by running the âSeparate Plenumsâ command on the same base room twice, resulting in two duplicated plenum rooms on top of one another in the same plenum Story. Granted, I can think of a lot of other ways that people can create overlapping rooms with the commands of the Model editor and, if I remember correctly, we can sometimes find them in the raw export of Revit.
So, while I know itâs going to make the performance of the âJoin Roomsâ command slower, I think I need to add in a check in it that will boolean union overlapping rooms together before trying to get a boundary around the whole shape. This seems like the only reliable way to avoid this exception and get the command to return a result.
Once that is in place, Iâll try to minimize the potential for creating these overlapping rooms in the first place.
FYI I have fixed the issue that caused the failure with joining rooms:
It seems that the extra step of just boolean unioning any overlapping rooms before we figure out the boundary around the shape is all it took.
I am going to reassign this issue to @antonellodinunzio so he can share thoughts on what the error related to the memory is. Also, I recreated the issue with the duplicate plenum identifiers and I think itâs also likely something that Antonello might be able to fix but weâll work through it using the model that you shared via PM.