2.1. Population-based design exploration

The exploration method consists of two nested loops: an adaptive loop and an iterative loop (Janssen Reference Janssen2004; Janssen et al., Reference Janssen, Basol and Chen2011), as shown in Figure 1. The outer adaptive loop focuses on defining a design schema, while the inner exploration loop focuses on exploring design variants based on that schema.

The adaptive loop consists of two main processes: schema ideation followed by schema exploration. Ideation is an inventive process in which the designer defines the design schema. Exploration is a systematic process in which the designer tests the workability of the schema. The results of the exploration process may trigger further ideation, which would in turn lead to additional explorations. Thus, the adaptive loop drives the design process forward by oscillating between ideation and exploration, providing input for each other. For a detailed example of this adaptive–iterative process, see Kashuik and Janssen (Reference Kaushik and Janssen2013).

Fig. 1. A population-based design exploration method.

From a search space perspective, the process of schema ideation can be seen as defining a design search space. The process of schema exploration can be seen as searching that space. Subsequent adaptive changes to the schema can be seen as modifications that shift the boundaries of the design search space.

The iterative loop consists of three main steps: developing design variants, evaluating design variants, and formulating decision feedback. Depending on the situation, these steps may be executed linearly with just one design, or in parallel with many designs, or in some other more complex arrangement.

The process of encoding the design schema as a set of computational procedures allows for the partial automation of the exploration process. The schema is encoded in the adaptive loop, and the resulting computational procedures are then transferred to the iterative loop.

The encoding of the design schema as a set of computational procedures allows for two levels of automation, referred to as the what-if approach and the if-what approach. In the what-if approach, the development and evaluation steps are encoded, enabling designers to ask “what are the performance implications if we make certain design modifications?” In the if-what approach, all three steps are encoded enabling designers to ask “if we have certain performance targets, what design modification should we make?”

The Dexen platform and the Eddex toolkit focus on the latter. They aim to support schema exploration by automating all three procedures in this inner iterative loop. Evolutionary algorithms are used to evolve populations of design variants by iteratively executing the developmental, evaluation, and feedback procedures. The typical approach is to define the development and evaluation procedures as parametric models and to define the feedback procedure as a script that performs selection and reproduction of design variants. In the following sections, Dexen and Eddex will be described.

2.2. Dexen system architecture

The development of Dexen started in 2009 at the Design Automation Lab at the National University of Singapore under a number of different research projects (Janssen et al., Reference Janssen, Basol and Chen2011; Janssen, Reference Janssen2013). A predecessor to Dexen was developed at the CRIDA lab at the University of Melbourne (Janssen, Reference Janssen2009). The general framework underlying both of these systems was developed by the author as part of his PhD research (Janssen, Reference Janssen2004; Janssen & Frazer, Reference Janssen and Frazer2005).

In the Section 1, the two key requirements identified for the platform were scalability and extensibility. In addition, two types of users were described: researchers focusing on developing customized toolkits, and designers focusing on using those toolkits in the design process.

In order to address these requirements, a three-tier client–server system architecture has been used. The data tier stores the data generated by the exploration process. The logic tier manages the distributed execution of computational procedures driving the exploration process. The presentation tier provides the user interface for interacting with the exploration process. The advantage of this system architecture is that toolkits can be created and added to the system without requiring any changes to the data or logic tiers. These various components are shown in Figure 2.

Fig. 2. Dexen system architecture.

