I will unfortunately not post a screenshot because my script is too complex, so I hope my text is clear.
(If dynamo hadn’t crashed three times on me, I would have provided a simplified script to illustrate what I want to do.)
I am working on a multi-storey building and need to run four scripts per level. The current script can be understood as follows:
Select Level
Open Excel and filter data by level
Perform operations on selected level with excel data
What I would like to do is:
Collect all Levels
Set Start Level
Set End Level
Run script at start level
Loop to next level, until End Level has been reached
Change the way you think about solving these kinds of problems. Looping like this often isn’t necessary in Dynamo.
Instead of figuring out how to make Dynamo “loop” for each instance of a level, you need to figure out how to make Dynamo iterate over a list of levels individually. This is all about list management. If you have 5 levels in a project you really just want Dynamo to get all 5 levels and then do the same thing to each level all at once.
I think I figured out how I can loop in dynamo, but realized it doesn’t work for what I need because of zero touch.
After sleeping on it, I’ve and determined that I can run the script using different methods. This was simply an attempt to run the script as currently built in order to keep the data sets small and not have to re-build the script.
The need to loop still exists. I’ve been working on very large projects, and the datasets I typically work with are running against dynamo’s lack of computing efficiency.
As for looping in dynamo, my workaround is as follows:
Create excel file with a single value (0)
import the excel data, and add one to it for each iteration
export the new value to excel (which re-imports it)
when value exceeds target, write value to new workbook path
The problem is that Dynamo doesn’t loop on execution. If you can do it all within Python you might be ok, but Dynamo executes the entire graph “at once” so you probably wouldn’t be able to read and write back to back to back in one run (I think I’ve tried this already).
If I’m understanding your situation correctly, my suggestion is still valid. You already know the target number of runs so you can just execute them all at once. The size of projects won’t make a difference since it’s you still have to run it on everything in the end. Unless you’re specifically saying that you would run the graph multiple times to avoid maxing out resources. If the goal is to keep count after each manual run so that you know which section of your model to handle then I think you’re on the right track.
I may not be understanding the whole process of what you are trying to do, so forgive if I am rambling. Have you tried taking out the processing part of your graph and making a custom definition/node out of that with an input for your list? Once you do that you can set the lacing to longest and feed your list into it and that should execute for each item in the list. You can probably have a counter that counts the number of levels and use the Range node to sequence out the numbers and feed that into another input in your node as well and use that for the starting row in the spreadsheet. The lacing longest should handle that part also. You will probably have to make sure you don’t set your script to open the spreadsheet after each execution or else it will probably fail for being write protected.
Just a thought.
As I noted earlier, running a loop will not work for the particular script I am running, since it creates new elements and these will get lost with each iteration. (Zero Touch.)
I already set the excel sheet not to open, and it seemed to run just fine. I can’t really say, because once I realized that newly created elements wouldn’t work, I immediately abandoned the idea for the purpose of what was initially intended. (Nothing like having an exciting concept at 10:00 in the evening, only to find that it isn’t that brilliant at 12:30 in the morning.)
In any case, there might be some use for it in the future, as I’ve run into dynamo’s resource-intensive computing limits for large data-sets…especially once I start drilling down into the model, or running nodes which deal with lots of geometry.
Basically, I’ve run into issues in the past where I could only run (for example) 100 items at a time. The method used for this was to have a parameter to filter at the front-end (front-end filter) of the script, run the next 100 items, and set the front-end-filter in order to grab the next 100 items. This worked fine and well, but I had to literally click run 10, 20, 30 times just to get through my list.
Anyways. The “issue” is solved for now…I will have to re-structure my list to filter levels and propogate them through my script. The idea was to keep the existing script as it currently exists, and just filter through the levels, since the original intention was to run the script level-by-level.
If I could do it within python, i most certainly wouldn’t be using dynamo! Well…at least not for this…
Yes, keeping resources available was part of the overall goal. I’m already handling thousands of elements per level. The main issue is that up until now, I’ve been importing / updating elements from a lead-model by level. This makes sense most of the time, but there are instances when I need to import multiple levels at once. (Most times two or three; but sometimes 10, 20, 30+ levels.)
In the past, running large data-sets has run for hours with no result. I can break that script up using filters and sublists, but I still have to manually click through each run of 500 items.
Basically, I want to be able to hit the run-button, go out for lunch, and then have 15000 new elements in the model when i get back.
…and I have to say, I’m always happy to see a response from Nick Boyts!
You’ve helped me solve MANY issues in the past couple of years!
You’re attempting to solve an interesting but complicated problem in trying to work around Dynamo and Revit both being resource hogs. With how Dynamo runs, you can’t really get the entire graph to loop. You could get some of that functionality to loop within Python, but I don’t know if you’d be able to dump memory from Python within a single Dynamo run, and that seems to be what you’re after. You could write to an Excel file to track progress, that’s not a bad idea, but that would require multiple runs. You could potentially look at running your graph in Automatic mode but that’s usually a bad idea.
Unfortunately this is all just an explanation of how I see it and not really helpful in any way. I’d be interested to know what it is you’re trying to do that requires so many elements. Usually these sort of scenarios are a band-aid fix for a poor system, but sometimes that’s all you can do.
This should give you a sense of what I am dealing with.
Dynamo, in a certain sense, is the all-purpose band-aid for Revit functionality.
Based on project size and owner requirements, the number of openings quickly becomes unmanagable without scripting.
I have 5,000+ openings in the first three underground levels alone. Then there is a 60+ storey tower on top of it. At the moment, this is only an additional 6000 openings, but will likely be double that by the end of the project. (If they decide to model openings into the fit-out then this will likely be 3x - 4x the number of openings which need to be managed.)
We are generally planning according to clustered levels, so sometimes I need to import a single level, sometimes I need to import 20 levels at a time.
Not really a poor system…just the nature of high-rise planning.
Anyways, it was just an idea I had to get my script running without actually needing to adjust anything already in-place. The data-matching is pretty intense, and I wanted a solution which would run the working script, as opposed to adjusting it and troubleshooting it. In the end, I came up with a relatively compact and flexible solution which can be run on one level, or up to 20 levels without maxing out my resources. Runs are typically < 5 Minutes.
That’s great. I think a lot of times we (as developers or end users) get used to instantaneous feedback with scripts that run in just a few seconds. So when you say it’ll take 5 minutes to run, they balk at how they now have to sit around and wait for 5 minutes… When really you’re saving them from hours of menial work. Don’t be afraid to write graphs that take a “long” time to run. You’re focusing on the important parts already - it works and it doesn’t crash your resources. I call that a win. Well done.
