Virtual Engineering in Architectural Design Herman NEUCKERMANS, Benjamin GEEBELEN, Stefan BOEYKENS

Department of Architecture, K.U.Leuven Leuven, Belgium

ABSTRACT

Computerized production of working drawings, specifications and renderings are common practice in architecture today.

Post-design computation is still the rule. However, the most important design decisions are taken in the early stages of design.

Therefore the future of real CAAD resides in developing a digital design environment capable of helping the architect while conceiving a design. What the architect needs is a CAAD system that ‘looks over his/her shoulder’ while designing and that informs about the qualities of the design, and at the same time leaves the decisions up to the designer or design team.

The paper discusses an approach to an integrated design environment for architecture.

Keywords: CAAD, architecture, simulation, engineering, digital building model

VIRTUAL ENGINEERING IN ARCHITECTURE

The implementation of such a system requires on the one hand an insight in the conceptual system of the architect and his/her ‘designerly’ way of thinking, and on the other hand the development of a data structure, both graphical and alphanumerical, capable of coping with the evolution of the design process. Subsequently we need to provide support for the testing at every design stage of those characteristics of the virtual model that seem relevant in that stage, such as daylighting, insolation, acoustics, energy, thermal bridges, cost, efficiency of circulation, shape, space, views, etc. Testing, appraisal and evaluation require the development of computational methods capable of coping with an incomplete model description, as is typical in the early stages of design.

Research has to elucidate the choice between the use of post-design computation methods with default values and the development of new simplified methods.

If we take daylighting as an example, we can distinguish between two major groups of computation methods: simple, manual methods - tables, diagrams, protractors - and advanced simulation software. In its current form the latter are not suited for early design stages: the input entails the painstaking gathering of data, most of which is not yet available, and operating the software requires a large amount of expert knowledge. The former, however, offer very low accuracy and their use, though very simple, is still rather laborious. In line with these two groups, one can come up with two new kinds of tools, tailored to the early design phases: software versions of the manual methods and user-friendly front-ends to the advanced simulation tools. The former would offer instant results, excellent accessibility but still a rather low accuracy.

The latter would guarantee trustworthy results and user friendliness by offering the user only a subset of the simulation tool’s functionality and data but may still involve long computation times. Only a thorough study of accuracies and default values can shed light on the choice between these two options. A third approach that has not yet been explored is to develop completely new tools that are based upon the same algorithms as the simulation packages but use fine-tuned versions of those algorithms to fit the needs and wishes of early design phases. This approach would combine the computation power of today’s workstations with any desired level of user friendliness and accuracy [1] [2].

Software for testing and appraisal of a design is existing today, even some for the early stages. These isolated modules however, require specific modeling again and again for each test separately.

Physical versus Virtual Engineering Visual simulation like fly-over and walkthroughs, color and texture mapping, depth cueing are done ‘at home’, on a simple personal computer and do not require anymore the sophisticated and expensive equipment like the TU Delft endoscope (Illustration 1).

The determination of insolation, shade and shadow patterns, insolation duration and coupled energy gains/benefits for whatever place on earth at whatever date and hour, is much more than the most complex heliodon is offering (Illustration 1).

Illustration 1: endoscope & heliodon

As far as daylighting is concerned, software is bringing the daylight room in the office. It provides daylighting levels as well as isoluxlines, and a rendering of light. The integrated computation of daylight and energy balance surpasses the physical daylight room (Illustration 2, Illustration 3).

Illustration 2: daylight room

Illustration 3: isoluxlines

The simulation of room acoustical qualities is done in software [3]. Till recently the prediction of room acoustical qualities required large scale physical models in order to be able to measure the impulse-response. This procedure was very tedious and above all, was not ‘soft’ enough to cope with the speed of evolving concepts and ideas in the early design stage, when the building model is still subject to major changes. Today reverberation time, distribution of loudness and speech intelligibility are tested and predicted with software allowing for iterative testing and refinement of the design solution by adapting the software model. The results of these simulations are no longer bare seconds and decibels, they are shown in graphics and they even can be heard acoustically via auralization (Illustration 4, Illustration 5).

Illustration 4: aula maxima, K.U.Leuven

Illustration 5: alternative of model from Illustration 4

Energy computation used to be done in the post-design phase, limited to and resulting in the dimensioning of the heating/cooling system. Today thermal performances, like the global level of insulation and the maximum U-value of elements belonging to the building envelope, are imposed by law. Software is available to compute surface temperatures, the risk for surface and /or internal condensation under stationary and non-stationary condition as soon as the composition of the building envelope is known [4] (Illustration 6, Illustration 7).

Illustration 6: 3D temperatures

Illustration 7: energy flow in W/m²

INTEGRATED DIGITAL MODEL

Ideally, all this happens in an integrated digital environment.

