Hello
I’m trying to create a list of wall pairs that intersect or are joined
I used List.combinations + Element.GetLocation to check all pairs of existing walls and it works fine
The problem starts when I try to run a script in the model with thousands of walls. Then Revit crashes due to lack of memory
For example, there are 4950 combinations of pairs for 100 walls
Let me know if there is another way to solve this problem
Limit your testing based on bounding boxes, levels, scope boxes, areas of the model, etc.
yes, I know about it and I plan to apply it to smaller groups of walls. however, there is still a lot of walls to be analyzed in each group
I wonder if the use of a python script could reduce memory requirements. I mean importing only the axial lines of the walls to python and find intersections in double loop. The output would be pairs of line indices.
Does it make sense?
-
Jacob is right, make sure you eliminate the walls that have no business being compared to one another before you compare them, biggest memory/power saver.
-
Check out the Bimorph package, those guys nicely documented how much faster/leaner their intersect method nodes are.
I believe the BiMorph method utilizes the RevitAPI’s intersection checker, and as walls automatically ‘self clean’ it may not report back correctly here.
1 Like
Thanks for the reply guys
I checked those Bimorph nodes and for the walls that are joined no intersection is detected,
in addition, the algorithm analyzes the 3D intersections so I work slower than my proposal
Please note that in my example, I analyze only the intersections of lines, which is faster and takes up less memory
Actually, that isn’t the case. Your method takes n database elements and stores that in memory, create n^x permutations and stores those in memory, then pulls the geometry and stores that in memory (geometry being denser data than elements), then transposes that list and stores that in memory, then pulls the first item out of the list and tires that in memory, then pulls the second item in the list and stores that in memory, then attempts to clash each geometry element against the last, and stores either a null or a value in memory… whereas the bimorph node works off the initial element list directly, storing the combined clashes in memory. So from a memory standpoint your method is much more invasive.
From a computational standpoint, every time you have to move from one geometry engine to another you are going to take a hit. This is the other reason the bimorph nodes are so much faster - they only utilize the Revit geometry engine. The hit you take translating from Revit geometry to dynamo geometry is a tough one to overcome.
However, as I noted the Revit geometry engine is pretty slick with how it deals with walls (in this instance). As such the bimorph node won’t work as the geometries no longer intersect. So you’re stuck using Dynamo methods.
I would avoid using the lines as there will be many situations for incorrect results (double height walls, walls with a base offset, etc), and would use element.geometry instead. Also do away with the list.permutations. That’s a VERY memory intensive node and usually gives bad results. Geometry.DistanceTo will work fine in this case if you manage your lists correctly. Doubly so if you remove manage the items as a single line of design script, custom node, or python code.
Lastly, as noted using all elements of category will cause issues with larger data sets. Break it up by floor, area, workset or scope box.
This is also a good use for Dynamo Player, as that disposed of the memory more effectively due to it being a headless version of Dynamo.
1 Like
Thanks for the valuable answer
I feel that apart from optimizing the wall’s list to a smaller one - which I have already done - I can do nothing more
If anyone has any other proposals then I will gladly try
…update
I gave a chance to my idea and it seems promising. I’ve learned a few lines of the python script
For 400 walls list:
- dynamo method - calculation time is 2’20 "
- python script - 0’14"
I omit here the issues You wrote of optimizing the list of walls, their level of insertion, offset, etc. This, in my opinion, is easy to solve
see files
I will be grateful for the commentwall join test end example.rvt (2 MB)
wall end join example.dyn (25.9 KB)