STRUCTURALCOMPONENTS 4 Conceptual Building Models with Structural Design Justiﬁcation

Master’s thesis STRUCTURALCOMPONENTS 4 Conceptual building models with structural design justiﬁcation

Arie Bovenberg

Delft University of Technology Faculty of Civil Engineering and Geosciences Department of Structural Engineering Section Structural and Building Engineering This page has been intentionally left blank. Preface

This report is the result of the Master’s thesis project of Arie Bovenberg, the fourth in a series of graduation projects on the subject of StructuralComponents: an early stage design tool for structural design (Rolvink et al., 2009). The subject of this thesis is the development of a conceptual building model to support composition of structural design justiﬁcation.

This research is part of a collaboration of the faculty of Civil Engineering and Geo- sciences of the Delft University of Technology, the BEMNext Laboratory, and White Lioness technologies. The graduation committee consisted of the following members:

Prof. dr. ir. J.G. Rots [email protected] Delft University of Technology Faculty of Civil Engineering and Geosciences Structural Mechanics Dr. ir. J.L. Coenders [email protected] Delft University of Technology Faculty of Civil Engineering and Geosciences Structural and Building Engineering White Lioness technologies Ir. A. Rolvink [email protected] Delft University of Technology Faculty of Civil Engineering and Geosciences Structural Mechanics White Lioness technologies Ir. J.W. Welleman [email protected] Delft University of Technology Faculty of Civil Engineering and Geosciences Structural Mechanics Ir. S. Hofman [email protected] Arup Amsterdam

iii This page has been intentionally left blank. Summary

The adoption of computation in the building industry has led to the development of a range of tools intended for design, but these are often focused on detailed analysis and documentation, instead of flexibility and insight. This results in missed opportunities for computational analysis in the early design stages where decisions are most influential. Also, a large part of the process and reasoning behind these decisions is lost due to a lack of suitable early-stage models. StructuralComponents is a design tool for conceptual structural design which aims to address the needs of the early design stages. The current implementation is focused on quick, insightful analysis of high-rise structures. The main aim of Struc- turalComponents 4 is not only to cover more general structural typologies, but also to model a more complete representation of structural design concepts: not as a single model or analysis method but as a design story or justification, consisting of the various models, simplifications, reasoning, alternatives, and scenarios used to develop and justify the design. The StructuralComponents 4 prototype implementation consists of the conceptual building model, a user interface and a simple computational (parametric) engine. High-level requirements for the tool have been developed based on existing research and insights into (structural) design and conceptual modeling. The iterative development process of the tool itself has also provided feedback to refine these assumptions. High-level characteristics of (structural) design indicate the tool must support:

• a unique process structure straction and scale • multidimensional problems and in- • various analysis models tegrated solutions • cases and scenarios • parallel alternatives • progression from preliminary to • modeling at different levels of ab- detailed design

The resulting central concepts of the conceptual building model are:

“Blank slate” components The main building-blocks of the model are components which aim to follow the designers needs, instead of providing a detailed standard. Components can be deﬁned by the user to represent any structural feature, and can contain quantitative as well as qualitative information. Hierarchical component breakdown Components are organized hierarchically to indicate the breakdown of the

v structure. This makes it possible to model the structure at several levels of abstraction. Reﬂective design reasoning Justiﬁcation behind an design information can be expressed as the result of a design-step, which in turn is based on the context of existing information. This allows a chain of decisions giving insight into the reasoning behind values as well as the effect of changes. Analysis models as automated reasoning Analysis models are implemented as automated logic to be applied in the design-steps, allowing these to be re-run when parameters change. Alternative values The building model supports multiple values per component attribute, allowing the user to represent alternative values in parallel. Component variants Complex alternatives are supported through component variants, which com- bine a set of choices for alternative values. These concepts been implemented in the prototype, and have been validated through application in practical cases (see Figure1 for a condensed example).

Figure 1: Schematic diagram showing the analysis of the stability of a “core” component in a building model, making use of various analysis models and scenarios. Based on the structural design of the RAI Elicium building (Arup Amsterdam, 2009).

The validation shows that the central concepts of the building model sufficiently address the high-level requirements. Notable limitations are the absence of geometric and visual representations, constraints on variation between alternative components, and lack of overview at detail level. Based on the observations during validation, further directions for investigation are suggested. These include opportunities for standardization; reflection and visual representations; bi-directional associations; geometric associations; replication; distinguishing alternatives and scenarios; and an improved user interface. By making a larger part of the design story explicit, the StructuralComponents 4 building model represents a significant step towards broader application of computation in design, specifically improved communication of reasoning behind design, and more effective use of optimization and analysis trough scenarios and parallel alternatives. This page has been intentionally left blank. Contents

Preface iii

Summaryv

1 Introduction1 1.1 Background...... 1 1.2 StructuralComponents...... 3 1.3 Motivation...... 4 1.4 Objectives...... 5 1.5 Thesis outline...... 7

2 Methodology9 2.1 Approach...... 9 2.2 Research...... 11 2.3 Development...... 11 2.4 Validation...... 11

3 Research 13 3.1 Design...... 13 3.2 Modeling...... 15 3.3 Computation...... 17 3.4 Conclusion (use cases)...... 18

4 Results 23 4.1 Application architecture...... 23 4.2 Conceptual building model...... 25 4.3 Computational engine...... 40 4.4 User interface...... 44

5 Validation 49 5.1 Examples...... 49 5.2 Evaluation...... 61

6 Discussion 65 6.1 Objectives...... 65 6.2 Background...... 66 6.3 Next steps...... 67 6.4 Potential...... 71

ix 7 Conclusions 73

References 75

List of Figures 79

Appendices 80

A Case study 81 A.1 Background...... 81 A.2 Structural design...... 82

B Development process 87 B.1 Version 0.1...... 87 B.2 Version 0.2...... 88 B.3 Version 0.3...... 89

C Publication 91 1 Introduction

This chapter introduces the background and starting points of this study. The ﬁrst section outlines relevant aspects of structural design, followed by a brief description of StructuralComponents: its approach and previous implementations. Section 1.3 describes the main motivations for this thesis, leading to the objectives outlined in Section 1.4. A description of the thesis structure is given in the last section.

1.1 Background

StructuralComponents is a software-tool for the early stages of structural design. It addresses the need for ﬂexible, insight giving tools to suit the complex and dynamic nature of conceptual design.

1.1.1 The design process The process of designing a structure is a complex process, with no predetermined ‘optimal’ result (Chapman et al., 2001). Especially in the early design stages solutions are developed by exploring options, with experience and creativity of the designer playing a large role. Figure 1.1 shows two trends throughout the design process. The ﬁrst is accuracy of information: at the start of design, there is little precise knowledge about the design problem. As the design progresses, accuracy of information increases as the designer gains insight into the problem and develops his or her design. The opposite trend occurs for impact of decisions: at the start of the design process all options are open and high-level decisions are made. Later in the process, when the design has been developed, it is often costly to make changes. The effect of this trend is that engineers often have to make inﬂuential decisions when information needed to make these decisions is lacking.

1.1.2 Design justiﬁcation Throughout the structural design process the engineer uses various models to build his or her design. Various models, scenarios and schematizations are are essential to the design process, and express the justiﬁcation behind the design. This can be thought of as a conceptual design story (Coenders, 2011, p.61), shown schematically in Figure 1.2.

1.1.3 Design tools in practice There are many tools available to the designer: common are modeling packages focused on detailed analysis and documentation. These are, however, not well suited

1 Figure 1.1: Design freedom (opportunities for change) vs. information during the design process. Image courtesy of dr. ir. J.L. Coenders (Coenders, 2011); based on MacLeamy curve (MacLeamy, 2004).

Figure 1.2: Schematic representation of design justification. Image courtesy of dr. ir. J.L. Coen- ders (Coenders, 2011, p.62). for conceptual design because these tools require precise information, while this is often not available early in the design process. Another disadvantage is that these detailed models are often time-consuming to modify following changes to the design. Also, as the output of these tools requires interpretation, which makes it often subject to mistakes (van Maaren and de Vries, 2009). Early in the design process, designers often apply simplified models which are more flexible and insight- providing.

2 1.2 StructuralComponents

1.2.1 Approach Recent years have seen the development of various computational tools to aid the engineer in design work. Most tools focus on either performing routine design (expert systems) or design optimisation, but StructuralComponents takes a different approach: instead of taking the latest technology as a starting point, Structural- Components aims to provide a set of tools to complement existing design strategies. In this way, StructuralComponents aims to provide a kind of digital sketching paper: a design environment where the engineer can develop his or her design justiﬁcation, select tools to perform analysis and where computation serves to perform repetitive tasks, leaving the designer more time to focus on the creative design process. This approach is based on the Structural Design Tools (SDT) approach (Coenders and Wagemans, 2005). The SDT approach suggests, instead of enforcing a single model or methodology, to develop smaller, dedicated tools from a common base. These small, adaptable tools should not focus on complexity or high accuracy, but on giving the engineer control, insight and conﬁdence. Following this approach StructuralComponents provides various calculation models, which can provide results in real-time on a dashboard, giving the engineer an overview of the structural behavior.

1.2.2 Previous research StructuralComponents 1 Janwillem Breider developed the first prototype of StructuralComponents in 2008 (Breider, 2008). This first version focused on two dimensional analysis and design of tall building structures. The prototype was implemented as plug-ins for GenerativeComponents (Bentley Systems, 2013), which provides an environment to compose a structure out of predefined elements and present information on a dashboard. Also a custom analysis engine was developed, which combines classical mechanics with the super-element method: this method makes a shorter computation time possible by reducing the amount of elements. StructuralComponents 2 StructuralComponents 2.0 (Rolvink, 2010) built on the earlier work of Brei- der. The aim of this second version was was to add functionality and improve flexibility. Research into tall building design led to additional components and analysis methods. A new analysis engine was developed, also based on the super-element method. Another important aspect was the development of a modular framework architecture, which allows for extensibility and easy adaptation. The framework itself contains various structural and analysis components. It is built as a plug-in for Grasshopper (McNeel, 2013), but the framework is structured to be independent of the representation software.

3 StructuralComponents 3 The most recent development on StructuralComponents was by Bastiaan van de Weerd (van de Weerd, 2013). His research focused on three main points. The ﬁrst aspect was research into available theory on design. Based on the cyclic and iterative nature of design, he developed a user guided optimization method using quick alternative generation. Second was the development of a custom FEM-analysis engine, which was more generally applicable than the super-element method. Thirdly, StructuralComponents was reimplemented using a client-server based architecture, instead of the previous plugin-based structure.

1.3 Motivation

In addition to the general aspects mentioned in Section 1.1, the motivations for this thesis also concern current limitations of StructuralComponents and the idea of a building model for the conceptual design story.

1.3.1 Current limitations The current implementations of StructuralComponents have some important limitations. Two limitations are particularly relevant to this thesis. Firstly, StructuralComponents is still focused on the design of high-rise structures. The available components cover the modeling of lateral structural systems of tall buildings. StructuralComponents lacks applicability in more common design cases, such as mid-rise structures, in which the lateral structural system is less governing. Secondly, StructuralComponents is limited in describing the conceptual design story. Although design justiﬁcation often relies on a combination of various models, Struc- turalComponents currently supports only one type of model: lateral wind loading on a linear structure.

1.3.2 A building model for the design story Supporting the composition of a multifaceted design justiﬁcation requires a change in modeling approach. The variety of schematizations, analysis models and scenarios used during design (Figure 1.3) cannot all be expressed in a single model. A possible solution is to allow for different representations of a structure within a single building model. In this way not only the design product but also the underlying reasoning and process can be documented. Because these representations exist in one building model, they can be associated and share parameters, such as dimensions and material properties. Through these associations the design parameters can be kept consistent throughout all representations: changes to one representation are mirrored in other representations.

4 Figure 1.3: Various representations used in the design of the Hogeschool voor Dans en Muziek in Rotterdam (de Boer and Henkens, 2001).

Figure 1.4: A building model consisting of various associated representations

1.4 Objectives

The purpose of this research is to extend StructuralComponents further in the direction mentioned previously: to provide early stage design tools for structural designers.

1.4.1 Main objective The objective of this thesis will focus on addressing the points outlined in the previous section. The main objective of this thesis can be formulated:

To develop a new prototype of StructuralComponents which supports creative design exploration and composition of design justiﬁcation.

5 1.4.2 Sub-objectives As part of this objective, three main sub-objectives can be identiﬁed:

1. Investigate the requirements for a tool or model to support a conceptual design story 2. Develop a building model in which the design story of a building can be structured 3. Implement a computational engine to support extending and modifying information in this building model

Other sub-objectives:

• Implement a new user interface for the tool • Implement reusable analysis tools (as a library or links to other analysis software).

1.4.3 Main components These sub-objectives are related to the main components of the software architecture (shown schematically in Figure 1.5). The core of StructuralComponents is the conceptual building model, which deﬁnes how information about a building is structured. The computational engine manages data within the building model, keeping the interrelated data consistent. The analysis library contains the available analysis tools, and the user interface determines how the user can interact with these components.

Figure 1.5: Concept of StructuralComponents 4 software architecture.

To picture this more concretely, these components could be compared to those of spreadsheet software: in that case the conceptual data model is the main idea of storing data in interrelated cells, organized in rows, columns and sheets. The computational engine manages the associations between cells, making sure the data in the cells is always up to date. The analysis library can be seen as the set of formulas available (e.g. sum(), mean(), or sqrt()). The user interface consists of various interactive components: the editable cells, but also the menu and formula bar, buttons, etc.

6 1.4.4 Research questions Corresponding to the main sub-objectives, a number of research questions are formulated: 1. What are the typical patterns and characteristics of the (structural) design process? 2. In what way can the conceptual design of a building be recorded and structured in a building model? 3. How can computation be used to manage information in a developing conceptual building model?

1.4.5 Scope To limit the scope of the research, a number of assumptions are proposed for different aspects of the project.

Structural aspects of building design Design of a building involves many disciplines besides structural design: architecture and climate design are important examples. However, Structural- Components aims to be an engineer’s tool which deals with the design of the building structure. Although the structural design often inﬂuences other disciplines, the scope of this project is limited to structural design. Building typologies The aim of this research direction is not to cover speciﬁc design typologies (such as high-rise, stadiums, shell structures), but rather more common, generic mid-rise structures. This has the advantage of not requiring advanced analysis methods (as is the case of shell structures) and being more widely applicable in practice (mid-rise vs. high-rise). Analysis engine In contrast to the earlier versions of StructuralComponents, development of a custom FEM-analysis engine is not an objective of this project. Software implementation Complete implementation of all features is not the aim of this project. Rather, the focus lies developing modeling concepts to aid in conceptual design. Im- plementation of core features will provide a proof of concept, while some aspects are only designed as a concept and are not implemented in software.

1.5 Thesis outline

This thesis contains the following chapters:

Chapter2: Methodology outlines the overall approach of this project and the methodology for research and software development.

