1. INTRODUCTION
With the increasingly complex nature of architectural and urban design, there is a need for design methods that leverage the latest computational tools and techniques in order to enable design and planning options to be more systematically explored.
The research focuses on multicriteria evolutionary design exploration methods (Holland, Reference Holland1975; Frazer, Reference Frazer1995; Bentley, Reference Bentley and Bentley1999; Deb, Reference Deb2001; Coello et al., Reference Coello, Lamont and van Veldhuizen2007). In this research, the goal of such methods is not optimization but rather the discovery of original and unexpected design configurations, which are high performing with respect to the criteria being evaluated. These methods do not diminish the intentionality of the designer. Instead, the designer engages in an open-ended reflective conversation (Schön, Reference Schön1983) in which evolutionary exploration processes are executed multiple times, thereby allowing the design variants being evolved to be repeatedly analyzed and modulated. For each exploration, the designer is able to strongly guide the evolutionary process by defining developmental, evaluation, and selection procedures that reflect their design visions (Frazer, Reference Frazer1974; Darke, Reference Darke1979; Frazer & Connor, Reference Frazer and Connor1979; Frazer, Reference Frazer1995; Janssen at al., Reference Janssen, Frazer and Tang2000; Janssen, Reference Janssen2004, Reference Janssen2006).
This use of evolutionary algorithms contrasts with how they are applied in other fields where the aim is to find an optimal solution or set of solutions to narrowly defined and unambiguous problems. Research in such areas often focuses on the competitive tweaking of specialized search algorithms for benchmark problems. In design fields, the types of projects being tackled are highly varied, and as a result, this type of research has limited relevance. What are needed instead are design exploration methods that are applicable to a wide variety of design projects. Such methods need to synergize human and computational actors to negotiate multiple conflicting design requirements and performance criteria. The software systems and algorithms are just one small part of a much larger and more holistic type of mixed-initiative adaptive–iterative design process.
The key challenges to developing such methods relate to the idiosyncratic nature of each design project, the fluidity of the design process itself, and the technical skills of the designers involved. The option of implementing project-specific exploration systems from scratch is unrealistic. Instead, a generic platform is required that can be easily customized to address questions relevant to each project.
1.1. Research context
The context for this research is the Department of Architecture at the National University of Singapore. Within this context, population-based design exploration algorithms are used by two distinct groups of students: research students and design students. At the research level, PhD students are developing specialized algorithms and user interfaces as part of their research projects. These students are mostly coming from an architectural background, but have in the course of their PhD developed some scripting and basic programming skills. The algorithms and user interfaces being developed vary significantly from one student to the next depending on each student's research focus, and will often involve complex sets of tools including simulation, surrogate modeling, and data analytics tools. For these research students, a platform is required that will allow them to easily create and test their algorithms and user interfaces.
At the design level, fourth-year students in the undergraduate architecture course are offered an elective in which they are required to explore design options using multicriteria evolutionary algorithms. In the 12-week elective, students need to learn parametric modeling, performance simulation, and multicriteria evolutionary exploration. They have only basic modeling skills and have no scripting skills. For these design students, a user-friendly platform is required that allows them to run evolutionary algorithms using a purely graphical interface.
For the design students, a popular technique is graph-based modeling, a type of parametric modeling that creates data flow and procedural graphs using nodes and wires (Janssen & Chen, Reference Janssen and Chen2011; Janssen, Reference Janssen2014; Janssen & Stouffs, Reference Janssen and Stouffs2015). A number of different graph-based modeling systems are available, including McNeel Grasshopper, Autodesk Dynamo (http://autodeskvasari.com/dynamo) Bentley GenerativeComponents (http://www.bentley.com/gc), and Sidefx Houdini (http://www.sidefx.com/). These modeling systems enable students to define the key computational procedures required for the population-based exploration process, including procedures for the development and evaluation of design variants.
1.2. Platform requirements
For these two groups of students, loosely labeled as researchers and designers, a design exploration platform is required. The first group focuses on developing customized toolkits for design exploration. The second group focuses on applying these toolkits during the design process.
Although these two user groups emerged from a specific academic context, they can also be found in many other contexts, including architectural and design offices. Based on these users, two key requirements are identified for the platform: to be scalable and extensible.
The platform needs to be scalable with regard to the execution of population-based exploration algorithms that may require complex procedures for developing and evaluating design variants. Both researchers and designers need to be able to run these algorithms in parallel on a variety of hardware, from networks of personal computers to cloud or grid computing infrastructures. This will insure that as problems get more complex, the run times of the algorithms can be controlled by adding additional processing power. Installing and running the platform on such distributed hardware should be straightforward even for novice users. At the same time, because of their digital nomadism (Makimoto & Manners, Reference Makimoto and Manners1997), design students also need to be able to easily install the complete platform on their personal laptops.
The platform needs to be extensible with regard to the incorporation of customized toolkits. Researchers need to be able to easily build toolkits consisting of population-based exploration algorithm (such as evolutionary algorithms and swarm algorithms; Engelbrecht, Reference Engelbrecht2007) coupled with customized user interfaces. This may include the integration and linking of various existing parametric modeling and simulation systems that may need to run on varying operating systems and that may require different programming languages. For building user interface components, the platform also needs to provide the necessary infrastructure to develop rich graphical interfaces that allow designers to interact with the evolutionary process while it is running. This extensibility will enable a wide range of toolkits to be developed, which will in turn allow designers to select the toolkits that best suit their design problems and workflows.
1.3. Existing libraries and systems
Numerous programming libraries and other types of software development frameworks exist targeting computer scientists who need to implement evolutionary algorithms to solve specific problems. For designers, these frameworks are too low level. Even for researchers, they can be daunting because they do not target design exploration. Integrating parametric modeling, building information modeling (BIM), and simulation systems with these libraries and frameworks can be very challenging.
A number of other researchers have developed evolutionary design systems. However, none address the requirements set out above. Although they may be easier for designers to use than programming libraries, they lack the required scalability and extensibility.
Two plugins exist for the McNeel Grasshopper parametric modeling plugin, but these are very limited (Galapagos, http://www.grasshopper3d.com/group/galapagos; Octopus, http://www.grasshopper3d.com/group/octopus). Although they are useful as learning devices, they quickly become too slow and inflexible when tackling problems of any significant complexity.
A number of other researchers have developed various multicriteria evolutionary design systems. Caldas developed an evolutionary design system called GENE_ARCH for energy-efficient building design linking with DOE2.1E building energy simulation software (Caldas, Reference Caldas2008). Geyer (Reference Geyer2009) developed an evolutionary design workflow for building optimization, linking BIM software with a commercial optimization platform ModelCentre (ModelCentre, 2015). Welle and Haymaker developed a BIM-based thermal building optimization system called ThermalOpt (Flager et al., Reference Flager, Welle, Bansal, Soremekun and Haymaker2009; Welle et al., Reference Welle, Haymaker and Rogers2011), linking with ModelCenter (http://www.phoenix-int.com) and the BIM software Digital Project (http://www.digitalproject3d.com/). Von Beulow is developing an interactive evolutionary system called ParaGen for structural optimization (Turrin et al., Reference Turrin, von Buelow, Kilian and Stouffs2012; von Buelow, Reference von Buelow2012), linking with GenerativeComponents and the structural simulation program STAAD.Pro (http://www.bentley.com/STAAD.Pro). Gerber is developing a BIM-based evolutionary design system called Beagle for energy optimization (Gerber & Lin, Reference Gerber and Lin2013; Lin, Reference Lin2014; Lin & Gerber, Reference Lin and Gerber2014), linking with Autodesk Revit (http://www.autodesk.com/products/revit-family) and to Autodesk Green Building Studio (https://gbs.autodesk.com). Bentley Systems is developing a system called the Darwin Framework that links to other Bentley applications such as GenerativeComponents and STAAD.Pro (Mueller et al., Reference Mueller, Crawley and Zhou2013; Mueller & Strobbe, Reference Mueller and Strobbe2013).
Despite each having individual merits, none of these systems offer a platform that is both scalable and extensible. A number of systems support distributed execution, but they tend to support only specific or proprietary hardware infrastructures. Furthermore, setting up and installing these systems tends to be very complex. The algorithms and user interfaces are deeply embedded within the system and are difficult to modify. The option of coupling these systems to additional parametric modeling and performance evaluation systems is either not supported or is cumbersome.
1.4. Content
The Dexen platform has been developed in order to support the researchers and designers in experimenting with design exploration algorithms. With regard to scalability, Dexen provides a comprehensive environment for executing computationally expensive procedures on distributed hardware. With regard to extensibility, Dexen allows researchers to create customized design exploration toolkits with specialized algorithms and interfaces. As a first test case, a toolkit has been developed focusing on multiobjective evolutionary developmental design exploration, called Eddex.
Dexen and Eddex have been developed as open-source projects and are freely available for download (http://dexen.org). They can run on all major operating systems.
Three sections follow. Section 2 describes the proposed Dexen platform and Eddex toolkit. Section 3 describes a case study of using the platform and toolkit to explore options for massing and façade design of a residential project. Finally, Section 4 draws conclusions and discusses future areas of research.
2. DEXEN PLATFORM
The starting point for this research is the proposition of a population-based design exploration method. A key element in this method is an algorithmic model created by a designer that defines how design variants are developed and evaluated. This algorithmic model is referred to as the design schema (Janssen et al., Reference Janssen, Frazer and Tang2000, Reference Janssen, Frazer and Tang2002; Janssen, Reference Janssen2004). The design schema captures the identifiable character of a family of designs. Members of the family share certain characteristics, but they may also vary considerably in other aspects. The proposed method uses the concept of the design schema to structure the exploration process.
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).
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.
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.
Event task for a typical multicriteria evolutionary algorithm
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.
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.
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.
Houdarcs, a library of nodes for Houdini to support design evaluation.
3. CASE STUDY
Over the last 5 years, Dexen has been applied to a wide variety of design scenarios. Uses of Dexen by design students include exploration of catenary structures for structural and wind loads (Lee, Reference Lee2011), exploration of paneled building envelopes for environmental performance (Kaushik & Janssen, Reference Kaushik and Janssen2012), exploration of urban street patterns using axial line analysis (Chee & Janssen, Reference Chee and Janssen2013), the exploration of high-rise urban farm typologies (Kaushik & Janssen, Reference Janssen and Kaushik2013; Zhong, Reference Zhong2013), and the exploration of urban configurations for walkable new towns (Chian & Janssen, Reference Chian and Janssen2014).
At the research level, a number of PhD students are using Dexen as a base for their research, allowing them to create and test customized toolkits. In addition, Dexen has also been used in a number of research projects. In the case study described below, Dexen was used to explore alternative configurations of a large residential development in Singapore. This example demonstrates how complex development and evaluation models can be created using parametric modeling systems without requiring any scripting.
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.
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.
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.
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.
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.
4. RESULTS
The evolutionary process was executed using Dexen on a set of 10 networked personal computers, consisting of one Dexen server (also running the Mongo DB) and nine Dexen nodes (each with four workers). The execution time to develop and evaluate a single design variant on one machine was close to 2 min, but when it was run using Dexen with the 9 compute nodes, it was reduced to approximately 18 s.
The population size was set to 200, and a simple asynchronous steady-state evolutionary algorithm was used. Each generation, 50 individuals were randomly selected from the population and ranked using Goldberg's multicriteria Pareto ranking method (Goldberg, Reference Goldberg1989). The 4 individuals with the lowest rank were killed, and the 4 individuals with the highest rank (rank 1) were used as parents for reproduction. Standard single-point crossover and single-point mutation operators for real-valued genotypes were used (Michalewicz, Reference Michalewicz1996, p. 101), with the mutation probability being set to 0.01. Reproduction between two pairs of parents results in 4 new children, thereby ensuring that the population size remained constant.
The evolutionary algorithm was run for a total of 16,000 births, taking approximately 8 h to execute. The Pareto graph for all 16,000 designs is shown in Figure 10. The horizontal axis indicates the percentage of windows that achieved a daylight level above the minimum threshold. The vertical axis indicates the estimated cost of the façade. The most desirable design variants are therefore in the bottom right-hand corner of the graph. The colors of the points indicate the third performance criteria, which is the total core length. (Blue indicates a lower core length, while red indicates a higher core length.) Various designs on the Pareto front were downloaded for further investigation. The initial configuration proposed by OMA and six selected design variants are highlighted in the graph in Figure 10.
Pareto graph for all designs.
In order to calculate the progress of the evolutionary algorithm, the Hypervolume metric was used (Zitzler & Thiele, Reference Zitzler and Thiele1998). At each 100 births, the nondominated Pareto set was found. For each Pareto set, the performance scores were normalized, and the good daylight window score was inverted so that all scores were being minimized. The Hypervolume was then calculated using the tool developed by Fonseca et al. (Reference Fonseca, Paquete and Ibáñez2006). The graph in Figure 11 shows the increase in Hypervolume as evolution progresses.
The Hypervolume graph for a run of 16,000 design variants.
The final nondominated Pareto set for the whole population contains a range of design variants with differing trade-offs between daylight performance and façade cost. Six of these design variants from this nondominated set are shown in Figure 12, all with a very low score for total core length. These design variants all improve on the initial configuration in one or more of the performance criteria.
Six design variants from the nondominated Pareto set, grouped into two clusters.
The selected designs have been grouped horizontally to highlight the two clusters of similar design variants. In the bottom cluster, the configurations are drawn in toward the middle of the site, and as a result, there is more interblock shading. This decreases both façade cost and daylight performance. For façade cost, the difference is significant, with design variant 13927 having a façade that is approximately SDG $1.8 million cheaper than the initial configuration. For daylight performance, these design variants are similar to the initial configuration.
In the top cluster, the configurations are more open, and as a result there is less interblock shading. This increases both façade cost and daylight performance. For façade cost, one design is still lower than the initial configuration, while another is higher. For daylight performance, all three design variants are significantly better than the initial configuration, with the improvement in performance ranging from 7% to 15%.
The performance criteria being considered in this evolutionary exploration process are very restricted. If such methods were used in the actual design process, the designers would need to interpret these results, taking into account a wider range of considerations including social, cultural, and aesthetic factors. In general, once these other factors are included, the optimized designs may not necessarily be the preferred option. Furthermore, the identification of flaws in these optimized designs may drive designers to start a new adaptive cycle by modifying the design schema to prevent the flaws and then to explore the modified schema (see Fig. 1).
5. CONCLUSIONS
The Dexen platform has been developed for two different types of user groups. The researchers group focuses on developing customized population-based design exploration toolkits. The designers group is interested in using the population-based exploration toolkits developed by the researchers to achieve improved design outcomes.
Based on these user groups, two key requirements for the platform are identified: to be scalable with regard to the execution of population-based exploration algorithms and to be extensible with regard to the incorporation of customized toolkits. In order to address these requirements, Dexen has been developed using a three-tier client–server system architecture that separates data storage, domain logic, and presentation. This separation allows toolkits to be created for Dexen without requiring any changes to the data or logic tiers.
As a first demonstration of such a customized toolkit, the Eddex toolkit has been developed to support multicriteria evolutionary developmental design exploration. This toolkit includes of two types of plugins: a Houdini plugin for generating the job definitions and associated tasks, and a Dexen plugin for providing additional user interface components for interrogating the data that is being generated. The Eddex toolkit has enabled design students to use Dexen within a variety of projects. Dexen is also currently being used by a number of PhD students in order to experiment and test the computational design methods that they are proposing.
The case study successfully demonstrates how a complex design scenario can be explored using Dexen. The Houdini modeling system was used to create a set of development and evaluation models. The job and associated tasks were then generated using the Eddex Houdini plugin, and uploaded to the Dexen server. The evolutionary job was run, and the progress of the evolutionary process was tracked using the graphs and charts provided by the Eddex Dexen plugin. Selected designs on the Pareto front were then downloaded for further investigation.
Eddex is seen as being the first of a series of toolkits that lower the entry barriers for designers to use Dexen for design exploration. Future research will create additional toolkits focusing on different design exploration methods and problem domains.
ACKNOWLEDGMENTS
This research was supported by the Singapore Ministry of Education under AcRF Tier 1 Grant R-295-000-092-112.
Patrick Janssen is an Assistant Professor in the Department of Architecture and the Director of the Design Automation Laboratory at the National University of Singapore. He received his PhD from Hong Kong Polytechnic University, his MS from Westminster University, and his AA Diploma from the Architectural Association. Dr. Janssen conducts research into computational methods for architecture and urban design that combine design exploration algorithms with performance analysis and simulation.
