Generative Design not running with custom dynamo package


I am trying to run a generative design study using a dynamo script I created with a local zero touch node library I have installed on my machine. I can run the dynamo script for every iteration, but when I attempt to run my design study I created using Generative Design my study is stuck idling at 0/10. I looked into the refinery-servery-log.txt file and it continuously writes “INFO health ping” but I am unaware what that error means. Let me know if anybody has any ideas!


It may be that your custom node isn’t compatible due to multi-threading or reliance on a tool which won’t allow concurrent API calls, or that the settings in Generative Design are over constrained.

First try doing a study with on of the samples provided to confirm that GD can run.

Then try doing a random study with your graph to see if the later is at fault. Upload the graph and custom nodes if you think it is related to the nodes you have built.

1 Like

Ahh multi threading! Very good to know. I can see the importance of using that for a tool like Generative Design. I have made the necessary adjustments to account for this and we are up and running. Thank you for the help! Always impressed by this forum.

1 Like

how can i create zerotouch node using c# suport multi threading?
As i understand i can’t use Zero touch node access to the API in the GD?

I wouldn’t recommend this.

While your custom node might be able to multi thread, the subsequent and proceeding nodes will not be able to do so. Unless your one node is obnoxiously long to run, I don’t think you’ll get much value there. Most (if not all) geometry operations in all CAD software (not just an Autodesk thing) today is single threaded for a reason: The intended gains actually set you back more in the end.

Further once you get into Generative Design you will be utilizing every core on the system concurrently to it’s fullest extent. I typically see 112% CPU usage for big runs (the extra 12% is the service CPU which deals with managing the threading). By incorporating your own multi-threading you’d break the multithreaded gains which are built into GD, and risk corrupting you’re study data as the CPU could lose track of which thread of data belongs to which study.

API is a vague term. Since GD runs Dynamo sandbox, anything accessible there will run (ie: the Dynamo API). Anything which requires accessing an integration (ie: the Revit API). Generally speaking I recommend keeping the data crunched by GD in the out of the box sandbox toolset, removing external dependencies as much as possible.

1 Like