7 Chapter3: Research contains research into (structural) design, conceptual building models, and computational design tools. The chapter concludes with a number of use cases which specify high-level requirements for the prototype implementation. Chapter4: Results describes the main result of this project: the StructuralCompo- nents 4 prototype. The requirements, proposed concepts, and implementation are discussed for each of the main components: user interface, conceptual building model, and computational engine. Chapter5: Validation discusses how the results of the previous chapter address the requirements resulting from Chapter3. This chapter includes a number of practical examples. Chapter6: Discussion reﬂects on the outcome of the previous chapters. It evaluates the relevance of the result within a broader context, and discusses new directions for investigation. Chapter7: Conclusions summarizes the main results and presents a number of recommendations for further research.

8 2 Methodology

Development of a design tool requires a structured approach, in order to ensure quality and veriﬁability of the result. This chapter begins with a description of the overall approach, which forms the basis of the methodology. Section 2.2, 2.3, and 2.4 describe the methodology for research, development and validation in detail.

2.1 Approach

StructuralComponents is based on the Structural Design Tools approach, which states the necessity for an engineering tool to be oriented towards the user instead of focusing on the latest technological developments (see Section 1.2.1). Many different approaches have been developed to take user requirements into account: traditional user-centered approaches, but also newer developments such as Critical Design and Empathic Design. Two main areas of difference can be distinguished between these approaches (Sanders, 2008). The ﬁrst difference is the main drive behind the approach: Research-led approaches follow the classical scientiﬁc method (analysis), while design-led approaches are driven by proposing solutions (synthesis). The second distinction indicates a difference in mindset towards users. Looking from an expert mindset, users are reactive subjects meant to be observed or analyzed. In case of a participatory mindset, users are seen as partners and are actively involved in the design process.

2.1.1 Research and design For this project a classical research-led approach would require extensive research to determine what users require from the StructuralComponents tool. From this analysis, a design proposal could then be deduced. By contrast, following a design- led approach the focus would be on developing a prototype, which can then be improved iteratively in response to user feedback. For this project, both approaches are of use. Research is necessary to study the state of the art and the main principles of conceptual design and modeling. However, due to the fact that there are few conceptual design tools in use, it is not possible to research user’s requirements completely. The complete design of StructuralCompo- nents cannot be simply derived from research, necessitating a partly design-driven approach.

