Generative Design - does not show large data results


I am Using ( GD )Generative Design ( with revit 2021 (, 20201109_1530(x64)) using Dynamo (
I have installed all the updates

When run in Dynamo all results are produced
When running GD - it is able to produce results, but only the results of smaller sites, and shows no value on larger ones.

Arraylayout_1.6.1.9.dyn (99.3 KB)

even if the results show no value , when opened in dynamo , and run, it produced the objects properly.
I have attached a sample of the script for your testing.

please help to fix this issue as i am currently working on large dataset for Generative design.

my system Config -
OS Name Microsoft Windows 10 Home Single Language
Version 10.0.18363 Build 18363

System Model HP Pavilion Notebook 15-bc5xxx
System Type x64-based PC
Processor Intel® Core™ i7-9750H CPU @ 2.60GHz, 2592 Mhz, 6 Core(s), 12 Logical Processor(s)
Installed Physical Memory (RAM) 16.0 GB

Could this issue be because i am using a python node ?
or because i am trying to display too many objects, maybe i turn off the dynamo previews ?

Could you zoom in and capture a better picture of your graph? Right now it’s illegible. Use the screen capture function in the top right of the Dynamo window for the best results.

The most common reason for this is accessing external resources which Generatove Design can’t see. Basically, if any nodes between your Data.Remember node and your Data.Gate node call the Revit, Civil 3D, FormIt, or other integration API then you will see results like this, as Generative Design doesn’t see Revit (hence the need did the Data.Remember and Data.Gate nodes). This includes all OOTB nodes in the integration, all custom nodes, and all Python nodes. This does not mean you can’t use Python nodes or custom nodes, but that they need to run without accessing the integration in any way.

Try opening the graph in Dynamo Sandbox not Dynamo Revit and see if you get results there. If you get errors showing all null results due to an attempt to load stuff, then we have IDed the issue.

the current sample graph does not use the data.gate and the data.remember nodes,
i tried the same script using only dynamo OOTB nodes of dynamo got the same results.

Will the graph in GD result in no value even if a null value is cast in between the graph , not in a output node.?

ill try dynamo sandbox, but does dynamo 2.6 sandbox work with the GD plugin, do i download it from the package manager ?

i went ahead and removed all the python nodes, replacing them with dynamo sandbox nodes,
tried the same test again via the sandbox, but still only the smallest results are displayed.

I can’t reproduce your issue.

Can you provide your refinery server log from %AppData%\Roaming\GenerativeDesign\refinery-server-log.txt and your hall of fame history results from the same folder (the specific study can most likely be easiest to identify via the timestamp).

With out seeing those logs, I can only guess as to the issue. On that front this may be a result of the added geometry complexity which likely should be addressed. My guess is as a result of the methods uses you’re running out of memory at some point as you generate the content, and once that happens Dynamo is unable to return values as the VM is just in a bad state until the next one spins up and does the same. I recommend:

  • Adjusting the scale to something more easily controlled. Are you placing 6 foot tables in a room that is measured in miles? or is this 6mm tiles in a 2.9 m surface? or something else? Keeping the units you’d use when describing the whole exercise helps.
  • Utilize dictionaries to simplify data flow. This will improve processing time by reducing the geometry display values, and push you to think of things mathematically instead of physically which will help in the next step.
  • Utilize coordinate systems instead of repeated geometry generation. This will reduce the number of tests you need to run, ane help keep things scaling well.
  • Test content via math instead of physical testing. Currently you’re using Geometry.DoesIntersect tests on points that mathematically have to be true. There is no need - you’re asking Dynamo to confirm things we know to be true. If there is complexity I dont’ see yet and tests are needed, test as few times as needed (if you can do it once at the end that’d be preferable to testing, making more, testing the original and the new again). Also if you must test repeatedly, test in an order which reduces scope quickly.
  • Reduce input ranges to additional tests won’t produce matching results. You can think of your design like an infinite area checker board - if you shift beyond the first red square a black square of matching dimension will take it’s place - as such you only need to offset by the value of a square, not the full length of the line.

For a sense of scope of such efforts would have on performance, your graph currently runs in 60 seconds per iteration. I have seen exercises which produce counts in this rage of your upper limit that run in about 6 seconds. Assuming consistent speed and 6 cores working in unison, and 20x10 study works out to the following run times:

Your graph: 2000 seconds (more than half an hour to complete)
A 6 second run: 200 seconds (less than 4 minutes to complete)

Here is a link to download the refinery server log -

The sample script i provided is only a part of the overall workflow.

Scale - The Tables (solar panel tracker) are 60 x 4m, and they must be arrayed on sites on average 5000x5000m sites. with 2 m spacing between 2 tables

For this test I reduced the script to just creating a rectangular site , that will array the table on it.

which is why it seem like there are extra does.intersect nodes. but your note on working things mathematically over physically is great advice and ill rework on the full code to work in that way.

ineither case - (full or test script) when I run a GD on it , at most i am able to work with a site of size 3000x3000m placing 25000 tables.

I thought it was an issue with the CPU or RAM, so i ran the same tests on a VM with a xeon processor and 30 GB RAM, but the results were similar. so I still was not able to ID the issue.

here is a copy of the script without any python, ive also updated the site length and width range to work with 3000 to 9000 m. let me know if you are getting errors in it like i am .

Arraylayout_1.6.1.9.dyn (89.6 KB)

I dont think I understand what u mean when u say,

could you give me another example ?

Few quick questions:

  • Is this refinery server log from the VM or from a standard system?
  • Do you have a hof_hist_results, hof_results, sln_set_hist or sln_set_results file for GUID a15dc5b3-3828-44e0-a26e-975789ebb915 anywhere?
  • Can you get one of the sample studies to run?

I am getting solutions, so it may be a system setting or something with your InfoSec configuration which is blocking execution of the code, but we need confirmation on if it’s specific to the graph or if there are issues in general.

Hi @Jacob, thank you for the prompt response :star_struck:

  • the server log is from the standard system, ill need a bit more time to get the server log from the VM.

  • here is the link for the files for GUID a15dc5b3-3828-44e0-a26e-975789ebb915 that i have available -

other hof_hist_results,hof_results,sln_set_historsln_set_results` file -

  • Can you get one of the sample studies to run - Yes , I have run it on site smaller than 2900x2900m (100x100m, 500x 500m etc) and all of them computed properly.

I’ll look into this later this weekend (holiday in the US and I am away from the keyboard), and will see if the development team has any insight next week if I don’t get anywhere with it. :slight_smile:

FYI @nate.peters

1 Like

Hi Jacob,

I went ahead and rewrote the script to work mathematically , only producing geometry at the end of the script. it has increased the speed of the script , but GD still wont populate result values.

here is the new script -arraylayout_math_sandbox_site_2.dyn (115.4 KB)

GD results -

the only time GD gave all results was when i froze the geometry creation nodes.

1 Like

It would appear that you have results on most of the results in both studies, but some are failing, but why isn’t clear.

Can you post the generative design log as well?

Hi Jacob,

here is the GD log -

1 Like

hi jacob, any update , or issue with the logs ? still not able to solve the issue

Digging on something - appears it may be related to another application but not sure which. Hope to have something for you soon.

hi @neel-studio4, I’m taking a look into your issue. Just to rule out any issues related to conflicts with other software on your machine, can you try running the “Three Box Massing” GD sample and let me know if the results are returned successfully?

@neel-studio4 I just spent some time looking at your arraylayout_math_sandbox_site_2.dyn and I tried running 40 random iterations through Generative Design. If you look at the input settings that are associated with the empty outputs in the Explore interface (displayed as * in the list), and try to run the graph in Sandbox with those same input values, you’ll notice that Dynamo will hang for a long time and start to consume a huge amount of memory.

We placed a 750 MB limit on each Dynamo instance that GD manages in the background to prevent crashes. Since your graph seems to cause spikes in memory usage, those instances are getting killed before they finish calculating the results, which is why the results for some outcomes are empty.

For instance, I ran the selected result in Sandbox, and it was consuming over 4 GB of memory on my computer before I killed the process. I would recommend narrowing the range of your input sliders in your graph to exclude any values that will lead to the calculations getting so complex.

Input Values that led to a crash:

Memory Usage in Sandbox:

Hi @nate.peters,
i am able to perfectly run the “three Box Massing” GD and all results did result successfully.