I was recently inspired by @john_pierson’s clever counter hack to dig a little more into the available Dynamo API. It only took me a few minutes of considering the information available in the workspace before I questioned whether or not I’d be able to manipulate individual graph branches via freezing and unfreezing specific nodes.
Turns out… it IS possible!
All you need is a condition (or conditions) to determine which branch(es) to run and a named node at the head of each branch to control freezing and unfreezing.
Example Code
# let's see if we can break some stuff
#import standard python libraries
import clr
#reference loaded dynamo revit module
clr.AddReference('DynamoRevitDS')
import Dynamo
#reference dynamo core to update node values
clr.AddReference('DynamoCore')
#access to the current Dynamo instance and workspace
dynamoRevit = Dynamo.Applications.DynamoRevit()
currentWorkspace = dynamoRevit.RevitDynamoModel.CurrentWorkspace
branch1 = None
branch2 = None
#find the branch nodes
for i in currentWorkspace.Nodes:
if i.Name.Equals("Branch 1"):
branch1 = i
elif i.Name.Equals("Branch 2"):
branch2 = i
#freeze/unfreeze branch nodes
if IN[0]:
branch1.IsFrozen = False
branch2.IsFrozen = True
out = "Running Branch 1."
else:
branch1.IsFrozen = True
branch2.IsFrozen = False
out = "Running Branch 2."
#return confirmation
OUT = out
A few comments/disclaimers so far:
This workflow shouldn’t replace the need for understanding how to optimize your graph. A lot of the questions we see around needing to split a graph or run only one “branch at a time” are due to lack of understanding how to better structure and manage your data.
There’s a little bit of an “element binding” issue when committing to Revit multiple times without closing the graph. Since the graph is actually running two separate branches (and therefore likely writing to Revit from two separate nodes) switching between branches doesn’t re-execute the nodes and update the element binding. It just freezes the creation of one output and unfreezes the other. There is no binding between branch executions. This should be remedied by using Player or just closing the graph.
That’s honestly difficult to say at this point. As I mentioned in the first disclaimer, most requests for this sort of functionality are coming from a place of misunderstanding rather than genuine need. That’s not to say there aren’t some scenarios where you might run a specific branch over another, but usually these situations can be fixed with better data manipulation.
I guess it could work kind of like the ScopeIf node but in the graph environment rather than the custom node environment. It could also be used to “manually” stop unwanted warnings from expected empty lists or nulls by preventing those portions of the graph from running under those conditions. I’m actually curious to see what other real world use cases people can find.
This is pretty slick!
Does it freeze the branch realtime, as in if there weren’t any results yet it will freeze it during execution? I could see the “linear” nature of a graph not taking very kindly to that. Also, assuming things like “preview” are properties as well, could be neat if results over 10k and preview is turned off or something like that.
It should be the same as any other node executing in the branch. The python code is when/where the freezing occurs. In my example above, the python node is detached from the branches, so theoretically it could finish running both branches before freezing anything since their executions are independent. In a real scenario you’d probably have the python node connected to the branches to prevent that from happening.
They are but I haven’t done anything with them yet. I had the same thought though. That you could force previews for certain outputs or conditions. That might be the next thing I try, but it should be the exact same process.
Hi @Nick_Boyts, this is an interesting workflow control for dynamo in Revit, great job, do you know where I can find information about the Dynamo API but for Civil 3D to test and apply this?
I haven’t had luck finding information online, I think the name of the assemblies and the methods to get into the current Dynamo document are different
Thanks
@luis.colina5BTB8 I don’t unfortunately. I used the code from John Pierson as my starting point and pulled the rest together after scanning the NodeViewModel here. There are also instructions on how to clone the DynamoRevit repo so I presume you could do the same thing (if you’d be more comfortable doing it that way) with C3D if you can find the repo for it.
Thanks @Nick_Boyts for your quick response, I’m going to try what you told me to find another way to reproduce the code and if I find anything I’ll let you know, again thanks a lot
# Original Revit version by Nick Boyts
# https://forum.dynamobim.com/t/executing-one-branch-at-a-time/74991
# Code has been updated/modified by Brendan Cassidy(@brencass86) to work with Civil 3d
import clr
clr.AddReference('AcDynamo')
import Autodesk.AutoCAD.DynamoApp.AcDynamoModel
#access to the current Dynamo instance and workspace
dynamoCivil = Autodesk.AutoCAD.DynamoApp.AcDynamoRuntime.DynamoModel
currentWorkspace = dynamoCivil.CurrentWorkspace
branch1 = None
branch2 = None
#find the branch nodes
for i in currentWorkspace.Nodes:
if i.Name.Equals("Branch 1"):
branch1 = i
elif i.Name.Equals("Branch 2"):
branch2 = i
#freeze/unfreeze branch nodes
if IN[0]:
branch1.IsFrozen = False
branch2.IsFrozen = True
out = "Running Branch 1."
else:
branch1.IsFrozen = True
branch2.IsFrozen = False
out = "Running Branch 2."
#return confirmation
OUT = out
@Nick_Boyts and @solamour and @jacob.small :
Does somebody know when the Dynamo-Player will not execute frozen nodes? I am currently using Revit 2019 by the way.
As far as I am aware, if frozen, nodes will not execute in Dynamo Player.
That said I don’t know if this method would work in Dynamo Player, as many parts of the application load differently in the player environment. Do you get odd results in 2019?
In-related note: 2019 is officially unsupported as of a few days back when Revit 2023 launched. Best to upgrade those projects so that if your RVT files go corrupt my colleagues in support can help you get back up and running.
I am really not too sure. We found out about it at the BILT hackathon in 2019. We were reading .dyns as JSON and rewriting the graphs to disk (with a description indicating what the graph might do using prediction based on the nodes within the graph). It tossed out all frozen node formatting and we were like .
That is strange. I still wasn’t able to reproduce the issue with Revit nodes, but my 2019 is still running 1.3 so maybe it was only an issue with earlier versions of 2.X.
Thank you for the video
I am really looking forward to our switch from 2019 to the 2021 version at work.
@jacob.small
I would like to use the new version but our group leader wants to stick to this version for a while until we switch to 2021. She doesn’t want to use the current versions as our company creates templates only for every 2nd version of revit and that takes a while. But I am glad that this issue won’t be a problem then anymore.
Regarding your offer for support: Our dynamo-scripts are all still based on Revit 2019 and I will maybe come back to your offer if our scripts won’t run anymore. We do not use any packages and rather rebuild nodes on our own with python-nodes using the api and I am afraid of the day where we will switch
[Edit]: @john_pierson I just saw your video on the new features in Dynamo for Revit 2023 and now I am even more afraid of the switch as we use quite a lot python-nodes. Is there a easy way to migrate the old python-node-codes to CPython 3? I know we can still simply use IronPython 2.7 in Revit 2023 but I think there will be an expiry date?
What practical uses do you see for this kind of approach?
.
and I am afraid of the day where we will switch 