For the data tier, a key-value database called MongoDB is used (http://docs.mongodb.org/). Large volumes of data will need to be stored, and in order to ensure maximum flexibility, the structure of this data cannot be predefined in advance. For such data, key-value databases are preferable, both in terms of flexibility and in terms of performance.

The logical tier consists of a Dexen server connected to one or more Dexen nodes. The set of procedures to be executed is collectively referred to as a job, and each individual procedure is a task. The server schedules the execution of jobs and tasks on a set of Dexen nodes. Each Dexen node has one or more workers that execute the tasks defined by the job.

The presentation tier consists of two types of interfaces. The first is a Dexen web application that provides a basic graphical user interface for running and managing jobs and tasks, and that can also be augmented with additional specialized user interface plugins. The second is a set of plugins for parametric modeling systems that allow designers to define computational procedures for design exploration without requiring any scripting.

2.3. Dexen tasks

For any given job, a set of tasks can be defined and uploaded to the Dexen server, and the system will schedule and execute the tasks on a set of workers in parallel, with all data input and output automatically being stored in the database. Tasks can be written in any language supported by MongoDB, including C, C++, C#, Java, Perl, PHP, Python, and Ruby (http://docs.mongodb.org/ecosystem/drivers/).

In order to define jobs and tasks, Dexen uses a programming model in which tasks only communicate through data objects stored in the key-value database. This programming model is very general and significantly simplifies the scheduling of tasks because a task need have no notion of other tasks. This programming model is based on the Linda model (Ahuja at al., Reference Ahuja, Carriero and Gelernter1986; Carriero at al., Reference Carriero, Gelernter, Mattson and Sherman1994), in which parallel processes operate upon objects stored in and retrieved from shared memory. Dexen falls under what are described as “Linda-like systems.”

In Dexen, the key-value database is used as a shared memory data store. Each data object has a set of attributes that can store any type of data, from simple types to complex data structures and binary objects. Tasks are able to create, modify, and delete either the objects themselves or specific attributes of objects. Reading and writing attributes allows tasks to communicate through shared objects.

Two types of tasks can be defined that are triggered in different ways: event tasks or data tasks. Event tasks get triggered by Dexen events, including events that are generated when starting and stopping jobs. Data tasks get triggered when certain types of data become available in the database.

For data tasks, each task is associated with a data template and a data input size. The template defines which data objects are valid for the given task. The data input size defines the number of valid data objects that are required in order to trigger execution of the task. Once the task is triggered, the valid data objects are assigned to the task for processing. If the number of valid data objects is greater than the input size, then the required number of objects is randomly selected. Furthermore, depending on the total number of data objects, the same task can be triggered multiple times.

2.4. Dexen for design exploration

Dexen is a generic platform that can be used for running many different types of jobs. This research focuses on the use of Dexen for population-based design exploration. In this case, data objects represent design variants, and tasks represent the evolutionary procedures. These tasks create attributes in the data objects to store genotypes, phenotypes, and evaluation scores.

Tables 1 and 2 show the five tasks for a simple multicriteria evolutionary algorithm with two evaluations. For each task, the input size, the data template, and the task action are defined. The initialization task creates new design variants and adds a genotype attribute, which is initialized with random values. The development and evaluation tasks each operate on a single design variant, adding phenotype and score attributes, respectively. The feedback task operates on a set of 50 design variants and performs selection and reproduction based on the evaluation scores. Selection selects design variants to kill and to reproduce. Reproduction then creates new design variants, generating new genotypes through crossover and mutation.

Table 1. Event task for a typical multicriteria evolutionary algorithm

Table 2. Data tasks for a typical multicriteria evolutionary algorithm

When the job is started, the initialization task will be triggered, thereby generating the initial population. The data tasks will then start being automatically triggered as and when the appropriate data objects become available in the database. The Dexen web application can then be used to view the tasks that are executing and interrogate and download the data for design variants in the database.

In order to support customization of the user interface, Dexen has a plugin framework that allows additional components to be easily added to the web application. This framework provides a JavaScript library for interacting with the Dexen server and for accessing any of the data in the database. This library can be combined with numerous existing JavaScript libraries for generating rich interactive graphs and charts. Using these libraries, researchers can create sophisticated user interfaces that facilitate design exploration.

2.5. Eddex toolkit

Dexen can be used for population-based design exploration, but it still requires the various scripts to be written. Furthermore, the interface provided by Dexen is necessarily very generic. This interface includes various components for starting and stopping jobs and tasks, and for reviewing the data that is being generated. However, it does not include any components specific to population-based design exploration.

Toolkits allow these limitations to be overcome by providing two types of plugins. First, to overcome the scripting hurdle, plugins can be developed for existing parametric modeling systems. This allows designers to create developmental and evaluation procedures as parametric models rather than as scripts. Second, to overcome the user interface hurdle, plugins can be developed for Dexen in order to provide additional user interface components that include various specialized components. This allows designers to more easily interrogate the data being generated by the exploration process.

The Eddex toolkit allows designers to use Dexen for multicriteria evolutionary developmental design exploration. Eddex currently includes a plugin for Houdini. The plugin communicates directly with the Dexen server in order to manage jobs and access job data. The interface for this plugin is shown in Figure 3.

Fig. 3. The Eddex plugin for Houdini. (a) Settings for (a) the feedback task and (b) running the evolutionary algorithm.

The Eddex Houdini plugin allows designers to start Dexen jobs from within the modeling environment. The designer creates the development and evaluation procedures as parametric models. The plugin is then used to automatically generate the job definition and the task scripts required for running the job. For initialization, feedback, and termination tasks, scripts are generated based on various settings defined by the designer through the plugin interface. For development and evaluation tasks, scripts are generated that wrap the parametric models defined by the designer. These wrappers act as an interface between Dexen and the modeling environment, allowing Dexen to execute the parametric models. Additional plugins are under development for other parametric modeling systems, including Grasshopper, GenerativeComponents, and VisTrails (Janssen, Reference Janssen2013).

The Eddex Dexen plugin can be used to interrogate the data being generated by the exploration process. The plugin augments the basic Dexen interface with a set of graphs and charts that are specific to multicriteria evolutionary algorithms, such as Pareto graphs and other graphs and charts that track the progress of the population. A screen shot of the web application is shown in Figure 4.

Fig. 4. The Dexen web application showing the Eddex Pareto graph.

The Pareto graph is the main graph in the Eddex interface. This graph is automatically populated as the evolutionary algorithm is running. A designer can select the axes to be displayed and zoom into specific areas of interest. Models and data files for design variants can also be downloaded by selecting points in the graph. In order to help the designer interrogate the set of design variants, various filters can be applied. Current filters include performance thresholds, Pareto rank, and age of individual. For design explorations with more than two performance criteria, other types of graphs are being developed, including matrix plots and parallel plots.

For design development, the built-in modeling commands within Houdini are generally sufficient. For design evaluation, however, a number of more advanced simulations are needed in order to calculate performance metrics. For this, a library of custom nodes is required. Such a library has been developed for Houdini, called Houdarcs. The library provides a set of nodes that enable designers to evaluate design variants using a variety of simulation and analysis programs. In some cases, these nodes link to existing simulation engines or libraries. Figure 5 shows the relationship between the nodes and the simulation engines or libraries being used.

Fig. 5. Houdarcs, a library of nodes for Houdini to support design evaluation.

3.1. The staggered-brick typology

The case study experiment is based on the design of the Interlace by the Office for Metropolitan Architecture (OMA; http://oma.eu/projects/2009/the-interlace). The design consists of 31 apartment blocks, each six stories tall. The blocks are stacked in an interlocking brick pattern, with voids between the blocks. Each stack of blocks is rotated around a set of vertical axes, thereby creating a complex interlocking configuration. An example is shown in Figure 6, where 6 blocks are stacked and rotated to form a hexagonal configuration.

Fig. 6. The staggered brick pattern. (a) Six blocks arranged in a straight line, and (b) the same six blocks folded into a hexagonal pattern.

Each block is approximately 70 m long by 16.5 m wide, with two vertical axes of rotation spaced 45 m apart. The axes of rotation coincide with the location of the vertical cores of the building, thereby allowing for a single vertical core to connect blocks at different levels. The blocks are almost totally glazed, with large windows on all four façades. In addition, blocks also have a series of balconies, both projecting out from the façade and inserted into the façade.

The initial configuration, shown in Figure 7, is based on the original design by OMA. The blocks are arranged into 22 stacks of varying height, and the stacks are then rotated into a hexagonal pattern constrained within the site boundaries. At the highest point, the blocks are stacked four high. The color of the façade indicates the different types of glazing systems that are required for the level of incident solar radiation. (Blue indicates areas where cheaper low-performance glazing systems can be used, while red indicates areas where more expensive higher performance glazing systems are required.) Sun shading louvers that are not part of the original design have also been added to the façade. These were added in order to explore trade-offs between minimizing solar radiation and maximizing daylight.

Fig. 7. The initial configuration based on the original design, consisting of 31 blocks in 22 stacks of varying heights.

For the case study, new configurations of these 31 blocks are sought that optimize certain performance measures. For the new configurations, the size and number of blocks will remain the same, but the way that they are stacked and rotated can differ. The size of the shading louvers and the types of glazing systems can also vary in response to the levels of incident solar radiation.

The case study is intentionally restrictive, with the level of variability being relatively conservative. This is seen as being more realistic because it is assumed that in practice designers would likely have a strong personal vision for the project and would be less interested in explorations that generated design variants that deviated significantly from this vision. For the case study, configurations are therefore required to adhere to a similar stacking logic, using the cores as axes of rotation. The key constraint that is relaxed is that while in the original, all blocks were rotated in 60-degree increments, in the new configurations, blocks can be rotated in 15-degree increments. This results in an almost infinite range of configurations with significantly differing performance profiles.

Dexen, together with the Eddex toolkit, were used to explore possible configurations using a multicriteria evolutionary algorithm. Parametric models were created for the development and evaluation procedures using Houdini and the Houdracs library. The Eddex Houdini plugin (see Fig. 3) was then used to generate the scripts for the Dexen tasks and to upload them to the Dexen server. Once the job was started, the Eddex user interface was used to keep track of the evolutionary progress and to download high-performance designs on the Pareto front.

3.2. Developmental procedure

The developmental procedure is defined as a Houdini model that generates design variants based on certain parameter values. The parameter values constitute the genotype, and the generated model is the phenotype.

It is typically very difficult to create genotype–phenotype mapping procedures that appropriately control the variability of three-dimensional designs with complex relationships and constraints. For this case study, Houdini's procedural modeling tools are used to create a sequential model building technique called decision chain encoding (Janssen & Kaushik, Reference Janssen and Kaushik2013, Reference Janssen and Kaushik2014). The reason for using this technique is that it allows for the variability of the design variants to be carefully controlled.

In this model, the placement of each of the 31 blocks is defined as a decision point. The process places one block at the time, starting with the first block on the empty site. At each decision point, a set of rules is used to generate, filter, and select possible positions for the next block. Each genotype has 32 genes, and all are real values in the range {0, 1}.

In the generation step, possible positions for the next block are created using a few simple rules. First, locations are identified; and second, orientations for each location are identified. The locations are always defined relative to the existing blocks already placed, and could be either on top of or underneath those blocks. The orientations are then generated in 15-degree increments in a 180-degree sweep perpendicular to either end of the existing block. In the filtering step, constraints relating to proximity between blocks and proximity to the site boundary are applied, thereby ensuring that only the valid positions remain. In the selection step, the decision gene in the genotype chooses one of the valid block positions.

When generating a new design variant, the first decision point involves selecting a starting point on the site from a set of possible starting points. These starting points are generated by overlaying a grid over the site and then filtering out all points that lie outside the boundary of the site. The next four decision points are shown in Figure 8. In the diagrams, the numbered lines are used to indicate possible valid block positions, so that the next block could be placed on any of those lines. The selected option for that decision point is shown as a thicker line.

Fig. 8. Four decision points in the process of mapping the genotype to the phenotype.

• • For decision point 2, the first block needs to be placed on the starting point. The generative rules create 12 possible positions for the block, orientated around the starting point, labeled 0 to 11. The gene selects position number 2.

• • For decision point 3, the second block has to be placed on either end of the first block. The generative rules find two locations where blocks can be placed, and they create 7 positions at each location, resulting in total of 14 possible positions. The gene selects position number 1. Note that the new block now has one end unsupported.

• • For decision point 4, the third block has to be placed. In this case, the generative rules give preference to the location that will result in a support for the previous block. This results in 7 positions, all underneath the previous block. The gene selects position number 4.

• • For decision point 5, the fourth block has to be placed. The generative rules find four locations, all on top of the three already placed blocks. The rules create 7 positions at each location, resulting in total of 28 possible positions. However, a number of these positions violate constraints, and are therefore discarded by the filtering rules. Figure 9 shows the filtering stages for decision point 5. Overall, 7 positions are discarded because they would result in blocks that would be too close to the three existing blocks, and 6 positions are discarded because they would result in blocks that extend outside the site boundary. This results in 15 remaining positions, from which the gene selects position number 7.

Fig. 9. Filtering of positions that violate constraints for decision point 5. (a) All 28 possible positions, (b) 21 positions after block-based filtering, and (c) 15 positions after site-based filtering.

The process shown in Figure 8 is continued until all 31 blocks are placed. The decision chain encoding technique results in two critical features: first, it guarantees that any genotype will map to a valid phenotype; and second, it guarantees that the all valid phenotypes can be generated from a genotype. Note that this is a many-to-one mapping, in that more than one genotype can map to the same phenotype.

As a final stage of the developmental model, cores and façades are added to the blocks. The cores (which would contain the lifts, service shafts, and escape stairs) are added to the interior of all blocks, and in some cases also inserted below blocks in those instances where a void remains below the block (in order to provide support for the block, and to ensure that the flats are accessible from the ground floor). For the façades, the windows on each of the blocks are analyzed, and both sunshades and glazing systems are created.

The size of the shades and the glazing system types both depend on the amount of solar radiation incident on the windows throughout the year. This is calculated in a two-step process, using the Radiance simulation program (Janssen & Kaushik, Reference Janssen and Kaushik2012). In Step 1, the solar radiation incident on the windows without shading is simulated using the Houdarcs Radiance node. Shades are then generated so that windows with more sun will get larger shades. In Step 2, the incident solar radiation is simulated a second time, but this time with shading. Windows that are still receiving too much solar radiation are then assigned more expensive glazing systems, which are able to reduce the transmission of solar radiation.

With regard to this last stage, it should be noted that these simulations are being executed as part of the genotype–phenotype mapping process. Although such simulations are often used within evaluation procedures, in some cases they may also be used as part of the developmental procedure. The generation of shading louvers in response to incident solar radiation is a typical example of this.

3.3. Evaluation procedures

The evaluation procedures evaluate design variants for three performance criteria. These procedures are defined as three separate Houdini models. As with the developmental procedure, this means that a designer is able to define these procedures without resorting to scripting.

The building is located in the tropics in Singapore, and two key requirements are to maximize the amount of daylight and to minimize the amount of solar radiation entering the windows. Both these factors are affected by the orientation of the blocks relative to the north direction, and relative to one another (due to interblock shading).

For daylight, a Houdini evaluation model is defined that uses the Houdarcs Radiance node in order to calculate the amount of light reaching the window on a cloudy overcast sky, which is seen as the worst-case scenario. The amount of light entering each window is then adjusted according to the visual transmittance of the glazing system for that window. The performance criterion is defined as the maximization of the total number of windows where the daylight entering the window is above a certain threshold level for reasonable visual comfort, referred to as good daylight windows.

As described in the previous section, the minimization of solar radiation entering the building is already tackled by the developmental model by adding the sun shades and high-performance glazing systems. However, these additional systems have a significant effect on the total cost of the façade, and therefore, the performance criterion in this case actually focuses on the cost of the façade. For façade cost, a Houdini evaluation model is defined that calculates the total cost of all the glazing systems and shading louvers for all 31 blocks. The model calculates this cost by summing the area of shading and of each glazing type, and multiples these by standard per square meter rates. The performance criterion is defined as the minimization of this cost, referred to as façade cost.

Finally, one more performance criterion is added, relating to the cores. As discussed in the previous section, the developmental model will generate design variants where additional cores need to be inserted. These cores will add significant additional cost and are also seen to be aesthetically undesirable. The final Houdini evaluation model therefore calculates the total length of core for all the blocks. The performance criterion is defined as the minimization of the total vertical core length.