Dynamo scripts are taking so long to run in our use cases. where it is geometry intense and big areas.
1.Is there any way to reduce the run time?(referred to previous posts)
2. Does any hardware update affect the runtime ? or any best hardware setup for intense geometrical task setups?
3.Does Revit has any limitation in handling this or any limitations of Revit affect the dynamo runtime?
Kindly, suggest me best practice to increase runtime and best hardware setup to use to get the maximum out of dynamo?
Don’t go back to the well often - gather once and filter out from there
One node with proper lacing and list levels will out-perform many nodes doing the same thing
Reduce geometry to only what you need and use simpler geometry types whenever possible
Utilize topology nodes to decrease runtime by reducing leveling
Utilize a single custom node in place of strings of nodes with large data sets
Utilize function passing and In-Line statements in Design Script to reduce memory consumption
Ensure Element Binding isn’t slowing you down
Move to Python/C# for complex custom manipulations that will be repeated on other projects or on workflows intended to scale.
Break down your collection to smaller chunks of elements rather than doing everything in one run
Remove the ‘wait’ from the equation and let the compute happen while you do something else: hit run from a 2nd PC that’s sitting idle, before going for lunch/fika/coffee, or let it go overnight.
If you give some insights into what you’re doing I might be able to get more specific, but it’s hard to fix a car that isn’t driven into the shop.
@jacob.small. To be Straight with what i need to know is I am working on solar projects automation, where the scale of the plot will be in huge km2. in that populating the panels and running some intersections and optimizations logics taking so much time and wanted to know if any way to increase the performance.
Im not sure there is much more tou can do but, if your issue is related to graph optimization and testing then the following is what i do.
Take your model and or dataset, copy it.
Delete nearly all of it, leave an amount reasonable to make yours tests, where there isnt too much content but there is enough to ensure your graph is working as intended.
When testing…element binding is your friend so run the graph on your reduced dataset, save the graph and continue testing at much faster speeds.
Then… when your ready for the whopper, go have lunch
So you’re creating and manipulating the panel once, and transforming it many times using coordinate systems, and not creating and manipulating many panels, right?
Keep in mind what we do in Dynamo ought to be an abstraction, while the final geometry is creating in another tool using family instances or blocks (I recommend blocks here as C3D is better with site work).
you need to start doing intersect test by fast filtering method first (boundingbox intersect test), rather than geometry test for each elements.
Group them, and do individual intersect test on each group
Shouldn’t need much in terms of intersection tests; trim your array property and you’ll have a hard time finding any which fit outside the extents, and that is a secondary optimization which happens after the initial layout.
@jacob.small what I do is to check for intersection i am creating polygon with the basepoints where the logic generates and check for intersection with that rectangle and finally after all the calculations with the final basepoints, family instance by point we use.
I used tune up to check for the maximum run time of nodes it is mostly with intersection nodes and curve. Split by points nodes. Is there any way that can be eliminated. I compiled all the obstruction into a single solid so that runtime improved drastically. now wanna check is there any other thing which I have to concentrate.
@pyXam for testing i use very small data so that is for now giving good results.
I have other graphs also where there are performance issues and Generative Design graphs where output is not showing accurately. @jacob.small need your support on that too. is there any way where i can connect with you and share the graph privately, since so much privacy is involved in our company policies with data sharing here, I need to take it that way is it possible??
Also I noticed dynamo performance is extremely dependant on your CPU single core power. It maxes out my i9s one core to 100% and leaves the rest at near 0%. Since revit doesn’t have multithreading support I’d say the best hardware solution is a CPU that excels at single core performance.
Sadly I can’t provide direct 1:1 support for a few reasons. Firstly my day job is to help customers who pay for what you’re asking and others getting that for free isn’t really fair to them or my employer, as such everything I do is ‘entirely open’ to allow others to learn from it. Secondly there is one of me, and about 1000 unique users a week - those sort of numbers don’t scale well.
I have worked with companies on with this specific task before. The biggest issue in terms of fit evaluation is pretty straightforward - there are a lot of fit tests to run. The solution is to limit the number of tests which you run; N tests will take longer than N/M tests, where M is the number of rows * 2.
Define the rows by trimming lines to the limits of the site. The angle and start point of the line array are your variables for generative design.
Place coordinate systems along the rows for each panel array
Transform the panel array by each coordinate system to place them all on site. Be sure to only place the panels from the origin into one quadrant.
Stuff at the center can’t spill past the boundaries so you don’t have to test them. In fact any panel with a panel closer to the edge than it is can’t spill past the boundary. As such only the first and last panel in each row/column can intersect with the extents of the site, and the first (or last row depending on which quadrant you used) won’t have issues with spilling out of the boundaries as the panels are entirely in the other direction.
Instead or testing the panels of concern against the site by polygon point containment or direct intersection, offset the site slightly outwards - say 1/100 of a meter - and test the panels of concern for intersection with that using a Geometry.DoesIntersect node. If they touch, they may not fit - too close for my own comfort anyway - and so you exclude them. If they don’t touch join them with the list of all the other panels and move to the next part of the process.
Reducing the number of coordinate systems placed can also help. If you have say a standard panel array of 2x12 panels which make up the larger field, instead of placing 24 coordinate systems, place one for that full set at interior panel conditions. This can be expanded further to reduce design - if a subfield consists of eight 2x12 arrays and a substation why not place that as a unit when you’re in the middle of the field rather than 8 or 192 coordinate systems? You already know the angle and location (or you can calculate it anyway) and that all panels N units away from the perimeter will fit…
Similar reductions ought to be applied in the context of analysis; I don’t recommend running any ‘solar hours’ calculations, instead build a gradient map showing maximum (1) to minimum (0.5) and below solar exposure, extract a few exposure bands, and extract the parameters of the rows where things depart each band. This won’t be an accurate value, but it will work for ensuring maximum exposure so that you can move onto doing the real calculations.
so run the graph on your reduced dataset, save the graph and continue testing at much faster speeds.