---
title: 'Optimisation & Exploration Tools'
---
```{toctree}
:maxdepth: 1
:hidden:
tunny
opossum
panda
```
The table below compares some of the most capable and popular design exploration and optimisation packages in Grasshopper.
| Galapagos | Opossum | Panda | Tunny | Wallacei | DSE | Octopus | Crow | LunchBox
-----------------------------------------:|:-----------:|:---------:|:-------:|:-------:|:----------:|:-----:|:---------:|:------:|:-----------:
**Sampling** | ✕ | ✕ | ✕ | ✓ | ✕ | ✓ | | |
**Brute-force** | ✕ | ✕ | ✕ | ✕ | ✕ | ✓ | | |
**Single objective** | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
**Multi-objective** | ✕ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
**Constrained** | ✕ | ✕ | ✓ | ✓ | ✕ | ✓ | ✕ | |
| | | | | | | | |
**Geometry saving (phenotypes)** | ✕ | ✕ | ✓ | ✓ | ✓ | ✕ | ✓ | |
**Real-time performance visualisation** | ✓ | ✓ | ✓ | ✓✓✓ | ✓✓ | ✕ | | |
**Result visualisations** | ✕ | ✕ | ✓ | ✓✓ | ✓✓ | ✕ | | |
**Result visualisations in Rhino** | ✕ | ✕ | ✕ | ✓ | ✓ | ✕ | | |
**Save results** | ✕ | ✕ | ✕ | ✓✓✓ | ✓ | ✕ | | |
**Design explorer** | ✕ | ✕ | ✓ | ✓ | | ✕ | | |
| | | | | | | | |
**In development** | ✕ | ✓ | ✓✓ | ✓✓ | ✕ | ✕ | ✕ | ✕ | ✕
**Open-source** | ✕ | ✕ | ✕ | ✓ | ✕ | ✓ | ✕ | ✓ | ✓
# DEO Components
The DEO components shown below are those that we have found to be most capable for workflows in RHDHV. Click on the card to go to its documentation.
```{gallery-grid}
- header: " Tunny"
content: Constrained single- and multi-objective optimisation with performance dashboard and phenotype storage.
website: "tunny.html"
- header: " Opossum"
content: "Single- and multi-objective optimisation with performance explorer."
website: "opossum.html"
- header: " Panda"
content: "Constrained (single- and) multi-objective optimisation with design explorer tools."
website: "panda.html"
```
**Author's note:** **Opossum** appears to be the component that works the best due to its usage of the RBF(M)Opt algorithm. However, Opossum's features are quite limited. **Tunny** has lots of features, many alternative algorithms and the optimisation performs well, though it works slightly slower during optimisation. **Panda** also performs well, and it has a cool built-in design explorer, but it stores data in the component itself, which slows down the GH script.
# General Usage of DEO Components
All DEO components require (among other things) inputs for the **design variables** (also called *features*) and the **objectives** (or *labels*). The picture on the right shows Grasshopper's built-in optimisation component called *Galapagos*. This component originally only implemented a evolutionary algorithm to perform optimsation, and in the context of evolutionary algorithms, the design variables are called **genomes**, and the objective is called **fitness**.
## Design Variables
The design variables are the parameters that drive the design of the model. For a building, this can be as global as the grid spacing between columns, and as specific as the cross-section of each beam.
In Grasshopper, the design variables are input usually as **sliders**, but they can also be often be **gene pools**, and sometimes even **panels** with a list of values. For the panel, these values must almost always be numeric, as very few of the components support categorical input.
❗ You should always set name of the design variables in the sliders because most of the components use that information when outputting data.
## Objectives
The objective is basically the goal of the optimisation or exploration, so what you are trying to minimize or maximize. For a building, this can be minimising the total mass or maximising the amount of sun hitting solar panels.
In Grasshopper, the objectives must always be numerical, and they often have to be stored in *Number* parameter containers. This is because some optimisation components point to these containers, as seen in the picture below for example. Other components take the objectives as normal inputs, in which case you don't have to use a container. Not all components support multiple objectives at once, such as Galapagos.
❗ You should always set name of the objectives in the containers because most of the components use that information when outputting data.
## Perform Optimisation
The picture below shows an example of a very simple optimisation of a known curve using Galapagos. The objective of the optimisation is to find the x- and y-coordinates that minimise the z-coordinate. In this case the objective function is known to the user, but it is not known to Galapagos.
For almost all DEO components, you have to double click the component to get a menu where you can specify the settings of the optimisation or exploration, as shown below. We're not going to go into detail into the settings of the Galapgos component now, but the most important for this example is that it's set to *Minimize*. Galapagos also allows to *Maximize*, which not all components do. However, it's easy to handle this by simply multiplying the objective you're trying to maximize with -1.
The video below shows the Solver window of the Galapagos component. This is where you select which optimisation algorithm to use (Evolutionary Solver or Simulated Annealing), before starting the optimisation. When the optimisation has started you can monitor the progress of the optimisation.
On the right, you can see how the solver first explores the entire design space in order to get to know what the objective function values are for various combinations of the design variables. You can also see that it quickly learns where the minimum is; after just 2 generations, most of the points explored are around the bottom of the surface.
All DEO components require (among other things) inputs for the **design variables** (also called *features*) and the **objectives** (or *labels*). The picture on the right shows Grasshopper's built-in optimisation component called *Galapagos*. This component originally only implemented a evolutionary algorithm to perform optimsation, and in the context of evolutionary algorithms, the design variables are called **genomes**, and the objective is called **fitness**.
## Design Variables
The design variables are the parameters that drive the design of the model. For a building, this can be as global as the grid spacing between columns, and as specific as the cross-section of each beam.
In Grasshopper, the design variables are input usually as **sliders**, but they can also be often be **gene pools**, and sometimes even **panels** with a list of values. For the panel, these values must almost always be numeric, as very few of the components support categorical input.
❗ You should always set name of the design variables in the sliders because most of the components use that information when outputting data.
## Objectives
The objective is basically the goal of the optimisation or exploration, so what you are trying to minimize or maximize. For a building, this can be minimising the total mass or maximising the amount of sun hitting solar panels.
In Grasshopper, the objectives must always be numerical, and they often have to be stored in *Number* parameter containers. This is because some optimisation components point to these containers, as seen in the picture below for example. Other components take the objectives as normal inputs, in which case you don't have to use a container. Not all components support multiple objectives at once, such as Galapagos.
❗ You should always set name of the objectives in the containers because most of the components use that information when outputting data.
## Perform Optimisation
The picture below shows an example of a very simple optimisation of a known curve using Galapagos. The objective of the optimisation is to find the x- and y-coordinates that minimise the z-coordinate. In this case the objective function is known to the user, but it is not known to Galapagos.
For almost all DEO components, you have to double click the component to get a menu where you can specify the settings of the optimisation or exploration, as shown below. We're not going to go into detail into the settings of the Galapgos component now, but the most important for this example is that it's set to *Minimize*. Galapagos also allows to *Maximize*, which not all components do. However, it's easy to handle this by simply multiplying the objective you're trying to maximize with -1.
The video below shows the Solver window of the Galapagos component. This is where you select which optimisation algorithm to use (Evolutionary Solver or Simulated Annealing), before starting the optimisation. When the optimisation has started you can monitor the progress of the optimisation.
On the right, you can see how the solver first explores the entire design space in order to get to know what the objective function values are for various combinations of the design variables. You can also see that it quickly learns where the minimum is; after just 2 generations, most of the points explored are around the bottom of the surface.