“Change an input until a chosen output meets a threshold.”
The Goalseeker begins by stating where you want the design to end, not how you want it to get there. This is the one pattern that is pretty much impossible in Revit or Vasari (or Grasshopper, for that matter) without some additional coding. Revit’s engine likes to string a bunch of elements and relationships together and accumulate the pieces into an integrated whole. This is essentially a bottom up process, where the result is determined by accumulated relationships. Goalseeker is the reverse, where the result is determined and we need to sift through multiple paths to figure out how to get there. Or how to get close.
This is not an easy operation for most platforms, partly because the end result is usually an approximation of an ideal. Finding the highest point on a hill, for instance, can be an eternal loop of finding points NEAR an ideal “top”, points that are infinitely ever-so-slightly higher than the last measured highest point. To make sure that the process stops, you need to build in the concept of “good enough”, a fuzzy area that satisfies the human sense of “top” but not a computer’s impossibly precise definition of “top” . Computers don’t usually like “good enough”.
In this example, there is a core Goalseeking engine, a python script authored by Aki Hogge, which simply manages an input, an output, a goal, and the differences between them. What is done with these numbers is defined by good old fashioned family parameters. This allows the heavy lifting to be done by the specialized script, and Revit allows the user to generalize it’s application.
Enough talk, let’s take a look ( I recommend full screen).
Woodbury writes that “Key to writing a working Goal Seeker is understanding how to build the desired measure into the system. Understand how the result will change with changes to the driver”
The interesting part for me is that the same script can be reused for many different applications. While it certainly will not satisfy every application (it’s pretty limited, in fact), it is remarkably generic and portable. That is, it can be used for all sorts of different measurement needs, so long as you just need an input, an output, and a set quantity to measure the output against.
The core of this pattern involves the discovery of base conditions that are now known, but an end state that is known. Usually in parametric modeling the reverse is true: you set up the relationships of pieces and welcome the surprise of a resulting condition. But with the goalseeker, you define what you want the outcome to be and let the algorithm figure out how to get there.