Executing One Branch At A Time

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.
Revit_2022-03-30_11-54-03

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:

  1. 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.
  2. 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.
30 Likes

This is pretty cool @Nick_Boyts :smiley: What practical uses do you see for this kind of approach?

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.

3 Likes

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.

3 Likes

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.

2 Likes

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

this is now super out of date- but one use for this is building a state machine:

3 Likes

This should work with Civil 3d

Code:

# 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
6 Likes

Awesome :sunglasses: @Brendan_Cassidy great job, I really appreciate the info
Thanks a lot

1 Like

@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.

1 Like

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.

1 Like

I’ve never had issues with frozen nodes in Dynamo Player. I just checked in 2019 to confirm and had no issues.

1 Like

This is patched as of 2021. I did a quick test and 2020 and older still execute frozen nodes.

made a quick vidya if that is of interest.

2 Likes

Interesting. Does this only affect Revit nodes? I only tested with a UI node and it did not execute in Player.

1 Like

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 :scream:.

1 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.

3 Likes

I think you are on to something there. Since 2.x was the JSON switch, I bet that was a regression

3 Likes

Thank you for the video :heart:
I am really looking forward to our switch from 2019 to the 2021 version at work. :roll_eyes:

@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. :slight_smile:
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 :man_facepalming: and I am afraid of the day where we will switch :sweat_smile:
[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?

1 Like