Slave Graphs

Unlike master graphs, slave graphs can vary significantly from each other since they contain the logic of what Dynamo is actually supposed to do with the Revit model. On an abstract level, slave graphs should always share two characteristics: all of them will

1. process the model in some way and
2. report back on their activities.

Processing the Model

When building the model processing part of slave graphs, there is only one thing you need to do differently as compared to a graph that processes a single model: avoid being model-specific. Do not use any nodes that identify specific elements in the model like the following from the Revit > Selection category:

• Family Types
• Floor Types
• Levels
• Select Divided Surface Families
• Select Edge
• Select Face
• Select Faces
• Select Model Element
• Select Model Elements
• Select Point on Face
• Select UV on Face
• Structural Column Types
• Structural Framing Types
• Views
• Wall Types

Element IDs in different models are likely to vary, even for family types under most circumstances – so the above methods cannot be considered safe. Instead, try identifying specific elements by their attributes (e.g. category, family name, type name, host level name, parameter value etc.). General collectors like All Elements of Category and All Elements of Type are safe but should be tested when switching to a newer Revit version.

Generating Reports

In theory it is completely optional to create a report of the activities of your slave graph. But since the Dynamo addin is run headless during a batch process, this is the only way of monitoring what the graph is actually doing. And in those cases where the slave graph is used to extract information from the model, a report is usually the desired delivery method. Reports can be generated and stored in a number of ways:

• Per-model report: Generate a separate report for each processed model. This approach may make sense if the reports have to be distributed to various stakeholders.
• Aggregated report: Accumulate all results in a single file (e.g. CSV or Excel). This approach may make sense if the results are to be post-processed in some way or are to be reviewed by a single person or party.
• Database storage: This is more or less just a (slightly more professional) variation of the aggregated report.

The samples contain examples for the first two methods. For storing reports in a database, use package Slingshot.