Inventory .dyn scripts

[willem.creffierKCWFB]

H there,

I try to make an inventory of our Dynamo scripts.

To a certain extents it goes easy with a folder structure classifying the ADSK software used and then a certain function.

I import this to power BI.

But I would like to add functionality, add comments with description on how to use the script, have an overview on what are the inputs and the outputs, have a list of OOTB nodes being used, have an overview of custom nodes, auxiliary files etc.

What is a good way to do this, or are there tools for this?
Do I embed all this information in a dedicated node in the .dyn file itself?

Kind regards,

Willem

[Draxl_Andreas]

@willem.creffierKCWFB ,

if it is for the enduser you can migrate your stuff to pyRevit. there you can explane well any function of your node. The user will luckely only see the button. For revisioning you can use GIT.

Thats my ideas.

[Nick_Boyts]

Most of what you’re asking for already exists within the dyn file. You can add descriptions and custom properties through the Graph Properties extension. The node/package information and input/output information is already stored in the dyn itself. You just have to pull that information into your spreadsheet so that it’s accessible to PowerBI or whatever viewer you want to use.

If you open a dyn in something like Notepad++, you can see how Dynamo stores all that information and how you can retrieve it for viewing later. The amount of information you add to the file is the amount of information you can get out of it.

[jacob.small]

@willem.creffierKCWFB

Do I embed all this information in a dedicated node in the .dyn file itself?

I’ll give the direction here which I give to companies daily, but at a higher level - you’ll have to work out the specifics on your own.

Descriptions and basics go in the file itself to help with portability. Fill out the properties for the file as @Nick_Boyts mentioned.

Help docs go on a web portal as you can tie to existing learning portals easier that way and embed stuff like walkthrough videos without bloating the file.

Nodes and packages used in any one dyn file can be mined from the JSON structure of the file itself. This can be done manually as Nick pointed out, but really you should just extract the data computationally by what we JSON parser you like. I would recommend limiting parsing to flagging package dependencies only though. I have had a lot of customers ask about identifying ‘what nodes do we use’ but none have shown business value in having that info yet. Package identification has instant value though.

While you are at it I also recommend adding a logger to each graph to track use (you’re already opening the JSON after all), and even setting the properties. The post here has some useful tools for that: Updating python node in multiple scripts - #15 by jacob.small. It also has tools for bulk updating and swapping nodes which you can use as a POC for your own efforts in this space.

[Nick_Boyts]

By the way, you can do all of this with a Dynamo script.

I initially thought that’s what you were doing, but now I realize that may not be the case. Just wanted to point out that it is an option though, and something I’ve done before myself. You can read the dyn as a JSON and parse your node library with a custom graph. If you want to do something exciting, you can even use the same logic (in reverse) to automate adding certain data back into your nodes.

[john_pierson]

If you want to experiment some…

1. Export nodes from graph to CSV with Graph Node Manager.
   
   
2. Copy the node names into ChatGPT with the prompt:

"Based on the following nodes for Dynamo for Revit: [nodes go here], What does it seem like the purpose of the Dynamo graph is?

3. See results and use those in the workspace properties like @Nick_Boyts said.

ChatGPT - Dynamo Wall Creation Process

[willem.creffierKCWFB]

Hi @Nick_Boyts

I am not sure we talk about the same thing.

In the same way that a Model with many different Families with a lot of Type characteristics is difficult to manage, my Dynamo scripts are difficult to manage too.

They are made to a specific project, and filled with data specific to this project.

So I would like to take a Data-driven process diagram of the design process, as I need it for the EIR & IDS.

With this diagram made specific for a project, I would like to apply the same logic to select & adapt the Dinamo graphs for the Dynamo player.

But first I need to clean op my graphs, make them more universally applicable, and document the process in which they are applied.

I managed to get Author Name, Learn More URL and Description to my report, thank you for pointing out.

My fraind has more difficulties extracting the group names (might be insightful to evaluate the process of a graph) and the extraction of the nodes that function as “input” in Dynamo player.

So if you have a script capable of this, do not hesitate to share.

Whether we will add project-specific metadata to the nodes directly, or feed them trough a preliminary design model…I do not know yet. Several strategies might be useful.

The goal is a model that easily adapts design changes, and good management of redundacy of information.

[Nick_Boyts]

Unfortunately the script I created was a one-off from years ago, before the dyn JSON structure changed, so it wouldn’t be much use now. The good news is that I think the new format is even easier to understand. If you open a dyn in something like Notepad++ like I suggest, you should be able to see how all the nodes, connections, inputs/outs, groups, and packages are all stored within the JSON structure of the file itself.

[willem.creffierKCWFB]

Hi @Nick_Boyts

thanks again.

I managed to extract the Groups, Description, Author Name and Input nodes.

1.The “group style”, as available in the context menu in Dynamo, is this recognizable in the JSON structure?