Conceptual System Its realization requires first knowledge of the conceptual system of the architect. However there is not such one system and it will always remain a subject of debate between those who believe in the legitimacy to look for such a system and those who claim that architectural design is by definition breaking the rules and therefore cannot be caught into a system or one design method. Well aware of these theoretical and methodological constraints, we have proposed a conceptual system that can be used for any design with grids [5]. Nowadays the flexibility of using grids in CAAD packages is rather limited, but it is reasonable to expect this will change in the future, provided architects are asking for it. Our conceptual system is conceived as an open system allowing the architect to enter the design upon choice on one of three (physical) levels: master plan, block and space (Illustration 8). That means that the architect can start from the bottom or, as it is mostly the case, from the top or from the idea of a shape. The model structures most of the entities an architect is working with: types, blocks, spaces, walls, floors, roofs, openings, windows, etc. These are organized in a hierarchical structure, positioned on grids and supported by the appropriate tests. The lower the physical level the more detail is shown. The mutation of a sketch design (SD) into a preliminary design (PD) and later on into working drawings (WD) is part of the system and has mainly to do with transformations of the level of detail.

WD

PD

Design Phases

SD BuildingProgram

Design Entities Grids Name Geometry and attributes Topology and attributes

Tests

-----

Cost/m² based on ratiosSurface and volume/spaceTemperature fluctuationsLevel of insulationMorphology

--------

Cost/m² or cost/m³Surface/blockCompactnessEnergy requirementsTrafficMorphologyViews and sightsShadowing

--

-----

Gross-nett surface/spaceCost based on elements methodComfort predictionDaylightingInsolationMorphologyElementary stability

----

Basic building typesMaster plan blocksCirculation axesSite contingencies

- Rooms or singular spaces

Building elements:WallColumnBeamArchOpeningDoor…

-------

Level 1

MASTERPLAN

Level 2

BLOCKorTYPE

Level 3

ROOMorSPACE

10/30

30/60

60/90

orthogonal

a n y o r i e n t a t i o

n

Illustration 8: Conceptual Model for Architectural Design

The feasibility however of the integrated digital environment is questioned more and more often. The complexity of a built artifact is so high that so far nobody has succeeded in tying it all together. Far from all possible functional, topologic, geometric interrelationships between architectural entities have been unveiled, studied and documented and subsequently no attempts to computerize their totality have succeeded.

The idea of an “Automated Design” is more and more abandoned in favor of “Assisted Design”. The computer can be seen as a complementary tool to the human brain, which excels in different areas, but it cannot be expected to take over design decisions and choosing options from the (human) designer. Recent developments in CA(A)D-software have shown manifold approaches, which provide new possibilities but also certain limitations.

Data Sharing A lot of research is focused on data sharing using an exchange file format: classic CAD-file formats (like DXF and IGES) only consider CAD-geometry (linework, surfaces, solids), while recent approaches like STEP and IFC propose a framework for the exchange of product model data. The problem is that these standards are still in development and that only the bare minimum of common objects is supported. At their best, they will assist in getting a design to be transferred from one user to another, without too much loss of information. And even when the data is transferred, there is limited support for the design intent that lies beneath the design.

Building Models Other research projects try to describe the building model itself. A first generation: e.g. GARM, RATAS, EDM/GDM, define common building objects and their respective relations. These efforts consider “SPACE” and “ACTIVITY” as a design object and not a mere “attribute”, as it is often the case in traditional CA(A)D-systems.

A newer generation of building models, more object-oriented and most of them not fully documented or finalized, can be seen in R&D projects such as BAS°CAAD, SEED, KAAD & P3, VEGA, BCCM and COMBINE2. One of the interesting aspects in these projects is providing means of describing an evolving design. Another feature is the description of the relations between physical and abstract entities, such as the connection between a wall and a space.

Based on our evaluation of these existing projects, we had some concerns [6]: − Most research projects do not elaborate on methodology. − The kind of data that is described often does not allow a

dynamic behavior of the objects, such as changing the object’s type during the design process.

− The different projects do not always clarify the level on which the different information is situated (the domain, the building phase, the terminology used). Some of them are not even focused on AEC-specifically.

− Most of these projects do not only deal with physical objects but also with spaces and activities, but all in a very different way. What is possible in one of these R&D projects is not feasible in another one; therefore it is not possible to choose one of them as a clear “winner”.

Core Object Model Taking into account all these considerations we decided to develop a new data structure, the “Core Object Model” [7]. In implementing this framework we avoid to rely on a rigid data structure, in order to allow for design changes and transitions, but practical limitations can (and will) occur, off course. The data structure, however, is a specific structure describing a building model and its relationships (Illustration 9).

LINK

ELEMENT GRAPHICAL

ENTITY CAADENTITY

REPRESENTATION

PHYSICAL ELEMENT SPACE USER ACTIVITY MASTERPLAN

BLOCK OUTSIDE

HOLE

USER SPACE

DEPENDENCE LINK

SPACE ASSEMBLY SPACE ASSEMBLY

LINK

SURFACE FINISH LINK

TYPE LINK

PHYSICAL ELEMENT TYPE

COMPOSITION LINK

PHYSICAL ELEMENT COMPOSITION

LOCAL COORDINATE SYSTEM

DRAWING LAYER DRAWING LAYER

LINK

USER SPACE ACTIVITY LINK

