Parametric Design Master Model
Parametric Design Master Model
Parametric Design Master Model
Process of a Complex
Building In Practice
Using Programmed Code
As Master Model
Kat Park and Nicholas Holt
359
Abstract
Parameter based design explorations inevitably require a unified master
model that represents the current design state, where each parameter
being explored is essentially a critical sub-case of this master model.
Throughout the constantly changing design state, it is beneficial to
maintain a master model that is flexible and adaptive.This paper
describes the design process of a complex building whose master
model documented the design logic through implementation of
software code.This process is illustrated by the case study of Lotte
Super Tower (Seoul, Korea) from the beginning of schematic design to
end of construction document phase. By maintaining the master model
as a platform-free software code, in contrast to platform-dependent
methods, the case study illuminates the advantages of documenting the
generative logic behind design variations in a way that allows greater
flexibility and a higher level of alignment with design intent.
360
1. Introduction
Integrating parametric models into the process of design requires a
formalization of the generative logic and a systematic way of evolving this logic
in concert with design changes.A successful master model must, therefore,
keep track of the various parameters being explored.The critical sub-cases
that these parameters represent might be as simple as studying the effects of a
numerical value on the buildings form or a much more complex set of values
that explore the buildings response to factors such as environmental
conditions. In the more complex scenarios it might be more efficient for the
explorations to take place outside of the master model; nevertheless, whatever
design decisions might have been made need to be fed back into the master
model in order to propagate its influence on the overall design, as well as
manage the relationships among the various sub-cases. Parametric
representation of a design is a constantly evolving task, since most complex
design problems in practice are continually reacting to addition and deletion
of inputs at multiple scales and levels of complexity. Setting up a parametric
model requires defining the major parameters in the initial stage, but this
initial set of parameters continues to grow and change as the project
develops into different stages. Parametric modeling platforms existing today
offer assistance in defining the parameters and their associative
relationships; however, it is inevitable that using their predefined set of tools
will make the representation dependent on the specific platform.The notion
that availability of a tool invites use is well accepted in design.[1] Different
modeling platforms demand the end-user to have differing levels of
understanding and rigor in the process of defining the parameters and their
relationships. Rigor obtained through the constraints opposed by a software
platform is not only limited and often biased, but it is also dependent on the
form defined by the platform. As design process is inherently parametric, it
is important that designers use an open platform that is most appropriate
for building the relationships as they arise.
The main roles that should be fulfilled by the unified master model are:
361
362
363
364
which can be easily saved as a cluster of modules, often within the same
Grasshopper file.This allows the designer to save the generative logic in an
efficient, organized manner. Nevertheless, the designer is still tied to a very
particular user interface, and consequently, only explore within its
boundaries under its indirect design influences. For instance, one quickly
runs into the way data structures are inherently handled within all the
modules and its large influence in many of the tasks. Because the data
structures are required to be set up in a particular way, users often resort
to creating workaround solutions rather than build a parametric
relationship or association that is intuitive to them. Creating ones own
modules have recently become fairly easy, which have added greater
flexibility. More importantly, Grasshopper has not yet been able to handle
the amount of data or complexity of a project described in this paper.
365
Figure 5 shows the simple parameter set and their relationships from
Figure 4 translated into a function named BuildData in AUTOLISP code. As
mentioned previously, the specific values of the parameters are stored in a
separate configurations file in order to keep an organized history of the
values at different design stages, often accompanied by the reasons for their
change from the previous version.The BuildData function abstracts the idea
of a line at the top and bottom of the tower, not a circle or a rectangle.This
lower-level of abstraction allowed the flexibility of changing the top figure
366
into a square (which was one of the numerous design explorations the
project went through) or a circle.This kind of flexibility can often be difficult
to achieve when the platform restricts the operator to use its specific set of
user interface tools to create parametric relationships.
367
discretizations occur along the lines were all design explorations that
affected architecture as well as structure.These ideas were translated into
code and passed back and forth with the structural engineers sometimes as
code, sometimes as pseudo-code.When parameter values changed,
coordination was as easy as communicating a new set of values, since both
disciplines had already agreed on the parameter logic and their relationships
through code.This type of platform-independent communication between
the disciplines facilitated a generative - as opposed to a strictly analytical structural design consultancy, and provided significant flexibility in contrast
to the platforms typically used by architects and structural engineers.
368
369
Figure 8. An example of
generative logic for defining the
relationship between structural
centroid and exterior wall
Figure 9. An example of
generative logic (the exploded
option) for exterior wall
expression panel geometry.
Expression panel zone is defined
by the dotted lines enclosing the
gap between surfaces
370
371
2.
3.
Due to the taper and transformation in the tower form, each triangular
facet (tri-surface) of the exterior surface resulted in a unique geometry,
aside from the reflective symmetry across the center of the overall surface.
Therefore, it was necessary to handle panelization of each surface
individually.The logic of how each surface should be panelized was explored
and documented in the software code; and depending on the location of the
surface, one of final three strategies mentioned above were applied to the
372
373
374
4. Conclusion
Parametric thinking in design may be conceived of as the process of
abstracting a specific task into its operation and inputs. For many designers,
scripting is the first step to explicitly defining and documenting the design
logic. As the Lotte Super Tower project demonstrates, when approached as
a loosely organized network of scripts, a master data model in the form of
programmed code can provide significant flexibility, efficiency, and
coordination capability, especially in the context of complex and prolonged
design problems in practice. In large complex projects, the malleable code
can respond to constantly growing and evolving changes in the project much
faster and more easily than other comparable software platforms.
Acknowledgements
The author would like to thank all members of Lotte Super Tower project
team.
375
References
1. Mitchell,W.,Thinking in BIM, Architecture and Urbanism, 2009, 09:08 Special Issue,
10-15.
2. Eastman, C.,What is BIM?, Architecture and Urbanism, 2009, 09:08 Special Issue,
16-17.
3. Turkle, S., Simulation and Its Discontents,The MIT Press, Cambridge, MA, 2009.
4. Holzer, Dominic. Are You Talking to Me? Why BIM Alone Is Not the Answer. In
Association of Architecture Schools in Australasia. Sydney, Australia, 2007.
5. Holzer, Dominik, Richard Hough, and Mark Burry. Parametric Design and
Structural Optimisation for Early Design Exploration. International Journal of
Architectural Computing 5, no. 4 (2007): 625-643.
6. Kilian, Axel. Design Evolution through Bidirectional Modeling of Constraints.
PhD, Cambridge, MA: Massachusetts Institute of Technology, 2006.
7. Haghparast, Farzin, and Andrew Marsh. The Application of Computer-Optimised
Solutions to Tightly Defined Design Problems. Eindhoven, Netherlands, 2004.
8. Cross, Nigel. Design as a Discipline. De Montfort University, 2002.
9. Silver, Mike. Towards a programming culture in the design arts. Architectural
Design 76, no. 4 (2006): 5-11.
10. Silver, Mike. Building without drawings: Automason Ver 1.0. Architectural Design
76, no. 4 (2006): 46-51.
11. Visser,Willemien. Designers Activities Examined at Three Levels: Organization,
Strategies and Problem-Solving Processes. Knowledge-Based Systems 5, no. 1
(March 1992): 92-104.
12. Kalay,Yehuda. Redefining the Role of Computers in Architecture: from draftingmodeling tools to knowledge-based design assistants. Computer-Aided Design
17, no. 7 (September 1985): 319-328.
13. Shaviv, Edna,Yehuda Kalay, and U.J. Peleg. An Integrated Knowledge-Based and
Procedural System for the Design of Energy Conscious Buildings. Automation in
Construction 1, no. 2 (September 1992): 123-141.
376