Sequence of execution

[kehehee1]

Dynamo version

2.0

Operating system

Windows 7

What did you expect to see?

The sequence of execution is random if there are many branches of node to execute. Can I determine it explicitly?

[mjkkirschner]

There used to be a node to do this, but not anymore, not explicitly as easy as you should be able to. @kronz @Racel I think we should solve this problem, potentially as part of a larger epic around imperative/ control flow nodes.

For now what you can do: (related to this post) DynamoDS/Dynamo#7431

• you can use function compose to order execution
• you can pass around a dummy value to custom nodes so they don't execute until the previous function finishes
• you can use python or DesignScript which allow you to express control flow
• you could explore writing a node that runs each of its input branches in order (I think this used to be called Begin)- you could start with the scopeIF source code and extend from there - essentially you need to pass the AST of each branch into the node and then output a new AST that defines an imperative block around all the input AST branches together. - atleast that is how I would start looking at this problem.

[kronz]

@kehehee1 can you say a little more about what you are trying to do? @andydandy74 has a node that is used to control the flow of a graph a little more tightly called Passthrough ("Forces a sequential order of execution. ") It's quite elegant, in that all it does is uses a tiny CodeBlock with:
{passthrough,waitfor}[0];
This means that the first argument will not be passed along until waitfor has been executed.

[kehehee1]

@kronz My situation is similar to DynamoDS/Dynamo#7431. Where can I find the "Passthrough" node you have mentioned and how to use it? I can't find anything about that.

[andydandy74]

@kehehee1 - It's part of package Clockwork.

[Racel]

@mjkkirschner - I agree about imperative/control flow nodes. Let's see what we come up with. Would also be curious to understand what @kehehee1 is trying to do. Might make a good sample case to test any new implementation out against. Any additional samples, @andydandy74 ?

[andydandy74]

@Racel - Not a sample, but a recent use case for my Passthrough node comes to mind. We needed to have a colour-coded volumetric model of rooms but did not want the volumes of room-bounding columns cut out of the room volumes. So first all room-bounding columns had to be set to non-bounding, only after that was done the rooms could be collected to extract the geometry and afterwards the roombounding properties of the columns had to be restored. I've had similar requirements in the past all of which I could solve with the Passthrough node. Basically this node always becomes handy when you need to first perform an action on elements that are not directly needed for the next action but will affect its outcome.

[Racel]

Thanks @andydandy74. That was helpful.

[Racel]

FYI- Added a related task to address this https://jira.autodesk.com/browse/DYN-435
Proposed features:
-- Exposing Force Re-execute
-- Allowing Re-execution of Selection