GRID

BLOCK ACTIVITY LINK

PROJECT

FREE ELEMENT

SPACE DEFINING LINK IMPLICIT SPACE DEFINING LINK

BOUNDARY LINK

PHYSICAL BOUNDARY LINK PHYSICAL CONTACT

LINK IMAGINARY BOUNDARYLINK

SURFACE

Illustration 9: entity relationship diagram

The object-oriented translation of this model into an entity-relationship model follows the MERODE methodology and is currently being implemented for a simple building model. The data model distinguishes CAAD objects with alpha-numerical characteristics and a platform-independent graphical representation of objects.

Currently a software prototype implementation of this Core Object Model is in progress, focusing on how to switch levels in the model and how to implement design phase transitions in architectural design [8]. It becomes clear that this cannot be achieved through automation. The architect still will have to make choices, such as where to position building elements with a thickness or how to solve nodes between building elements when evolving from an elementary model (‘support/graph lines’) towards a more elaborated building model.

ADDITIONAL RESEARCH

Along with this search for the ideal data structure, a lot of interesting issues pop up and play a role in the development of any digital design environment, such as the evolutionary nature of design entities, the transition from one design phase to the next, the switch from the bigger spatial and physical entities to the smaller embedded ones.

This is where scale dependent representation comes into play [9]. For architects this has always been an evidence: when drawing on a small scale, in the early stage of design or when they produce a masterplan, they draw less detail than while the are producing execution drawings on the larger scale. Strangely enough this has only recently been discovered in the digital world by introducing some kind of intelligent zoom (Illustration 10, attributes shown are CI/SfB building classification codes)

Illustration 10: intelligent zoom

An early stage building model of a design project requires only lines varying in line thickness. When furthering the design, these lines are translated into walls and floors representing their physical thickness. Attempts to automate this transition fail, because of the endless number of cases, combination and nodes that possibly can occur in an open building system. The best strategy seems to allow the architect to decide interactively how to solve the building nodes and where to position the primitive dimensionless ‘graph’ lines (Illustration 11) versus the full building element (Illustration 12).

inside terrace

inside inside

level

Illustration 11: graph lines

Even though graph lines can be an accurate representation of the designer’s intent, the resulting construction model can differ significantly. Design tools can only offer the designer choices, the decision cannot be automated.

level

Illustration 12: detail including offset graph lines

CONCLUSION

Virtual engineering is a valid approach in architectural design. Simulation and evaluation tests can support the design process, especially in the early design stages.

We are focusing, in the context of our research projects, on the intellectually interesting problems, on the key issues in the realization of an integrated design environment for architecture. A full implementation is far beyond the capabilities of a single research unit. We are instead investigating concepts that are limited or missing in current architectural CAD-software.

REFERENCES

Illustrations − TU Delft: Illustrations 1 & 2 − J.L. Scartezzini, R. Compagnon: Illustration 3 − G. Vermeir: Illustrations 4 & 5 − Physibel: Illustrations 6 & 7 − A. Hendricx: Illustration 9 [1] B. Geebelen, B., Natural-Lighting Design in

Architecture, Filling in the Blanks, in: R. Lamberts, C. Negrao, J. Hensen (eds.) Building Simulation’01, Proceedings of the 7th International IBPSA Conference, Rio de Janeiro, Brazil, 13-15/08/2001, pp. 1207-1214.

[2] B. Geebelen, Daylighting in Architecture: design and simulation, PhD dissertation, K.U.Leuven, Belgium, 2003.

[3] G. Vermeir, P. Mees, Numerieke simulaties in de zaalakoestiek: principes, realisaties, Bouwfysica, deel 3, K.U.Leuven, 1992, pp. 2-7 (course notes Building Physics, only available in Dutch)

[4] Physibel website: http://www.physibel.be [5] H. Neuckermans, A conceptual model for CAAD, in:

Automation in construction, vol 1, no 1, 1992, pp. 1- 6. [6] A. Hendricx, A core object model for architectural

design, PhD dissertation, K.U.Leuven (Belgium), 2000. [7] A. Hendricx, The object model at the core of the IDEA+

design environment,. in: Advances in building informatics, proceedings of Europia8 - Advances in Design Sciences and Technology, the 8th EuropIA International Conference on the application of Artificial Intelligence, Robotics and Image Processing to Architecture, Building Engineering and Civil Engineering, BEHESHTI, R. (ed.), Delft (The Netherlands), April 25-27, 2001, pp. 113-125.

[8] S. Boeykens, B. Geebelen, H. Neuckermans, Design phase transitions in object-oriented modeling of architecture, in: Connecting the Real and the Virtual - design e-ducation, proceedings of the 20th eCAADe Conference, Warsaw (Poland) 18-20 September 2002, pp. 310-313.

[9] H. Neuckermans, The Intelligent Pencil, A framework for CAAD in education, in: TURNER, J.A., (Ed.), Architectural Education, Research, Practice in the Next Decade Association for Computer-aided design in Architecture, proceedings of the ACADIA Workshop '86, Houston, 1986, pp. 113-128.