Dynamo <-> Vasari Back and Forth: Workflow Issue

[archinate]

Consider the following workflow...

1. Dynamo is used to generate Reference Curve geometry...
2. Designer uses Dynamo Reference Curves to create a surface using Make Form in Vasari... the surface updates when the Dynamo definition changes.
3. Designer can Reference the Vasari Surface BACK into Dynamo using Select Face... However, when the curves change, the Vasari Surface will change, but the Select Face node will NOT refresh the surface.
   

My question: Why not? :)

[LevL]

Simple answer would be that two branches of the graph are independent, so it is not clear for Dynamo which branch to execute first. But this answer is not the real one. The real answer (in my understanding) to "why not" question needs a little dive into technical issue with update of BIM model. There is no partial model update, as updating model after every node will hit performance and risks intermediate failures for intermediate states. Hence current implementation does model update on commit at the end of the run. Same consideration would be behind my recommendation not to use the geometry of the Revit elements created by graph in the same graph.

[s-overall]

Would it be possible to have a simple component that can somehow break the execution into parts? I did some experimenting with some of the watch nodes and time nodes to see if I could get this to work with boolean expressions that would execute after a delay or after it saw the family update, and I could actually get the surface to update within dynamo. The problem was that I couldn't actually get nodes to operate on the surface after it updated, not to mention that It was very round-about and a bit confusing.

[LevL]

This sounds close to my suggestion to enable graph pages with each page fully updating the model at its end, and to allow outports from previous pages used on current page as well as selection of affected elements. Is this right? That suggestion is still in discussion. Help me out by providing feedback, if you like the idea! I am looking for alternative suggestion too.

[s-overall]

Yeah, that sounds pretty close, like a way to execute multiple definitions in a sequence. When you say graph, do you mean like a user definition/script? I'm just not too familiar with that term in this context.

[LevL]

yes, graph is current one page of connected dynamo nodes. The idea is to allow several pages and interpret end of each page as model updating commit.

[dbaldacchino]

Sounds interesting...are you suggesting something analogous to having worksheets within the same workbook in an Excel document, where you can reference cells between worksheets (and in this case it would be nodes)?

[LevL]

yes, except worksheets are sequenced for execution so results of later worksheets should not be used in earlier ones.

[dbaldacchino]

If that's the case then you'd need to make it clear which direction you're moving. Would you have multiple tabs open at the top similar to workspaces and compute left to right?

[LevL]

I am thinking about this more like pages of the book. Previous/next arrows, range of pages with drop down commands: "goto N", insert page, merge into previous/or next, anything else? Just initial thought, suggestions are welcome!

[Steell]

Either the Select Face node hasn't registered it's selection with Dynamo's model update watcher, or there is a problem with Faces and Revit's Dynamic Model Updater API.

[LevL]

Excellent comment and 100% right. Right now dynamo model updater is supressed during Dynamo run, as otherwise there is risk of deadlock. Say, select face of instance, compute something, set parameter on the instance. Instance is modified, selection is redone, process repeats.

[Steell]

Correct @LevL

To simplify what @archinate is saying:

1. Make some curves in Dynamo
2. Make a Form out of the Curves in Revit
3. Insert form back into Dynamo workflow via Selection node.
4. Modify curves in Dynamo -- Form updates, but execution branch containing Select Face does not re-evaluate.

The reason for this is that Dynamo runs everything inside of one Revit API Transaction. Revit does not report any Element changes until a Transaction has been committed. This means that the steps of Dynamo's evaluation of this workflow is as follows:

1. Start Transaction
2. Evaluate all nodes, including Select Face
3. Commit Transaction
4. Revit reports modified elements
5. Select Face node now knows the Face was modified, but it's too late because Select Face already executed.

To make things even more complicated, Dynamo ignores all changes caused by Dynamo's Transactions in order to prevent infinite evaluation loops. This means that step 5 above isn't true. Dynamo does not report a change in Select Face because Dynamo caused the change.

[LevL]

The proposal is to allow one more update for changes caused by Dynamo's Transactions and ask user to do run again if this is not sufficient.

[riteshchandawar]

Workflow mentioned in this issue worked with Revit. Vasari is already discontinued.

Closing this issue.

Thanks, Ritesh