I can only find the presence of Input or Output type nodes within a group, but this is not the same. The selection of a specific string “is input” within an outputgroup might be very useful to make graphs more universally applicable.

2.I would like to ad “Liaisons”, which expresses the link between groups. The link between nodes is findable, the adherence of a node to a group too.

So on the criteria, “find links between nodes which are not part of the same group”, I should be able to get the “liaisons” between group, no?

I would like to isolate the links between groups, in order to create a simplified relational diagram which shows the relations between the groups only.

If I have all this up & running, I hope this is a great help to clean up my Graphs, add the correct properties, make an inventory in a structure that is relevant.

By doing so, I can reflect on how to reduce the number of graphs and make them as universally applicable possible.

Unfortunately, I cannot match the node ID’s when Identifying the groups, with the node ID’s when identifying the connectors…

…in order to tag “External” connectors , the relations between groups.

Any thoughts on why these scripts do not match?

import json connectors 03 .py (2.6 KB)
import json grouptitle 01.py (1.4 KB)

[Nick_Boyts]

@willem.creffierKCWFB

1.The “group style”, as available in the context menu in Dynamo, is this recognizable in the JSON structure?

Yes. GroupStyleId can be found under View > Annotations for each group. The name of the GroupStyle is not included though, so you will have to generate a list of standard style ids before you can “identify” what’s assigned to each group.

@willem.creffierKCWFB

2.I would like to ad “Liaisons”, which expresses the link between groups. The link between nodes is findable, the adherence of a node to a group too. […] Unfortunately, I cannot match the node ID’s when Identifying the groups, with the node ID’s when identifying the connectors…

You might be getting mixed up on vocabulary in the JSON structure. Connectors aren’t mapped to nodes, they’re mapped to individual ports. Connectors in this context refers to the wire, with a Start and End port Id that needs to be matched to the Input and Output Ids of a node.

[jacob.small]

For your first question:
The group style is tracked by it’s ID here in the structure:

However that GUID is configured in your DynamoSettings.xml.

I see no ‘statement of consistency’, so that GUID can and can (will?) vary between systems/environments. Also between Dynamo 2.14 (when group styles were first introduced) and 2016 there is no GUID introduced. They were added and appear to be ‘locked in’ from 2.17 to 3.5. I say appear as I only see consistent GUIDs in a partial sampling of just Dynamo Sandbox, but they would all have been made by me on my CPU and don’t account for differences between Dynamo core and Dynamo integrations - Civil 3D might report them differently than Revit. You’ll want to test that hypothesis thoroughly across multiple user accounts and systems - otherwise you might get mismatches and not know it. If you do, then collecting EVERY SETTINGS FILE might not be viable, so consider using the other properties to find commonalities. Color may be a good indicator (I use it 100x more than styles as my work has to vary between so many different styles).

---

For your second question
The theory for ‘links between groups’ makes sense to me. More or less it’d be something like this (screenshots of a .DYN from my back catalog opened up in text editor):

1. Get your connectors from the JSON structure.
   

   

2. For first connector, get the ID from the ‘start’. This is an output from a node.
   

   

3. Find the output in the ‘nodes’ section.
   

   

4. Find the ID of the node which contains that output.
   

   

5. Find the group which contains that node and extract it’s ID.
   

   

6. Go back to the connector (step 2) and take the ‘end’. This is an input from a node.
   

   

7. Find the input in the ‘nodes’ section.
   

   

8. Find the ID of the node which contains that input.
   

   

9. Find the group that contains that node and extract it’s ID.
   

   

10. If the ID found at step 9 is the same as the ID found at step 5 then you’re inside the same group. If they differ, you have a connection from the group found at step 5 to the group found at step 9, and therefore you have a liaison to account for (I leave it to you to decide how to manage that).

[willem.creffierKCWFB]

Hi @Nick_Boyts & @jacob.small

Your input was very valuable, thank you.

Taking the color code is really pragmatic, and might be a good incentive to classify no more than 16 groups types.

If of interest to somebody, here is the result.

folder rapport 45.py (7.1 KB)

If somebody has knowledge of a relational diagram Visual that can get relations out of a single line…do not hesitate to share.

Selecteren objecten-Filteren en grouperen___geometrie ophalen 1ste solid-meten ordenen tellen toekennen___referentie oppervlak ophalen-meten ordenen tellen toekennen___meten ordenen tellen toekennen-wegschrijven___Filteren en grouperen-geometrie ophalen 1ste solid___Filteren en grouperen-wegschrijven

[mclough]

if it’s relevant or useful, i started a small command line tool to help with these sort of maintenance activities. it’s crude and not professionally finished, but you can find functions to extract/report package usage by script, or script dependency by package. it outputs to xml so you can use something like notepad++ to get some hierarchical/folding browsing.

chartreuseUNICORN/DynamoLibraryScanner