9 2.1.2 Mindset towards users Feedback from end-users is an important validation tool; for StructuralComponents this means involving structural designers when assessing the result. Involvement of an experienced structural designer can provide valuable insights on practical applicability and aspects of structural design. As mentioned in Section 2.1.1, both research and design are integral to this project. A participatory mindset is particularly valuable during the design-phase, to gain feedback on the design proposals. Looking at the overall system architecture (see Figure 1.5, this feedback is most relevant for the conceptual building model, user interface and analysis library. For the design of the underlying computational engine, however, this participatory mindset is less practical.

2.1.3 Overall approach The approach for this project is based on Design Thinking (Brown et al., 2008) and Agile Development (Shore and Warden, 2007). This approach supports a design-led process and allows for user involvement during development. The starting points of the development phase are the result of earlier research. Following the initial assumptions, the development consists of ideation, implementation and testing. The feedback from the testing can then be used to reﬁne assumptions for the next iteration. This iterative approach ensures the development is continuously focused on meeting the correct requirements (see Section 2.3). The overall approach is illustrated schematically in Figure 2.1. The next chapters of this report discuss the end result of this process. A description of the development iterations is given in AppendixB.

Figure 2.1: Overall project approach

10 2.2 Research

The research phase provides the starting points for the development phase. These starting points consist of requirements, assumptions, and high-level use cases. Mir- roring the main components of StructuralComponents 4 (see Figure 1.5), aspects of interest are the (structural) design process, conceptual building models and computational tools. Use cases provide more concrete examples for application of the tool. To develop these use cases the following resources have been used:

• Publications and design documentation of existing buildings • Interviews with structural designers • A case study (see AppendixA) • Observations and personal experience

2.3 Development

The core of this project is the development of the new StructuralComponents tool. The software development cycle generally consists of 4 steps: analysis, design, cod- ing and testing. A development methodology based on Agile methods and Extreme Programming (XP) (Shore and Warden, 2007) is used. In XP, the development steps occur simultaneously and in short iterations. This results in regularly deployable software, instead of a single product delivery at the very end. This development methodology ﬁts well in the design-driven development approach, providing the following advantages:

• Focus on quick setup of core functionality • Iterative implementation based on use cases • Frequent opportunities for user involvement • Possibility to adjust requirements in response to feedback during development

2.4 Validation

The final verification step serves to confirm correctness of the outcome: realization of requirements and the applicability of the StructuralComponents tool in practical structural design problems. Because the software implementation is limited to a proof of concept (see Sec- tion 1.4.5), application in a complete design in detail is unsuitable for validation purposes. Rather, realization of requirements is demonstrated by application of the concepts in the use cases. For each use cases, one or more examples demonstrate how the prototype deals with certain situations. The case study is used to give

11 an overall indication of the progression of a building model throughout the design process.

12 3 Research

This chapter concerns a literature review into the main topics relevant to the objectives of this thesis. Following the research questions in Section 1.4.4, the main areas of interest are design theory and practice, approaches to building modeling, and computational tools. This research forms the basis for high-level use cases and implementation requirements for development.

3.1 Design

The subject of (structural) design is central to the goals of this research. As Struc- turalComponents 4 aims to support the conceptual design story, it is important to understand the basic principles of design.

3.1.1 The design process Design is a complex process and design problems are widely considered ill-defined and ill-structured: there is no single, correct solution (Chapman et al., 2001). The design process is often described as iterative, cyclic or chaotic, and there have been many attempts to map the sequence of events in the design process. Although design often consists of separate activities such as analysis, synthesis and evaluation, the process generally does not occur in a fixed order (Lawson, 2006). Designers, therefore, tend to focus on proposing solutions, rather than extensive problem analysis (Cross, 1982). Design problems are generally multidimensional, requiring breakdown into sub-problems. Solutions are often also complex: integrated solutions solve several problems at once. Design solutions become part of other design problems. Another important characteristic of design are parallel lines of thought: several alternatives are often considered without an immediate attempt to resolve them (Law- son, 2006). When advancing the design, the designer works with his past experiences as well as knowledge of the current subject. This process can be seen as “reflection”: by reflecting on what he is doing, the designer has the ability to develop new interpretations (Schön, 1983). Each representation allows for reflection and development of design into a new direction. These new developments are then available to be re-interpreted (Gero, 1998). This concept of constructive memory is illustrated in Figure 3.1.

13 Figure 3.1: Constructive memory: new interpretations resulting from re-interpretation of earlier design experiences (Gero, 1998)

3.1.2 Representations and design Representations are integral to the design process: to describe problems and solutions requires representation. The objective of design can be deﬁned as the representation of an artifact in sufﬁcient detail for its realization (Mostow, 1985). In engineering design, a variety of representations are necessary to enable description of analytical, geometric or quantitative models (Dym, 1994). Design also requires models at different levels of abstraction and scale, and the designer frequently switches between them. Although designers often proceed in a top-down or bottom- up approach, the overall process and sequence of representations is opportunistic rather than systematic (Visser, 2006).

3.1.3 Structural design This section discusses a number of design aspects characteristic of structural design.

Use of different models

As mentioned in Section 1.1.2, the conceptual design story consists of several different elements. One important aspect in the design justification are models. As mentioned in the previous section, engineering design requires models of various types, and at different levels of abstraction and scale. An important characteristic of structural design is the use of simple as well as complex models: simplifications can be used to make quick evaluations and gain confidence in results, while complex models can provide extra insight (Coenders, 2011). Examples of models are rules of thumb, codes, custom calculations, and wireframe models.

Cases and scenarios

Related to alternatives, cases and scenarios are another main aspect of the structural design justiﬁcation. Cases and scenarios are often expressed from requirements and illustrate how the structure deals with a particular situation. Scenarios are often also used to take into account unfavourable situations. Especially in early design, various assumptions are made in order to obtain sufﬁciently conservative values.

14 Preliminary vs. deﬁnitive design

The structural design process runs from preliminary design to definitive design, and finally design for tender and realization. Aside from those mentioned in Sec- tion 1.1.1, there are a number of key aspects to note as design progresses from preliminary to definitive design. One of the main areas of difference is that preliminary design is mostly concerned with the overall feasibility of structural systems, not with each individual structural element. Only in later stages, when verification of more detailed design is necessary, are all members necessarily defined. Another key difference is that during preliminary design of typical buildings, structural designers mostly work in 2D representations, combining these along the main axes of the building to obtain insight into 3D behavior (Baker et al., 1987).

3.2 Modeling

One of the main elements of StructuralComponents 4 is a building model which covers composition of the conceptual design justiﬁcation. This section discusses the existing computer models, tools, and their effectiveness in supporting conceptual design composition.

3.2.1 Models in practice In current engineering practice, software tools are frequently used to model buildings. Most of these models focus on representing a structure precisely and in detail, for the purpose of (FEM) analysis and documentation (CAD). As described earlier (in Section 1.1.3), these models are not suitable for the early stages of design:

• In the conceptual design stage, precise information is often unavailable and exact results are not required. • Constructing and modifying a detailed model is time-consuming. This is impractical in the early design stages when design changes are frequent. • These models are limited in their ability to describe underlying design reasoning. • These models only represent one “reality”, and do not account for scenarios or alternatives.

3.2.2 Building Information Modeling (BIM) A growing trend in the building industry is Building Information Modeling (BIM). There are many different technologies which can be categorized as BIM, but the deﬁnition of BIM itself is unclear (Race, 2012). The aim of BIM-technology is to facilitate information creation, storage and transfer across disciplines in the design

15 process. In the broad vision of BIM, computation facilitates information management throughout the entire design process, but this is currently not the case (Coen- ders, 2011): in practice, BIM often means a single 3D-model in which information from various disciplines is combined. An important advantage, however, of this type of BIM-model is its object-orientation: while traditional CAD models often only contain geometric data, a BIM model consists of objects, which can contain various properties and design information. This allows complex models to be richly populated with information, allowing for more accurate and comprehensive analysis and documentation. However, because these detailed 3D-models require precise information and are complex to build and modify, their advantages for the conceptual design stages are limited (Sacks and Barak, 2008).

3.2.3 Building models for conceptual design Although most building models are aimed at the later design stages, a few representations have been proposed to support the early design process. One such development is SEED (Rivard et al., 1995), a software environment to support the early stages of building design. SEED’s modeling approach is object oriented, but it aims to support design evolution as well as to provide a standardized building model to allow for case-based design, allowing designers to apply knowledge from earlier designs. From a central model, conceptual building models are derived for each discipline. Objects in each model are organized hierarchically and relationships can be defined between them. In the structural model, all possible structural elements fit in a pre-defined top-down hierarchical decomposition (Rivard and Fenves, 2000). This hierarchical division has been adopted by several other design tools such as StAr (Mora et al., 2008), a system for collaborative structural and architecture design. Although the design process is often mostly top down, this strict decomposition limits design evolution, which often switches between different scales. The centralized modeling approach also limits its flexibility: while the model may be extensible, interoperability between disciplines depends on the use of standardized concepts, making it impractical to adapt the model to each design. An alternative to this centralized modeling approach is to adopt a federation of proprietary models, which allows users to determine their own modeling standard (Coenders and Wagemans, 2005). In order to support conceptual design, it is important that models not inhibit the designer’s creative process: models can cause fixation on existing patterns or blindness to design options that cannot be expressed by the model. In order to provide sufficiently versatility, conceptual models should not focus on strict definitions, but allow room for interpretation. This can be achieved by implementing very generic components, incorporating both structured and unstructured data, and allowing different views within the same model (Turk, 2001).

16 3.3 Computation

As models become more complex, they generally become increasingly inﬂexible due to the large amount of information they contain. Various computational solutions have been developed to automate information management and eliminate repetitive tasks.

3.3.1 Parametric and associative software The last 10 years have seen the development of parametric and associative design (PAD, or ‘parametric’) systems. PAD systems address the problem of inflexibility by not just storing parameters, but also their underlying logic and relations. When parameters are modified, associated parameters are also updated automatically. A familiar example is spreadsheet software, in which information can be set manually, or calculated automatically by associations with other cells. Specialized PAD systems focus on 3D geometric modeling, and often contain powerful tools for vector operations and spatial transformations. Important examples are Grasshopper (McNeel, 2013), GenerativeComponents (Bentley Systems, 2013), DesignScript (AutoDesk, 2014) and CATIA/Digital Project (Gehry Technologies, 2014). Application of these systems makes it possible be create and analyse complex models earlier in the design process (Holzer et al., 2008). These tools, however, have their limitations: firstly, PAD systems are mainly limited to geometrical representation of a design: structural concepts are not included in the previously mentioned systems. Also, while change is possible rather easily within a certain range and logic, change and exceptions outside these defined limits or to the logic of the model are difficult. Another limitation of PAD systems is that relationships between objects are single-directional (i.e. can only be traversed in one direction). This imposes a limit on the design process which often relies on backtracking and feedback-loops (Coenders, 2011).

3.3.2 NetworkedDesign NetworkedDesign is a proposed infrastructure for computational design (Coenders, 2011). In this PhD thesis, Coenders uses observations concerning the building industry, structural design and computation to formulate a computational (structural) design theory. Comparing the theory to the functionality provided by parametric and associative design technology, he concluded that these still have signiﬁcant limitations. A new infrastructure is proposed to facilitate future development of structural design systems. Although its concepts have not been fully implemented, Networked- Design offers some advantages over traditional parametric and associative design systems. Especially relevant for this research is the possibility for bi-directional object relationships, making feedback loops possible and switches, which allow for alternative representations.

17 3.4 Conclusion (use cases)

To illustrate high-level requirements, a number of general use cases has been developed. These are illustrated in the format shown in Figure 1.4 (associated representations in a building model).

3.4.1 Decomposition and integration Analysing design problems by decomposition is elementary to the design process. When investigating a new direction, it is often necessary to base this on earlier information. This can be made possible by allowing new representations to be derived from other representations. To ensure the entire design remains consistent, changes to each representation should also be reﬂected in related representations.

This additional information should also be able to be integrated into related representations.

18 3.4.2 Considering alternatives in parallel Considering alternatives is integral to the development of design. Alternatives allow the designer to explore various solutions to a problem. To make decisions, it is important to compare these alternatives: alternative representations must be able to co-exist.

It should be possible to experiment locally, without immediately resolving all incon- sistencies within the system.

3.4.3 Applying various analysis models In analyzing the structural behavior structural designers employ a variety of models. These can be used to approximate behavior, or validate other models: several types

19 of models should be available for describing the behavior of a structural system.

3.4.4 Modeling cases and scenarios Cases and scenarios are an essential part of design justiﬁcation. It should be possible to consider not one, but several of cases and scenarios (e.g. ﬁre, imperfections, and special loads).

3.4.5 Evolution from preliminary to detailed design The focus of design changes as it moves from preliminary to deﬁnitive design: these changes include development of 3D models and individual member sizing. A building model must be able to be developed in these directions.

20 3.4.6 Expressing design justiﬁcation In order to communicate the design story effectively, it needs to be possible to represent the justiﬁcation based on reasoning, models, and scenarios.

21 This page has been intentionally left blank. 4 Results

This chapter describes the design of StructuralComponents 4. Section 4.1 gives description of the application as a whole. The sections thereafter describe the requirements, underlying concepts, and implementation of the three main components: the conceptual building model, computational engine, and user interface. As per the methodology, the prototype is the result of an iterative process in which the concepts are implemented and tested. The following sections describe the end result of several iterations; development of these concepts throughout the iterations is given in AppendixB.

4.1 Application architecture

This section describes the design of the StructuralComponents 4 application as a whole: requirements, concepts, and implementation at software-architecture level.

4.1.1 Requirements Extensibility The application must be developed in such a way that functionality can be extended without requiring fundamental changes to the application. Although this is a prototype implementation, extensibility is crucial to allow further work. Presentation independence In order to support code reuse and allow for re-implementation, a separation must be maintained between the application logic and its presentation.

4.1.2 Concept The main structure of StructuralComponents 4 follows the project structure and conceptual software architecture outlined in Section 1.4.2 (see also Figure 4.1).

Figure 4.1: Conceptual StructuralComponents 4 software architecture

23 The central component is the building model: the data structure used in modeling a building structure. The underlying computational engine serves to keep the data relationships updated. Finally the user interface allows the designer to interact with the building model.

4.1.3 Implementation The application has been implemented in C#, utilizing the .NET Framework (www. microsoft.com/net), in order to allow for integration opportunities with Networked- Design (also implemented in C#), and because of C#’s expansive GUI framework (WPF) (https://msdn.microsoft.com/en-us/library/ms754130). The following sections describe high-level implementation.

Architecture pattern

The application is organized according to the Model-View-ViewModel (MVVM) design pattern. Similar to the classic Model-View-Controller (MVC) design pattern, MVVM facilitates the separation of the graphical user interface (View) and business logic (Model). In MVVM, the ViewModel contains the interaction logic between the view and model, consisting of view-speciﬁc commands and data bindings (see Figure 4.2).

Figure 4.2: Illustration of the MVVM architecture pattern (https: // msdn. microsoft. com/ en-us/ library/ gg405484, retrieved april 2015)

In the case of StructuralComponents, the “Model” domain consists of the building model and computational engine: the conceptual building model refers to the classes which describe entities in the building model, while the computational engine deﬁnes their interactions. The user interface is implemented by Views and ViewModels: the viewModels deﬁne interactions with the underlying models, while the view determines the graphical appearance (see Figure 4.3).

Automated testing

Automated testing allows for straightforward refactoring and extension of functionality. Application of the MVVM architecture pattern allows for testing of each component individually. Units tests cover the functionality of all model and viewmodel classes.

24 Figure 4.3: Detailed StructuralComponents application architecture

Automated UI (view) testing is not implemented due to time constraints, and is tested manually. Considering the function as a prototype, exact appearance is not critical and omitting automated UI testing is warranted.

4.2 Conceptual building model

Central to the StructuralComponents implementation is the datamodel: the conceptual building model to contain the design story. The next sections discusse requirements from research, concepts devised to address these requirements, and the implementation in software.

4.2.1 Requirements Flexible design process structure In order for the conceptual building model to support a process as complex as design, it should not attempt to enforce a particular sequence of design steps, but focus on enabling the designer to take the steps he/she deems necessary. Multi-dimensional design problems and integrated solutions Design is characterized by the interaction between problems and solutions. The building model should support complex design problems which inﬂuence a number of solutions, as well as integrated solutions which target several problems. Parallel alternatives An essential part of design is the consideration of alternatives, without immediate attempts to resolve them. The building model should allow multiple variants to be able to co-exist. The user must be able to easily switch between them. Different types of representations

25 The use of a variety of representations is central to design. It should be possible to create the analytical, geometric, and quantitative representations within a single model. Representations at different levels and abstraction and scale During the design process, representations are also created at various level of abstraction and scale. The building model must support representation at various levels and abstraction simultaneously. Various analysis models Characteristic of structural design is the use of various analysis models. The building model should support various modelling approaches, ranging from simplified to complex models. Reasoning with cases and scenarios Modeling with cases and scenarios is an essential part of design justification. The building model should allow the designer to formulate cases and scenarios, and apply them when necessary. Preliminary and detailed design As design progresses, the general focus changes from investigation into overall feasibility of structural systems to detailing and verification of individual elements. The building model must support modeling needs throughout these various design phases.

4.2.2 Concepts As mentioned in Section 3.1.1, (structural) design encompasses a variety of subjects: design problems and solutions, alternatives, reﬂection, representations, models, scenarios and cases, etc. In order to structure this information, the StructuralComponents building model consists of four main domains: components, reasoning, modeling and geometry.

1. The component-domain consists of the design subjects and contained design information. For example, a beam and its length. 2. In the reasoning-domain, the justiﬁcation behind this design information is described. For example, the reason behind a parameter value, or a design decision. 3. The modeling-domain contains models and calculations used in this reasoning. For example, a beam model. 4. The geometry-domain is used to describe dimensions, shape and ﬁt.

Conceptually, these layers express the answer to the fundamental questions “what is being designed?” (components), “why?” (reasoning) “how?” (models), and “where?” (geometry).

26 The following sections describe six main features of the building model. Only the geometric domain is not addressed here (see Section 6.3.4).

Concept 1: “Blank slate” components

Target requirements: ﬂexible design process structure, different levels of abstraction and scale, different types of representations

In order to support creative design progression, the StructuralComponents building model adopts a non-standardized approach to modeling. As mentioned previously, one of the limitations of current models is the requirement for exact and detailed information. Components in traditional or BIM models often have strict definitions on which properties must be specified, dictating the information the designer must provide. As discussed in Section 3.2.3, this type of model not only directs the designer towards a limited set of standardized solutions, but also causes blindness to problems and solutions not able to be expressed in the model. Considering the goal of the StructuralComponents design tool to complement the design process and not impose restrictions, a different strategy for conceptual modeling is proposed: “Blank slate” components. One part of this approach is simplicity. Providing the designer with simple, elementary building blocks is essential for fostering creativity as they make it possible to create a large set of designs. This idea is exemplified by the original LEGO-brick: although recent LEGO-kits may provide more specialized components, it are the most simple, traditional bricks which allow the greatest diversity in constructions (Resnick et al., 2005). Another central aspect of the “blank slate” components is adaptability. Although standardization has certain advantages (e.g. consistent definitions, interoperability, straightforward indexing, etc.), they are by nature less innovative than design itself (Coenders, 2011). In order to avoid the fixation and blindness associated with strict, standardized definitions, it is important account for a variety of different interpretations. This can be achieved by supporting customization and evolution, but also structured as well as unstructured data. This idea is exemplified by pen and paper: even with widespread adoption of computational design tools, pen and paper are still popular amongst engineers because they are almost infinitely adaptable and do not limit the creative process (Turk, 2001). This concept is is implemented in the StructuralComponents building model by “components”: the information-containers of the building model. Components are basic building-blocks: at their core, components are simply named abstractions of structural features such as a beam, core, truss, or stability system. The designer determines the components of the building model and the model itself does not enforce any methodology or process. Because the designer can determine his or her own abstractions, the building model becomes not only more flexible, but also more insightful: it does not simply consist of a collection of low-level elements such

27 Figure 4.4: Two practical design tools exemplifying the concepts behind “blank slate” components. Like traditional LEGO-bricks, simple components make it possible to compose a large variety of constructions. Similar to pen and paper, highly adaptable tools enable the designer to express the design without strict limitations. as beams and columns, but a representation closer to how the designer views the structure. Tools for conceptual design partially make this possible through high-level components (Rivard and Fenves, 2000), but design uniqueness can most effectively be expressed through user-deﬁned components (see Figure 4.5).

Figure 4.5: The signiﬁcance of custom objects in describing a building design: BIM and other traditional tools deal with low-level objects such as beams and columns. Tools for conceptual design include deﬁnitions for higher-level objects. However, often much of the “intelligence” of the design lays in components which are unique to the situation. Example from (de Boer and Henkens, 2001)

When a component is created, it similar to a blank sheet of paper: there are few restrictions and many possibilities. Adding and modifying information about the component is possible trough attributes, which are used to represent any property of the component: e.g. materialization, length, stiffness, structural principle, weight,

28 load, etc. Through the flexibility of attributes the component becomes highly adaptable. Firstly, it allows a component to evolve during the design process: attributes are created by the designer, allowing the component to follow the design process instead of dictating it. For example, the designer can give an initial indication of the thickness of a floor slab, without immediately needing to specify the concrete type or reinforcement. Second, by not limiting available attributes to a fixed set, unique situations can also be easily represented. For example, attributes can be used to describe situational requirements, such as architectural or functional demands. Lastly, attributes can not only contain quantitative, but also qualitative information. This allows description of exact, calculable parameters (e.g. deflection, material properties, loads), but also high-level or even subjective information such as function or structural principle. Examples of components are (see Figure 4.6):

• A beam with a length, load, and height • A truss with a particular type (e.g. Warren truss) and section proﬁles for chords and bracing. • A foundation pile of a certain type, and an initial value for axial stiffness. • A connection between structural elements. Attributes describe in which direction the connection is constrained, its strength, and execution. • A core stability element with a height, wall thickness, and material properties. • A stability system describing walls of various stiffnesses.

Further examples of components can be found throughout Chapter5.

Figure 4.6: Examples of customized components

29 This modeling approach offers several opportunities. Firstly, its general approach does not limit the model to buildings of a standardized typology. For example, a par- tial structure such as an atrium or annex could be represented. Even non-building type structures such as bridges could potentially beneﬁt from this approach. Sec- ondly, working with custom deﬁned components also keeps the designer in charge of where design is focussed. The designer is not only free to choose which components to use, but also when to include them in the model.

Concept 2: Hierarchical component breakdown

Target requirements: ﬂexible design process structure, different levels of abstraction and scale, preliminary and detailed design

The previous concept showed how simple, adaptable components can be used to represent the elements of a structural design: low-level components such as beams and columns, but also high-level components such as a core, truss, or stability system. This modeling approach accounts for variations in abstraction and scale, but does not offer an approach to model these levels simultaneously. For example, a core or truss may initially be represented as a single element, but can later be represented as a collection of sub-elements. How can a building model include both high-level components and low-level components in a structured way? This issue is addressed by the concept of hierarchical component breakdown. As discussed in Section 3.2, the design tool SEED addresses the issue of simultaneous levels of abstraction by offering a standardized hierarchical decomposition: high- level components can be broken down into subcomponents (Rivard and Fenves, 2000). In this way, a top-down breakdown of the structure is represented with several abstraction levels. The StructuralComponents building model implements a similar approach: Each component may be related to a number of “child” or “parent” components. How- ever, because of the ﬂexibility of components, the designer is not restricted to one particular hierarchy, or a even a strictly top-down process. Combined with “blank slate” components, the designer can create components at any abstraction level, but also develop these components further by integrating or decomposing them into other components when necessary. Figure 4.7 shows several examples of applications for hierarchical component relationships:

• A truss can be decomposed into chords and bracing. • A building can contain structural systems for lateral and vertical loading. • If a beam has a special cross-section, its design could be encapsulated in a subcomponent. See also Figure 4.8. • A group of columns could be designed as one component, with subcomponents for each speciﬁc instance. See also Figure 4.8.

30 • A ﬂoor structure can consist of slabs and supporting beams. See also Fig- ure 4.8. • A wall can be part of several structural systems, indicating its function for both vertical and lateral support.

Figure 4.7: Examples of hierarchical component relationships.

Also, in the StructuralComponents building model, related components (such as parent-child) may reference each other’s attributes. Figure 4.8 shows several examples of applications of attribute references:

• A group of columns designed collectively, but detailed individually: the column group defines a cross-section and concrete type, which is “inherited” by the individual columns. The design axial force, however, can be defined for each column separately. • The design of floor subcomponents: the floor may contain attributes concerning loads and requirements. These can be passed on to the beam and slab components. • The stiffness of a composite beam: the cross section component may contain specific information about profile geometry, relative stiffnesses and execution. For the beam component itself, only the resulting stiffness may be relevant.

31 Figure 4.8: Examples of attribute references in parent-child component relationships

Concept 3: Reﬂective design reasoning

Target requirements: multi-dimensional design problems and integrated solutions

The previous concepts show how a large variety of design information can be represented as attributes in a hierarchical breakdown of structural components. The justification behind this information, however, is not yet indicated. For example: what is the reason behind a specific requirement, or the process that has lead to a component parameter? The concept of reflective design reasoning addresses this issue. As discussed in Section 3.1.1, making design decisions is a complex process without a specific sequence. Thus, the building model does not aim to enforce a specific sequence of steps, but follows the more general model of reflection and constructive memory (Gero, 1998): reflection within a certain context leads to new insights, which can be used as context for future reflection. Mirroring this principle, a design step in the StructuralComponents building model consists of three elements: context, reasoning, and outcomes (see Figure 4.9). The context represents the situation being reflected upon: a collection of component attributes. Reasoning represents the logic which is applied as a result of the context. The result of this reasoning are several concrete outcomes: values which are added back into the model. This representation of design steps is general enough to support both analysis, synthesis, and evaluation. For example:

• Analysis

– Context: a beam with load, length, and stiffness – Reasoning: a beam calculation

32 – Outcomes: beam deﬂection, bending moments

• Synthesis

– Context: a ﬂoor with a large span – Reasoning: prefabricated slabs are most cost-effective for spanning large distances. – Outcomes: prefabricated slabs ﬂoor type

• Evaluation

– Context: a beam with a deflection and maximum allowable deflection – Reasoning: the deflection is acceptable if it is less than the allowable deflection. – Outcomes: deflection OK or not OK

Figure 4.9: Design steps in the StructuralComponents building model, based on the principle of reﬂection and constructive memory (Gero, 1998)

This approach supports the cyclic nature of design: as in the model of constructive memory, the outcome of a design step may be context for another. In this way a chain of decisions can be created. For example, the deflection of a beam is the outcome of an analysis step, but potentially part of the context of another (evaluation) step. An additional advantage of this approach is that it allows investigation into both the implications of, and reasoning behind design choices. For example, the choice for the floor system may be affected by acoustical requirements, span distance, and other functional requirements. Conversely, the choice of floor system affects the dead load, which in turn affects de design of the vertical load bearing structure, as well as the stability system. Another implication of this representation of reasoning is that the context of design decisions can be monitored. The design-step can be notified of any changes to its original context. For example, a decision for a floor type based on a span distance may need to be revisited when the span distance changes. Some other examples of reflective design reasoning (see Figure 4.10):

33 • The initial height of a beam can be estimated based on its span, using a rule of thumb. The applied load may also be included in the reasoning. If the span changes, the designer is notiﬁed that the value for the beam height may no longer be valid. • The stiffness of the foundation may not be able to be determined precisely during the preliminary stages. Thus, an initial estimate can be made based on the execution method. This value can then be used for a quick stability calculation. • A collection of ﬂoors may have a common function. The live load can be deduced by making use of a design code. • The observation of a large tensile force in a concrete beam may necessitate pretensioning. This qualitative judgement can also be included as a design step.

Figure 4.10: Examples of reasoning steps within components

Concept 4: Analysis models as automated reasoning

Target requirements: various types of analysis models, different types of representations

The concept of reflective design reasoning shows how the justification behind design information can be structured. However, often this reasoning makes use of relationships expressed by a code, formula, model, or rule of thumb. When the context of design step changes, the designer is notified, but must redetermine the outcome manually. To prevent repetitive work, the building model supports definition of automated logic in design steps. This way, when a parameter changes, the affected design steps are not only notified, but also recalculate their outcomes if automated logic is defined. In the StructuralComponents building model, this automated logic is recorded in an

34 “analysis model”. An analysis model consists of input- and output-parameters, and a relationship. In a simply supported beam model, for example, length and load are input parameters, the bending moment at the center is an output, and the relation 1 2 relationship can be described with the formula M = 8 qL . This format also allows for a description of various rules of thumb, codes, and math- ematical functions. Figure 4.11 shows examples of application of models:

• A simple beam model can be used to determine the bending moment and the center of a beam. Both a model for hinged and ﬁxed supports may be used. • The initial thickness of a concrete ﬂoor can be calculated with a rule of thumb, based on the maximum span and applied load. • The wind load on a building can be determined by a design formula, based on the building’s location and height. • An automated unity check can be applied to a column component in order to monitor its performance.

Figure 4.11: Examples of application of models

This approach to analysis models offers a number of opportunities. Firstly, by allowing multiple models per component, the designer is not only able to apply various modelling approaches, but also to indicate multiple functions per component. For example: a ﬂoor may be modelled as a slab under vertical load, but also as a stiff plate which transfers lateral loads to the stability elements. Secondly, this approach not only allows standardized mechanics models, but also the inclusion of customized formulas or situational rules of thumb. For example, a specialized formula can be applied to a concrete element to estimate the required reinforcement. Lastly, because the model is applied within a design-step, it is the designer who determines the context and scope of a model. For example, the engineer can determine which “length” parameter to use for a certain analysis. Also, the engineer determines where to use

35 the outcome of the model, and he or she can also apply additional design-steps to interpret the outcomes further.

Concept 5: Alternative values

Target requirements: parallel alternatives

The use of alternatives is an essential part of design. Alternatives range from alternative values to complex, detailed variants or combinations. The building model supports the most simple alternatives through alternative attribute values: the designer may assign more than one value to an attribute. For example, different steel sections can be assigned to the “section proﬁle” attribute of a beam. This approach offers a number of opportunities: Firstly, this parallel storage of information allows the designer to alternative quickly between these values. When the alternative is switched, any dependent design-steps are also notiﬁed, allowing the effect of the change to be seen. Second, each attribute value can be given a description, or is the result of a reasoning step which indicates its purpose. For example, values can be indicated as “conservative”, “upper-bound”, “initial assumption”, or “second-order”. Finally, multiple values per attribute also makes the application of various models more straightforward by allowing the outcomes of various models point to the same attribute. Figure 4.12 shows some examples of alternative values:

• Two alternatives for the materialization of a column can be considered. • In analysing the stiffness of a shear wall, different values can be chosen for the elastic modulus of concrete assuming the concrete as cracked or uncracked. • The model of a beam which is part of a rigid frame can be approximated by two extremes: a beam on hinged or fixed supports. In the building model, both these analysis models can be used to find a value for the bending moment at the center of the beam. • In the conceptual design stages, a rule of thumb can be used to determine the thickness of a concrete floor. Later in design, a more detailed calculation may yield a more accurate indication.

36 Figure 4.12: Examples of alternative values for attributes

Concept 6: Component variants

Target requirements: parallel alternatives, cases and scenarios

The previous concept showed how the most basic form of alternatives can be represented: alternative values. In practice, alternatives are often more complex combinations. For example, alternative concepts for a floor structure are often combinations of different beam- and slab-types, as well as different spans. In order to address these alternative combinations, the building model supports component “variants”. Per component, multiple variants can be created, with each variant recording a different configuration of alternative values. One of the variants is marked as the “current” or “default” variant. In this way alternative values can be combined in a meaningful way. In the example of a floor structure, different values for a slab type and span can be combined into two or more main alternatives (see Figure 4.13).

Figure 4.13: Two component variants illustrating combined alternatives for a ﬂoor structure.

37 Component variants can also be used to describe scenarios. Scenarios are used to describe certain characteristic situations, often combining several conservative assumptions. For example, in order to calculate an unfavourable value for the rota- tional stiffness of a foundation, a lower number of piles can be assumed, as well as a more conservative estimate for the average pile stiffness (see Figure 4.14).

Figure 4.14: Two component variants illustrating combined scenarios for a foundation structure.

The building model also supports combining of component variants. With each association between components, the designer can specify which variant of the component to use. For example, when referencing the foundation from a shear wall component, the designer can choose which foundation scenario or alternative to use. Combining variants in such a way offers a number of advantages. Firstly, this allows local experimentation with alternatives: the designer can create a new variant and experiment with different values without affecting the rest of the model. At a later time this variant can be included in the rest of the model by marking it as the current variant. Alternatively, the new variant can be introduced in steps, by up- dating each association with other components separately. Secondly, combined with the hierarchical component structure, variant referencing makes it possible to manage a complex alternative tree. At higher abstraction levels, the number of variants can be reduced to a few main variants, instead of a cumulative total of all possible combinations (see Figure 4.15).

38 Figure 4.15: Hierarchical component breakdown and variant-component references reduce the number of high-level alternatives

Other concepts

Templating In order to provide a starting point for design, StructuralComponents supports basic component templating. A component and its attributes can be saved as a template for later use. Analysis model export and import Analysis models can be saved for use in other building models. This makes it possible to build a simple analysis library.

4.2.3 Implementation

Figure 4.16: Simpliﬁed UML class diagram showing main datamodel components and their associations

39 The above ﬁgure shows the main elements of the conceptual building model. These are discussed below.

Component The component’s main function is to group attributes. Component states (alternatives and scenarios) are managed by its base class , ChangeManager (see Section 4.3.3). Attribute Attributes contain a number of alternative values, and expose a single value for each component state. DesignStoryItem Attributes form the context of a design-story item, which represents a reasoning- step. The design-story item may reference an analysis model for automated logic, in which case the design-story item also stores the mapping from context to input-parameters and from output-parameters to outcome. The outcome of the design-story item is a list of attribute values. AnalysisModel In an analysis model, a scripted relationship is deﬁned from input- to output- parameters. The script is stored as text, and is compiled during runtime for use in design reasoning. AnalysisModelParameter Both the input- and output-parameters of the analysis model are of this type. Parameters can be numeric or non-numeric, and deﬁne a human- and machine- readable name. ValueContainer Attributes reference a number of value containers as alternative values. At- tributes themselves and attribute-values are both derived from this class. This base class is described in more detail in Section 4.3.3.

4.3 Computational engine

This section describes the computational engine behind the building model, which functions to keep information consistent within the system of interrelated elements.

4.3.1 Requirements Change propagation The building model implements several relationships between elements: for example, attributes reference other attributes or values and design-story items reference a collection of attributes (“context”). The effect of changes must be registered by all dependent elements throughout the model.

40 Alternates and scenarios Different variants (scenarios, alternatives) are a central aspect of the conceptual building model. An attribute may contain several values, and a component can host a variety of scenarios.

4.3.2 Concepts

Value containers and dependents

In order to implement change propagation, the computational engine distinguishes value containers and dependents. In the building model, component attributes are containers, and design-story items are dependents: attributes notify dependent design-story items when their value changes. In response, the design-story item can set the value of other value containers, leading to a chain of change propagations (see Figure 4.17).

Figure 4.17: Change notiﬁcation from value containers to dependents. New value changes can be initiated as a result.

Switches

Attributes, however, are not limited to one value, but may contain several alternative values. The attribute can be represented as a “switch” (Coenders, 2011): dependent on the state of the switch, one of the alternative values is active. In terms of change propagation, a switch is both a value container and a dependent: it contains a value (dependent on its state) and it is dependent on changes of its alternative values.

41 Figure 4.18: Value switches expose one of several alternative values.

Containers and states

In order to support component variant, the computational engine implements an additional level of control over the states of multiple switches. This control is represented as an overarching “state” for a collection of switches. This requires all switches to be associated with a certain container (i.e. the component), and each container to have one or more states. Within this container, the state determines the setting of each switch, see Figure 4.19.

Figure 4.19: A state records the individual settings of each switch within its container. In this case both switches direct to a different value for states A and B.

As discussed in Section 4.2.2 (concept 6), variants of different components can be linked. For the computational engine, this means that each state determines under what state other containers are referenced. This allows references to values between containers without explicitly deﬁning the state for each value dependency.

42 Figure 4.20: Associations between states determine which values from other containers are referenced.

4.3.3 Implementation The computational engine is implemented as a variant of the “observer” software design pattern, which describes the relationships between subjects and dependent observers. The pattern allows for an abstract coupling between subject and observer, which provides re-usability, and supports broadcast communication, which separates the concerns of notifying and handling of this notiﬁcation (Gamma et al., 1994). The concept of containers and states complicate the subject-observer dependency, because these determine when certain values are active. This behavior can be encapsulated in a “change manager” object, which maintains the relationships between subjects and observers and handles updates according to a particular strategy (Gamma et al., 1994). Figure 4.21 shows the main elements of the computational engine. ValueContainer and IValueObserver form the central subject and observer of the design pattern. The ChangeManager and its contained State s determine the routing of change notiﬁcations and value retrieval.

43 Figure 4.21: Simpliﬁed UML class diagram showing the main components of the computational engine, and their concrete implementations in the building model.

IValueObserver The value observer is implemented as an interface, in order to ensure a loose coupling between subject and observer. The interface exposes a NotifyValueChanged method to notify the observer of a value change in a particular state. ValueContainer The value container exposes a GetValue method to retrieve the value for a particular state. Value containers also contain a list of observers. ValueSwitch The value switch is a special case of the value container. A switch observes several other value containers, and can route notifications and GetValue requests according to a specific state. ChangeManager All notifications and value requests are handled through the change manager. The change manager routes these values according to its state. State The state records a state of the change manager. This state includes the settings for the value switches (i.e. which value to relay). Each state also handles references between change managers, by observing their states.

4.4 User interface

Although the user interface is not the main focus of the application, it is an important factor in determining usability. This section describes the general requirements and

44 the resulting concepts and implementation.

4.4.1 Requirements Low threshold For design tools, it is essential to not inhibit the creative process. One important consideration is that the user interface should make it easy to get started (Resnick et al., 2005). Ideally the tool should be familiar to designers without advanced computational experience. Overview It is important to keep an overview during design: in a complex system of components, values and alternatives, the user must not be overwhelmed.

4.4.2 Concepts

Graph interface

In contrast to earlier versions of StructuralComponents, which feature a dashboard interface (Rolvink, 2010), the main interface of StructuralComponents 4 follows a graph-based UI pattern. This pattern can be found in design systems such as Grasshopper (McNeel, 2013) and NetworkedDesign (Coenders, 2011). A dashboard interface pattern is aimed at object monitoring. Because the central concept of this implementation is not one, but a collection of interrelated components, a graph representation is more suitable.

4.4.3 Implementation Figure 4.22 shows the main UI elements. The central view contains a graph representation of the building model components. The list of applied design-story items are displayed in the top-right. The analysis library, a collection of available models, is displayed in the bottom-right. Commands for creating, and editing elements of the building model are accessible in a toolbar at the top of the window.

45 Figure 4.22: Overview of the main user interface

Component tree

This main view serves to display the components, their relationships, and attributes. It is implemented as a “canvas” type control, on which components can be created and positioned. Components can be expanded to reveal their attributes. Lines indicate component relationships; these can be created by dragging lines between component connectors.

Design story

The Design-story view displays the list of applied reasoning steps. Each of these items can be expanded to reveal a detailed view of the context, reasoning, outcome, and analysis model used (see Figure 4.23). The context is composed by dragging attributes from the component tree. Outcomes are added in the design-story item interface, and can be dragged to the component tree to link it to an attribute.

46 Figure 4.23: Detailed overview of a design-story item

Analysis model view

Customized analysis models can be deﬁned by the user. In the interface (see Fig- ure 4.24), the user can deﬁne the input- and output-parameters and write a script in which the output parameters are calculated.

Figure 4.24: Editing an analysis model

47 This page has been intentionally left blank. 5 Validation

This chapter describes the evaluation of the results outlined in the previous chapter: how the developed concepts have addressed the requirements. This chapter is divided into two sections. The ﬁrst section describes a number of practical applications of the conceptual building model: the use cases and case study. Based on these applications, the second section evaluates the implementation of each component in regard to the predetermined requirements.

5.1 Examples

As described in Section 2.4, the goal of these practical examples is not to replicate a design or process in detail, but to indicate how the devised concepts can be applied to practical situations. The use cases describe several speciﬁc situations which illustrate high-level requirements for the tool. The case study is meant to illustrate the development of a building model throughout a series of situations.

5.1.1 Use cases The practical examples for the use cases have been taken from the structural design of the RAI Elicium (Arup Amsterdam, 2009). The Elicium building is an expansion of the RAI conference center in Amsterdam. The building consists of a large exhibition space (2.500 m2) 5 m above street level, a conference center (800 m2), and a seven- story ofﬁce tower. Distinctive structural features include the slender concrete cores, the large column-free exposition space, the overhanging conference spaces, and the slanted columns supporting the exposition ﬂoor (see Figure 5.1).

Figure 5.1: An overview of the RAI Elicium building in Amsterdam. Left: an overview of the main parts of the building. Right: a cross section showing the large span in the exposition space, the ofﬁce tower with core, and the overhanging conference center.

49 Decomposition and integration

The first example of decomposition in the case of the RAI Elicium is the identifi- cation of the boundary conditions and initial assumptions during the preliminary design stage. At this stage, these include functional requirements, loads, safety requirements, and assumptions about composition of the floor structure. In the StructuralComponents building model, this information can be structured effectively through decomposition. Global assumptions which influence the entire structure can be defined at the level of the whole building. Specific requirements for each of the elements can be defined in their subcomponents (see Figure 5.2). Examples of global requirements include:

• The wind load across the height of the building is based in its location in wind zone II. Values for the wind load of all building elements are derived from this value. In a similar way, the representative snow load can also be defined. • In the case of this specific building, the width of the building is constant. Thus, this parameter can be defined centrally. Other global parameters such a material properties could also be defined in this way. • This project falls into safety category 3, which means all loads are multiplied by an additional safety factor. This parameter will influence load calculations of all components. • Due to the urban location of the structure, a number of restrictions are imposed on the execution: noise pollution must be minimized and prefabricated components are preferred in order to reduce disruption to the RAI and sur- roundings. This global decision has influence on decisions for the structural principles of all subcomponents. For example, the choice of foundation type is greatly influenced by this consideration. Considerations regarding sustain- ability can be defined in a similar fashion.

For each of the main subcomponents of the building (exposition space, conference center, and ofﬁce tower), separate assumptions are formulated. For example:

• Considering the different functions, each subcomponent may be subject to different demands for fire-safety. • The live and dead floor loads differ based on function and floor structure. • The maximum allowable roof deflection of the exposition space is affected by the presence of movable interior walls.

50 Figure 5.2: Decomposition of initial assumptions throughout the main structural elements

Another example of decomposition and integration is the analysis of the structure of the exposition space. As mentioned previously, the exposition space features a large roof span and a floor supported by slanted columns. In designing this structure, these main elements were first analyzed separately and then integrated into a whole. This process is also possible in the StructuralComponents building model (see Figure 5.3). At the global level of the entire frame, a parameter can be set indicating the center- to-center distance of all elements. The subcomponents can make use of this parameter, as well as define specific information. First, the roof truss is analysed. At this level, attributes can be used to define the truss height, deflection requirements, loads, etc. In order to analyze the truss in detail, it is broken down further into bracing and chords: each consisting of circular hollow sections. Various combinations of these profiles, as well as different heights for the truss can be considered. The main results of this analysis include support reactions and deflections. Next, the supporting structure of the floor is analyzed. Because the slanted columns lead to horizontal forces in the floor beams, the system of floor, columns, and shear wall must be analyzed as a whole. The StructuralComponents building model offers particular advantages here. Firstly, a custom component can be created to represent this system, indicating its subcomponents work together. Second, the flexible hierarchical component relationships allow the core wall to be a part of this system: this “wall” component is then part of the floor system which introduces horizontal forces, as well as the core, which defines parameters such as concrete type. This

51 shared function not only adds intelligence to the model, but also prevents duplicate definition of components. Other subcomponents of the floor support structure are the columns, floor beam, and floor slabs. Similar to the truss structure, various combinations can be considered. Another important consideration is the column in the facade, which transfers the support reaction from the truss to the overhanging floor beam. With these subcomponents defined, the main outcomes can be integrated into the main component: support reactions, deflections and stiffnesses.

Figure 5.3: Decomposition of the structure of the exposition space

Considering alternatives in parallel

One example of considering alternatives in parallel is the conceptual design of the roof of the exposition structure. Early in the design process, several high-level alternatives were compared: trusses in longitudinal, transverse, or both directions. In the StructuralComponents building model, these alternatives can be represented as variants (see Figure 5.4). A component can be created to represent the entire roof structure, with different values for certain attributes. In this case, the maximum allowable stresses and dis- placement, as well as the height and diagonal proﬁle are the same for all variants. The alternatives differ in chord proﬁle, and are compared on the resulting difference in weight.

52 Figure 5.4: High-level alternative concepts for a roof supporting structure. Bold attribute names indicate differing values.

The decomposition of the exposition structure (see Figure 5.3 previously) also provides an example of more complex alternatives: during the design, several combinations of the subcomponents (truss, ﬂoor structure, facade column) were considered. For example, a ﬂoor structure with a reduced beam section combined with a taller truss. This type of comparison is supported in StructuralComponents through variant combinations (Figure 5.5 and also Figure 4.15): numerous combinations of subcomponent variants can be reduced to a few primary combinations at a higher level. In this case, the “expo-frame” is the overaching component, with subcomponents each containing several variants:

• The truss component, itself a collection of subcomponents, has several variants with varied profile sections and heights. • The curved facade column has several variants for different amounts of curva- ture. • The floor structure contains variants with different sections for the floor beam.

Combinations can be formulated by creating variants of the “expo-frame” component and referencing different subcomponent variants. For example, the main “combination A” variant may reference the “reduced cross-section” ﬂoor component, and the “tall” truss variant.

53 Figure 5.5: Representing combined alternatives of the exposition structure

Applying various analysis models

An example of the application of various analysis models is the core structure. Throughout the design process, the core has been analysed in various ways. In the building model, various models are supported by applying different design steps (see Figure 5.6). In this case, a simple early-stage model can be applied to a design- step in order to determine the feasibility of the structure. During the later design stages, a more complex model can be used in a validation design-step.

54 Figure 5.6: The application of various analysis models for the core

Modeling of cases and scenarios

The study for feasibility of the core structure also provides an example of the application of cases and scenarios. During the feasibility study of the core, several representative scenarios were analyzed. For example, a scenario with a soft foundation and unfavourable concrete elasticity. These scenarios can be represented in the building model as variants and variant combinations (see Figure 5.7). Firstly, favourable and unfavourable values for properties are supported through alternative values. For example, alternative values can be added for concrete elasticity or the moment of inertia of the cross section. Secondly, variants of other components can be referenced. In this case, the foundation stiffness is taken from the foundation component, and the total vertical load is taken from the “ofﬁces” component. Ref- erences to variants of these components can be used to create combined scenarios.

55 Figure 5.7: Cases and scenarios involved in design of the “core” component

Evolution into detailed design

The roof truss of the exposition space can also be used to illustrate the progression from preliminary to detailed design. As seen in Figure 5.4, the roof is initially analysed at a high level. In the ﬁnal veriﬁcation, the individual members are checked. This progression is supported in the building model through hierarchical breakdown (see Figure 5.8): both high-level concepts and individual elements can be modeled simultaneously. Initially, the roof structure can be modeled as a single component. Progressing to a further level of detail, the roof can be subdivided into subcomponents such as a the roof truss. Later in design when more detail is required, this truss can be broken down further into subcomponents. Individual checks can then be recorded at element level.

56 Figure 5.8: Progression from high-level components to validation of individual members

Expressing design justiﬁcation

The design of the truss in the exposition space provides an example of communicating design justification. The design of the truss results from a calculation based on imposed loads and requirements for deflection. In turn, these parameters are the result of other decisions. In the conceptual building model, this reasoning can be expressed by tracing the lines of reasoning created by design-steps (see Figure 5.9). In the case of the truss, a design-step containing a calculation of the deflection is governing for several truss parameters, such as the height. This deflection calculation, in turn, is based on a load and a maximum allowable deflection. Following the lines of reasoning further, the source of the (rather strict) deflection criterion can be traced: the use of suspended interior walls limits the allowable deflection. The load affecting the deflection calculation can also be found, in this case tracing back to a load calculation of the roof.

Figure 5.9: Expressing the design justiﬁcation behind the roof truss

5.1.2 Case study This section describes how the case study, described in AppendixA, is represented using the StructuralComponents 4 building model. The case study in particular demonstrates how the model follows a practical design progression.

57 Overhanging structure

The ﬁrst subject tackled in the design is the overhanging structure. Initially, two options were considered: an overhang supported from below and a suspended structure. In the model, this can be represented as two alternatives for a “overhang” component (see Figure 5.10). Reasoning can be applied to describe the effect of the different structural principles: a suspended structure is more difﬁcult to construct, while the supported structure leads to undesirable walls prohibiting functional use.

Figure 5.10: Initial comparison of structural concepts for the overhanging structure.

Eventually, another option was chosen: the ﬂoors were to overhang individually.

Upper ﬂoors

The next design issue is the layout of the ﬂoors on the upper levels. Four main alternatives are suggested with different combinations of beams, slabs and span direction (see Figure 5.11). The option with steel overhanging beams is chosen.

Figure 5.11: Alternatives for the upper ﬂoor structure

58 Overhanging beams

The next design issue is the overhanging steel beam. The reasoning behind the “double” section is that the beam must pass the column continuously. A simple model is applied to get an initial indication of bending moments and displacements.

Figure 5.12: Preliminary design of the overhanging beams

Lower ﬂoors

The beams on the lower levels are not part of the overhanging structure. The reasoning behind the placement of a center column is that the functions in this part of the building do not require large spans. The additional advantage of reduced column loads on the foundation can also be mentioned in this reasoning.

Figure 5.13: Reasoning behind center column supporting the lower ﬂoors

Stability

A unique aspect of this structure is the stability system, which consists of the core supported by a table structure at the ﬁfth ﬂoor. Figure 5.14 shows the location of the stability system in the building model.

59 Figure 5.14: The stability system within the building model

Missing corner column

The requirement for a missing column at the position of one of the stability elements, results in the application of a steel frame instead of a concrete shear wall. Figure 5.15 shows an overview of the building model containing also previously mentioned components.

Figure 5.15: Accounting for a missing column in the building model.

60 5.2 Evaluation

This section evaluates the concepts and implementation of the system design elements (see Chapter4) based on application in the examples of the previous section. The section discusses how the predetermined requirements are addressed, and encountered limitations. Solutions for these limitations are discussed in Section 6.3.

5.2.1 Application architecture

Extensibility

Because of the iterative nature of development, extensibility of the tool was observed within the scope of this project. Automated testing has ensured existing functionality, and increases conﬁdence in extending the tool. This indicates the application is sufﬁciently extensible, although this can only be fully validated in future research which further extends the tool.

View independence

GUI-core separation is achieved through application of MVVM architecture pattern. The conceptual building model is implemented separately from presentation (View) and interaction logic (ViewModel). However, the choice for implementation in C# limits its use to .NET environments.

5.2.2 Conceptual building model

Flexible design process structure

The conceptual building model does not enforce any sequence of design steps. Rather, the building model puts the designer in charge of what information to include, when, and trough which method of reasoning. Simple and adaptable components allow the designer to determine which information is relevant at each stage. Hierarchical decomposition makes it possible for the design to develop according to the speciﬁc design needs.

Multi-dimensional design problems and integrated solutions

Multi-dimensional design problems are supported by allowing component attributes to play a role in any number of lines of reasoning. The inﬂuence of requirements and problems thus be traced throughout the design. Integrated solutions can be represented as values determined from a wide context of design problems. See Figure 5.16.

Parallel alternatives

Alternatives are supported on two levels. Firstly, each attribute can contain any number of alternative values. The designer can quickly change which value is cur-

61 Figure 5.16: Left: a multi-dimensional design problem inﬂuencing several design decisions. Right: an integrated solution based on several design problems rently active. Second, alternatives can be deﬁned at component level. This allows alternatives to be composed from a combination of several other alternative values. It also allows local experimentation with a component variant, so long as it is not marked as the “current” variant. However, the way alternatives are modeled limits the possible differences between models, as they must must contain all of the same attributes. Another limitation is that the reasoning behind a choice for a certain alternative cannot be expressed in the current implementation.

Different types of representations

The core representations of the building model are components, which can contain quantitative as well as qualitative information. Analytical representations can be applied trough models used in design reasoning. Geometric and visual representations are not implemented.

Representations at different levels of abstraction and scale

The implementation of components as adaptable building blocks allows the designer to create components, and related representations, at any abstraction level or scale. Hierarchical organization allows these different levels to be described, and for representation at different scales and abstraction to co-exist.

Various analysis models

As mentioned in the previous section, any number of models can be applied to a component. The general implementation of analysis models as input/output pro- cessors makes it, in principle, possible to use them for both complex and detailed models. In practice, however, complex analysis is often carried out by specialized software tools. These specialized tools often require geometric deﬁnitions, and standardized representations of loads, stiffnesses, materials, etc.

62 Reasoning with cases and scenarios

Components support the creation of any number of scenarios as “variants”. Through component references, it is possible to create combined scenarios. However, because scenarios are implemented as isolated component states, the effect of scenarios cannot be transferred between them. In a practical situation, a scenario will affect the design of the “real world”.

Preliminary and detailed design

The versatility of components allow the modeling of both high- and low-level structural concepts and elements. However, two main limitations are encountered when representing detailed design: Firstly, at detail level the deﬁnition of large numbers of components is time-consuming and makes it hard to keep an overview. Second, geometry plays a large role in composition of detailed design, which is currently not implemented.

5.2.3 User interface

Low threshold

The user interface provides clear commands for creating and customizing components and models. Establishing relationships between reasoning, models and components through drag-drop operations is less clear, necessitating speciﬁc instruction.

Overview

The graph UI gives an overview of components and their relationships. However, as the model grows more complex, the graph can become cluttered. Also, the existing connections between attributes and reasoning are not easily recognizable in the interface.

5.2.4 Computational engine The computational engine aims to allow the data in the building model to respond to changes. The computational engine implements single-directional change propagation (from value containers to dependent observers) and alternative states, which determine the routing of change propagation and value requests.

63 This page has been intentionally left blank. 6 Discussion

This chapter discusses the results of the previous chapters: patterns in observations, implications, possible enhancements, and future possibilities. First, the results are compared to the objectives outlined at the start of this thesis. Second, the significance of the results is discussed within the broader context of building models, design tools, and computation. In Section 6.3, a number of improvements are suggested based on the validation and previous observations. The chapter concludes with the future implications of this study.

6.1 Objectives

The main objective of the thesis as outlined in the ﬁrst chapter:

To develop a new prototype of StructuralComponents which supports creative design exploration and composition of design justiﬁcation.

This objective has been achieved by implementation of the conceptual building model in the StructuralComponents application. The prototype offers a tool which stimulates creativity and exploration through simple, adaptable components, and supports documentation of the reasoning process behind design steps through re- ﬂective reasoning. Regarding the sub-objectives:

Investigate the requirements for a tool or model to support a conceptual design story.

Based on research into design theory and structural design, requirements have been formulated. Relevant aspects of design in general include its ﬂexible process structure, interactions between problems and solutions, and parallel alternatives. En- gineering and structural design in particular rely on the use of various representations, models, and scenarios. The requirements have been abstracted into several high-level used cases, illustrating speciﬁc required functionality.

Develop a building model in which the design story of a building can be structured.

A conceptual building model has been developed to represent the elements of structural design justiﬁcation. The building model provides combinable “blank slate” components which enable the designer to work at various levels of abstraction and scale. Reﬂective reasoning steps support representation of various types of design steps, and allow the application of various models. Scenarios and alternatives are supported through alternative values and component variants.

65 Implement a computational engine to support extending and modifying information in this building model.

A computational engine has been developed to manage associations between the elements of the building model. The effect of changes is propagated through a chain of notiﬁcations. The engine also supports maintaining several alternative representations through switches and states.

Other objectives New user interface A new user interface has been developed. Instead of the dashboard type control of earlier versions of StructuralComponents (Rolvink et al., 2009), a graph control is applied to visualize relationships in the model. Reusable analysis tools Analysis tools are implemented as user-deﬁned, reusable models. The building model supports creation of a simple analysis library through exporting of analysis models.

6.2 Background

6.2.1 Design tools in practice As discussed in Chapter1, StructuralComponents takes a fundamentally different approach to modeling. Instead of requiring precise and detailed information, the StructuralComponents tool allows designers to build a model from the early stages onward, which develops according to design needs. Also, in contrast to traditional models, design reasoning, lacking in most traditional models, plays a central role in the StructuralComponents building model. Compared to existing tools, however, the developed prototype lacks functionality for advanced geometry and visualization.

6.2.2 Design theory and conceptual building models The StructuralComponents prototype demonstrates new implementations of concepts in existing research, as well as extending these in new directions. Existing research into design theory and conceptual building models have provided backing for the ﬁrst three concepts of the StructuralComponents building model: generic components (Turk, 2001, Resnick et al., 2005), hierarchical decomposition (Rivard and Fenves, 2000), and constructive memory (Gero, 1998). Through implementation and application, these concepts have been extended with customized models for representing analysis models, alternatives, and scenarios.

66 6.2.3 Structural Design Tools As mentioned in Section 1.2.1, StructuralComponents has been developed based on the Structural Design Tools approach (Coenders and Wagemans, 2005). Struc- turalComponents 4 continues in this direction by providing tool which is highly adaptable and controllable. This is achieved by letting the engineer determine the components and organization of the building model. Also, because the user can de- ﬁne their own underlying reasoning, engineers can use their insight into structural behavior to select the correct means for design justiﬁcation, instead of a “one-push- on-the-button-calculation” (Coenders and Wagemans, 2005).

6.2.4 StructuralComponents Like earlier versions, StructuralComponents 4 aims to provide a ﬂexible toolbox for conceptual design. Compared to earlier versions of StructuralComponents, this research takes a broader and more conceptual approach. A clear difference is the objective of making the tool applicable to building typologies other than high-rise structures. The most profound difference lies in the modeling approach. Whereas previous versions of StructuralComponents offered a library of “structural components” with built-in analysis capabilities, this version abstracts components to objects containing design information, and lets the designer determine which reasoning and calculations to apply to determine this information. Although a model takes longer to set up with this approach, the resulting model is highly adaptable with customized models, reasoning, parallel alternatives, and scenarios. The functionality of previous versions of StructuralComponents could be incorporated in the future through a plug-in or library.

6.2.5 Computational tools Compared to existing computational tools, the computational engine supports only basic single-directional change propagation. Additionally, the computational engine supports alternative values through the implementation of switches (see also NetworkedDesign (Coenders, 2011)). Furthermore, it extends on this implementation through the concept of states, which determine the setting of a collection of switches.

6.3 Next steps

6.3.1 Opportunities for standardization Although generic components are essential for covering unique design situations, further developments necessitate some measure of standardization:

• Support for complex analysis models requires the use of recognizable concepts for loads, stiffnesses, supports, etc.

67 • Preventing repetitive deﬁnition of routine components requires a (standardized) library. • Communicating design logic in a more standardized format improves under- standing and enables re-use.

When implementing any standardization, it is important to do so in a way which does not compromise the benefits of highly adaptable components. One way to do this is to implement standardized component interfaces and attribute types. These interfaces would define certain attributes that a component must contain. Design flexibility is maintained because the designer still can determine which interfaces to apply, the reasoning behind these properties, as well as define any additional properties as needed.

6.3.2 Reflection and visual representations The conceptual building model implements a simple type of design “reflection”: reasoning from a state of component attributes. In design practice, reflection often takes many forms, often aided by various (visual) representations such as drawings or sketches. Supporting this type of reflection requires not only visual representations, but also a broader conceptual model for design reasoning context.

6.3.3 Bi-directional associations The computational engine currently only supports single-directional propagation of changes: from a value source to its observers. Propagation of changes in the opposite direction (back to the source) is currently not implemented, but can be made possible within the current structure of the computational engine. However, an important limitation is that, while a chain of dependent attributes can be traversed easily in reverse direction, analysis models are limited to single- directional calculation (see Figure 6.1). One way to allow traversing of the calculation logic in other directions is to represent them as constraint problems, which can be solved in multiple directions (Coenders, 2011).

Figure 6.1: Bi-directional associations limited by single-directional analysis models

68 6.3.4 Geometry It is clear that geometry is an important aspect of design, especially in the later design stages. One way to implement geometric representations in an organized manner is to allow deﬁnition of a geometric breakdown, along with the hierarchical component breakdown. In this way a component could contain a geometric representation of the composition of is subcomponents. A simple geometric representation could be built up from nodes and lines, with each linked to a component (e.g. a beam component is associated with a line and a connection with a node). Figure 6.2 shows an example of a truss component consisting of subcomponents. The truss component, in turn, is part of a larger supporting structure.

Figure 6.2: Example of geometric decomposition of a truss component

Potentially, geometric representations could also beneﬁt from functionality of the parametric engine, allowing the deﬁnition of alternatives and scenarios.

6.3.5 Replication Because building design involves large amounts of data, the building model becomes more and more detailed as design progresses. At the level of individual structural members, individual deﬁnition of attributes, models, and reasoning becomes repetitive. Part of this problem can be solved by templates or standardized models, but repartition of identical logic can more effectively be addressed through replication. Within the current model, this could take the form of component “inheritance”: child components could be created with their attributes automatically referencing those of their parent.

69 6.3.6 Distinguishing alternatives and scenarios Currently alternatives and scenarios are implemented in the same way: as component variants. Implementation has shown that this provides an effective way of recording and combining them. However, more speciﬁc requirements for scenarios and alternatives diverge: Alternatives often require the need for more substantial differences, as their attributes do not always overlap. Also, alternatives are used in reasoning to indicate a choice, while scenarios are often used to express a governing situation.

6.3.7 Component validation Especially later in the design stages, not only the reasoning behind values, but also validation of these values becomes important. Currently these “checks” can be implemented as models with a unity check or “ok/not ok” result. Instead of this workaround, it would perhaps be clearer to deﬁne these checks seperately, resulting in a “checklist”. In this way, the ﬁnal validation could be more clearly communicated.

6.3.8 User interface A clear and effective user interface is a major factor in determining its usability in practical situations: the user cannot take advantage of advanced functionality if it is not made easily accessible. One issue mentioned in Section 5.2.3 is the presentation of relationships between components and reasoning. A potential solution is to include both component and reasoning in the same graph, which emphasizes their relationships. These relationships could then also be created in a similar way as component-to-component relationships, making the user interactions more consistent. Another issue is the representation of complex and detailed models, which can easily become cluttered. One possibility is the application of layers within the graph interface, in order to ﬁlter the visible information. Another possibility is to implement “hiding” or “collapsing” of components into groups or parent components.

6.3.9 Other enhancements Analysis model plugins The currently implemented (scripted) models demonstrate how simple input/output models can be applied in the building model. A straightforward enhancement would be to implement plug-ins to other input/output type analysis models, such as spreadsheet software. Attribute grouping Currently, attributes are contained within one list. As components develop, a clear overview may be lost. To prevent this, grouping of attributes could be

70 implemented. This grouping could then also be used to create sub-scenarios, improving scenario overview. Reasoning behind choices Currently, the reasoning behind attribute values can be indicated. However, reasoning cannot be applied to justify the choice for a value or alternative. This could be implemented in a similar way as reﬂective design reasoning, with a focus on comparison. Usability enhancements Due to the experimental nature of the prototype, the application still lacks a number of usability enhancements. Among others, these include shortcuts for repetition and undo/redo functionality, which is essential for users to explore options with conﬁdence (Resnick et al., 2005). Component detail view The graph UI gives an overview of all components, but often an analysis is centered around a single component. This requires a component “detail” view, which could be implemented as a dashboard.

6.4 Potential

The previous discussions shows that the StructuralComponents provides a flexible, adaptable conceptual model to not only represent a building structure, but also its underlying justification based on reasoning, models, simplifications, and scenarios. These aspects offer the following opportunities:

• The ﬂexibility of the model makes it possible to structure the design earlier in the design process. This could enable the use of powerful computational analyses and potentially lead to more informed decisions. • By recording a more comprehensive representation of the elements of design justiﬁcation, the model could increase opportunities for the re-use of design knowledge. • By making design reasoning explicit, design intent can be communicated more effectively, potentially avoiding miscommunication across the design stages and between disciplines. • The inclusion of alternate representations allow for more targeted applications of computation, such as optimization.

71 This page has been intentionally left blank. 7 Conclusions

The study has been set out to develop a new prototype of the StructuralComponents design tool, focussing on creative design exploration and composition of design jus- tiﬁcation. The study has succeeded in achieving this objective, and has led to the following conclusions:

• A signiﬁcant step has been made in the development of a building model for composition of structural design justiﬁcation, within the vision of Structural- Components (Rolvink et al., 2009) and in concurrence with the Structural Design Tools approach (Coenders and Wagemans, 2005). Building modeling concepts have been developed and applied in practical examples, which have shown that:

– In contrast to the standardized deﬁnitions characteristic of current modeling approaches, simple and adaptable components support design uniqueness, and give the designer the necessary control over the focus, structure and progression of design. – Incorporation of a reﬂective model of design progression allows documentation and investigation of the reasoning processes behind design steps, as well as comprehensive insights into their impact. – Alternative values and combined states provide a basis for representing and structuring alternatives and scenarios.

• Key characteristics of (structural) design have been outlined. Although not exhaustive, these have shown to be sufﬁcient in order to establish high-level requirements for the design tool. • A computational engine has been developed in order to implement the concepts of the building model. The modeling concepts regarding alternatives and scenarios have demonstrated the need for switches (Coenders, 2011) as well as an additional level of control in the form of states. • The developed StructuralComponents 4 prototype application serves as a proof- of-concept that these concepts can be implemented, and provides an extensible base for future developments.

Recommendations

As a result of this research, a number of recommended directions for future investigation are outlined:

73 Geometry This research demonstrates the likely next step is the implementation of geometric representations and decomposition. Visual representations It is proposed to implement visual representations of design, and incorporate these representations into design reasoning. Component validation In addition to reasoning behind values, it can be investigated how to represent (ﬁnal) validation of these values (e.g. unity checks or high-level requirements). Standardization It should further be investigated how standardization can be combined with customizability in the building model. Design history A potential opportunity of a more comprehensive model is the documentation of design progression. Integratrion with NetworkedDesign Integrating the developed parametric engine with NetworkedDesign will facilitate the implementation of multi-directional models, as well as concepts for replication, and re-use of design logic. User interface It can be recommended to improve the user interface to more clearly indicate associations, alternatives, and scenarios.

74 References

AutoDesk (2014). DesignScript. www.designscript.org. last accessed: 21-08- 2014.

Baker, N. C., Fenves, S. J., et al. (1987). A knowledge acquisition study of structural engineers performing preliminary design. Carnegie Institute of Technology: Department of Civil and Environmental Engineering.

Bentley Systems (2013). GenerativeComponents. www.bentley.com/en-US/ Products/GenerativeComponents/. last accessed: 22-11-2013.

Boer, M. de and Henkens, G. (2001). Virtuoze constructie in staal, beton en staalbeton. Bouwen met staal, 158:18–25.

Breider, J. (2008). StructuralComponents - development of parametric associative design tools for the structural design of high-rise buildings. Master’s thesis, Delft University of Technology.

Brown, T. et al. (2008). Design thinking. Harvard business review, 86(6):84.

Chapman, W., Rozenblit, J., and Bahill, A. (2001). System design is an NP-complete problem. Systems Engineering, 4(3):222–229.

Coenders, J. (2011). NetworkedDesign. PhD thesis, Delft University of Technology.

Coenders, J. and Wagemans, L. (2005). The next step in modelling for structural design: Structural Design Tools. In IASS 2005 International symposium on Shell and Spatial Structures, Theory, Technique, Valuation, Maintainance, pages 85–92.

Cross, N. (1982). Designerly ways of knowing. Design studies, 3(4):221–227.

Dym, C. L. (1994). Engineering design: a synthesis of views. Cambridge University Press.

Gamma, E., Helm, R., Johnson, R., and Vlissides, J. (1994). Design patterns: elements of reusable object-oriented software. Pearson Education.

Gehry Technologies (2014). Digital Project. www.gehrytechnologies.com/en/ products/. last accessed: 21-08-2014.

Gero, J. S. (1998). Conceptual designing as a sequence of situated acts. In Artiﬁcial intelligence in structural engineering, pages 165–177. Springer.

Holzer, D., Hough, R., and Burry, M. (2008). Parametric design and structural optimization for early design exploration. International journal of architectural computing, 5(4):625–643.

75 Lawson, B. (2006). How designers think: the design process demystiﬁed. Routledge.

Maaren, H. van and Vries, A. de (2009). De zin en onzin van 3D. Cement, 2009(6):36–40.

MacLeamy, P. (2004). The future of the building industry: The effort curve. HOK Network, YouTube www.youtube.com/watch?v=9bUlBYc_Gl4. accessed: 22-11- 2013.

McNeel, R. (2013). Grasshopper. www.grasshopper3d.com. last accessed: 22-11- 2013.

Mora, R., Bédard, C., and Rivard, H. (2008). A geometric modelling framework for conceptual structural design from early digital architectural models. Advanced Engineering Informatics, 22(2):254–270.

Mostow, J. (1985). Toward better models of the design process. AI magazine, 6(1):44.

Race, S. (2012). BIM Demystiﬁed. Riba Publishing.

Resnick, M., Myers, B., Nakakoji, K., Shneiderman, B., Pausch, R., Selker, T., and Eisenberg, M. (2005). Design principles for tools to support creative thinking.

Rivard, H. and Fenves, S. J. (2000). A representation for conceptual design of buildings. Journal of Computing in Civil Engineering, 14(3):151–159.

Rivard, H., Fenves, S. J., Gomez, N., et al. (1995). An information model for the preliminary design of buildings. Carnegie Institute of Technology: Department of Civil and Environmental Engineering.

Rolvink, A. (2010). StructuralComponents2.0 - a parametric and associative toolbox for conceptual design of tall building structures. Master’s thesis, Delft University of Technology.

Rolvink, A., Breider, J., and Coenders, J. (2009). Structural components– a parametric associative design toolbox for conceptual structural design. In International Association for Shell and Spatial Structures (IASS) symposium 2009, Evolution oand Trends in Design, Analysis and Construction of Shell and Spatial Structures, pages 280–281.

Sacks, R. and Barak, R. (2008). Impact of three-dimensional parametric modeling of buildings on productivity in structural engineering practice. Automation in Construction, 17(4):439–449.

Sanders, L. (2008). An evolving map of design practice and design research. interactions, 15(6):13–17.

76 Schön, D. A. (1983). The reﬂective practitioner: How professionals think in action. Basic books.

Shore, J. and Warden, S. (2007). The Art of Agile Development. O’Reilly Media, Inc.

Turk, Ž. (2001). Phenomenologial foundations of conceptual product modelling in architecture, engineering and construction. Artiﬁcial Intelligence in Engineering, 15(2):83–92.

Visser, W. (2006). Designing as construction of representations: A dynamic viewpoint in cognitive design research. Human–Computer Interaction, 21(1):103–152.

Weerd, B. van de (2013). StructuralComponents - a client-server architecture for FEM-based structural design exploration. Master’s thesis, Delft University of Tech- nology.

77 This page has been intentionally left blank. List of Figures

1 Simpliﬁed diagram of the analysis of a “core” component with the StructuralComponents building model...... vi

1.1 Design freedom v.s information during the design process...... 2 1.2 Schematic representation of design justiﬁcation...... 2 1.3 Representations used in the design of the HDMZ (case study)...... 5 1.4 A building model consisting of various associated representations....5 1.5 Concept of StructuralComponents 4 software architecture...... 6

2.1 Overall project approach...... 10

3.1 The process of constructive memory...... 14

4.1 Conceptual StructuralComponents 4 software architecture...... 23 4.2 The MVVM architecture pattern...... 24 4.3 Detailed StructuralComponents application architecture...... 25 4.4 Examples of simple and adaptable desig tools...... 28 4.5 The significance of custom objects in describing design illustrated by example...... 28 4.6 Examples of customized components...... 29 4.7 Examples of hierarchical component relationships...... 31 4.8 Examples of attribute references in parent-child component relationships 32 4.9 Design steps in the StructuralComponents building model...... 33 4.10 Examples of reasoning steps within components...... 34 4.11 Examples of application of models...... 35 4.12 Examples of alternative values for attributes...... 37 4.13 Variants describing combined alternatives for a floor structure...... 37 4.14 Variants describing combined scenarios for a foundation...... 38 4.15 Hierarchical component breakdown reduces the number of high-level alternatives...... 39 4.16 Simplified UML class diagram showing main datamodel components and their associations...... 39 4.17 Change notification from value containers to dependents...... 41 4.18 Value switches expose one of several alternative values...... 42 4.19 A state records the individual settings of each switch...... 42 4.20 Associations between states determine which values from other containers are referenced...... 43 4.21 Simplified UML class diagram showing the main components of the computational engine...... 44

79 4.22 Overview of the main user interface...... 46 4.23 Detailed overview of a design-story item...... 47 4.24 Editing an analysis model...... 47

5.1 Overview of the RAI Elicium building in Amsterdam...... 49 5.2 Decomposition of initial assumptions throughout the main structural elements...... 51 5.3 Decomposition of the structure of the exposition space...... 52 5.4 High-level alternative concepts for a roof supporting structure...... 53 5.5 Representing combined alternatives of the exposition structure..... 54 5.6 The application of various analysis models for the core...... 55 5.7 Cases and scenarios involved in design of the “core” component..... 56 5.8 Progression from high-level components to validation of individual members...... 57 5.9 Expressing the design justification behind the roof truss...... 57 5.10 Initial comparison of structural concepts for the overhanging structure.. 58 5.11 Alternatives for the upper floor structure...... 58 5.12 Preliminary design of the overhanging beams...... 59 5.13 Reasoning behind center column supporting the lower floors...... 59 5.14 The stability system within the building model...... 60 5.15 Accounting for a missing column in the building model...... 60 5.16 Multidimensional design problems and integrated solutions in the model 62

6.1 Bi-directional associations limited by single-directional analysis models. 68 6.2 Example of geometric decomposition of a truss component...... 69

A.1 Front view of the HDMZ building and the overhang at the rear of the building...... 81 A.2 Two initial concepts for the overhanging structure...... 82 A.3 Four initial concepts for the ﬂoor structure with overhang...... 83 A.4 Structural scheme showing beams supporting the overhang and lower levels...... 83 A.5 A rigid connection at the facade leads to a reduction in the bending moments in the main span...... 84 A.6 A table structure supporting the cores horizontally...... 85 A.7 Linking the lower ﬂoors to the core would lead to large shear forces... 85

B.1 conceptual diagram of elements in version 0.1...... 87 B.2 conceptual diagram of elements in version 0.2...... 88 B.3 conceptual diagram of elements in version 0.3...... 89

80 A Case study

This chapter contains the information on the case study: an example building structure to guide development. All information has been retrieved from an interview conducted with the project’s lead structural designer, ir. G. Henkens and the building’s publication in Bouwen met Staal (de Boer and Henkens, 2001). Illustrations courtesy of ir. G. Henkens.

A.1 Background

A.1.1 Overview The Hogeschool voor Dans en Muziek (‘HDMZ’) is a mid-rise building in Rotterdam which was built to house schools of music and dance. The functional layout called for a number of speciﬁc rooms, with large column-free spaces and strict demands for acoustic insulation. Due to the compact building site, the building shape is rather narrow and slender and, due to limitations on the building height, also necessitated an overhang of 6,5 m over the neighboring concert hall De Doelen.

Figure A.1: Front view of building of the Hogeschool voor Dans en Muziek (left) and the overhang at the rear of the building (right). Photo’s from de Boer and Henkens(2001).

A.1.2 Suitability for case study This building was determined to be a suitable case-study due to:

• its mid-rise, orthogonal structure • the presence of statically undetermined systems • its integrated, multifaceted design story • the frequent use of schematizations and simpliﬁed models

81 Figure A.2: Two initial concepts for the overhanging structure

• several changes to requirements during design

A.2 Structural design

In the following sections the main elements of the building’s structure are outlined, more or less in the order they were designed.

A.2.1 Overhanging structure Due to the large influence of the structural overhang on the overall structural concept, this issue was tackled first. Initially two options were proposed to deal with the overhang: suspend the structure from the roof, or support the overhang with a truss (see Figure A.2). Eventually, neither of these two options was chosen: a suspended structure is difficult to construct and would lead to extra loads in the columns, while supporting all overhanging floors by a large transfer structure would inhibit the building’s functional use. Eventually, it was decided to let floors extend individually.

A.2.2 Upper floors With it being decided to overhang the floors individually, a number of concepts were considered for the structural layout of the floors (see Figure A.3). It was chosen to place steel beams in transverse direction, linking the overhang with an interior span of 13 m (see Figure A.4). This large span allowed the placement of large column-free spaces at these levels, while the overhang simultaneously reduced the field moments.

82 Figure A.3: Four initial concepts for the ﬂoor structure with overhang.

Figure A.4: Structural scheme showing beams supporting the overhang and lower levels.

83 Figure A.5: A rigid connection at the facade leads to a reduction in the bending moments in the main span.

A.2.3 Overhanging beams To allow for both continuous beams and columns (see Figure A.4), the beams are built up from two sections. To ensure sufﬁcient stiffness of the overhang, the beams and facade columns are connected rigidly. This rigid connection is made after the construction of the structural frame and ﬂoors, making the connection transfer only facade weight and live loads. A rigid connection was also applied at the opposite facade to reduce moments in the central span (see Figure A.5). At the location of the cores, a suspended structure was applied due to relaxing of constraints on the building height. Because the construction of the cores preceded the rest of the structure, the suspended structures did not adversely effect the construction time.

A.2.4 Lower ﬂoors The structural scheme of the lower levels is similar to the upper levels: the most important difference is the absence of the overhang and the presence of a central column which divides the main span into sections of 5 m and 8 m. This extra column is possible due to the presence of smaller spaces at these levels. Additionally, this central column reduces the load on the foundation right next to the neighboring building.

A.2.5 Stability Overall stability in the principle directions is ensured by the two main cores of the building. The cores not only bend horizontally due to wind, but also due to the vertical loads on the overhanging structure. Due the to slenderness of the cores in perpendicular direction, the cores are supported by a table structure, consisting of the 5th floor and 3 shear walls (see Figure A.6). A additional complication was the linking of floor and cores in level 1-4: These floors are supported by 2 shear walls

84 Figure A.6: A table structure supporting the cores horizontally.

Figure A.7: Linking the lower floors to the core would lead to large shear forces; it was chosen to keep the floors separate from the cores at these lower levels. and transfer large shear forces if linked to the core. To prevent this, these floors are kept seperate from the core (see Figure A.7).

A.2.6 Missing corner column Another important feature of the structure are the tall free-standing columns. These are 300 mm wide and are unsupported for 12 m. This slenderness is achieved mainly due to the column being continuous and its rigid connection to the foundation. The architect’s design called for the omission of a column at the corner. To make this possible, a truss was designed at the facade to carry the loads from the upper levels, see Figure A.6.

85 This page has been intentionally left blank. B Development process

This chapter describes the development of the prototype implementation of Struc- turalComponents 4. Each section describes the result of one development iteration; the latest version (0.4) is described in Chapter4.

B.1 Version 0.1

Figure B.1: conceptual diagram of elements in version 0.1

B.1.1 Features The initial release implemented the ﬁrst three concepts:

Generic components The user can create components, and add simple text attributes. Hierarchical organization Components can be organized into a parent-child tree structure. Reﬂective design reasoning The designer can create design-story items to indicate steps in design reasoning. Attributes and components can be attached to the context of a reasoning- item.

The goal of this ﬁrst implementation was not to implement any parametric or automation functionality, but to determine if the aforementioned concepts provide an effective way of representing design information and underlying reasoning.

B.1.2 Observations Implementation of this iteration resulted in the following observations:

87 • Getting started with a model is straightforward and takes little time. • The designer can easily determine at which abstraction level to work, due to ﬂexibility of components. • Various types of structures are possible, as there are no restrictions in component or attribute types. • The logic of design steps can be represented by reasoning from context to outcome. • Standardized components could be useful in routine cases. • The model can become cluttered at detailed level. • Some design steps could be automated.

B.2 Version 0.2

Figure B.2: conceptual diagram of elements in version 0.2

B.2.1 Features This version’s main feature is implementing models as automatic reasoning (concept 4). This in response to the observed applications of the reasoning-steps. Other enhancements include:

• The design-story item detects when any of its context is changed.

– If it contains an analysis model, this model is re-run. – If is contains only manual logic, a warning is displayed.

• Design-story items can be (de)activated.

B.2.2 Observations • User-deﬁned models allows for customization and use of individual rules of thumb. • Automatic re-running of calculations is useful to check the effect of changes.

88 • The inputs-to-output format can be applied to many models found in practice (rules of thumb, spreadsheets). However, multiple outputs are required (not implemented in version 0.2). • Complex models require more advanced input:

– Wireframe models require geometric input – Standardized concepts for loads, sections, etc. are required

B.3 Version 0.3

Figure B.3: conceptual diagram of elements in version 0.3

B.3.1 Features This version is primarily aimed at addressing earlier feedback. It offers to following enhancements:

• Component templates for saving a list of component attributes for later use. • Import and export of analysis models, allowing re-use. • Multiple outputs per model.

89 This page has been intentionally left blank. C Publication

Following this research project, a paper has been submitted and accepted for publication in the proceedings of the International Association for Shell and Spatial Structures (IASS) Symposium 2015 in Amsterdam.

91 Proceedings of the International Association for Shell and Spatial Structures (IASS) Symposium 2015, Amsterdam Future Visions 17 - 20 August 2015, Amsterdam, The Netherlands

StructuralComponents 4: Conceptual building models with structural design justification

Arie BOVENBERG1, Anke ROLVINK1, Jeroen COENDERS1

1Delft University of Technology, White Lioness technologies Stevinweg 1, 2628 CN Delft, the Netherlands [email protected], [email protected], [email protected]

Abstract The adoption of computation in the building industry has led to the development of a range of tools intended for design. Although commonly used for detailed analysis (FEA) and documentation (CAD/BIM), few tools address the needs of the early design stages for flexibility and quick, insightful feedback and documenting the justification of design choices. This absence of suitable tools leads to missed opportunities for computation in early-stage analysis and documentation of design progression and rationale. StructuralComponents has been developed as a tool for the early conceptual stages of structural design, until recently mainly focused on high-rise structures (Rolvink [13]). This paper describes the next steps of the development of a more generally applicable building model which supports composition of design justification (Coenders [5]): the collection of analysis models, reasoning, mental models, scenarios, etc. which form the backing of the choices which form design. This paper discusses the proposed building model and its underlying concepts, based on research into design theory, modelling approaches, and structural design practice as well as its application in practical examples. As a proof-of-concept, a prototype has been developed which demonstrates this modelling approach is flexible and versatile enough to document various types of designs, processes and reasoning. Opportunities for future developments include extending functionality for geometry and visualisations, as well as investigation into standardization. Keywords: conceptual structural design, computational design tools, design rationale, building information modelling

1. Introduction The process of designing a structure is a complex process, with no predetermined “optimal” result (Chapman [4]). The design process runs from the early design stages, where there is a great deal of flexibility but a lack of information, to the later stages, where this situation is reversed (more information, less flexibility). The effect of this trend is that engineers often have to make influential

92 Proceedings of the International Association for Shell and Spatial Structures (IASS) Symposium 2015, Amsterdam Future Visions

decisions when information needed to make these decisions is lacking. Making changes later in the design process is often costly. Most design tools, however, focus on detailed analysis and documentation and are therefore primarily suited for the later design stages. In the early design stages, designers often apply simplified models which are more flexible and insight-providing. StructuralComponents is a software tool for the early design stages which addresses these needs. As a design tool, its purpose is not to perform design itself (as is the case with expert-systems or optimisation tools), but to provide a set of tools to complement existing design techniques. This concept is based on the Structural Design Tools approach (Coenders and Wagemans [6]). In this way, StructuralComponents aims to provide a new generation of digital sketching paper: a design environment where the engineer can develop his or her design justification or concept, select tools to perform analysis and where computation serves to perform repetitive tasks, leaving the designer with more time to focus on the creative design process. Until recently, StructuralComponents was only focussed on the design of high-rise structures. In addition to extending the functionality to more common typologies, this research focuses on the development of a conceptual building model in which to represent the structural design justification: not as a single model or analysis method, but as a conceptual “design story” of various models, simplifications, schematisations, and scenarios (Coenders [5]).

2. Methodology The approach for the development of the conceptual building model is partly research- and design- driven. Research into (structural) design and conceptual building modelling yields initial assumptions and requirements. The development of the central concepts of the building model has been performed based on Design Thinking (Brown et al. [3]) and Extreme Programming (Shore and Warden [15]): utilizing an iterative development process, implementation of each concept offers opportunities for feedback and re-evaluation of assumptions.

3. Research

3.1 Design As mentioned earlier, design is a complex process. It is often described as iterative, cyclic or chaotic, and there have been many attempts to map the sequence of events in the design process. Although design often consists of separate activities such as analysis, synthesis and evaluation, the process generally does not occur in a fixed order (Lawson [10], Visser [18]). Designers, therefore, tend to focus on proposing solutions, rather than extensive problem analysis (Cross [7]). Another important characteristic of design are parallel lines of thought: several alternatives are often considered without an immediate attempt to resolve them (Lawson [10]). When advancing the design, the designer works with his past experiences as well as knowledge of the current subject. This process can be seen as “reflection” ch n [15]): each representation allows for reflection and development of design in a new direction. These new developments are then available to be re-interpreted (Gero [9]). Representations are integral to the design process: to describe problems and solutions requires representation. In engineering design, a variety of representations are

93 Proceedings of the International Association for Shell and Spatial Structures (IASS) Symposium 2015, Amsterdam Future Visions

necessary describe analytical, geometric or quantitative models (Dym [8]). Design also requires models at different levels of abstraction and scale, and the designer frequently switches between them. Structural design justification consists of several different elements. One important aspect are (analysis) models. An important characteristic of structural design is the use of simple as well as complex models: simplifications can be used to make quick evaluations and gain confidence in results, while complex models can provide extra insight (Coenders [4]). Related to alternatives, cases and scenarios are another main aspect of the structural design justification, and are used to illustrate how the structure deals with a particular situation. Another characteristic is the progression from preliminary to detailed design: preliminary design is mostly concerned with the overall feasibility of structural systems (Baker and Fenves [1]); often only later in design every individual member is defined.

3.2 Conceptual building models Most models in engineering practice focus on representing a structure precisely and in detail, for the purpose of (FEM) analysis or for representing the “ideal” structure for construction through documentation (CAD/BIM). As described earlier, these models are not very suitable for the early stages of design:  In the conceptual design stage, precise information is often unavailable and exact results are not required.  Constructing and modifying a detailed model is time-consuming. This is impractical in the early design stages when design changes are frequent.  These models are limited in their ability to describe underlying design reasoning.  Structural engineering is focussed on multiple boundary cases or worst-case scenarios while the above mentioned models often focus on the single “ideal” to be built scenario. A growing trend in the building industry is Building Information Modelling (BIM). In the broad vision of BIM, computation facilitates information management throughout the entire design process, but this is currently not the case (Coenders [5]): in practice, BIM often means a single 3D-model in which information from various disciplines is combined or multiple singe-disciplinary models combined to a single coordination model. An important advantage, however, of this type of BIM- model is its object-orientation: while traditional CAD models often only contain geometric data, a BIM model consists of objects, which can contain various properties and design information. This allows complex models to be richly populated with information. However, because these detailed 3D- models require precise information and are complex to build and modify, their advantages for the conceptual design stages are limited (Sacks and Barak [14]). Although most building models are aimed at the later design stages, a few representations have been proposed to support the early design process. One such development is SEED (Rivard and Fenves [12]), a software environment to support the early stages of building design. EED’s modelling approach is object oriented, but aims to support design evolution as well as to provide a standardized building model to allow for case-based design, allowing designers to apply knowledge from earlier designs. Objects in the model are organized hierarchically and relationships can be defined between them. This conceptual model provides a standardized top-down hierarchical decomposition. This approach has been adopted by several other design tools (Mora et al. [11]).

94 Proceedings of the International Association for Shell and Spatial Structures (IASS) Symposium 2015, Amsterdam Future Visions

Although this hierarchical division suits a top-down design process, enforcement of a standardized structural decomposition limits the model's flexibility: while the standard is extensible, it is by its nature not as innovative as design solutions themselves (Coenders [5]). In order to support conceptual design, it is important that models not inhibit the designer’s creative process: in order to provide sufficiently versatility, conceptual models should not focus on strict definitions, but allow room for interpretation. This can be achieved by implementing very generic components, incorporating both structured and unstructured data, and allowing different views within the same model (Turk [17]).

4. Results

4.1 Requirements The conceptual building model must support:  A unique process structure  Opportunistic switches between  Multi-dimensional design problems and representations integrated solutions  Various analysis models  Design progression through reflection  Cases & scenarios  Parallel alternatives  Evolution from preliminary to definitive  Different types of representations design  Representations at different levels of abstraction and scale

4.2 Concepts To structure the elements of the structural design story, the conceptual building model is subdivided into four domains. The component-domain describes the design subjects and contained design information: for example, a beam and its length. In the reasoning-domain, the justification behind this design information is described: for example, the reason behind a parameter value, or a design decision. The modelling-domain contains models and calculations used in this reasoning: for example, a beam model. The geometry-domain is used to describe component dimensions, shape and fit.

Concept 1: “Blank slate” components The first and central concept of the building model is that of generic, customizable components: components which are not characterized by strict definitions, but are first and foremost adaptable to design needs. The goal is to allow for representation of design-specific components, as well as increase model flexibility. This is implemented by allowing components to represent any structural feature which contains design information (attributes). This not only allows straightforward modelling of nonstandard structural features, but also modelling at any level of abstraction or scale. Components can thus include traditional components (beam, column, etc.), high-level components (truss, core), and also project-specific components such as custom systems or groupings (see Figure 1).

95 Proceedings of the International Association for Shell and Spatial Structures (IASS) Symposium 2015, Amsterdam Future Visions

Figure 1: the significance of custom object in describing building design: BIM and other traditional tools deal with low-level objects such as beams and columns. Tools for conceptual design include definitions for higher-level objects. However, often much of the “intelligence” of the design lays in components which are unique to the situation. Example from de Boer and Henkens [2].

Concept 2: Hierarchical organization The second central feature is that of hierarchical component organisation: components may contain subcomponents. This allows representation at various levels of abstraction and scale in the same model. This is implemented by allowing a component to have any number of “parent” or “child” components. This allows breakdown of components as needed for each design phase and makes it possible for one model to represent both a conceptual design – where systems and representative members are designed – and detailed design where each element is checked.

Concept 3: Reflective design reasoning The third main concept concerns modelling of design changes or additions as the result of reasoning from a certain design state or context. This methodology has been applied by allowing new attribute values to be added trough reasoning, which in turn may be based on other attributes. This way of modelling reasoning aims to allow for design parameters to play a role in several lines of reasoning, as well as allow to integrated solutions.

Concept 4: Analysis models as automated reasoning In the same way that manual logic (reasoning) can be applied in design steps, it is possible to apply models as a form of automated logic. The application of models is an important tool in design progression; many design parameters are the result of model outcomes. The goal is to allow the designer to determine what type of model to use, and when to use it. This functionality is implemented

96 Proceedings of the International Association for Shell and Spatial Structures (IASS) Symposium 2015, Amsterdam Future Visions

by allowing the designer to add a model to any reasoning item. Input for the model is gathered from the reasoning context, and model output determines the value of the outcome.

Concept 5: Alternative values per attribute As design information is stored in attributes, alternatives are represented as alternative values for this attribute. The StructuralComponents building model allows the designer to assign several different values to an attribute, with one being “active”. A value can be a reasoned outcome, but also an attribute from another component. The designer can switch between these values, and the model will respond to these changes. The idea of multiple values per attribute also makes the application of various models more straightforward by allowing the outcomes of various models to point to the same attribute.

Concept 6: Scenarios and alternatives as component states Scenarios and alternatives are both represented as a component in different states. In each state the component’s attributes may have different values. In the tructuralComponents building model, the designer can create any number of alternative variants. Different alternative values can be activated and associated with this variant. When referencing this component, a specific variant or the “default” variant can be specified.

Figure 2: Examples of components. Top and bottom left: a beam and floor component with (automated) design reasoning. Top-right: alternate values for an attribute. Bottom-right: one variant of a floor component.

97 Proceedings of the International Association for Shell and Spatial Structures (IASS) Symposium 2015, Amsterdam Future Visions

4.3 Implementation The conceptual building model has been implemented in a prototype application developed on the .NET platform. Aside from the building model, the prototype implements a user interface and a parametric engine. The parametric engine serves to keep the information consistent throughout associated elements of the building model and has been developed to support alternative values and component states.

5. Discussion

5.1 Validation The concepts of the building model have been validated through application in several pre-determined use-cases, which illustrate the required functionality. Figure 3 shows a condensed example: the analysis of a “core” stability element in a simple building model. The examples have shown that the central concepts of the building model sufficiently address the high-level requirements. Notable limitations are the absence of geometric and visual representations, and lack of advanced analysis tools.

Figure 3: Analysis of a “core” component. The value for total vertical load is dependent on whether the office tower is constructed in steel or concrete. A “soft” foundation scenario can be used to obtain a sufficiently conservative stability calculation. For the stability calculation itself, both a simplified model and a more exact model can be used. Sketches obtained from the preliminary design of the RAI Elicium in Amsterdam (Arup, 2009).

98 Proceedings of the International Association for Shell and Spatial Structures (IASS) Symposium 2015, Amsterdam Future Visions

5.2 Background Compared to design tools in current engineering practice, StructuralComponents takes a fundamentally different approach. Firstly, by providing a tool for early stage-design exploration. Additionally, design reasoning, lacking in most traditional models, plays a central role in the StructuralComponents building model. Compared to existing tools, however, the developed prototype still lacks functionality for geometry and visualization. As mentioned earlier, StructuralComponents has been developed based on the Structural Design Tools approach (Coenders and Wagemans [6]). This research continues in this direction by providing a tool which is highly adaptable and controllable. This is achieved by letting the engineer determine the components and organization of the building model. Also, because the user can define their own underlying reasoning, engineers can use their insight into structural behaviour to select the correct means for design justification, instead of a “one-click-calculation”.

5.3 Next steps This section discusses possible development directions following observations of the prototype validation.

5.3.1 Opportunities for standardization Although generic components are essential to cover unique design situations, some measure of standardization is required to allow for interoperability and prevent repetitive definition of routine situations. It is important, however, to implement this in a way which does not compromise the benefits of highly adaptable components. One way to do this is to implement standardized component interfaces and attribute types. These interfaces would define certain required attributes. Design flexibility would be maintained, as the designer is free to define which interfaces to apply, the reasoning and models behind these properties, as well as define any additional attributes as needed.

5.3.2 Reflection and visualization The conceptual building model implements a simple type of design “reflection”: reasoning from a state of component attributes. In design practice, reflection often takes many forms, often aided by various (visual) representations such as drawings or sketches. Supporting this type of reflection requires not only visual representations, but also a broader conceptual model for design reasoning context.

5.3.3 Geometry It is clear that geometry is an important aspect of design, especially in the later design stages. One way to implement geometric representations in an organized manner is to support definition of a geometric breakdown, along with the hierarchical component breakdown. In this way a component could contain a geometric representation of the composition of is subcomponents. A geometric representation could be built up from nodes and lines, with each linked to a component (e.g. a beam component is associated with a line and a connection component with a node).

99 Proceedings of the International Association for Shell and Spatial Structures (IASS) Symposium 2015, Amsterdam Future Visions

5.3.4 Other enhancements Possible enhancements include better handling of complexity trough replication, implementing reasoning behind alternative choices, expanding functionality for alternatives and scenarios, component validation trough automated checks, and links to more advanced analysis tools.

6. Conclusion The study has been set out to develop a new implementation of the StructuralComponents design tool, focussing on representing the various aspects of structural design justification. The study sought to investigate the elements of structural design justification, and develop a conceptual building model in which to represent these elements. Core characteristics of the design process and the structural design justification have been identified. These have established high-level requirements for modelling design in general, representations, and structural design. A conceptual building model has been developed to address these requirements: several core concepts have been proposed, partly derived from existing concepts and partly evolved from feedback during iterative development. As a proof-of-concept, a prototype has been developed which implements these concepts. Application in practical examples has demonstrated that these concepts address the high-level requirements, and have given insight into directions for future research. As a significant step towards a comprehensive model of structural design justification, the developed building model offers several opportunities. Firstly, by making design reasoning explicit, it could reduce miscommunication, and potentially promote re-use of design knowledge. Also, the flexible nature of the model allows for application of computational analyses earlier in the design process, leading to more informed decisions. Additionally, the inclusion of scenarios allows for more targeted use of optimisation.

Acknowledgements This research is part of a collaboration of the faculty of Civil Engineering and Geosciences of the Delft University of Technology, the BEMNext Laboratory, and White Lioness technologies. The authors would like to thank Prof. dr. ir. J.G. Rots. and Ir. J.W. Welleman (department of Structural Engineering, Faculty of Civil Engineering and Geosciences, Delft University of Technology) for their feedback during research and development. The authors would also like to thank Sander Hofman (Arup Amsterdam) for his feedback and for providing the practical examples for validation of the prototype.

References [1] Baker, N. C., Fenves, S. J., et al., A knowledge acquisition study of structural engineers performing preliminary design. Carnegie Institute of Technology: Department of Civil and Environmental Engineering, 1987. [2] Boer, M. de and Henkens, G., Virtuoze constructie in staal, beton en staalbeton, in Bouwen met staal, 2001; 158; 18–25. [3] Brown, T. et al., Design thinking, in Harvard business review, 2008; 86(6); 84.

100 Proceedings of the International Association for Shell and Spatial Structures (IASS) Symposium 2015, Amsterdam Future Visions

[4] Chapman, W., Rozenblit, J., and Bahill, A., System design is an NP-complete problem, in Systems Engineering, 2001; 4(3); 222–229. [5] Coenders, J., NetworkedDesign, PhD thesis, Delft University of Technology, 2011 [6] Coenders, J. and Wagemans, L., The next step in modelling for structural design: Structural Design Tools. In IASS 2005 International symposium on Shell and Spatial Structures, Theory, Technique, Valuation, Maintainance, 2005, 85–92. [7] Cross, N., Designerly ways of knowing, Design studies, 1982, 3(4); 221–227. [8] Dym, C. L., Engineering design: a synthesis of views, Cambridge University Press, 1994. [9] Gero, J. S., Conceptual designing as a sequence of situated acts. In Artificial intelligence in structural engineering, 1998; 165–177. [10] Lawson, B., How designers think: the design process demystified, Routledge. 2006. [11] ora, ., dard, C., and Rivard, H., A geometric modelling framework for conceptual structural design from early digital architectural models, in Advanced Engineering Informatics, 2008; 22(2); 254–270. [12] Rivard, H. and Fenves, S. J., A representation for conceptual design of buildings, in Journal of Computing in Civil Engineering, 2000; 14(3); 151–159. [13] Rolvink, A., Breider J., and Coenders, J., StructuralComponents–a Toolbox for Conceptual Structural Design, in IABSE Symposium Report, International Association for Bridge and Structural Engineering, 2010; 97(7); 32-39. [14] Sacks, R. and Barak, R., Impact of three-dimensional parametric modeling of buildings on productivity in structural engineering practice, In Automation in Construction, 2008, 17(4); 439– 449. [15] Sch n, D. A., The reflective practitioner: How professionals think in action, Basic books, 1983. [16] Shore, J. and Warden, S., The Art of Agile Development. O’ eilly edia, Inc., 2007. [17] Tur , ., Phenomenologial foundations of conceptual product modelling in architecture, engineering and construction, in Artificial Intelligence in Engineering, 2001; 15(2); 83–92. [18] Visser, W., Designing as construction of representations: A dynamic viewpoint in cognitive design research, in Human–Computer Interaction, 2008. 21(1); 103–152.

101