Not sure if this question has been posted before, but I am gearing up to do some cross-product generative design on one of my projects and I have a maths question.
As part of the script, I am creating a rectangle by width and height. Both of these variables will be inputs of the generative design script, such that:
IN_Width can vary between 2 and 20
IN_Height can vary between 2 and 20
So that I would get all possible iterations of a rectangle with any dimension between 2 and 20 (meters), for a total of 19x19 generations. However, the “orientation” of the rectangle does not matter in the analysis, such that a rectangle with h = 2 and w = 20 would be the same as a rectangle with h = 20 and w = 20.
I have quite a few other inputs in my generative design script which will vary across wide ranges of number and would like to make my program more computationally effective by avoiding repeating rectangles for combinations of dimensions that have already been processed. Is there a way in which I can modify my script to achieve this?
@jacob.small discussed this in one of his (AU?) presentations a few years back. One option is to create and cache all potential combinations in a pre-emptive run and then have Generative Design randomly select one of those combinations rather than build it on the fly. This reduces the chance at “redundant” options but doesn’t remove the chance at randomly selecting the same option more than once. (It also allows for pre-filtering if needed.) Unfortunately, there’s just no good way to definitively prevent a random process from “randomly” doing the same thing more than once.
Keep in mind, you don’t have to do this for every parameter, only the ones that would otherwise create those “redundant” options. In the case of Width and Height being interchangeable, you really just need unique pairings of values and not unique combinations. Setting up your logic to select a defined pair would prevent you from accidentally building duplicate combinations.
Likely Generative Design at Hogwarts: Using Tech Instead of Magic.
@evalsb my advice on this particular question is not do whatever it is that you are planning on on… there is very little value in a full cross product study compared to the computing resources you’re about to consume.
Let’s assume there are three options for 10 other inputs. Your actual size is 191933333 3333*3 = 21,316,689 studies. And guess what, you have no need to optimize anything anymore as the full data set has been run… Except users have to review over 21 million options… Assuming you have a problem which can be optimized, a typical space of 21 million should at least start to find the Pareto front in a 20x100 study… or 2000 runs. That’s 0.0001% of the resource expenditure for a more functional data set for the end user.
I get there is some allure to these types of studies. Letting cross product run the low, high, and mid point of all variables has value to you as a computational designer building the tool, and the end users trying to apply it to a project. But all options for any size variable set isn’t something I would recommend for any more than a handful of situations.
I’d also agree that this use case (cached options) only works on studies with very few unique options where it’s common to hit duplicates. In a large enough dataset you just won’t have that issue.
We are working on developing a new tool for building assessment and are currently conducting some sort of proof-of-concept to assess the tool’s performance in different environments – hence why we are interested in applying the tool on shapes of different aspect-ratio, even if it may seems redundant.
In terms of number of studies, we are not quite as high as 21 million since we have 3 other inputs with around 5 options each, but we are definitely quite high up, which is why I was wondering if there was an easy fix to avoid these repetitive permutations.
I think it looks like the best solution would be to increase the step of evolution of my dimensions so we get some sort of equivalent to the low/mid/high values you mentioned @jacob.small.
Regarding the cached options, @Nick_Boyts are just suggesting to manually create a list of all possible combinations, prune the duplicates and then use that list as a generative design input? I thought generative design only took sliders/numbers/bools/revit elements as inputs? Or am I misunderstanding the use case?
This is really only helpful if you effectively can produce all the unique combinations. The idea is that you use Dynamo to do it once and then cache those outputs with the Data.Remember node or store them in an external file. (The point is that GD doesn’t have to create them every single time.) Your GD input is then an index to return one of those predefined values.
With Width and Height both allowing values of 2 to 20, you should have no problem prescriptively creating those pairs. You wouldn’t necessarily want to include all the other parameters you’re generating as that could easily get too large to be effective.
You can see here the difference between creating all the unique combinations (which GD would essentially do) versus creating the unique pairs which you could do fairly easily without GD.
This is is where I would start the testing, though the unique permutations is worth reviewing… and since you’re into the experimental areas of Dynamo and generative design where I tend to do a good amount of effort… check out this stack overflow post: math - Nth Combination - Stack Overflow
The goal is to build a list of all possible dimensions… A and B are both the same so you could define your range’s start (I’d use a static number input here - a number would work) and end (again, a static input) the count (static input). Then the range would be start..stop..#count; in a code block. The result should be something like [2, 3, 4… 19, 20], where your can set the low and high values in Generative Design as a step setup.
Now that would feed into Python as for example IN[0]. The Python code I would use to build the full set of possible values would be
valueOptions = IN[0] + IN[0]
valueOptions.sorted
From there implementing the nth combination would allow you to utilize a single slider to get nth pairing from the sorted list of all possible pairs, without building all the combinations as @Nick_Boyts’s code above does.
This same method can be expanded to get the nth possible pairing of the sorted set of pairs for VERY large lists… there is a limiting factor though - the 64 bit limit in windows. The largest possible value for an integer is (2^64)-1, or 9,223,372,036,854,775,807. Limiting your number slider to that means you can get any possible duplicate pairings for a list up to… 4,294,967,295 items… certainly more pairs then I would want to build and hold in memory.
Very cool way of getting the right number of items from the list to make the unique combinations! I haven’t gotten to running the generative design with this revised script yet, but I have added a couple of nodes to extract the width and length from the selected combination – not sure that is the correct use of the Data.Remember node though?
Currently when I create your suggested Python node it looks like I am just appending the list a second time after itself, which results in the same list with duplicate numbers once I sort it. Is there an additional function that should be adding (from your StackOverflow post for example) that I have missed? Thank you!
Yeah - need to implement the code from the stack overflow post too. I can try and have a look at it later this week, but try to give it a shot on your own first as I’m pretty busy with deadlines.
That’s what I thought! I’ll take a look at it don’t worry, thank you for your help! Nick’s solution works great at the moment but I’ll look at implementing the stack overflow code for cases with more combinations than I currently have.
