EEN PROTOTYPE VAN SOFTWARE TOOL VOOR DE ANALYSE VAN GEBOUWSTRUCTUREN

Faculteit Ingenieurswetenschappen en Architectuur Vakgroep Architectuur en Stedenbouw Voorzitter: prof. dr. ir.-architect Pieter Uyttenhove

EEN PROTOTYPE VAN SOFTWARE TOOL VOOR DE ANALYSE VAN GEBOUWSTRUCTUREN door Wendy Geeraert

Promotor: prof. dr. Ronald De Meyer Scriptiebegeleiders: drs. ir.-architect Ruben Verstraeten, dr. ir.-architect Pieter Pauwels, drs. ir.-architect Tiemen Strobbe

Scriptie ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: architectuur Academiejaar 2011–2012





iii

Voorwoord Dankwoord Graag zou ik de mensen die hun steentje hebben bijgedragen bedanken, want zonder hen zou dit werk niet zijn wat het nu is. Vooreerst gaat mijn dank uit naar mijn thesisbegeleiders, drs. Ruben Verstraeten en drs. Tiemen Strobbe, hen wil ik bedanken voor de grote hoeveelheid tijd en energie die ze in mij en dit werk stopten, voor hun geduld met mij wanneer ik kwam aankloppen met het zoveelste programmeerprobleem. In deze druk ik ook mijn dankbaarheid uit voor de commentaren en suggesties van dr. Pieter Pauwels. Tevens wens ik mijn promotor, prof. dr. Ronald De Meyer, te bedanken voor het vertrouwen en de geboden kans. Verder wens ik hen allen te danken voor hun advies, ondersteuning, waardevolle feedback en geduldig doorlezen van mijn teksten en script. Mensen voor wie geen dank te veel kan zijn, zijn mijn ouders. Het zijn zij die mij de kans gegeven hebben om te studeren en mij ten volle gesteund hebben in mijn keuzes. Zij hebben mij de mogelijkheden gegeven om te staan waar ik nu sta, om mij te verdiepen in mijn interesses, mij te ontwikkelen. Wie zeker aandacht verdient in deze passage, is Frederik, die ook steeds opnieuw en opnieuw klaarstond om mijn thesis te doorlezen en zonder wie dit werk nooit tot stand was gekomen. Verder wil ik nog een aantal mensen bedanken die hier niet bij naam vermeld zijn maar toch op een of andere manier voor mij een uitlaatklep geweest zijn, mij gesteund hebben tijdens mijn studies en dit jaar in het bijzonder. Bedankt.

Toelating tot bruikleen “De auteur(s) geeft(geven) de toelating deze masterproef voor consultatie beschikbaar te stellen en delen van de masterproef te te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze masterproef.” “The author(s) gives (give) permission to make this master dissertation available for consultation and to copy parts of this master dissertation for personal use. In the case of any other use, the limitations of the copyright have to be respected, in particular with regard to the obligation to state expressly the source when quoting results from this master dissertation.”

Wendy Geeraert, 10 augustus 2012

Een prototype van software tool voor de analyse van gebouwstructuren door Wendy Geeraert Scriptie ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: architectuur Academiejaar 2011–2012 Promotor: prof. dr. Ronald De Meyer Scriptiebegeleiders: drs. ir.-architect Ruben Verstraeten, dr. ir.-architect Pieter Pauwels, drs. ir.-architect Tiemen Strobbe Faculteit Ingenieurswetenschappen en Architectuur Universiteit Gent Vakgroep Architectuur en Stedenbouw Voorzitter: prof. dr. ir.-architect Pieter Uyttenhove

Samenvatting Onderhavige thesis probeert een oplossing te bieden voor de integratie van de structuuranalyse in het architecturaal schetsontwerp. Dit wordt bekomen door een theoretisch studie en de ontwikkeling van een prototype. Hoofdstuk 2 vertrekt van de analyse van de ontwerpfasen (§1),om te eindigen met de ontwerpprogramma’s (§2). Hoofdstuk 3 behandelt de evaluatie van bestaande structuuranalyse-programma’s. Gebaseerd op de bevindingen uit voorgaande hoofdstukken wordt er een prototype ontwikkeld in hoofdstuk 4. Hoofdstuk 5 bevat de handleiding bij dit prototype.

Trefwoorden Schetsontwerpfase, structuur, analyse, optimalisatie, generisch

A prototype for a structural analysis and optimization software Wendy Geeraert Supervisor(s): prof. dr. R. De Meyer, drs. ir.-architect R. Verstraeten, dr. ir.-architect P. Pauwels, drs. ir.-architect T. Strobbe Abstract—This dissertation will explore the possibilities to incorporate structural analysis in to the early architectural design stage. The aim is to develop a design support tool, instead of the usual analysis tools. Keywords— Early architectural design stage, structural, analyse, optimizing, generic

I. I NTRODUCTION UMEROUS technological advances have been made during the last decennia, resulting in a lot of complex technologies with a significant impact on the world. Consequently, complexities in architectural design grew at an equally fast pace. Examples of the high level of complexity can be found in architectural design projects that thrive on collaboration between multiple sub-areas of expertise. Because of this increasing level of complexity, new technologies are needed again, resulting in a vicious circle. The complexity and the innovative character of design stimulated the continued search for new design tools. There are few systems that assist users in the optimization and design of the structure in spite of the strong need for such computational tools. Dorsey states: ’Most of recent developments have failed to tap the potential of the computer as a design tool. Instead, computers have been relegated largely to the status of drafting instruments, so that the ’D’ in CAD stands for drafting rather than design’ (Dorsey, 1998). To tackle the issues outlined, previous research projects have investigated computational design. Researchers in this research domain seek to understand the design process and to use computers to help the designer during this process by applying a computational approach that complements the capabilities of the designer in a general and flexible way. This has resulted in computational design tools that typically provide a process that flexibly creates a variety of forms. A specifically promising methodology in this regard is the Generative Design Methodology (GDM). This methodology offers a way of conceptualising and producing design problems and solutions. The GD software is finally able to produce the most optimal solution within the boundaries of the problem space defined by the designer. This process continuously starts anew, until a satisfactory solution is obtained. This iterative process of coding and prototyping is nowadays typically performed by a team of experts and thus only available to large companies.

N

II. S TRUCTURAL ANALYSIS TOOLS Construction has had only a limited impact on the architectural design process, mainly in the form of tools and experts that are consulted when the design is almost final. We argue that this limited impact is caused by the limited accessibility of con-

structive analysis and optimizing tools to architectural designers during the early architectural design stage. This is an important limitation, because, as was indicated above, this stage is one of the most important steps of the complete iterative design process, during which some of the most crucial decisions about the design are made (Reitman, 1964). Such a tool should thus also support the iterative design of the early architectural design stage. Structural elements and structural features are part of such a design process and are subject to such crucial decisions. Reality shows that only experienced designers are capable to deal with the kind of complexity resulting of the interaction of structural aspects with other aspects at play in the design process. Beside this complexity, the large offer of structural analysis software makes it difficult to select the right software package. Additionally, most of these software packages are stand-alone solutions. This implies that the designer, who typically works in a pure 2D or 3D modelling environment, needs to redraw the design in the structural analysis software every time he wants to do a structural analysis of the design. This makes it impossible to efficiently use structural analysis software during the design process. There are a lot of tools and plug-ins, such as Building Performance Analysis tools, rendering tools etc., available for modelling environments. SketchUp (SU) for example has a whole library of plug-ins and ’rubies’ but no structural analysis tool that enables the user to evaluate his building during the early architectural design stage. A tool or software package that offers an integrated solution and one that is user-friendly is not available today. To develop a framework for this kind of plug-in, we have investigated structural analysis software. The outcome of this evaluation show the strengths and weaknesses of different tools and approaches. These eventually serve as guidelines in the development of a prototype. The general conclusion of the evaluation was as following: • there are too many different tools, with different functionalities; this makes it difficult to choose, • most of the tools are too complex and detailed to use during the early architectural design stage. In most case you need to be an expert to work with the tools, • the tools are too often stand-alone tools with an interoperability problem, • the faster a user gets result and the fewer action needed to do so, the better, • an optimizing function is recommended, • the amount of control components must be as less as possible, • the learning time must be short; the manual can’t be too extensive,

all data must be presented visually, in real-time. The chaotic nature of the early architectural design stage and the fact that no concept is fully defined during this stage provide another set of specific conditions for developing the prototype. Krish (2010) states that these kind of tools need to be easy to apply, in order to disturb the design as little as possible. The interventions of the designer need to be as limited as possible. Such a tool also needs to support the chaotic design process (Strobbe, 2011). Another condition according to Tversky (1999) is that a design process is iterative and visual, so the tool should be so as well. Figures and calculation have little value during the design process. •

wants to make a structural analysis, he runs the tool and a structurally optimal proposal is returned (figure 1). The prototype gets the necessary data from SU, analyzes, optimizes and proposes an optimized construction. So the tool itself propose a construction of beams, the designer doesn’t need to suggest a beam layout (figure 2). This process of analyzing and implementing continues until the designer is satisfied with the design. Finally when the design is finished the civil engineer will still need to make an exact analysis, but based on an already evaluated structure, without any big surprises.

III. P ROTOTYPE The conclusions from the previous analysis are the basis for the development of the suggested tool. The tool will be standalone but needs to have the functionality of a plug-in. One of the starting points for the design of this prototype is that it should be as generic as possible, so that it can easily be implemented into another modelling environment. In order to achieve this, the prototype is based on the fact that the data extracted from the model will be imported by an xml file. So the only change that needs to be made, to implement the tool into other software, is the data extraction and implementation process. The analysis and optimization is independent from the data extraction and visualization. Exporting the data to xml files also implies that the prototype itself can be scripted in any language, in this case in C#. The data extraction in this case is done by a tool developed by SmartLab as part of the BuildingChecker application (Jonckheere, 2009).

Fig. 1. Schematic representation of the prototype

The aim of this tool is to form an efficient and user-friendly structural analysis and optimization tool, which enables the user to evaluate and optimize the design in every stage of the design process, even in the early architectural design stage. As proof of concept this prototype concentrates at the evaluation of a timber beam structure, but it should be easily expanded to other structure types. In this case the prototype is developed for SU, because this is an application often used during the early architectural design stage (Jonckheere, 2009). The prototype brings analytical features to a modelling environment. As a result, the designer is able to model his building in SU, and whenever he

Fig. 2. Prototype

IV. C ONCLUSION This prototype discusses a prototype tool for structural analysis in the early architectural design process. The prototype can be extended into a structural analysis tool that can be used throughout the complete design process. In a next implementation phase, the following functionalities can be added to the initial prototype: • importing the proposed beam configuration back into the modeller environment, • testing another modelling environment, • adding extra parameters, • increasing the complexity of the geometry that can be handled, • adding another type of structure, like steel of concrete, • adding the evaluation of columns, walls, foundations... Eventually, all this could lead to a structural analysis tool that is better integrated with the general architectural design process. The followed approach might even allow the development of novel solutions that are difficult or impossible to achieve through regular structural analysis applications. R EFERENCES [1] Dorsey, Julie and McMillan, Leonar, Computer graphics and architecture: state of the art and outlook for the future, SIGGRAPH Comput. Graph., number 1, vol. 33, pp. 45-48, New York, USA, Feb. 1998. [2] Reitman, Walter R. and Shelly, Maynard W. and Bryan, Glenn L., Heuristic decision procedures, open constraints, and the structure of ill-defined problems, Human judgments and optimality, pp. 282-315, John Wiley and Sons, New York, USA, 1964. [3] S. Krish, A practical generative design method, Computer-Aided Design, number 1, vol. 43, pp. 282-315, January 2011.

[4] T. Strobbe, Onderzoek naar de inzetbaarheid van parametrische ontwerpstrategieën, Ghent, 2011. [5] B. Tversky, What does drawing reveal about thinking, Proc. Visual and spatial reasoning in design, Cambridge, 1999. [6] T. Jonckheere and R.Verstraeten and P. Pauwels and R. De Meyer, Ontwikkeling van een Google SketchUp-plugin als ontwerpinstrument voor een energiezuinige architectuur, IBPSA-NVL 2010 event : Simulatie voor energie-efficiénte of energieproducerende gebouwde omgeving, Eindhoven, Netherlands, 2010.

ix

Inhoudsopgave Overzicht

v

Extended abstract

vi

Inhoudsopgave

ix

Gebruikte afkortingen

xv

1 Inleiding 1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Doelstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Hoofdlijnen binnen de scriptie . . . . . . . . . . . . . . . . . . . . . . . . . 2 Achtergrond 2.1 Ontwerpfasen . . . . . . . . . . . 2.1.1 Verschillende benaderingen 2.1.2 Samenvatting . . . . . . . 2.1.3 Verschillende fasen . . . . 2.1.4 Conclusie . . . . . . . . . 2.2 Ontwerptools . . . . . . . . . . . 2.2.1 Visualisatie . . . . . . . . 2.2.2 Simulatie . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

3 Structuuranalyse programma’s 3.1 Finnwood - FinnForest . . . . . . . . . 3.1.1 Algemeen . . . . . . . . . . . . 3.1.2 Graphical User Interface (GUI) 3.1.3 Invoer . . . . . . . . . . . . . . 3.1.4 Analyse . . . . . . . . . . . . . 3.1.5 Output . . . . . . . . . . . . . . 3.1.6 Interoperabiliteit . . . . . . . . 3.1.7 Evaluatie . . . . . . . . . . . . 3.2 Karamba - Grasshopper . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . .

1 1 2 3

. . . . . . . .

5 5 5 10 10 14 16 17 22

. . . . . . . . .

23 24 24 24 25 27 28 28 28 28

3.3

3.4

3.5

3.6

3.7

3.2.1 Algemeen . . . . . . 3.2.2 GUI . . . . . . . . . 3.2.3 Invoer . . . . . . . . 3.2.4 Analyse . . . . . . . 3.2.5 Output . . . . . . . . 3.2.6 Interoperabiliteit . . 3.2.7 Evaluatie . . . . . . OpenStaad - GC . . . . . . 3.3.1 Algemeen . . . . . . 3.3.2 GUI . . . . . . . . . 3.3.3 Invoer . . . . . . . . 3.3.4 Analyse . . . . . . . 3.3.5 Output . . . . . . . . 3.3.6 Interoperabiliteit . . 3.3.7 Evaluatie . . . . . . PowerFrame - BuildSoft . . 3.4.1 Algemeen . . . . . . 3.4.2 GUI . . . . . . . . . 3.4.3 Invoer . . . . . . . . 3.4.4 Analyse . . . . . . . 3.4.5 Output . . . . . . . . 3.4.6 Interoperabiliteit . . 3.4.7 Evaluatie . . . . . . Risa 3D - Risa Technologies 3.5.1 Algemeen . . . . . . 3.5.2 GUI . . . . . . . . . 3.5.3 Invoer . . . . . . . . 3.5.4 Analyse . . . . . . . 3.5.5 Output . . . . . . . . 3.5.6 Interoperabiliteit . . 3.5.7 Evaluatie . . . . . . Robot - Revit . . . . . . . . 3.6.1 Algemeen . . . . . . 3.6.2 GUI . . . . . . . . . 3.6.3 Invoer . . . . . . . . 3.6.4 Analyse . . . . . . . 3.6.5 Output . . . . . . . . 3.6.6 Interoperabiliteit . . 3.6.7 Evaluatie . . . . . . MasterSeries - MasterSeries

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28 29 30 31 31 33 33 33 33 34 34 35 36 36 37 37 37 37 38 40 41 41 41 42 43 43 43 45 45 46 46 46 46 46 47 49 50 50 50 50

3.8

3.7.1 Algemeen . . . . 3.7.2 GUI . . . . . . . 3.7.3 Invoer . . . . . . 3.7.4 Analyse . . . . . 3.7.5 Output . . . . . . 3.7.6 Interoperabiliteit 3.7.7 Evaluatie . . . . Conclusie evaluatie . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

4 Prototype 4.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . 4.2 Concept . . . . . . . . . . . . . . . . . . . . . . 4.3 Proces . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Modelleeromgeving . . . . . . . . . . . . 4.3.2 Data extraheren . . . . . . . . . . . . . . 4.3.3 Verrijking met catalogi . . . . . . . . . . 4.3.4 Verrijking door de gebruiker . . . . . . . 4.3.5 Evaluatie . . . . . . . . . . . . . . . . . 4.3.6 Optimalisatie . . . . . . . . . . . . . . . 4.3.7 Visualisatie . . . . . . . . . . . . . . . . 4.3.8 GUI . . . . . . . . . . . . . . . . . . . . 4.4 Algoritme . . . . . . . . . . . . . . . . . . . . . 4.4.1 BuildingElementsReader . . . . . . . . . 4.4.2 ThisTimber en Timber . . . . . . . . . . 4.4.3 Load . . . . . . . . . . . . . . . . . . . . 4.4.4 LengthEdges . . . . . . . . . . . . . . . 4.4.5 Calculation . . . . . . . . . . . . . . . . 4.4.6 Visualisation . . . . . . . . . . . . . . . 4.5 Implementatie in Grasshopper . . . . . . . . . . 4.5.1 Modelleeromgeving . . . . . . . . . . . . 4.5.2 Data extraheren . . . . . . . . . . . . . . 4.5.3 Verrijking door catalogi en de gebruiker . 4.5.4 Verwerking data . . . . . . . . . . . . . . 4.5.5 Evaluatie en optimalisatie . . . . . . . . 4.5.6 Visualisatie . . . . . . . . . . . . . . . . 4.5.7 Alternatieven . . . . . . . . . . . . . . . 4.5.8 GUI . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

50 50 51 52 52 53 53 53

. . . . . . . . . . . . . . . . . . . . . . . . . . .

59 59 60 63 63 63 65 65 67 68 69 69 70 71 72 72 73 74 75 75 77 77 78 79 79 80 80 80

5 Handleiding 83 5.1 Minium systeemvereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.2 Installaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.3

5.4

5.5

5.2.1 Installatie Google SketchUp . . . . . 5.2.2 Installatie xml-exporter . . . . . . . . 5.2.3 Installatie SketchStruct . . . . . . . . Modelleren in SU . . . . . . . . . . . . . . . 5.3.1 Eenheden . . . . . . . . . . . . . . . 5.3.2 Gebruik van lagen . . . . . . . . . . 5.3.3 Modelleren van de geometrie . . . . . 5.3.4 Modelleren van scheidingsconstructies Exporteren . . . . . . . . . . . . . . . . . . 5.4.1 Zones aanmaken . . . . . . . . . . . 5.4.2 Constructies aanmaken . . . . . . . . 5.4.3 Export . . . . . . . . . . . . . . . . . SketchStruct . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

83 84 85 85 85 86 87 87 91 92 93 94 95

6 Besluit 99 6.1 Beperkingen en opportuniteiten . . . . . . . . . . . . . . . . . . . . . . . . 100

Bijlagen

103

A Houtsoorten

103

B Formules voor de doorbuiging

107

C Ontwerpmethodes C.1 Inleiding . . . . . . . . . . . C.2 Evolutionary Algorithms . . C.2.1 Opbouw . . . . . . . C.2.2 Basisprincipe . . . . C.2.3 Selectieprocedure . . C.2.4 Reproductie . . . . . C.2.5 Werking . . . . . . . C.2.6 Voor- en nadelen . . C.2.7 Toepassingsvoorbeeld

109 . 109 . 110 . 110 . 110 . 111 . 112 . 112 . 113 . 114

Bibliografie Bibliografie

Lijst figuren en tabellen Lijst van figuren

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

117 117

123 123

Lijst van tabellen

127

Lijst van codefragmenten

127

GEBRUIKTE AFKORTINGEN

Gebruikte afkortingen AEC

Architecture Engineering and Construction

BIM

Building Information Modelling

B-rep

Boundary Representation

CAD

Computer Aided Drafting

CAM

Computer Aided Manufacturing

CSG

Constructive Solid Geometry

EA

Evolutionary Algorithms

EC

Eurocode

EP

Evolutionary Programming

ES

Evolution Strategies

GA

Genetic Algorithms

GC

Generative Components

GUI

Graphical User Interface

OA

Orde van Architecten

RIBA

Royal Institute of British Architects

SU

SketchUp

SDK

Software Development Kit

xv

xvi

INLEIDING

1

Hoofdstuk 1 Inleiding 1.1

Context

In een maatschappij die steeds complexer wordt, staat ook het creatieve denkproces van een ontwerper niet los van de technologische vooruitgang. Ongetwijfeld hebben deze technologieën de laatste decennia een significante invloed gehad op de laatste architecturale hoogstandjes overal ter wereld. De onophoudelijke stroom van nieuwe informatie en de manier waarop deze wordt verspreid geeft de ontwerper meer mogelijkheden om te experimenteren en te innoveren. Toch mag niet uit het oog worden verloren dat, ondanks deze mogelijkheden en ondersteuning, de complexiteit van het architecturale ontwerp met eenzelfde exponent is toegenomen. De meest voor de hand liggende voorbeelden van deze verregaande complexiteit tijdens het architecturale ontwerp zijn terug te vinden in ontwerpprojecten die tot stand zijn gekomen tijdens de samenwerking tussen verschillende domeinen van expertise. Een samenwerking die steeds meer wordt opgedrongen door de nieuwe maatschappelijke noden en maatstaven. Experten, zoals architecten, technische ingenieurs, bouwkundig ingenieurs, veiligheidsverantwoordelijken, landschapsontwerpers enzovoort, moeten hierbij niet in het minst rekening houden met een veelvoud aan lokale en internationale legale bepalingen, verordeningen en wetten met betrekking tot veiligheid, duurzaamheid, energie, stabiliteit... Deze context geeft aanleiding tot een vicieuze cirkel. De toegenomen complexiteit voedt de vraag naar nog meer en betere hoogtechnologische ondersteuning. As the scale of design processes increases, as well as their ” knowledge’s intensity and organizational complexity, the traditional approaches may no longer suffice” [51]. Iets later merkt zijn Nederlandse collega op: When the number of ” involved elements has become too large, relying on traditional methods becomes insufficient and risky” [14]. Deze nood aan ondersteuning stimuleert de zoektocht naar technologische hulpmiddelen zoals Augmented Reality Environments [57], Metadata Archives [73], Complex Rule-based Simulation Tools [29] en andere. Er bestaat weinig twijfel over dat de informatietechnologie deze ondersteunende rol waarmaakt. De centrale vraag blijft echter welke de meeste ideale invalshoek is voor een geschoolde ontwerper of een ontwerpteam.

2 De laatste ontwikkeling in software die een poging doet deze complexiteit aan te pakken, staat gekend als Building Information Modelling (BIM). Deze ontwikkeling trekt de aandacht van vele onderzoekers, ontwerpers en kantoren en wordt dan ook aanzien als dé methode voor toekomstige ontwerpprocedures. Vandaag echter blijft deze beperkt tot een methode voor grotere projecten door de complexiteit van dergelijke programma’s en de dure aanschafwaarde (‘Most important obstacles to BIM adoption’, Annex A) [72]. Het is een misvatting dat de toenemende complexiteit enkel toe te schrijven is aan de omvang van een project. De meest eenvoudige en voor de hand liggende ontwerpen worden ook geconfronteerd met nieuwe vragen of vereisten die hun oorsprong vinden in een steeds breder wordende waaier van disciplines en kennis. Een ontwerpproces heeft immers inherent een complexe structuur die, afhankelijk van het standpunt, steeds anders wordt ge¨ınterpreteerd en benaderd. Een architect creëert heel wat alternatieven om deze te onderzoeken en tegenover elkaar af te wegen. Gedurende het ontwerpproces, tijdens verschillende ontwerpstadia, maakt hij gebruik van computergestuurde technieken en programma’s die hem helpen deze verschillende alternatieven te genereren. Dorsey stelt echter: Most of recent developments have failed to tap the potential of the computer as a design ” tool. Instead, computers have been relegated largely to the status of drafting instruments, so that the ’D’ in CAD stands for drafting rather than design” [28]. Ook de constructieve structuur, die ontegensprekelijk deel uitmaakt van het ontwerp, bezit vaak een complexiteit die de computer als ontwerphulpmiddel noodzaakt. Naast deze complexiteit, maakt het grote aanbod van structuuranalyse-programma’s dat het moeilijk wordt om het juiste programma te selecteren. Bovendien zijn dergelijke programma’s meestal alleenstaande oplossingen voor experten, wat efficiënt gebruik vroeg in het ontwerpproces bijna onmogelijk maakt. Een applicatie die een ge¨ıntegreerde oplossing aanbiedt die daarenboven ook gebruiksvriendelijk is, lijkt vandaag niet voorhanden.

1.2

Doelstellingen

Diverse auteurs besluiten dat er weldegelijk een nood is aan computergestuurde hulpmiddelen die het iteratief ontwerpproces van de schetsontwerpfase ondersteunen omdat dan enkele van de meest kritieke beslissingen over het ontwerp worden genomen [61]. Het doel van onderhavige scriptie is vast te stellen wat de problemen zijn met de huidige programma’s en vervolgens een prototype te ontwikkelen voor een efficiënt en gebruiksvriendelijk programma dat toelaat een analyse en optimalisatie te maken van een constructieve structuur. Dit prototype moet de ontwerper in staat stellen om het ontwerp te

1.3 Hoofdlijnen binnen de scriptie

3

evalueren en de houten balkenstructuur te optimaliseren in elke fase van het ontwerpproces, ook tijdens het schetsontwerp.

1.3

Hoofdlijnen binnen de scriptie

1. Het tweede hoofdstuk omschrijft de beginstellingen waarop onderhavige scriptie is gebaseerd. Dit hoofdstuk doet tevens dienst als theoretische achtergrond voor de ontwikkeling van het prototype. 2. Het derde hoofdstuk gaat in op het gebruik van de bestaande architecturale hulpprogramma’s en in het bijzonder van structuuranalyse-programma’s. Dit hoofdstuk besteedt aandacht aan de voor- en nadelen van deze programma’s. De resultaten van deze evaluatie zullen worden ingezet tijdens de ontwikkeling van het prototype. Na dit inleidende deel wordt er ingegaan op het prototype zelf. 3. Hoofdstuk vierde bespreekt het algemene concept en de ontwikkeling van het prototype. 4. Het vijfde hoofdstuk bevat de handleiding voor het gebruik van het prototype. 5. Tot slot volgt de evaluatie en het besluit met de beperkingen, opportuniteiten en komende uitdagingen. De evaluatie gebeurt aan de hand van de conclusies die zijn gemaakt na de analyse van de literatuurstudie en de opgelijste structuuranalyse-programma’s.

4

ACHTERGROND

5

Hoofdstuk 2 Achtergrond Dit hoofdstuk bakent het kader af waarbinnen deze scripte moet worden gelezen. Het biedt geen volledig overzicht maar schetst de fasen, de verschillende hulpmiddelen en de methoden voor het architecturaal ontwerpproces. Voor een uitgebreid overzicht van de verschillende fasen wordt er verwezen naar het referentiewerk van Cross ‘Developments in Design Methodology’ [27] of ‘Architecture in use, an introduction to the programming, design and evaluation of buildings’ van van der Voordt en van Wegen [77].

2.1

Ontwerpfasen

Het architecturaal ontwerpproces wordt in de literatuur opgesplitst in verschillende fasen. Elk van deze fasen wordt afzonderlijk benaderd en voor elke fase worden er afzonderlijke programma’s voorzien. Meningen lopen uiteen, meestal gestoeld op de achtergrond van de waarnemer, over hoe deze fasen moeten worden opgedeeld en over hoe ze moeten worden benaderd.

2.1.1

Verschillende benaderingen

Achten [12] stelt, gebaseerd op het overzichtswerk ‘Developments in Design Methodology’ van Cross [27], dat er binnen de literatuur verschillende klemtonen worden gelegd. Met de eerste conferentie over Design Methods te Londen in 1962, startte ook het debat en onderzoek naar ontwerpmethoden. In de jaren zestig verschenen de eerste boeken hierover: Asimow [20], Archer [18], Gordon [37] en Osborn [55]. Gedurende deze periode werd er voornamelijk gezocht naar het ideale ontwerpproces. In de jaren zeventig zette men zich af van deze benadering en trachtte men de ontwerpproblemen zo nauwkeurig mogelijk te beschrijven om deze zo op te kunnen lossen. Zo bevat ‘A Pattern Language: Towns, Buildings, Construction’ [15] van Alexander een oplijsting van verschillende regels en afbeeldingen, die telkens een probleem beschrijven en een oplossing aanreiken.

6 Ook Jones realiseerde zich dat ontwerpen begint bij het definiëren van het probleem [43]. Verder kwam de term Wicked problem in deze periode aan bod [63]. De reactie hierop kan worden opgesplitst in twee stromingen, de ene ging ontwerpers observeren tijdens hun ontwerpproces, Lawson ‘How Designers Think’ [49], Rowe ‘Design Thinking’ [66] en Herbert Simon ‘The Sciences of the Artificial’ [71], terwijl de andere trachtte de fundamentele concepten van het ontwerpen vast te leggen Archer ‘Design as a discipline’ [19]. Vanaf de jaren tachtig werd met de opkomst van de computer de focus verlegd naar de ondersteuning van het ontwerpen.

Divergeren - transformeren - convergeren Jones [43] stelt dat onderzoekers het erover eens zijn dat er drie essentiële ontwerpfasen zijn: analyse, synthese en evaluatie. Hij vat ze samen als volgt: de analyse is de beschrijving van het probleem in zijn geheel en het opbreken in subproblemen; de synthese is het opdelen van de subproblemen in onderdelen en deze samenvoegen tot een nieuw geheel en de evaluatie is het bepalen van de mate waarin de gehele of gedeeltelijke oplossingen voldoen aan de vooraf vastgestelde voorwaarden. Hiertegenover staat dat hijzelf andere klemtonen legt door het ontwerpproces op te delen in een divergerende, transformerende en convergerende fase. Deze fasen kunnen als volgt worden beschreven: Divergerende fase: Het probleem wordt getest om grenzen, gevolgen en paradoxen te ontdekken. The act of extending the boundary of a design situation so as to have ” a large enough, and fruitful enough, search space in which to seek a solution.” [43]. Transformerende fase: In deze fase zijn de problemen en parameters reeds gedefinieerd. De problemen worden opgedeeld in subproblemen, gecombineerd, geëlimineerd, vereenvoudigd, getransformeerd of aangepast. Belangrijk is dat het resultaat van deze fase voldoende precies is om convergentie naar één uniek model in de volgende fase mogelijk te maken. Convergerende fase: Het ontwerp wordt steeds concreter om uiteindelijk te convergeren tot één ontwerp. Als er tijdens deze fase een probleem zichtbaar wordt dat niet opgemerkt werd, moet de transformatiefase opnieuw worden doorlopen. Jones stelt dat in deze fase een rationele aanpak mogelijk is en dat deze fase dus aan de hand van een computer kan worden gevoerd.

Jones concludeert dat in een ontwerpmethode het één van de doelstellingen is om het ontwerp minder cyclisch en dus meer lineair te maken. Een cyclische methode impliceert namelijk dat bepaalde kritieke nevenproblemen pas in een latere fase van het ontwerpproces worden ontdekt. Dit kan er toe leiden dat het volledige ontwerp moet worden herbekeken. Een lineaire methode impliceert dat alle problemen gedefinieerd zijn aan het

2.1 Ontwerpfasen

7

begin van het ontwerpproces, zonder risico om later het ontwerp te moeten herzien. De moeilijkheid in deze doelstelling is dat de relaties tussen de verschillende problemen en subproblemen onvoorspelbaar zijn.

De basis ontwerpcyclus Een ander benadering is deze die het ontwerpproces definieert als een iteratief proces. Er kunnen verschillende gradaties worden onderscheiden, van geheel iteratief (de iteratie is mogelijk vanaf elke fase) tot beperkt iteratief (enkel vanaf bepaalde fasen wordt er teruggekoppeld), of enkel iteratief binnen elke fase afzonderlijk. Figuur 2.1 geeft de ’Basis Ontwerpcyclus’ van Roozenburg en Eekels [64] weer. Dit is geen ontwerpmethode en legt geen nadruk op de verschillende fasen maar op het feit dat het ontwerp een iteratief proces is waarbij elke fase wordt doorlopen zonder stappen over te slaan. Het ontwerpproces is een trial-and-error -proces dat bestaat uit een reeks van empirische cycli. In elke cyclus worden oplossingen gegenereerd en vervolgens getest. Dit proces herhaalt zich tot het gewenste resultaat wordt bekomen.

Figuur 2.1: De basis ontwerpcyclus van Roozenburg en Eekels

8 Watervalmodel Dit is een model dat bestaat uit een reeks van processen en subprocessen die elkaar opvolgen in een chronologische volgorde, zonder dat er iteraties zijn (figuur 2.2). Dit model vindt zijn oorsprong in de productie- en bouwsector. In deze sectoren is het bijna onmogelijk om na bepaalde fasen nog aanpassingen door te voeren. Het was in ‘Managing the Development of Large Software Systems’ dat Winston [78] dit model en de nadelen ervan voor het eerst beschreef voor de ontwikkeling van software. Tegenstanders van dit model stellen dat het onmogelijk is om elk fase geheel af te sluiten en over te gaan naar de volgende.

Figuur 2.2: Watervalmodel

Voordelen van dit model zijn: Er is een duidelijke opdeling van de verschillende fasen. Dit maakt dat het proces makkelijk door externen is te volgen en te controleren. Er is geen overlapping tussen de verschillende fasen mogelijk, het is een lineair model, dat de complexiteit van een iteratiefproces uitsluit.

2.1 Ontwerpfasen

9

Nadelen: Zoals eerder aangehaald is het in een lineair proces belangrijk alle problemen in het begin te definiëren. Dit is volgens Jones [43] onmogelijk. Het is mogelijk dat problemen die dienen te worden opgelost in één fase pas duidelijk worden in de volgende fase.

Iteratief convergerend Ontwerpen is een iteratief proces, waarbij iedere ontwerper gebruik maakt van zijn eigen methode om het ontwerp aan te pakken. Of er nu wordt gesproken over het watervalmodel, het eigenlijk iteratiefmodel of het model van Jones, elk ontwerpproces lijkt een aantal elementen gemeen te hebben.

Figuur 2.3: Asimow ontwerpcyclus

Asimow [20] beschrijft het ontwerpproces als een cyclus van activiteiten die plaatsvinden tijdens een bepaalde tijdspanne. Hij onderscheidt twee structuren in het ontwerpproces: de horizontale en de vertikale (figuur 2.3). De horizontale structuur is een cyclus die begint met de analyse (A) en door middel van synthese (S) en evaluatie (E) overgaat naar de communicatie (C). Deze cyclus wordt gezien als een iteratie in de verschillende fasen van het ontwerpproces. De vertikale structuur, die de verschillende fasen van het ontwerpproces bevat, evolueert van een abstract probleem tot het uiteindelijke gebouw zelf.

10 De klassieke oplijstingen van de ontwerpfasen, die in het volgend hoofdstuk worden bespoken, zijn voorbeelden van het ’iteratief convergerend’ model.

2.1.2

Samenvatting

Achten [12] stelt, gebaseerd op Jones, Cross en Roozenburg en Eekels dat het ontwerp op te delen is in vier verschillende fasen. De eerste fase is de analytische fase waarin de aard van het ontwerpprobleem wordt onderzocht. De tweede is de creatieve fase waarin een oplossing wordt bedacht. De derde is de uitwerkingsfase waarin de oplossing wordt getoetst. Tot slot, de vierde fase, is de overhead over het proces. Voor elk van deze fasen zijn er verschillende ontwerpmethoden en hulpmiddelen.

Verder kan er een samenvatting worden gemaakt van alle voorgaande processen, als er wordt gekeken naar de types van tekeningen die worden gemaakt tijdens de verschillende fasen:

conceptuele tekeningen en schetsen,

gedetailleerde schetsen,

definitieve en gedetailleerde tekeningen,

constructieve tekeningen.

2.1.3

Verschillende fasen

Naast de theoretische benaderingen zijn er organisaties die de verschillende fasen oplijsten, om deze in te zetten als draaiboek tijdens het ontwerp en de realisatie.

2.1 Ontwerpfasen

11

RIBA plan of work

Gray, Hughes and Bennett

Capricode

-Appraisal

-Outline design

-Approval principle

-Design Brief -Concept

-Conceptual design

Construction handbook in

OA Vlaamse Raad

-Feasibility

-Budget cost

-Outline Proposals

-Design

-Scheme Design

-Voorontwerp

-Detail Design

-Definitief voorontwerp

-Production Information

-Stedenbouwkundige vergunning

-Tender action

-Uitvoeringsdossier

-Design Development -Technical Design -Production Information

-Detailed design

-Tender contract

and

-Tender Documentation -Tender Action -Mobilisation

-Construction drawings

-Construction

-Construction to Practical Completion

-Commissioning

-Post Practical Completion

-Evaluation Tabel 2.1: Lineaire benaderingen

RIBA (Royal Institute of British Architects) Het werkplan van RIBA (http://www.architecture.com/) concentreert zich op de organisatie van het beheren van het proces, het ontwerpen van bouwprojecten en de administratie van bouwcontracten. Deze aanpak kan worden gereduceerd tot vijf belangrijke tussenstappen: Voorbereiding of Appraisal & Design Brief : Tijdens deze fase wordt er nagegaan wat de noden en objectieven van de opdrachtgever zijn. Dit wordt gevolgd door een haalbaarheidsstudie en een onderzoek naar alle benaderingsmogelijkheden. Hierbij

12 mogen ook de aanwezige beperkingen niet uit het oog worden verloren. Tenslotte wordt het bouwprogramma, dat voldoet aan de noden, wensen en beperkingen opgesteld. Ontwerp of Concept & Design Development & Technical Design: Het schetsontwerp wordt in deze fase uitgewerkt. Dit schetsontwerp neemt een initiële stelling in ten opzichte van het bouwprogramma. Verder wordt er ook al een onderzoek naar technieken en structuur gevoerd. Dit alles wordt tenslotte in een kostenraming opgenomen. Pre-constructie of Production Information & Tender Documentation & Tender Action: Het ontwerp wordt verder uitgewerkt en gedetailleerd. Deze fase legt vooral de nadruk op de structuur en de technieken. Verder wordt er een onderhoudsplan opgesteld en gezocht naar een aannemer die dit onderhoud kan uitvoeren. Constructie of Mobilisation & Construction to Practical Completion: Tijdens deze fase wordt de aannemer aangesteld en worden de bestekken opgemaakt. De informatie die de aannemer en specialisten aanbrengen wordt nagekeken. Ingebruikname of Post Practical Completion: Tenslotte worden de werken opgeleverd. Nu wordt ook de assistentie bij het betrekken van het gebouw door de bouwheer voorzien en het controleren van de prestaties na de ingebruikname.

Gray, Hughes and Bennett’s model Dit model [38] is eenvoudiger dan de fasen beschreven in het ‘Plan of Work’ van RIBA. Het focust zich meer op het ontwerpproces en de verschillende documenten en tekeningen die per fase worden geproduceerd. Outline design: De ontwerper stelt zijn ideeën rond de vorm van het gebouw in relatie tot de functie voor en hij bepaalt zijn algemeen concept voor de architectuur. Conceptual design: Tijdens deze fase wordt het ontwerp meer in detail uitgewerkt. Er wordt ook al nagedacht over zaken als constructieprincipes. Detailed design: Dit is de meest uitgebreide en complexe fase, vooral op vlak van de hoeveelheid materiaal die wordt geproduceerd en de graad van detail. Alle plannen en snedes worden op een kleinere schaal, zoals bijvoorbeeld 1/20, geprint. Construction drawings: Tot slot moeten alle componenten, dimensies, materialen, connecties en details exact worden bepaald en getekend zodat de aannemer hiermee aan de slag kan om het gebouw effectief te bouwen.

2.1 Ontwerpfasen

13

Capricode Dit is een checklist die wordt gebruikt bij de ontwikkeling van een gebouw in de gezondheidssector. Het is een checklist die zowel het ontwerp, de kostenbeheersing, de aanbesteding, de bouw, de inbedrijfstelling en de evaluatie behandelt. Approval in principle & Budget cost: Het bouwprogramma en het budget worden bepaald. Design: Het ontwerp wordt hier als één onderdeel behandeld en niet verder opgesplitst. Tender and contract: De aannemers voor de bouw en het onderhoud worden aangesteld. Construction & Commissioning: Deze fase omvat de bouw en de ingebruikname. Evaluation: Tot slot wordt het gebouw geëvalueerd op comfort.

Construction handbook Dit handboek bekijkt de fasen vanuit een administratief oogpunt en legt de nadruk op kosten en planning [25]. Feasibility & Outline Proposals: Er wordt een haalbaarheidsstudie gemaakt aan de hand van de verschillende voorstellen en het budget wordt bepaald. Scheme Design & Detail Design: Het ontwerp wordt getoetst aan het budget en er wordt een kostenplanning opgesteld en geactualiseerd. Production Information & Tender action: Ook wanneer men effectief overgaat naar de materialisatie en het bouwen, blijft de strikte koppeling met het eerder bepaalde budget aanwezig. Tot slot wordt er ook voor het onderhoud een kostenraming opgesteld.

OA (Orde van Architecten) Vlaamse Raad

OA raadt zijn leden aan om de betalingsschijven voor de bouwheer op volgende fasen te baseren. De nadruk ligt vooral op de taken van de architect in elke fase (http://www.architect.be/). Voorontwerp: De architect maakt eerst een studie van het bouwproject waarbij hij rekening houdt met de wensen en behoeften van de bouwheer, het budget, het bouwterrein en de stedenbouwkundige voorschriften. Het resultaat is het voorontwerp dat een duidelijk beeld geeft van het beoogde gebouw.

14 Definitief voorontwerp: De architect werkt, in samenspraak met de bouwheer, het goedgekeurde voorontwerp uit door onder andere een uitspraak te doen over de materialisatie. Tijdens deze fase wordt een eerste (of aangepaste) raming van de kosten gemaakt. Stedenbouwkundige vergunning: Op basis van het goedgekeurde definitief voorontwerp stelt de architect het dossier samen voor de stedenbouwkundige aanvraag. Dit dossier bundelt alle officiële formulieren voor de aanvraag: een situatieplan, een inplantingsplan, de grondplannen, doorsneden en geveltekeningen, de vereiste foto’s van het terrein of de bestaande toestand, de aansluiting op de nutsvoorzieningen en informatie over bouwmaterialen en -technieken. Uitvoeringsdossier: Wanneer de stedenbouwkundige vergunning is goedgekeurd, maakt de architect een uitvoeringsdossier op. Dit dossier omvat niet alleen de uitvoeringsplannen en de nodige detailtekeningen maar ook een bestek (of lastenboek) en eventueel een samenvattende of gedetailleerde meetstaat.

2.1.4

Conclusie

Uitgaande van voorgaande theoretische principe en de voorschriften van de OA Vlaamse Raad wordt in deze thesis het architecturaal ontwerp opgedeeld in vier fasen: ‘Schetsontwerpfase’, ‘Voorontwerpfase’, ‘Uitvoeringsontwerpfase’, en ‘Constructiefase’. Aangezien er geen eenduidig, alomvattend principe bestaat, is deze onderverdeling uitsluitend richtinggevend.

Schetsontwerpfase Gedurende deze fase zijn de tekeningen conceptueel en schematisch en kunnen ze nog op verschillende manieren worden ge¨ınterpreteerd. De ontwerper heeft hier als enige doel zijn ideeën voor te stellen, die aan de basis liggen van het ontwerp. Deze ideeën verbinden het gebouw met zijn functie en zijn een definitie van het algemene concept, zowel architecturaal als constructief. Om dit doel te bereiken gebruikt de ontwerper eenvoudige schetsen, vormelijke maquettes en eenvoudige technologische hulpmiddelen. De auteurs kiezen ervoor om het ontwerpproces te baseren op de procedure van Roozenburg en Eekels [65]. Zij beschrijven een trial-and-error procedure die bestaat uit een opeenvolging van empirische cycli waarin the knowledge of the problem as well as the so” lution increases in a spiral way” [65]. Zo is ook de schetsontwerpfase een trial-and-error procedure. Tijdens de schetsontwerpfase zal de ontwerper dan ook verschillende alternatieven, benaderingen en mogelijkheden genereren en evalueren. Het gebruik van de computer kan hier

2.1 Ontwerpfasen

15

helpen: door gebruik te maken van de rekencapaciteit om deze alternatieven te genereren, door de architect instaat te stellen 3D-modellen te tekenen en door hem snel toegang tot informatie te verschaffen. Het gebruik van programma’s en de soorten die gebruikt worden zijn echter afhankelijk van het type praktijken en de omvang van het project. Vandaag1 zien we een toenemend gebruik van CAD-programma’s voor 3D-modellering [7], in vergelijking met het onderzoek van Mirza & Nacey Research in 1999 [52].

Voorontwerpfase De tekeningen in deze fase worden vooral gebruikt om de ideeën van de ontwerper te bestuderen en te valideren. De schetsen bereiken hier een hoger niveau van detaillering, omdat ze moeten dienen als informatiedrager of als communicatiemiddel naar andere partners tijdens het bouwproces. Dit is dan ook de reden waarom in deze fase vooral gebruik wordt gemaakt van Computer-Aided Design (CAD) programma’s, in deze context mag onder CAD Computer-Aided Drafting worden begrepen. Het voordeel van het gebruik van deze CAD-programma’s is dat, in tegenstelling tot een schets op papier of zelfs een schaalmodel, het ontwerp kan worden gemodelleerd in een driedimensionale omgeving en dat hiermee een goede basis wordt gelegd voor de volgende ontwerpfasen.

Uitvoeringsontwerpfase De meeste CAD-tools zijn precies ontwikkeld om te kunnen omgaan met het hoge niveau van detaillering die vereist is in deze fase. De tekeningen moeten preciezer en meer gedetailleerd zijn op verschillende niveaus: dimensie, materialen, verbindingen. . . In deze fase gebeurt het tekenen en modelleren uitsluitend nog met CAD-programma’s. Het is pas op dit moment in het ontwerpproces dat de meeste ontwerpers voor de eerste maal zien wat voor impact de constructie, technieken e.a. hebben op het ontwerp zelf, juist omdat tijdens deze fase de constructie in het ontwerp wordt berekend en ge¨ımplementeerd. Er voor kiezen om de implementatie van de structuur en technieken uit te stellen tot een later moment in het ontwerpproces, kan belangrijke gevolgen hebben. Het is niet ondenkbaar dat een ontwerper zijn ontwerp moet aanpassen omdat dergelijke zaken niet kunnen worden ge¨ımplementeerd in het uiteindelijke ontwerp. Om tijdverlies en problemen door de implementatie achteraf te voorkomen, moet de ontwerper met deze zaken zo vroeg mogelijk in het ontwerpproces rekening houden. 1

In 2007 werkt het grootste deel, 63%, van de CAD gebruikers in 2D en 37% in 3D. In 2012 werken 53% van de gebruikers in 3D. [7]

16 Constructiefase In deze fase moet iedere component, elke dimensie, elk materiaal en elke verbinding nauwgezet en precies worden getekend. Deze tekeningen, meestal op een schaal van 1:10, worden gebruikt als communicatiemiddel tussen de verschillende actoren. Meer bepaald moeten het ontegensprekelijke documenten zijn die de ideeën van de ontwerper eenduidig overbrengen aan diegene die het project realiseren. De invloed die iedere fase op het finale ontwerp heeft is zeer uiteenlopend. Hoe later in het ontwerpproces, hoe minder invloed een beslissing heeft op het uiteindelijke resultaat. Dit valt te verklaren omdat een ontwerp voortbouwt op de beslissingen die genomen zijn in het begin van het ontwerp. De initiële beslissingen wegen veel zwaarder door dan deze op het einde van het ontwerpproces die gemakkelijker kunnen worden aangepast. Vandaar dat verkeerde beslissingen vroeg in het ontwerpproces een grote impact zullen hebben op de latere stadia en zelfs het eindresultaat (figuur 2.4).

Figuur 2.4: invloed en detail in functie van de tijd [58]

Gebaseerd op deze argumenten zal deze thesis zich verder concentreren op de schetsen de voorontwerpfase. De combinatie van deze twee belangrijke fasen in het ontwerp zal worden aangeduid als de schetsontwerpfase.

2.2

Ontwerptools

Er zijn er verschillende ontwerptools beschikbaar voor de verschillende fasen. Voor een ontwerper is het belangrijk om de juiste tools te kiezen voor het werk dat hij voor ogen heeft. In dit hoofdstuk wordt er dieper ingaan op de modelleer- of visualisatieprogramma’s voor ontwerp en simulatie.

2.2 Ontwerptools

2.2.1

17

Visualisatie

Een tool om het ontwerp te visualiseren is een rekensysteem dat de voorstelling van voorwerpen kan aanmaken, aanpassen en bewerken. Een voorwerp is een eindig volume dat wordt begrensd door een eindig aantal oppervlakken. Verschillende tools zijn ontwikkeld om de ontwerper hierin te ondersteunen. Er moet echter een onderscheid worden gemaakt tussen wireframe modellers, mesh modellers, surface modellers en solid modellers. Elk van deze heeft zijn specifieke eigenschappen en zijn toepassingsdomeinen [44].

Wireframe modellers Bij dit type van modelleren worden voorwerpen voorgesteld door lijnstukken. Bepaalde lijnstukken stellen de ribben van het voorwerp voor en daarmee de fysieke grenzen ervan. Andere lijnstukken zijn hulplijnen om grensvlakken vorm te geven. Het zijn de representaties van de grensvlakken die een indruk geven van de eigenlijke vorm van het voorwerp. Er worden echter geen vlakken opgevuld; de gebruiker krijgt enkel een indruk van het volume en het voorwerp. Met deze voorstellingswijze is het mogelijk om een zeer ambigu beeld te krijgen.

Figuur 2.5: Links is het dubbelzinnige wireframe, rechts is ondubbelzinnig [9]

Bij de figuur 2.5 is het duidelijk dat er twee kubussen zijn getekend. De ene kubus is volledig omschreven door de grotere kubus maar het is voor de toeschouwer onduidelijk waar eventuele openingen zich zouden moeten bevinden (figuur 2.5). De voorstelling ontbeert de grafische en visuele coherentie van een meer solide modelleertool.

Mesh modellers De modellen die uit een mesh modeller, zoals SketchUp (SU) (figuur 2.6, figuur 2.7), voortkomen bestaan enkel uit oppervlakken. Elk voorwerp dat driedimensionaal is opgebouwd bestaat uit verschillende vlakken wat maakt dat de ontwerper een beter 3D-beeld krijgt van het voorwerp in vergelijking met een wireframe modeller. In werkelijkheid echter

18 blijven deze voorstellingen opgebouwd uit lege vormen. Juist omdat de volumes ijl zijn kan deze modelleertool enkel worden toegepast voor het visualiseren van tekeningen en ontwerpen. Organische vormen kunnen ook worden gemodelleerd door deze te benaderen door vlakken, hoe kleiner deze vlakken, des te preciezer de benadering.

Figuur 2.6: Muur opgebouwd door één vlak, SU [48]

Figuur 2.7: Links: Muur opgebouwd door meerdere vlakken in SU, Rechts: Snede door de muur opgebouwd door meerdere vlakken in SU [48]

Surface modellers Deze manier van modelleren werd ontwikkeld voor de scheepsbouw [67]. Ontwerpers hadden een manier nodig om de vloeiende lijnen van een schip te tekenen. Dit deden ze door een smallen houten lat (spline) door een reeks controlepunten, in dit geval metalen gewichten, te laten buigen. Hoe groter de gewichten, des te groter de invloed was. Wan-

2.2 Ontwerptools

19

neer er overgeschakeld werd naar computermodellen moest de vorm wiskundig benaderd worden, wat resulteerde in de ontwikkeling van de Splines en de Bézier-spline (B-spline).

Figuur 2.8: Spline met controlepunten in Rhinoceros

Een Non-uniform rational B-spline (NURBS) zal ook door het gebruik van controlepunten een bepaalde vorm zo nauwkeurig mogelijk gaan benaderen. De grenzen van een oppervlak en het oppervlak zelf worden bepaald door controlepunten (figuur 2.8). De controlepunten tussen de grenzen vormen aantrekkingspolen die het oppervlak naar zich toe trekken (het oppervlak loopt niet door deze punten). Zo zal de verplaatsing van één controlepunt ook als een imaginair gewicht inwerken op nabijgelegen controlepunten. Een van de wiskundige modellen die nog steeds wordt gebruikt is de B-spline. Deze manier van modelleren wordt voornamelijk gebruikt in de scheeps-, auto- en vliegtuigindustrie, maar vindt meer en meer zijn ingang bij de architectuur, zoals bijvoorbeeld bij het Guggenhiem Museum in Bilbao van Frank Gehry (http://www.foga.com/).

Solid modellers Dit type van modelleertool onderscheidt zich van de vorige omdat het wel volledig wiskundig, fysisch betrouwbaar en universeel is. Er zijn twee types Solid modellers, namelijk de Constructive Solid Geometry (CSG) en de Boundary Representation (B-rep). CSG maakt gebruik van primitieven om volumes voor te stellen. Primitieven zijn vlakke of kwadratische geometrische figuren zoals sferen, kubussen, cilinders, kegels, torus, etc. Een volume kan door de modelleertool worden voorgesteld als een primitieve of door een samenstelling van primitieven. De samenstelling wordt bekomen door één of meerdere modelleeroperaties uit te voeren, zoals lineaire transformatie of een Booleaanse transformatie (subtract, intersect en union) (figuur 2.9). Verder is het ook mogelijk om op volumes, eerder bekomen door een transformatie van twee primitieven, een transformatie uit te voeren. Deze manier van werken gaat het uiteindelijke bekomen volume impliciet beschrijven en opslaan in zogenaamde CSG boomstructuur (figuur 2.10). Deze CSG boomstructuur bevat dan zowel de primitieve volumes als de transformaties waaruit het volume is opgebouwd.

20

Figuur 2.9: Booleaanse transformatie: subtract, intersect en union

Figuur 2.10: CSG tree

2.2 Ontwerptools

21

Figuur 2.11: Structuur van een B-rep model

Figuur 2.12: Links snede door volle muur in ArchiCAD, Rechts: snede door muur opgebouwd door aparte elementen, ArchiCAD [48]

Een B-rep model wordt gedefinieerd door het oppervlak of grens waardoor het omsloten is. Dit type model verschilt van de Surface modellers omdat ook de informatie van de aansluitingen van verschillende vlakken (de topologie) van het model wordt opgeslagen

22 (figuur 2.11). Dit zorgt ervoor dat een B-rep model steeds een ’vol’ volume beschrijft en geen ’hol’ zoals een Surface-model (figuur 2.12). Omdat elk volume steeds wiskundig gedefinieerd is, is het mogelijk fysische eigenschappen, zoals volume, massa, traagheidsmoment, etc. aan de volumes te koppelen. Dit maakt dat dit type van modelleren geschikt is om later structuuranalyses te berekenen en dus bruikbaar is in BIM-applicaties zoals ArchiCAD (http://www.graphisoft.com/).

2.2.2

Simulatie

De meeste programma’s die worden ontwikkeld om een ontwerp te modelleren, worden aangeboden met de nodige analyseprogramma’s. Toch zijn er nog een aantal ontwikkelaars die onafhankelijke tools op de markt brengen. Deze tools kunnen verschillende driedimensionale modellen analyseren. Om de ontwikkeling van nieuwe producten te ondersteunen worden de hedendaagse tools uitgebreid bestudeerd. Sinds de introductie van CAD en CAM echter, wordt de meeste vooruitgang gemaakt op basis van productkwaliteit en de efficiëntie van het ontwerpproces. De meeste van deze programma’s slagen er in een verbeterde ondersteuning aan te bieden door uitgebreide functionaliteit onder de vorm van voorgeprogrammeerde functies en objecten. Zoals generische constructieelementen die aangepast kunnen worden voor verschillende doeleinden door het specificeren van een lijst met parameters. Door de geometrische precisie en het hoge aantal van gedetailleerde keuzes die dergelijke programma’s vergen lijken ze niet aangepast aan de noden van de ontwerper tijdens de eerste fasen van de uitwerking van een idee. Indeed, the required level-of-detail, although necessary for ” the operation of these programs, is often largely irrelevant and tends to distract from the design activity itself.” (Aliakseyeu, 2006) [16]. Gevorderde tools worden pas gebruikt in een latere fase van het ontwerpproces omdat de meeste cruciale beslissingen dan al zijn genomen en de focus zich meer richt op de gedetailleerde specificaties van het ontwerp. Om de tijdsbesteding te verbeteren in de overgang van de vroege naar de late fasen in het proces gebruiken steeds meer ontwerpers en architecten software zoals ArchiCAD of AutoCAD tijdens het volledige proces. Het nadeel van deze keuze is echter dat de creativiteit hiermee wordt ingeperkt in de vroegste fasen van het ontwerp door de gevraagde precisie bij het gebruik van deze tools [50]. Het hoofdstuk 3 programma’s structuuranalyse gaat verder in op de structuuranalyseprogramma’s.

STRUCTUURANALYSE PROGRAMMA’S

23

Hoofdstuk 3 Structuuranalyse programma’s Dit hoofdstuk behandelt de evaluatie van beschikbare structuuranalyse-programma’s zoals opgenomen in de databank ‘Structural Engineering Software’. Deze databank bevat een breed scala aan architecturale en bouwkundige programma’s, en is met 462 programma’s één van de meest volledige in zijn soort. Om onderzoek te doen naar structuuranalyseprogramma’s in het architecturaal ontwerp, wordt hier deze databank onderverdelen in drie types: Type onderdeel: Analyse - Ontwerp - Ge¨ıntegreerd (analyse en ontwerp) - Project management - Visualisatie, Type project: Gebouwen - Bruggen - Dammen - Tunnels, Type programma: Plugin - Alleenstaand.

De types Analyse en Ontwerp hebben nog enkele subtypes; Analyse: Eindige-elementenmethode, Eurocodes (EC), Detaillering, Optimalisatie, Beton - Baksteen - Hout - Staal, Funderingen - Geotechnisch - Keermuren, Aardbevingen, Energie, Brandbeveiliging, 2D - 3D - BIM en Ontwerp: 2D - 3D - BIM, detaillering. Zo resulteert AutoCAD onder: Ontwerp, Gebouwen, Alleenstaand en Karamba onder: Analyse, Gebouwen, Plugin. Op basis van deze rangschikking wordt in dit hoofdstuk de vergelijking gemaakt tussen structuuranalyse-programma’s van een standaardgebouw, dit is van de types Analyse, Gebouwen en alle subklassen. De vergelijking licht enkele geselecteerde programma’s toe aan de hand van een eenvoudige gevalstudie. Aangezien niet alle programma’s dezelfde analysemogelijkheden bieden, is er gekozen om de analyse van een eenvoudig opgelegde, uniform belaste balk te vergelijken.

24

3.1

Finnwood - FinnForest EC

Hout

3D

Details

Optimalisatie

Alleenstaand

Analysetijd: snel

Expertniveau: laag

Aanleertijd: snel

Handelingen: matig

Componenten: veel

Interoperabiliteit: geen

Tabel 3.1: Evaluatie Finnwood

3.1.1

Algemeen

Finnforest, leverancier van hout voor constructieve en esthestische toepassingen, is de ontwikkelaar van Finnwood. Het programma stelt de klanten van Finnforest in staat om de structuur, opgebouwd uit rechte houten balken van het type Finnjoist, Kerto, KertoRipa, gezaagd hout en Leno te analyseren en te optimaliseren. Het is een alleenstaand softwarepakket; de invoer van de geometrie en extra gegevens, de analyse, de optimalisatie en de uitvoer gebeuren in Finnwood.

3.1.2

Graphical User Interface (GUI)

Figuur 3.1: GUI van Finnwood

De GUI is opgebouwd volgens de standaard conventies [54], met een titelbalk, menubalk, taakbalk en visualisatievenster. De taakbalk bevat enkele knoppen en tabbladen (figuur 3.1). De invoer van gegevens gebeurt over de verschillende tabbladen.

3.1 Finnwood - FinnForest

25

Elk project start met de keuze van het type van structuur. Door op de gewenste icoon (linksboven in het venster) te klikken, kan een keuze gemaakt worden tussen vloer (horizontaal), dak (diagonaal), muur (verticaal) of een combinatie van deze. Verder zijn er zeven tabbladen: geometrie, sparingen / uitsnijdingen, belastingen, berekeningen, resultaten, balkschoenen, afdrukken. De gebruiker wordt verwacht om deze stelselmatig te doorlopen. Deze techniek van stelselmatig invoeren zorgt ervoor dat de gebruiker geen gegevens vergeet in te geven, dit voorkomt fouten in het model.

3.1.3

Invoer

Finnwood is geen grafische modelleeromgeving waar de gebruiker in kan tekenen. De structuur wordt bepaald door zijn dimensies, vorm, aantal steunpunten en overkragingen, die worden ingevuld op het desbetreffende tabblad (figuur 3.2). Naast deze basisgegevens kan de gebruiker enkele bijkomende parameters invoeren, zoals de hart-op-hart-afstand, balkhoogte, profielvorm en versterkingen (figuur 3.2). Deze parameters zijn al ingevuld met standaardwaarden, waardoor het niet noodzakelijk is ze in te vullen of aan te passen. Dat deze extra parameters standaardwaarden hebben, maakt dat de gebruiker snel een eerste berekening kan maken. Verder versnellen de databanken voor hout en de balkschoenen het initialisatieproces.

Figuur 3.2: Gegevens geometrie van Finnwood

Onder het tabblad ’Sparingen / uitsnijdingen’ kan de structuur eventueel van uitsnijdingen worden voorzien. Hier moet de gebruiker het type en de plaats opgeven. Sparingen

26 en uitsnijding worden gecontroleerd op hun afmetingen en de invloed op de sterkte en stijfheid. Vervolgens moeten de types van belasting (puntbelastingen, momenten, lijnverdeelde belastingen of vlakverdeelde belastingen) en de belastingscombinaties (permanente belasting, scheidingswanden, gebruiksbelasting, geconcentreerde belasting of trilling) worden gekozen. Hoe groot de verschillende belastingen zijn, hangt af van het type gebouw of gebruik. Er wordt onderscheid gemaakt tussen: woning, kantoor, school, winkel, opslagruimte en wegverkeer. Deze types zijn terug te vinden onder het venster ’Bepalen standaard belastingen’ (figuur 3.3). Het venster ’Belastingscombinaties en overzicht belastingsgevallen’ geeft een overzicht van alle mogelijke belastingscombinaties en belastingen die op de constructie kunnen aangrijpen. Alvorens het programma kan beginnen met de analyse, moet er in het respectievelijke tabblad ’Berekeningen’ een keuze worden gemaakt tussen profieltypes, het materiaal dat de voorkeur geniet, een klimaatklasse en het profiel zelf. Na de selectie van eisen (controle van de bezwijksterkte, knikcontrole, uitkipcontrole, controle doorbuiging, controle trilling) kunnen de belastingen op het element worden berekend.

Figuur 3.3: Standaardbelastingen in Finnwood

Onder het tabblad ’balkschoen’ kan de gebruiker de producent van de balkschoen en het type selecteren. Deze selectie is een bijkomende parameter die reeds is ingevuld met een standaardwaarde, het is dus niet noodzakelijk om deze aan te passen.

3.1 Finnwood - FinnForest

3.1.4

27

Analyse

Figuur 3.4: Analyse in Finnwood

Indien het gekozen element niet voldoet aan de eisen, die geselecteerd zijn en door de EC worden opgelegd, zullen er duidelijke rode waarschuwingssignalen verschijnen bij de belastingsgevallen die niet voldoen (figuur 3.4). Door op de toets ’zoek de volgende’ te klikken, zal het programma de lijst met afmetingen van dat type materiaal doorlopen (exhaustive search) en de eerstvolgende optie die wel voldoet, weergeven.

Figuur 3.5: Resultaat analyse van Finnwood

Wanneer er na het doorlopen nog steeds rode waarschuwingssignalen verschijnen, wordt de gebruiker aangespoord om een nieuw type materiaal te selecteren en de procedure te herhalen tot alle signalen groen zijn (figuur 3.4).

28

3.1.5

Output

Het programma is zo opgebouwd dat de gebruiker, indien gewenst, altijd een afdruk kan maken van de berekeningen. Hij kan ze weergegeven in een tabel die alle waarden oplijst of in grafieken die de momenten, dwarskrachten, doorbuiging en oplegreacties tonen (figuur 3.5). De selectie van de af te drukken resultaten, de opties voor het afdrukken, het afdrukvoorbeeld en het uiteindelijke afdrukken zijn terug te vinden onder het tabblad ’afdrukken’.

3.1.6

Interoperabiliteit

Finnwood kan geen data importeren of exporteren.

3.1.7

Evaluatie

Het programma is door de eenvoudige opbouw met tabbladen intu¨ıtief en snel aan te leren. Verder beperkt het gebruik van de chronologische tabbladen de kans op fouten. Door de lage graad van detaillering, de mogelijkheid tot optimalisatie en de snelle output lijkt het er op dat het programma geschikt is om ingezet te worden tijdens de schetsontwerpfase. Omdat er geen import- noch exportmogelijkheden zijn, wordt de gebruiker verplicht het ontwerp te hertekenen en te analyseren in Finnwood om vervolgens de structuur opnieuw in een modeleeromgeving te hertekenen. Het gebrek aan interoperabiliteit zorgt ervoor dat Finnwood minder geschikt is om ingezet te worden tijdens de schetsontwerpfase.

3.2

Karamba - Grasshopper FEM

Staal

3D

Parametrisch

Plug-in

Analysetijd: snel

Expertniveau: hoog

Aanleertijd: matig

Handelingen: matig

Componenten: matig

Interoperabiliteit: Rhinoceros

Schetsontwerp

Tabel 3.2: Evaluatie Karamba

3.2.1

Algemeen

Karamba is een structuuranalyse-programma dat wordt ontwikkeld door Clemens Preisinger in samenwerking met het ‘Structural Design Institute’ van de ‘University of Applied Arts’ in Wenen en Bollinger-Grohmann-Schneider ZTGmbH in Wenen. Het is een plug-in voor Grasshopper (http://www.grasshopper3d.com/) die de kloof tussen het parametrisch

3.2 Karamba - Grasshopper

29

ontwerpen en de structuuranalyse overbrugt. Parametrisch ontwerpen wordt hier verstaan volgens de definitie van Woodbury: Parametric approaches aim at representing change. ” Rather than the designer creating the design solution (by direct manipulation) as in conventional design tool, the idea is that the designer first establishes the relationships by which parts connect, builds up a design using these relationships and modifies the relationships by observing and selecting from the results produced. The system takes care of the job of keeping the design consistent with the relationships and thus increases designer ability to explore ideas by reducing the tedium of rework.”[79].

3.2.2

GUI

Figuur 3.6: GUI van Grasshopper

De plug-in bestaat uit grasshopper-componenten. Elk van deze componenten is een script dat een specifiek element of functie, zoals punt of rotatie, beschrijft. Aan de hand van deze componenten kan een gebruiker de geometrie, gemodelleerd in Grasshopper, verrijken met de gegevens die nodig zijn om een analyse uit te voeren. Grashopper zelf is conventioneel opgebouwd, met een titelbalk, menubalk, taakbalk en modelleervenster. De taakbalk bevat enkele knoppen en tabbladen (figuur 3.6). Onder de verschillende tabbladen staan de componenten. Zo heeft ook Karamba een tabblad met zijn specifieke componenten. Deze componenten bepalen, in de plaats van geometrie, de analyse.

30

3.2.3

Invoer

Figuur 3.7: Invoer in Grasshopper

Grasshopper is een parametrische modelleeromgeving. In Grasshopper wordt er door het schakelen van de zogenaamde ’Componenten’ geometrie gedefinieerd. Om de as van de staaf of balk te bepalen moeten de punten van de geometrie, ontworpen in Grasshopper, met een ’lijncomponent’ van Karamba worden verbonden (figuur 3.7). Dit kan omdat er rechtstreeks met de ontworpen geometrie kan worden gewerkt. Deze as moet vervolgens met de Line-invoer van de Karamba LineToBeam-component worden verbonden, die zoals de naam aangeeft, van de lijnen balken maakt (figuur 3.7). Nadat de balken zijn gevormd, kan de gebruiker de steunpunten bepalen (figuur 3.7). Deze worden gedefinieerd door hun positie (de punten die in de vorige stap als invoer voor de balken werden gebruikt), door het vlak waar ze op staan en door de voorwaarden die de translatie en rotatie fixeren. Zoals figuur 3.7 aangeeft, is het gemakkelijk om snel een aantal mogelijke vlakken te testen, door een variabel getal onder de vorm van een Slider (dit maakt het mogelijk verschillende getallen te doorlopen) te gebruiken in plaats van een vast getal.

3.2 Karamba - Grasshopper

31

De laatste component die nodig is om de analyse uit te voeren, is de belasting (figuur 3.7). Het is mogelijk verschillende componenten te kiezen, zoals zwaartekracht, lijnlast, puntlast, uniforme last en voorspanning. In dit voorbeeld wordt er gewerkt met de lijnlast, die als noodzakelijke invoer een vector nodig heeft, die de richting en grootte van de kracht definieert. Verder moet de oriëntatie gekozen worden respectievelijk, lokaal, globaal of volgens het project (figuur 3.7). Met de extra parameters Beam Id en LCase kan de gebruiker specifieke belastingstoestanden introduceren, zoals bijvoorbeeld een uniforme belasting op de eerste helft van de balk.

3.2.4

Analyse

Na het bepalen van de belastingen worden alle componenten met de Assemble-component verbonden. Dit geeft een model waarop de analyse, door de Analyze-component, kan worden uitgevoerd (figuur 3.8).

Figuur 3.8: Analyse in Grasshopper

3.2.5

Output

Figuur 3.9: Doorbuiging in Grasshopper

De laatste stap is de visualisatie. Dit wordt verkregen door de component ModelView na de Analyze-component te plaatsen (figuur 3.10). Afhankelijk van welke informatie de gebruiker wenst te zien, kunnen de verschillende parameters in de ModelView -component

32 worden aan- of uitgezet (voor de definities van de verschillende parameters van deze component wordt er verwezen naar de Karamaba ‘User Manual for Version 0.9.083’ [59]). Aangezien Karamba volgens de eindige-elementenmethode analyseert, wordt naast de traditionele doorbuiging (figuur 3.9) ook de belasting in het element zelf gevisualiseerd (figuur 3.11).

Figuur 3.10: Output van Grasshopper

Figuur 3.11: Doorbuiging, eindige-elementenmethode in Grasshopper

Via de uitgang ’Legende’ van de component ModelView kan de gebruiker een legende voorzien en een eigen kleurgradiënt opstellen. Het is vervolgens aan de gebruiker om te oordelen of de spanningen en doorbuigingen voldoen aan de normen.

3.3 OpenStaad - GC

3.2.6

33

Interoperabiliteit

Grasshopper biedt geen mogelijkheid om scripts te exporteren of importeren. Wanneer het ontwerp voltooid is, is het mogelijk de geometrie te Baken (te fixeren) in Rhinoceros. Rhinoceros biedt voldoende import- en exportmogelijkheden naar de meest gangbare standaarden (zoals naar Autodesk, SketchUp, 3dstudio max, IGES...). Verder is het mogelijk door een functie in Generative Components (GC) om het parametrisch Grasshopperscript te linken aan GC. Elke aanpassing in Grasshopper wordt, na het opslaan van het bestand, rechtstreeks in GC doorgevoerd.

3.2.7

Evaluatie

De gebruiker wordt niet gestuurd in het selecteren van de juiste componenten, maar dit blijkt geen probleem te zijn omdat het aantal Karamba-componenten beperkt is. Als plug-in voor Grasshopper/Rhinoceros, vermijdt Karamba exportproblemen en dus tijdverlies. Componenten van Karamba en Grasshopper kunnen aan elkaar geschakeld worden. Hierdoor kan er direct met de bekomen resultaten worden ontworpen in Grasshopper en Rhinoceros. Dit maakt dat deze plug-in geschikt is om in te zetten tijdens de schetsontwerpfase. Tot slot is de handleiding duidelijk, gebruiksvriendelijk en begeleidt deze de gebruiker in het aanleerproces.

3.3

OpenStaad - GC EC

Staal

BIM

Parametrisch

Plug-in

Analysetijd: matig

Expertniveau: hoog

Aanleertijd: matig

Handelingen: weinig

Componenten: weinig

Interoperabiliteit: GC

Tabel 3.3: Evaluatie OpenStaad

3.3.1

Algemeen

De StructuralAnalysisEngine-component, gebaseerd op het programma OpenStaad, is ge¨ımplementeerd in GC (http://www.bentley.com). De component biedt de mogelijkheid om in een vroeg stadium in het ontwerpproces het effect te analyseren en te visualiseren dat de vorm en de structuur op de verdeling van de krachten en op de vervormingen hebben. Het doel van de component is slechts een indicatie te geven in plaats van gedetailleerde en nauwkeurige resultaten. De rechtstreekse koppeling met Staad

34 (http://www.bentley.com/en-US/Products/Structural+Analysis+and+Design/) in een latere fase van het ontwerp is steeds mogelijk.

3.3.2

GUI

Figuur 3.12: GUI van GC

De GUI van GC is conventioneel opgebouwd, met een titelbalk, menubalk, taakbalk en venster waarin de geometrie wordt gevisualiseerd. Verder is er nog een venster Task en New Nodes, het zijn deze vensters die van belang zijn bij het modelleren (figuur 3.12). Aangezien OpenStaad als plug-in in GC (een parametrisch programma) is ge¨ıntegreerd is het proces gelijklopend met dat van Karamba. Maar in tegenstelling tot Karamba is de structuuranalyse-component in GC tussen de vele componenten opgenomen. Dit maakt dat het geheel minder overzichtelijk en moeilijker wordt voor onervaren GC-gebruikers.

3.3.3

Invoer

GC is een parametrische modelleeromgeving. GenerativeComponentsV8i werkt met Componenten die met elkaar kunnen worden verbonden. Door de Componenten te verbinden wordt er een script bekomen dat een bepaalde geometrie genereert. In GC moeten de punten die de geometrie definiëren naar GNodes worden omgezet. GNodes zijn componenten die fysische eigenschappen kunnen dragen. De GNodes worden gebruikt om GMembers op te bouwen (figuur 3.13), die naast de GNodes ook nog een materiaal meekrijgen als invoer.

3.3 OpenStaad - GC

35

Om over te gaan tot de structuuranalyse, moet er enkel nog bepaald worden welke het type van project is. De belasting hangt af van het type van gebouw of van wat het programma is; in GC wordt dit bepaald door de Project-component (figuur 3.13).

Figuur 3.13: GNodes en GMembers in GC

3.3.4

Analyse

Voor de analyse worden zowel de GNodes als de GMember en de Project-component aan de StructuralAnalysisEngine-component gekoppeld (Figuur 3.14). Deze analyse wordt uitgevoerd volgens de normeringen van de EC.

Figuur 3.14: StructuralAnalysisEngine-component van GC

Door een extra functionaliteit die GC biedt, krijgt de gebruiker de keuze om de analyse lokaal, op de eigen pc, of Cloud, op een netwerk beschikbaar gesteld door GC, te laten

36 berekenen. Cloud biedt het voordeel dat de gebruiker ongehinderd de computer en GC kan gebruiken terwijl de analyse wordt uitgevoerd. Eenmaal gekozen om lokaal of Cloud te gebruiken, kan de analyse starten.

3.3.5

Output

Er zijn een reeks bewerkingen nodig om het resultaat van de analyse om te zetten in een visueel resultaat (figuur 3.15). Door middel van een kleurgradiënt is het mogelijk om de analyse op het model zelf te projecteren (figuur 3.16). Dit zorgt ervoor dat de gebruiker de analyse van het geheel in één keer kan overzien. Maar omdat de gebruiker zelf een gradiënt moet bepalen en er geen legende mee opgenomen wordt, is het moeilijk de analyse te evalueren.

Figuur 3.15: Visualiseren resultaat in GC

Figuur 3.16: resultaat van GC

3.3.6

Interoperabiliteit

GC biedt voldoende import- en exportmogelijkheden naar de meest gangbare standaarden (zoals naar Autodesk, SketchUp, IGES...).

3.4 PowerFrame - BuildSoft

37

Verder voorziet GC de mogelijkheid een Realtime koppeling te leggen met parametrische Grasshopper-modellen, om deze in GC verder uit te werken.

3.3.7

Evaluatie

Exportproblemen en tijdverlies worden vermeden omdat Openstaad de functionaliteit van een plug-in krijgt door middel van de StructuralAnalysisEngine-component. Door deze component kan er rechtstreeks met de bekomen resultaten verder gewerkt worden. Dit maakt dat deze plug-in geschikt is om in te zetten tijdens de schetsontwerpfase. Toch zorgt de GUI van GC ervoor dat het moeilijk is om GC in te zetten tijdens de schetsontwerpfase, als onervaren GC-gebruiker. Maar door de koppeling met Grasshopper wordt het wel interessant om GC te gebruiken voor de verdere uitwerking van het ontwerp.

3.4

PowerFrame - BuildSoft EC

Staal

Beton

Hout

3D

Alleenstaand

Analysetijd: snel

Expertniveau: matig

Aanleertijd: snel

Handelingen: matig

Componenten: veel

Interoperabiliteit: .dxf

Tabel 3.4: Evaluatie PowerFrame

3.4.1

Algemeen

BuildSoft is een bedrijf dat rekensoftware voor stabiliteits- en sterkteberekeningen ontwikkelt. Met PowerFrame biedt BuildSoft een programma aan dat staaf- en balkconstructies analyseert in staal, beton of hout die onderworpen zijn aan zowel seismische, dynamische als brandbelasting.

3.4.2

GUI

De GUI is conventioneel opgebouwd, met een titelbalk, menubalk, taakbalk en modelleervenster (figuur 3.17). Ondanks er met duidelijke iconen wordt gewerkt, is het onduidelijk welke van die iconen strikt noodzakelijk zijn voor de structuuranalyse, ook al omdat ze niet in chronologische volgorde staan (figuur 3.17). Deze benadering vraagt van de gebruiker een extra inspanning om alle stappen te doorlopen.

38

Figuur 3.17: GUI van BuildSoft

3.4.3

Invoer

PowerFrame is een modelleeromgeving waar in wordt getekend met lijnen. Aan deze lijnen worden vervolgens eigenschappen gekoppeld, zoals het type steunpunten, het materiaal en de vorm. Het eerste wat in PowerFrame getekend wordt, is dus een lijn die de desbetreffende balk voorstelt. Vervolgens worden de steunpunten toegekend (figuur 3.18). Er kan gekozen worden om zelf een steunpunt te definiëren of om één van de standaard voorgedefinieerde te gebruiken. Om een correcte keuze van het type steunpunt te maken, heeft de gebruiker voorkennis nodig over de reactie van het gebouw. Dit maakt dat het kiezen van de juiste voorwaarden moeilijker wordt. Verder moet er een materiaal worden gekozen. Standaard is echter enkel staal geladen. Om in dit geval met hout te werken, moet eerst de profielbibliotheek van hout worden ge¨ımporteerd. Het is ook mogelijk als gebruiker zelf een materiaal te omschrijven aan de hand van de elasticiteitsmodulus, de coëfficiënt van Poisson, het eigengewicht en de thermische uitzettingscoëfficiënt. Tot slot kan het gewenste profiel geselecteerd worden (figuur 3.19). Opmerkelijk is dat deze lijst veel uitgebreider is dan de gebruikelijke standaarddimensies (bijlage B: Hout soorten). De houtsoorten moeten in dit venster geselecteerd worden.


39

Figuur 3.18: Invoeren steunpunten in BuildSoft

Figuur 3.19: Selecteren profiel in BuildSoft

De types belastingen worden in het volgende venster bepaald (figuur 3.20), door aan te vinken welke belastingen in de analyse moeten worden beschouwd. De coëfficiënten en combinatiefactoren worden automatisch ingevuld naargelang de norm die geselecteerd wordt. Verder kan ook een seismische belasting aangeduid worden.

40

Figuur 3.20: Coëfficiënten en combinatiefactoren in BuildSoft

3.4.4

Analyse

Nu alle parameters zijn bepaald kan de gebruiker aanduiden hoe de kniklengtes moeten worden berekend en welk type analyse moet worden uitgevoerd (figuur 3.21). Hier heeft de gebruiker twee keuzes:

een eerst-orde analyse (eerste-orde effecten zijn de verwachte effecten onder normale belastingen en de hierdoor optredende vervormingen-doorbuigingen en diverse spanningen).

een tweede-orde analyse (typische voorbeelden hiervan zijn het uitknikken van een kolom of het kippen van een ligger. Deze analyses houden rekingen met het optreden van vervormingen in de structuur om deze effecten te begroten).

Bij de structuuranalyse worden de EC en de betreffende nationale normen toegepast. Lastencombinaties worden automatisch gegenereerd conform EC1 en nationale bijlagen.


41

Figuur 3.21: Analyse in BuildSoft

3.4.5

Output

De resultaten worden in tabellen of via een gekleurde grafiek weergegeven (figuur 3.22). Het programma doet zelf geen uitspraak over al dan niet voldoen van de structuur.

Figuur 3.22: Resultaat van BuildSoft

3.4.6

Interoperabiliteit

Powerframe biedt import- en exportmogelijkheden naar de Autodesk programma’s.

3.4.7

Evaluatie

Hoe complexer de geometrie, hoe meer tijd het vergt om deze te hertekenen of aan te passen in PowerFrame. Het automatisch genereren van de data die aan de EC en de

42 nationale normen is gekoppeld, bespaart tijd en zorgt ervoor dat de gebruiker zelf geen specialist ter zake moet zijn. Anderszijds moeten er veel parameters worden ingevuld alvorens een analyse mogelijk is en wordt de gebruiker hierin niet gestuurd. Omdat de import- en exportmogelijkheden beperkt zijn, wordt de hele procedure omslachtig. De gebruiker wordt verplicht het ontwerp te tekenen en te analyseren in PowerFrame om vervolgens de structuur te hertekenen in de modelleeromgeving. Men kan concluderen dat PowerFrame minder geschikt is om in te zetten tijdens de schetsontwerpfase.

3.5

Risa 3D - Risa Technologies

FEM

Staal

Beton

Hout

Baksteen

BIM

Details

Optimalisatie

Alleenstaand

Analysetijd: snel

Expertniveau: zeer hoog

Aanleertijd: zeer lang

Handelingen: zeer veel

Componenten: zeer veel

Interoperabiliteit: Revit

Tabel 3.5: Evaluatie Risa 3D

Figuur 3.23: GUI van Risa Technologies

3.5 Risa 3D - Risa Technologies

3.5.1

43

Algemeen

RISA Technologies ontwikkelt al meer dan twintig jaar geavanceerde ontwerpen optimalisatiesoftware voor de structuuranalyse van gebouwen. Binnen het brede aanbod van RISA Technologies is RISA-3D een algemeen 3D-analyse- en ontwerpprogramma. Het programma geeft de mogelijkheid om hybride constructies, meerdere materialen in één ontwerp gelijktijdig te analyseren. Verder is het mogelijk om een koppeling te maken met andere RISA programma’s, zoals RISA-Floor en RISA-Foundation.

3.5.2

GUI

De GUI van RISA 3D is conventioneel opgebouwd [54], met een titelbalk, menubalk, taakbalk en modelleervenster. De taakbalk bevat enkele knoppen en tabbladen (figuur 3.23). Er verschijnen opeenvolgende vensters waar de gebruiker de nodige parameters kan invoeren, hierdoor wordt de gebruiker in het initialisatieproces goed begeleid.

3.5.3

Invoer

Figuur 3.24: Steunpunten in Risa Technologies

Risa 3D is een grafische modelleeromgeving waar de geometrie eerst in wordt getekend alvorens deze wordt geanalyseerd. In het opstartvenster kan de gebruiker kiezen om staven/balken of muurpanelen te tekenen, een standaardmodel te genereren of om een bestand te openen. Hierna verschijnt een

44 venster met algemene documentgegevens en parameters die de gebruiker voor de archivering kan invullen. Het volgende venster is Draw Member ; in dit venster worden naast de gegevens van de balk ook de tekenwijze en naamgeving gevraagd. In het vak Member Material Type and Shape moet het materiaaltype (staal, hout, beton, aluminium of algemeen) worden geselecteerd om vervolgens, in dit geval, de houtsoort, vorm en type te kiezen. Deze selectie moet later nogmaals herhaald worden. Het venster Continuous Beam Generator definieert de balk door het aantal steunpunten, het type en de belastingen (figuur 3.24). In het volgende venster moet de gebruiker nogmaals het type materiaal en de eigenschappen selecteren. Verder moet hij ook de dimensies van de balken definiëren. Ook voor de steunpunten volgt een extra bevestiging en kan de gebruiker elk steunpunt selecteren uit een lijst met standaardtypes en aanpassen indien nodig. Na het definiëren van de steunpunten volgt de bepaling van de belasting. De belasting is afhankelijk van het type gebouw of gebruik. De gebruiker kan de starten eindbelasting laten variëren in grootte en bepalen waar de belasting moet beginnen en eindigen. Het venster Load Combination Generator definieert de verschillende belastingscombinaties. Dit venster is als onervaren gebruiker moeilijk in te vullen en te begrijpen. Eenmaal aan het venster Load Combinations gekomen, wordt de gebruiker geconfronteerd met een lijst van verschillende belastingscombinaties (figuur 3.25). Omdat deze lijst zo uitgebreid is, is een zekere specialisatie nodig om de juiste selectie te maken. Verder zijn parameters als ‘ASCE 5 (a)’ (ASCE = American Society of Civil Engineers) weinig relevant voor Europanen. De gebruiker kan, door de bijhorende parameters te interpreteren, uitzoeken wat dergelijke termen betekenen maar dit maakt het proces alleen maar trager.

Figuur 3.25: Belastingcombinaties in Risa Technologies

3.5 Risa 3D - Risa Technologies

45

In het volgend venster wordt het mogelijk om de Single Combination te kiezen, wat het geheel eenvoudiger maakt.

3.5.4

Analyse

Eenmaal de gebruiker op solve klikt, start de analyse. In dit geval blijkt er een fout te zijn want het foutvenster met de melding ‘Ontoereikende randvoorwaarden, het model is onstabiel, error code=2002 ’ verschijnt. Nochtans zijn dezelfde parameterwaarden gebruikt als bij de vorige evaluaties. Een volgende venster verschijnt met de melding dat het programma de problemen zelf kan oplossen met de vraag of de gebruiker deze oplossing wil bekijken. Na bevestiging verschijnt het eerste foutvenster opnieuw. Binnen de tijdspanne van het onderzoek kon geen oplossing worden gevonden voor deze foutmelding. Hierdoor ontbreekt een uitspraak over de kwaliteit van het programma.

3.5.5

Output

Dezelfde foutmelding blijft steeds terugkomen. Aangezien we zelf geen resultaat hebben bekomen, is voor de volledigheid toch een afbeelding van een mogelijk resultaat opgenomen in figuur 3.26. Dit geeft een impressie van welke resultaten de gebruiker zou kunnen krijgen. Aan de hand van de verkregen grafieken moet de gebruiker oordelen of de structuur al dan niet voldoet aan de normering.

Figuur 3.26: tutorial van Risa Technologies

46

3.5.6

Interoperabiliteit

De interoperabiliteit tussen RISA 3D en Revit Structure wordt door RISA Technologies verzekerd omdat zij een door Autodesk gemachtigd softwareontwikkelaar is. Men stlet wel in de masterproef ‘Ontwerpmethodologie voor lage energiewoningen aan de hand van software tools’ [36]: Hoewel de bidirectionele link tussen Revit Structure en RISA veelvuldig ” aangehaald wordt om de BIM-oriëntatie van RISA te duiden, vertoont het model na importeren in RISA fouten. Kolommen, vloeren, funderingen, raamopeningen zijn verdwenen. Het model was evenwel in Revit Structure opgebouwd uit de voorradige componenten.”

3.5.7

Evaluatie

Ondanks de stelling dat de gebruiker goed begeleid wordt, hebben we zelf geen resultaten uit de analyse bekomen. Er zijn te veel parameters nodig om de analyse snel te kunnen uitvoeren waardoor het programma te complex en te uitgebreid is. Rekening houdende met deze bevindingen en de gebrekkige interoperabiliteit kunnen we voorlopig besluiten dat Risa 3D minder geschikt lijkt om in te zetten tijdens de schetsontwerpfase.

3.6

Robot - Revit FEM

Staal

Beton

Hout

BIM

Parametrisch

Details

Optimalisatie

Alleenstaand

Analysetijd: snel

Expertniveau: zeer hoog

Aanleertijd: zeer lang

Handelingen: veel

Componenten: veel

Interoperabiliteit: Autodesk

Tabel 3.6: Evaluatie Robot

3.6.1

Algemeen

Robot Structural Analysis is een programma ontwikkeld door Autodesk. Het is ge¨ıntroduceerd om de BIM-mogelijkheden van de Autodesk modelleerprogramma’s te verbeteren.

3.6.2

GUI

De GUI is conventioneel opgebouwd [54], met een titelbalk, menubalk, taakbalk en modelleervenster. De taakbalk bevat enkele knoppen en tabbladen (figuur 3.27).

3.6 Robot - Revit

47

Figuur 3.27: GUI van Robot

3.6.3

Invoer

Figuur 3.28: Balken plaatsen in Robot

Robot is geen grafische modelleeromgeving waar de gebruiker de geometrie in kan tekenen. De gebruiker definieert voor elke balk die moet worden geanalyseerd, het type, de sectie

48 en vervolgens de coördinaten (figuur 3.28). Als de balken getekend zijn, moeten de secties bepaald worden (figuur 3.29). Voor staal en hout zijn er verschillende standaardtypes gedefinieerd die vrij te kiezen zijn uit lijsten.

Figuur 3.29: Sectie bepalen in Robot

Figuur 3.30: Steunpunten in Robot

Vervolgens worden de steunpunten bepaald (figuur 3.30). Enkel de condities Fixed (geen rotatie mogelijk) en Pinned (rotatie mogelijk) zijn vooraf gedefinieerd. Elke andere situatie moet de gebruiker zelf omschrijven.

3.6 Robot - Revit

49

Na het invoeren van de steunpunten kan de gebruiker meerdere belastingsgevallen toevoegen: dead, live, snow, wind, temperature, accidental en seismic (figuur 3.31).

Figuur 3.31: Belastingen in Robot

3.6.4

Analyse

Nadat de belastingen gedefinieerd zijn kan de analyse volgens de eindige-elementenmethode beginnen (figuur 3.32).

Figuur 3.32: Analyse en resultaat van Robot

50

3.6.5

Output

Aangezien Robot volgens de eindige-elementenmethode werkt, kan de gebruiker duidelijk de krachten in de sectie van de balk visualiseren (figuur 3.32). De gebruiker moet echter zelf oordelen of de spanningen al dan niet voldoen aan de normen.

3.6.6

Interoperabiliteit

Er is een bidirectionale link met Revit Structure (http://usa.autodesk.com/revit/structuraldesign-software/).

3.6.7

Evaluatie

Modelleren in de software zelf is heel omslachtig omdat elk element apart, coördinaat per coördinaat, moet worden ingegeven. De bidirectionale koppeling met Revit Structure blijkt te werken voor eenvoudige constructies, maar eenmaal de constructie complexer wordt vertoont de koppeling gebreken. De gebruiker wordt matig begeleid of gestuurd in het proces. Tot slot zijn er te veel componenten en parameters. Dit alles maakt het programma minder geschikt om in te zetten tijdens de schetsontwerpfase.

3.7

MasterSeries - MasterSeries FEM

Staal

Beton

Hout

Baksteen

BIM

Details

Optimalisatie

Alleenstaand

Analysetijd: snel

Expertniveau: hoog

Aanleertijd: lang

Handelingen: veel

Componenten: zeer veel

Interoperabiliteit: .dxf, .dwg

Tabel 3.7: Evaluatie MasterSeries

3.7.1

Algemeen

MasterSeries ontwikkelt software voor ge¨ıntegreerde structuuranalyses, ontwerp, uitwerking en detaillering. Naast de algemene analyseprogramma’s bieden ze ook specifieke programma’s aan per materiaal, zoals ‘Wood Design’ en ‘Steel Design’.

3.7.2

GUI

De GUI is conventioneel opgebouwd [54], met een titelbalk, menubalk, taakbalk en modelleervenster. De taakbalk bevat enkele knoppen en tabbladen (figuur 3.33). Het proces

3.7 MasterSeries - MasterSeries

51

is goed gestuurd omdat de gebruiker wordt aangemoedigd de verschillende tabbladeren chronologisch te doorlopen.

Figuur 3.33: GUI van MasterSeries

3.7.3

Invoer

Figuur 3.34: Balken ingeven in MasterSeries

MasterSeries is een modelleeromgeving waarin de gebruiker geometrie kan tekenen. Om te beginnen moet de gebruiker onder ‘DesignerSuite’ het gewenste materiaal kiezen. Eenmaal een materiaal gekozen, laadt het programma het bijhorende programmaonderdeel. De gebruiker start met het ingeven van de lengte, breedte en hoogte van de balk (figuur 3.34). De belastingen die nochtans hier ook gevraagd worden, kunnen later meer gedetailleerd in het daarvoor voorziene venster worden ingevuld.

52 Het programma gaat standaard uit van een portiek bij het invoegen van de steunpunten (figuur 3.35), onder Supports (Columns). Door Below op 0 te zetten krijgt de gebruiker echter de mogelijkheid te werken met gewone steunpunten.

Figuur 3.35: Steunpunten in MasterSeries

Het volgende tabblad omvat de belastingen. Dit kunnen puntlasten of uniform verdeelde lasten zijn (figuur 3.36). MasterSeries biedt geen voorgedefinieerde belastingsgevallen dus de gebruiker moet zelf de aard van de belasting introduceren.

Figuur 3.36: uniforme belastingen of puntlasten in MasterSeries

Als laatste krijgt de gebruiker de mogelijkheid om niet-uniforme belastingen te beschouwen.

3.7.4

Analyse

Na het bepalen van de verschillende belastingen wordt de analyse automatisch gestart.

3.7.5

Output

Na elke actie krijgt de ontwerper steeds de gevolgen van zijn aanpassingen realtime te zien in de vorm van grafieken (figuur 3.37). Deze grafieken stellen de doorbuiging van en de spanningen en momenten in de balk voor. Aan de hand van deze gegevens kan de gebruiker oordelen of de structuur voldoet aan de normering. MasterSeries biedt de mogelijkheid om na te gaan waar zich problemen voordoen, maar het is onduidelijk welke normering wordt gebruikt.

3.8 Conclusie evaluatie

53

Figuur 3.37: Resultaten van MasterSeries

3.7.6

Interoperabiliteit

MasterSeries voorziet een koppeling met Revit via MasterCAD (http://www.masterseries.co.uk/product-specific/mastercad-bim-integration).

3.7.7

Evaluatie

Hoe complexer de geometrie, hoe meer tijd het vergt om deze te tekenen in MasterSeries. Het programma is te gedetailleerd, waardoor het de gebruiker veel tijd kost alvorens een analyse kan worden uitgevoerd. MasterSeries lijkt minder geschikt om ingezet te worden tijdens de schetsontwerpfase.

3.8

Conclusie evaluatie

Er is een steeds groter wordende vraag naar digitale hulpmiddelen die de ontwerper toelaten om op een flexibele manier ontwerpvariaties in het schetsontwerp te maken [46]. Er zijn diverse antwoorden gekomen op deze vraag, maar een algemene conclusie is dat de structuuranalyse-programma’s tekort schieten. Nieuwe digitale hulpmiddelen zoals parametrische ontwerpsystemen geven de ontwerper de mogelijkheid om op een flexibele manier te ontwerpen. Structuuranalyse-programma’s zijn nog te vaak als een alleenstaande toepassing opgevat. Daardoor wordt het moeilijk om deze efficiënt in te zetten in de schetsontwerpfase. Verder zijn er te veel verschillende antwoorden op de vraag naar structuuranalyse-programma’s en structuurontwerp, waardoor het voor de ontwerper moeilijk wordt om het juiste programma te kiezen. Tabel 3.8 en tabel 3.9 vatten de studie van de structuuranalyse-programma’s samen die gedocumenteerd werd in dit hoofdstuk. Enkel de beschikbare programma’s zijn geanalyseerd door middel van een concrete gevalstudie. De programma’s die niet beschikbaar

54 waren zijn geanalyseerd aan de hand van de informatie die beschikbaar was op de betreffende websites en zijn enkel opgenomen in tabellen.

Analyses Materiaal

FEM

X

EC

X

X

staal

X

X

beton

X

OpenStaad - GC

Karamba Designer - Grasshopper

Finnwood - FinnForest

Framing Design - Structural Soft

Fastrak Building Designer - CSC

55

Advance Design - Graitec


X

hout

X

X

X

X X

X

baksteen Modelleren

2D

X

X

X

X

X

X

3D

X

X

X

X

X

X

BIM

X

Parametrisch Details

X

Optimalisatie Type

Alleenstaand

X

plug-in

X

X

X

X

X

X

X

X

X

X

X

X

Analysetijd

+

+

+-

Expert niveau

-

+

+

Aanleertijd

-

+-

+-

Handelingen

+-

+-

-

Componenten

+

+-

-

Rhino

GC

Interoperability

Revit

Revit

.dxf

Schetsontwerpfase

X Tabel 3.8: Structuuranalyse-programma’s

Materiaal

X

X

X

staal

X

X

X

X

beton

X

X

X

X

hout

X

X

X

X

X

X

X

2D

X

X

X

X

X

3D

X

X

X

X

X

X

X

X

BIM Parametrisch

X

X

Details

X

X

X

Optimalisatie

X

X

X

X

X

X

X

Analysetijd

+

+

+

+

Expert niveau

+-

++

++

+

Aanleertijd

+

++

++

+

Handelingen

+-

++

+

+

Componenten

+

++

+

++

.dxf

Revit

Autodesk

.dxf, .dwg

Type

WoodWorks Sizer - CWC

X

EC

baksteen Modelleren

MasterSeries - MasterSeries

FEM

Robot - Revit

Analyses

Risa 3D - Risa Technologies

PowerFrame - BuildSoft

56

Alleenstaand

X X

plug-in

Interoperability

Revit

Schetsontwerpfase Tabel 3.9: Structuuranalyse-programma’s

De meeste programma’s zijn te complex om in te zetten tijdens de schetsontwerpfase. Dergelijk probleem zien we ook terugkomen bij de implementatie van CAD in het algemeen [46]. Een ontwerp in de schetsontwerpfase is namelijk nog onvoldoende uitgewerkt en wijzigt nog te vaak om al nuttig gebruik van gedetailleerde programma’s tijdens deze fase mogelijk te maken. Hoe sneller de gebruiker resultaat heeft en hoe minder bewerkingen er hiervoor nodig zijn, des te beter inzetbaar het programma is tijdens de schetsontwerpfase. Deze bevindingen stemmen overeen met deze in het werk van Sviataslau Pranovich [58]


57

waarin de eigenschappen worden beschreven van een programma voor de schetsontwerpfase. Hieronder staat de oplijsting van zijn en onze bevindingen waarop het verdere verloop van de masterproef is gebaseerd. Er zijn te veel verschillende programma’s, met verschillende functionaliteiten, de meeste programma’s zijn te complex en te gedetailleerd om ingezet te worden tijdens de schetsontwerpfase, de programma’s zijn vaak alleenstaand en hebben een beperkte of slechte interoperabiliteit, de analyse duurt te lang, een optimalisatie ontbreekt meestal, in de meeste gevallen moet de gebruiker een expert zijn, de aanleertijd is meestal te lang en de handleiding te uitgebreid, de initalisatietijd is meestal te lang en er zijn te veel handleiding nodig, te veel componenten, de programma’s hebben vaak een slechte interoperabiliteit, tabellen en berekeningen zeggen weinig, hybride constructies zijn meestal niet mogelijk, implementatie van normeringen versnelt het proces.

Het chaotische karakter in het begin van de architecturaal ontwerp en het feit dat geen concept volledig is gedefinieerd tijdens deze fase, vormen een aantal specifieke voorwaarden voor de ontwikkeling van een prototype voor deze fase. Krish [46] stelt dat dit soort programma’s gemakkelijk moet kunnen gebruikt worden, om het ontwerp zo min mogelijk te verstoren. En de interventies van de ontwerper moeten zo beperkt mogelijk zijn. Een andere voorwaarde volgens Tversky [76] is dat een dergelijk programma het iteratief ontwerpproces moet ondersteunen en visueel moet zijn. Cijfers en berekeningen bieden weinig waarde tijdens het ontwerpproces. De voorwaarden waar een structuuranalyse prototype voor de schetsontwerpfase aan moet voldoen zijn de volgende: het prototype mag geen beperkende factor voor het ontwerp zijn, complexe vormen mogelijk,

58 export- en importhandelingen beperken, het prototype moet zelf kunnen bepalen wat vloer, muur, plafond of dak is, alleenstaand met de functionaliteit van een plug-in, functionaliteiten moeten overeenstemmen met de noden van de ontwerper in de desbetreffende fase, het prototype mag niet complex en gedetailleerd zijn, efficiëntie van een parametrisch programma, GUI moet overzichtelijk zijn en begeleiden in het intialisatieproces, standaardwaarden, weinig handelingen, weinig componenten, intu¨ıtief, een optimalisatie moet ge¨ıntegreerd zijn, alle plausibele oplossingen moeten kunnen worden weergegeven, combinatie van verschillende materialen, ge¨ımplementeerde normering, snel resultaat, visueel schematisch resultaat, resultaat moet bewerkbaar zijn in de modelleeromgeving, algoritme moet generisch zijn.

PROTOTYPE

59

Hoofdstuk 4 Prototype 4.1

Inleiding

Structuur is inherent aan een ontwerp; het groeit mee met de ideeën en tekeningen van de ontwerper om uiteindelijk, samen met het concept, de vorm van het gebouw te bepalen. Het is dus een belangrijk onderdeel van het ontwerpproces waaraan van bij de aanvang van het ontwerpproces aandacht moet worden besteed. Anderzijds leert de praktijk dat enkel ervaren architecten in staat zijn met de complexe wisselwerking tussen structuur en creativiteit om te gaan en dit op voorwaarde dat de ontwerpopdracht niet te ingewikkeld is. Naast deze complexiteit, zorgt het grote aanbod van structuuranalyse-programma’s er voor dat het moeilijk wordt om het juiste programma te selecteren. Bovendien zijn dergelijke programma’s meestal alleenstaande oplossingen, wat efficiënt gebruik, binnen het architecturaal ontwerpproces, bijna onmogelijk maakt. In de praktijk zijn de verschillende onderdelen, zoals architectuur en structuur, nog lang niet ge¨ıntegreerd in één ontwerpproces. De architect maakt zijn ontwerp, maakt een voorstel voor de structuur en geeft het ontwerp aan de ingenieur. Deze zal vervolgens dit voorstel conceptualiseren op basis van zijn intu¨ıtie en ervaring. Dit concept wordt in het structuuranalyse-programma gemodelleerd en geanalyseerd. Aan de hand van deze analyse zal de ingenieur het ontwerp aanpassen en voorleggen aan de architect. In het beste geval kunnen deze aanpassingen gewoon in het model worden overgenomen. Indien dit niet het geval is, past de architect zijn ontwerp aan en moet de structuur opnieuw worden geanalyseerd en dit tot er een ’aanvaardbaar’ compromis is gevonden [26]. Ongetwijfeld is het gebruik van structuuranalyse-programma’s nuttig, maar de huidige programma’s dragen weinig bij tot het ontwerp. Integendeel, vaak beperken ze het ontwerp omdat ze tijdrovend zijn of omdat ze pas op het einde van het ontwerp worden ingezet. Bijkomend geven de bestaande structuuroptimalisatie-programma’s de gebruiker een optimale oplossing (hoofdstuk 3), in plaats van de mogelijkheid om alle plausibele oplossingen te gebruiken. In het laatste geval kan de architect het structuuroptimalisatie-

60 programma inzetten als ontwerptool om verschillende alternatieven te genereren. De beperkte aandacht voor de invloed van de structuur op het ontwerp, tijdens de eerste fasen van het ontwerpproces, kan deels te wijten zijn aan de beperkte toegankelijkheid van structuuranalyse-programma’s en optimalisatie. Een applicatie die een ge¨ıntegreerde oplossing biedt die daarenboven ook gebruiksvriendelijk is, blijkt vandaag niet voorhanden te zijn. Er is wel onderzoek gevoerd, over hoe structuuroptimalisatie-programma’s als ontwerptool kunnen worden ingezet in de ingenieursontwerpdomeinen zoals vliegtuigbouw [53]. Aangezien hoofdstuk drie heeft uitgewezen dat er nog geen structuuranalyseprogramma’s en optimalisatie voor de schetsontwerpfase bestaan, werd hier gekozen om een prototype voor deze fase te ontwikkelen. Dit hoofdstuk geeft een gedetailleerd overzicht van de verschillende stadia van de ontwikkeling van het prototype. Deel één beschrijft het concept van het prototype, identificeert de problemen en de methode om ze aan te pakken. Deel twee gaat dieper in op het proces dat moet worden doorlopen bij het gebruik van het prototype. Deel drie gaat dieper in op het script en de gebruikte algortimes.

4.2

Concept

Een van de uitgangspunten voor de ontwikkeling van het prototype is om de opbouw zo generisch mogelijk te houden, zodat het gemakkelijk kan worden ge¨ımplementeerd in een andere modelleeromgeving. Om dit te bereiken worden de gegevens uit het model ingevoerd door middel van een xml-bestandstype. De enige aanpassing die moet worden gemaakt, om het prototype te implementeren in een ander programma, is de data-extractie uit en de data-import na de optimalisatie in de modelleeromgeving. De analyse en optimalisatie is onafhankelijk van de data-extractie en visualisatie. Het prototype is dus een alleenstaande applicatie, maar heeft de functionaliteit van een plug-in. Het exporteren van de gegevens naar een xml-bestand impliceert ook dat het prototype in een taal naar keuze kan worden geprogrameerd; hier is dit in C#. In dit geval wordt de data-extractie door middel van een, in het kader van de ‘BuildingChecker’ ontwikkelde applicatie gerealiseerd [42]. Het doel van dit prototype is om een efficiënt en gebruiksvriendelijk structuuranalyseen optimalisatieprogramma te ontwikkelen, waarmee de gebruiker in elke fase van het ontwerpproces, zelfs in de beginfase, het ontwerp kan evalueren en optimaliseren. Als proof of concept richt dit prototype zich op de evaluatie van een houten balkstructuur, maar het kan worden uitgebreid naar andere materialen door het generische karakter van het script. Er is gekozen om te vertrekken van SU als modelleeromgeving omdat dit een progamma is dat vaak wordt gebruikt in het begin van het ontwerp [41] en omdat er reeds eerder binnen de faculteit ingenieurswetenschappen en architectuur en de onderzoeksgroep SmartLab (http://smartlab2.elis.ugent.be/smartlabportal/Home.aspx) prototypes

4.2 Concept

61

voor SU zijn ontwikkeld. De ontwerper kan zijn ontwerp in SU modelleren, en wanneer hij wil kan hij een structurele analyse uitvoeren.

Figuur 4.1: Prototype, het rode kader geeft aan wat door het prototype moet worden uitgevoerd

Een analyse van een structuur doorloopt steeds een vast schema (figuur 4.1). Eerst worden de nodige gegevens geëxtraheerd om in te voeren in het structuuranalyse-programma. Het kan de gebruiker zijn die dit manueel invoert, de gebruiker kan het ontwerp hertekenen in het structuuranalyse-programma of er bestaat een rechtstreekse link tussen de modelleeromgeving en de structuuranalyse. Eenmaal de analyse is uitgevoerd, wordt indien dit nodig blijkt de structuur geoptimaliseerd. Dit kan door de gebruiker worden uitgevoerd of door het programma zelf. Tot slot wordt de structuur in het ontwerp ge¨ımplementeerd, door de gebruiker of het programma. De tussenkomst van de gebruiker moet zo veel mogelijk worden beperkt (figuur 4.1). In dit geval zal het prototype de gegevens van SU krijgen, deze analyseren, optimaliseren en een structuur voorstellen, zonder het tijdverlies van hermodelleren of invoeren van parameters. Omdat dit prototype ge¨ımplementeerd is in de modelleeromgeving kan de gebruiker het prototype inzetten als een analystische ontwerptool. Terwijl het ontwerp in SU evolueert kiest de gebruiker zelf, onafhankelijk van de de fase waarin het ontwerpproces zich bevindt, om de structuur te analyseren. Zo kan het ontwerp eventueel, aan de hand van de resultaten, tijdig worden bijgestuurd. Het prototype krijgt de nodige gegevens van SU, analyseert, optimaliseert en stelt een geoptimaliseerde structuur voor (figuur 4.2). Het prototype zal het gebouw en zijn geometrie analyseren om zo zelf een geoptimaliseerde structuur voor te stellen, de ontwerper

62 hoeft niet eerst een structuurvoorstel te maken. De analyse gebeurt op basis van de xmlbestanden, deze bestanden zijn echter niet voldoende om de analyse en optimalisatie uit te voeren, de gegevens moeten nog worden verrijkt. De verrijking gebeurt enerzijds door de ontwerper en anderzijds via catalogi. Na de analyse krijgt de ontwerper een geoptimaliseerde structuur en de mogelijkheid om alle oplossingen die voldoen aan de normen op te roepen. Zo kan een ontwerper zich volledig concentreren op het ontwerp, zonder belast te worden met de berekeningen, en kan hij het prototype als ontwerpapplicatie gebruiken. Dit proces van analyseren en terug implementeren in het ontwerp gaat door tot de ontwerper tevreden is met het ontwerp. Tot slot, wanneer het ontwerp klaar is, moet de ingenieur stabiliteit nog een exacte analyse maken, maar dit op basis van een reeds geëvalueerde structuur.

Figuur 4.2: Proces dat doorlopen wordt

Dit prototype heeft in geen geval de intentie een volwaardige applicatie te zijn maar is slechts een basis voor de ontwikkeling van dergelijke applicaties en een poging om de mogelijkheden en problemen te exploreren.

4.3 Proces

4.3

63

Proces

Figuur 4.2 geeft het proces weer dat moet worden doorlopen bij gebruik van het prototype. Het rode kader bevat het eigenlijke prototype (figuur 4.2).

4.3.1

Modelleeromgeving

In dit prototype wordt SU (http://sketchup.google.com/) als modelleeromgeving gebruikt. SU is een 3D-oppervlakte modelleeromgeving, uitgebracht door Google en compatibel met Mac OS en Windows. Deze software is ontwikkeld om ontwerpers toe te staan met dezelfde vrijheid te tekenen als met pen en papier. De interface is eenvoudig gehouden en voor de hand liggend, dit maakt dat het een inu¨ıtitieve omgeving is. In deze omgeving wordt er getekend met vlakken en niet met volumes. Verder hebben SketchUp gebruikers toegang tot de zogenaamde 3D Warehouse van Google, een databank met 2D en 3D modellen gemaakt in SketchUp, waardoor ontwerpers tijd kunnen besparen. De verschillende exportformaten 2D en 3D geven de gebruiker de vrijheid om de tekeningen naar andere CAD en grafische software te exporteren. Ontwerpers die de behoefte hebben om de basisfuncties uit te breiden kunnen hun eigen applicaties of ’Rubies’ ontwikkelen, deze worden geschreven in de programmeertaal Ruby (http://www.ruby-lang.org/en/). Veel van deze Rubies zijn vrij beschikbaar op het SketchUp Ruby forum (http://groups.google.com/group/googlesketchup-developers). Om het gemakkelijker te maken om deze Rubies te ontwikkelen bestaat de SketchUp Software Development Kit (SDK), de SDK is beschikbaar in C# voor Mac en Windows. Tot slot zijn heel wat applicaties en plug-ins, zoals Building Performance Analysis applicaties, renderapplicaties, energieprestatie-applicaties, etc. beschikbaar voor SU, maar geen structuuranalyse-programma’s waarmee de gebruiker zijn ontwerp kan analyseren tijdens het begin van het ontwerpproces. In het volgende hoofdstuk wordt er verder ingegaan op de wijze van modelleren en de afspraken die hieruit voortkomen.

4.3.2

Data extraheren

Van zodra de gebruiker zijn ontwerp wil analyseren, moeten gegevens worden geëxporteerd. Door gebruik te maken van het xml-bestandstype als export formaat is getracht het prototype zo generisch mogelijk op te bouwen. Voor deze export wordt er gebruik gemaakt van een applicatie die deel uitmaakt van de ‘BuildingChecker’, ontwikkeld door de onderzoeksgroep SmartLab aan de Universiteit Gent. Deze applicatie werd ontwikkeld in het kader van de masterproef ‘The development of an energy-analysis plugin to Google SketchUp’ (Jonckheere, 2010) [42]. De applicatie stelt de gebruiker van dit prototype in staat om data uit SU naar het xml-bestandstype te exporteren (figuur 4.3).

64

Figuur 4.3: Conceptschema Export plug-in

De plug-in maakt het mogelijk om extra informatie mee te geven met het exportbestand. Voor de structuuranalyse is het belangrijk de verschillende vlakken, waaruit het SU model is opgebouwd, te definiëren. Zo moet er worden bepaald welke vlakken de vloer, het plafond, het dak en de muren voorstellen. Materialen en gebouwtype kunnen ook worden meegegeven maar voor dit prototype werd gekozen om een aparte interface te ontwikkelen die alle informatie nodig voor de structuuranalyse bevat.

Het SU-model en de extra gegevens vormen samen de output van de plug-in, onder de vorm van xml-bestanden. De elements.xml en de topo.xml zijn van belang voor de structuuranalyse (figuur 4.4). De elements.xml bevat per constructietype een identificatienummer, de BuildingElements Id. Door in de elements.xml bestand bijvoorbeeld te zoeken naar Dak vindt de applicatie het identificatienummer van het dak terug. Met dit cijfer kan in de topo.xml gezocht worden naar de hoekpunten die het dak definiëren. Op basis van deze hoekpunten wordt uiteindelijk de analyse uitgevoerd.

Figuur 4.4: elements.xml (links) en topo.xml (rechts)

4.3 Proces

4.3.3

65

Verrijking met catalogi

Alvorens er berekeningen kunnen worden gemaakt moeten de gegevens van de xmlbestanden worden verrijkt met externe gegevens. Dit prototype maakt gebruik van een catalogus met courante constructiehoutsoorten in België (bijlage B: Hout soorten) [10]. ’Oregon Pine’ uit Noord-America, ’Vuren’ uit België, ’Noordvuren’ uit Noord-Europa, ’Grenen’ uit België, ’Noord grenen’ uit Noord-Europa.

Uiteraard kan deze catalogus eenvoudig worden uitgebreid met andere houtsoorten en hun specificaties. Om een houtsoort te selecteren voor een specifiek ontwerp, zijn er verschillende parameters, zoals sterkte en duurzaamheid, nodig. Elk van deze voorwaarden kan worden gevonden in Eurocode 5 [4]. Een tweede catalogus, die op de achtergrond wordt gebruikt, is deze met de verschillende belastingsmodellen (zie Bijlage C: Formules voor de doorbuiging). Het prototype maakt echter enkel gebruik van de uniform belaste balk op twee steunpunten, een rol- en mesoplegging, zonder overkraging (figuur 4.5).

Figuur 4.5: Belastingssituatie: uniform belaste balk op twee steunpunten zonder overkraging

4.3.4

Verrijking door de gebruiker

Na analyse van de verschillende bestaande programma’s is gebleken dat applicaties in de schetsontwerpfase eenvoudig en snel moeten zijn. Vandaar dat voor dit prototype werd gekozen om het aantal basisparameters, die noodzakelijk zijn om de analyse uit te voeren, te beperken (figuur 4.6). Het is mogelijk om het aantal parameters uit te breiden maar de gebruiker moet steeds snel zijn ontwerp kunnen testen. Om de snelheid te verzekeren, moeten deze parameters standaardwaarden bevatten. Verder moet het steeds duidelijk blijven dat deze parameters additioneel zijn.

66

Figuur 4.6: Laden elements.xml en topo.xml bestanden

Naast het inladen van de twee .xml bestanden kan de gebruiker de doorbuigingslimiet, de houtsoort en de belasting die gekoppeld is aan het type van gebouw invoeren (figuur 4.7).

Figuur 4.7: Noodzakelijke analyse parameters

De waarde voor de beperking van de doorbuiging, waar deze analyse op is gebaseerd, kan worden teruggevonden in de EC [4]. Aan elke type houtsoort is een lijst met courante afmetingen, de E-modulus en de densiteit gekoppeld. De veranderlijke belasting verticaal op de vloeren en de daken, is afhankelijk van het type gebouw en gebaseerd op NEN 6702: Veranderlijke belasting voor een woningvloer is 1.75 kN/m2 , Veranderlijke belasting voor een zoldervloer is 0.7 kN/m2 , Veranderlijke belasting voor een kantoorvloer is 2.5 kN/m2 , Veranderlijke belasting voor een winkelvloer is 4 kN/m2 , Veranderlijke belasting dak voor een woning is 1 kN/m2 .

De permanente belasting is afhankelijk van het eigengewicht van de vloer- of dakstructuur. Een extra parameter die al voorzien is, maar niet noodzakelijk voor de analyse, is de mogelijkheid om de draagrichting te veranderen (figuur 4.8). Door deze parameter na de

4.3 Proces

67

’play-toets’ te plaatsen, wordt aangegeven dat de parameter niet noodzakelijk is voor de analyse.

Figuur 4.8: wisselen van de draagrichting

4.3.5

Evaluatie

Tijdens de evaluatie wordt met behulp van een eenvoudig algoritme de structuur geanalyseerd en een optimalisatie voorgesteld. Dit algoritme is gebaseerd op de begrenzing van de doorbuiging (figuur 4.9), volgens de formule uit de EC:

Figuur 4.9: Schema doorbuiging

u0 = voorgespannen balk [m] u1 = doorbuiging door permanente belastingen [m] u2 = doorbuiging door variabele belastingen [m] unet = netto doorbuiging = u [m] De netto doorbuiging onder de rechte lijn, unet , wordt gegeven door:

u = u1 + u2 - u0 In het geval van de eenvoudige opgelegde balk met een uniforme belasting (figuur 4.10), waar dit prototype vanuit gaat, wordt dit: u= (5.q.l4 )/(384.E.I)

68 u = verplaatsing [m] q = lading [kN] l = lengte [m] E = E-modulus [N/mm2 ] I = traagheidsmoment [N.m]

Figuur 4.10: Schema doorbuiging in het geval van de uniform belaste balk op twee steunpunten

Verder stelt NBN B 03-003 dat de uitgestelde vervorming van een vloer die aan minstens twee zijden wordt ondersteund als volgt wordt begrensd: maximum 1/350 van de overspanning voor daken die aan de binnenzijde worden bepleisterd, maximum 1/250 van de overspanning indien er geen afwerking is voorzien.

Afhankelijk van de voorziene afwerkingen en/of scheidingswanden op de vloer kunnen bijkomende eisen worden opgelegd. Vandaar dat dit prototype ook de mogelijkheid geeft om dadelijk met de eis van l/500 te rekenen. De formule wordt dan: u= (5.q.l4 )/(384.E.I) < l/500 Op basis van deze vergelijking worden alle dimensies van het gekozen houttype gecontroleerd. Als extra parameter wordt er ook rekening gehouden met een standaard afstand tussen de balken in dit geval 60 cm. De tussenafstand kuan als extra parameter worden voorzien maar dit nog niet ge¨ımplementeerd in het huidige prototype, de mogelijkheid is wel al voorzien in het algoritme.

4.3.6

Optimalisatie

De optimalisatie van dit prototype gebeurt volgens een exhaustive search methode. Hierbij wordt voor alle dimensies van het gekozen houttype, die voldoen aan de voorwaarde van de evaluatie, het totaal benodigd volume hout bepaald. Dit volume wordt berekend afhankelijk van het aantal balken, die er per opstelling nodig zijn. Vervolgens wordt een optimalisatie naar de minimale hoeveelheid hout gemaakt, gebaseerd op de dimensies

4.3 Proces

69

van de balken, de tussenafstanden en het aantal balken. Voor elke opstelling, wordt het volume hout vergeleken met de anderen. Telkens wordt de opstelling met het kleinste volume weerhouden tot alle oplossingen zijn vergeleken.

4.3.7

Visualisatie

In dit prototype is de visualisatie onderdeel van de analyse-interface (figuur 4.11). In een verdere uitwerking van het prototype zal de geometrie worden gevisualiseerd en bewerkbaar zijn in de modelleeromgeving.

Figuur 4.11: Visualisatie

4.3.8

GUI

Er is bewust gekozen om een aparte GUI te ontwikkelen, die losstaat van de SU GUI, om het prototype zo generisch mogelijk te houden. De GUI werd zo opgebouwd dat deze duidelijk en gebruiksvriendelijk is. Het venster is opgedeeld in een eerste deel (figuur 4.12 (1)) voor de visualisatie, een tweede deel (figuur 4.12 (2)) voor de verschillende

70 invoermogelijkheden en parameters en tenslotte een derde deel (figuur 4.12 (3)) waar de analyseresultaten in de vorm van tekst en tabellen worden weergegeven.

Figuur 4.12: GUI

4.4

Algoritme

In onderhavige scriptie wordt er niet verder ingegaan op de broncode, wel zullen de voornaamste algoritmes en principes in dit deel worden besproken aan de hand van pseudocode.

Figuur 4.13: Verschillende onderdelen

In het algoritme worden de verschillende stappen die moeten worden doorlopen in het prototype afzonderlijk behandeld. Elk onderdeel heeft zijn eigen klassen, methoden en

4.4 Algoritme

71

objecten (figuur 4.13 en 4.14). De visualisatie is strikt gescheiden van het analyseproces, zo kan de visualisatie later worden vervangen door een rechtstreekse terugkoppeling naar de modelleeromgeving (zie deel 4.5). Verder zijn ook de GUI en het analyseproces afzonderlijk opgebouwd.

Figuur 4.14: Klassendiagram

4.4.1

BuildingElementsReader

De BuildingElementsReader gaat in de elements.xml opzoek naar het identificatienummer van het dak, de vloer en de muren, om vervolgens met dit identificatienummer in de topo.xml de respectivelijke coördinaten van de hoekpunten in te lezen. Deze coördinaten worden via de methode GetListDVertex3Element in een lijst van DVertex3 objecten opgeslagen. Via deze lijst kan het algoritme later de coördinaten opvragen.

72 Data: .xml Result: coördinaten van de hoekpunten van het dak lees elements.xml; while einde document==False EN coördinaten niet gevonden EN error==False do if type==dak then id dak = id gevonden; lees topo.xml; while einde document==False EN id dak niet gevonden EN error==False do if id dak then coördinaten dak = coördinaten gevonden; else error; end end else error; end end Opzoeken coördinaten van de hoekpunten van het dak

4.4.2

ThisTimber en Timber

Vervolgens wordt de klasse Timber aangemaakt met de eigenschappen: naam, E-modulus, densiteit en dimensies van de balken. Het aanmaken van de verschillende houtsoorten met hun eigenschappen wordt bekomen door ThisTimber. Momenteel zijn er drie houtsoorten beschikbaar. Het is op basis van de E-modulus, de densiteit en de dimensies van deze houtsoorten dat de analyse wordt uitgevoerd. Verder zijn de dimensies noodzakelijk om een optimalisatie te bekomen. Deze gegevens worden voor dit prototype rechtstreeks in de code geschreven maar het is mogelijk om een externe databank te koppelen aan het prototype.

4.4.3

Load

De klasse Load gaat de verschillende gebouwtypes met de respectievelijke belastingen definiëren. Omdat er maar enkele belastingsgevallen zijn gedefinieerd, worden deze niet via een externe databank ge¨ımporteerd maar rechtstreeks in de code verwerkt.

4.4 Algoritme

4.4.4

73

LengthEdges

Om de structuur te kunnen evalueren en optimaliseren moeten eerst de gegevens die ge¨ımporteerd zijn worden geanalyseerd. De evaluatie heeft volgende invoer nodig: LshortMain, LlongMain, MyTimber, ThisLoadCalculationMain, Dimensions, Condition. Alle gegevens zijn bepaald door de invoer van de gebruiker behalve LshortMain en LlongMain. Dit zijn de lengtes van de kortste en langste zijde van het dak. De kortste zijde stelt de lengte van de balken voor en de langste de lengte van de muur waar de balken op rusten. Data: lijst van coördinaten van de hoekpunten van het dak Result: de lengte van de kortste zijde van het dak lees lijst van coördinaten; while einde document==False do if lengte1 < lengte2 then LshortMain = lengte1; else LshortMain = lengte2; end end Bepalen van de lengte van de kortste zijde van het dak Door de GetLengthEdgeShortMain en GetLengthEdgeLongMain methodes te doorlopen wordt, afhankelijk van de flip beam functie, de lengte van de balken opgeroepen. Wanneer flip beam geselecteerd is dan worden de balken volgens de langste richting gelegd, indien de lengtelimiet van 5 m niet wordt overschreden. De lengte van de langste zijde wordt opgeroepen door GetLengthEdgeLongMain, volgens het algoritme ‘Bepalen van de lengte van de kortste zijde van het dak’. Na het bepalen van de lengte van de hoofdbalken en de dimensies die voldoen aan de voorwaarde van de doorbuiging, worden de lengte van de tussenbalken, die dwars tussen de hoofdbalken zitten, bepaald. Dit gebeurt met het algoritme ThisLengthEdgesBetween, volgens het algoritme ‘Bepalen de lengte van de tussenbalken’. Data: lijst van de dimensies van de balken en de tussenafstanden Result: de lengtes van de tussenbalken lees lijst met de dimensies van de balken en de gekoppelde tussenafstanden; while einde lijst dimensies==False do lengte tussenbalken = (lengte oplegzijde van de hoofdbalken - (breedte x aantal balken))/(aantal balken - 1); end

74 Bepalen van de lengte van de tussenbalken

4.4.5

Calculation

Om de analyse uit te voeren, zijn de lengte van de balken, de klasse Timber met de eigenschappen van het hout, de doorbuigingslimiet, het belastingsgeval en tot slot nog de lijst met alle mogelijke dimensieverhoudingen voor het hout nodig. Data: lijst met dimensies, hout en belasting Result: lijst met dimensies en tussenafstanden die voldoen aan de doorbuigingslimiet lees lijst met dimensies, hout en de belasting; while einde lijst==False do belasting = (1,35 . (eigengewicht hout + permanente belasting)) + (1,5 . veranderlijke belasting); doorbuiging = (5 . belasting . lengte4 )/(384 . E-modulus . traagheidsmoment); if doorbuiging < doorbuiging max then balken met tussenafstanden toevoegen aan lijst; else end end Aanmaken van de lijst met alle plausibele dimensies en tussenafstanden De evaluatie zelf bestaat uit twee, geneste, for-loops, waar in de eerste loop het aantal balken als parameter geldt en in de tweede de dimensies. Tenslotte wordt getest of elk van de situaties voldoet aan de begrenzing van de doorbuiging. Indien het resultaat voldoet, wordt het in een lijst weggeschreven. Het is deze lijst die in de optimalisatie wordt doorlopen om het resultaat met het kleinste volume te bepalen. De volgende stap in de evaluatie is het bepalen van de tussenbalken. Deze zijn uiteraard afhankelijk van de eerder verkregen dimensies van de hoofdbalken en moeten aan dezelfde regels als de hoofdbalken voldoen. Het algoritme dat eerder werd gebruikt voor de evaluatie van de hoofdbalken kan dan opnieuw worden toegepast, mits het aanpassen van de lengte van de balken. Nu de lijst met de hoofden tussenbalken compleet is, kan de optimalisatie door middel van een exhaustive search-methode beginnen. Hierbij worden alle mogelijke oplossingen ten opzichte met vergeleken en de beste telkens bijgehouden.

4.5 Implementatie in Grasshopper

75

Data: lijst met de plausibele hoofden tussenbalken Result: configuratie met het kleinste volume lees lijst met de plausibele hoofden tussenbalken; Volume = L . B . H . aantalbalken; while niet op het einde van de lijst do if configuratie1 < configuratie1 then optimum = configuratie1; else end end Bepalen van de optimale configuratie met het minimale volume hout als optimum

4.4.6

Visualisation

Nu zowel de hoofdbalken als de tussenbalken bepaald zijn, kan alles worden gevisualiseerd. Het visualisatiealgoritme voor de hoofdbalken kan ook voor de tussenbalken worden gebruikt. De invoer voor het visualisatiealgoritme is steeds de lengte en breedte van het gebouw, het aantal balken, dimensie van de balken, de z-coördinaat van het dak en de basis (de zijde waar de eerste balk op wordt gevisualiseerd). Eenmaal alles is ingevoerd moet het algoritme alle coördinaten bepalen om vervolgens de vlakken te visualiseren. Hiervoor is de volgorde waarop de coördinaten worden ingegeven belangrijk. Dit moet namelijk volgens de regel van de rechterhand gebeuren. Wordt deze regel niet gevolgd zal het desbetreffende vlak transparant worden gevisualiseerd. Het voordeel van deze losgekoppelde visualisatie is dat deze eenvoudig uit het script kan worden vervangen door een andere visualisatie of door de modelleeromgeving. De losgekoppelde visualisatie heeft als belangrijk nadeel dat na elke aanpassing de simulatie volledig moet worden herhaald. Parallel met het optimum wordt er een lijst met alle plausibele oplossingen bijgehouden, wat de gebruiker toelaat andere oplossingen, die voldoen aan de doorbuigingslimiet, te visualiseren.

4.5

Implementatie in Grasshopper

Om te testen in hoe verre het algoritme generisch is, is het in Grasshopper - Rhinoceros ge¨ımplementeerd. Deze implementatie heeft aangetoond dat de specifieke klassen en methoden die in Grasshopper worden gebruikt, moeten worden aangepast in het algoritme,

76 zoals de klasse DVertex3 die in Grasshopper Point3d wordt. Buiten deze aanpassingen zijn er geen correcties nodig. Het voordeel van de implementatie in Grasshopper is dat er steeds een rechtstreekse koppeling is met de Rhinoceros modelleeromgeving (figuur 4.15). De structuur is dus zichtbaar en bewerkbaar in Rhinoceros. Verder is het ook mogelijk de Grasshoppercomponenten aan deze van de analyse en optimalisatie te koppelen, zodat het geheel parametrisch blijft (figuur 4.16).

Figuur 4.15: Visualisatie in Rhinoceros

Figuur 4.16: Implementatie in Grasshopper

In Grasshopper zijn dezelfde onderdelen als bij de SU versie terug te vinden (figuur 4.17, figuur 4.18, figuur 4.19, figuur 4.20 en figuur 4.21).


4.5.1

77

Modelleeromgeving

In deze toepassing van het algoritme wordt Rhinoceros (http://www.rhino3d.com/) als modelleeromgeving en Grasshopper (http://www.grasshopper3d.com/) als generatieve plug-in voor Rhinoceros gebruikt. Grasshopper is zo ontwikkeld dat het de gebruiker instaat stelt om eenvoudig zonder ervaring met programmeren parametrisch te ontwerpen. De plug-in is opgebouwd uit componenten, dit zijn stukken script die specifieke elementen of functies, zoals punt of rotatie, beschrijven. De gebruiker kan geometrie parametrisch beschrijven door de componenten, in een specifieke volgorde, achter elkaar te plaatsen. Het bekomen resultaat wordt steeds in Rhinoceros gevisualiseerd. Eenmaal de gebruiker het gewenste resultaat heeft bekomen, kan hij de geometrie Baken of fixeren in Rhinoceros. Het Baken van het resultaat zorgt dat de geometrie losgekoppeld wordt van Grasshopper en in Rhinoceros bewerkbaar wordt. De ontwerper kan de standaardcomponenten gebruiken of beslissen om zelf componenten toe te voegen door gebruik te maken van de VB- of C#-component. Zo zijn er heel wat componenten en pakketten (zoals Karamba) beschikbaar voor Grasshopper (http://www.food4rhino.com/). Het prototype in Grasshopper maakt gebruik van de standaardcomponenten en zal door middel van de C#-component het algoritme implementeren.

4.5.2

Data extraheren

Figuur 4.17: Implementatie in Grasshopper, onderdeel invoer data

78 Er zijn twee mogelijkheden om het prototype in te zetten, enerzijds kan de gerbuiker een ontwerp in Rhinoceros analyseren en anderzijds een ontwerp in Grasshopper. In het laatste geval kan het prototype rechtstreeks de nodige gegevens uit de Grasshopper componenten halen. Van zodra de gebruiker zijn ontwerp in Rhino wil analyseren, moet de nodige gegevens eerst naar Grasshopper worden geëxporteerd, dit wordt door het gebruik van standaard-componenten bekomen (figuur 4.17 onderdeel SelectionRoof). Door gebruik te maken van component Curve kan de gebruiker de curve die het dak beschrijft selecteren en in Grasshopper importeren. De component Explode die hierna is geschakeld, zal de curve verdelen in de verschillende lijnstukken en hoekpunten. Met volgende component Length worden de lengtes van de verschillende lijnstukken bekomen.

Figuur 4.18: Implementatie in Grasshopper, onderdeel verwerking geometrische data

4.5.3

Verrijking door catalogi en de gebruiker

Door de component Value List kan de gebruiker de houtsoort, de belasting en het type gebouw selecteren (figuur 4.17). Bij de belasting en het type gebouw zijn dadelijk de getalswaarden in de component voorzien. Voor de houtsoort zijn er meerdere parameters en is er dus een eerste C#-component nodig, de component GetTimber. Deze component bevat het algoritme dat in het vorige deel werd besproken. De invoer is telkens de gekozen houtsoort en de uitvoer zijn de standaarafmetingen, de E-modulus en de densiteit. Er wordt telkens gebruik gemaakt van dezelfde catalogi als deze die in het vorige deel zijn


79

besproken.

4.5.4

Verwerking data

Alvorens de evaluatie en optimalisatie kunnen worden uitgevoerd, moeten de geometrische gegevens worden verwerkt (figuur 4.18). Door middel van de C#-component GetLengthMain worden de langste en kortste zijde bepaald van de hoofdbalken. Nadat de evaluatie is gebeurd en de plausibele oplossingen van de hoofdbalken gekend zijn gaat de C#-component GetLengthBetween de lengte van de tussenbalken bepalen, zodat ook deze kunnen worden geëvalueerd. Wanneer alles moet worden gevisualiseerd, gaat de C#-component GetBaseEdge de zijde bepalen waar de eerst balk moet worden getekend.

4.5.5

Evaluatie en optimalisatie

De evaluatie en optimalisatie zijn opgebouwd volgens hetzelfde algoritme als van het SU prototype en is rechtstreeks in de C#-componenten ge¨ımplementeerd (figuur 4.19). De C#-component Calculation voert zowel de evaluatie als de optimalisatie uit van de hoofdbalken. Deze component wordt ook gebruikt voor de evaluatie en optimalisatie van de tussenbalken.

Figuur 4.19: Implementatie in Grasshopper, onderdeel evaluatie en optimalisatie

80

4.5.6

Visualisatie

De C#-component VisualizationMain gekoppeld aan de C#-component Beams visualiseert de optimale compositie van de hoofdbalken en de C#-component VisualizationBetween met C#-component Beams visualiseert deze van de tussenbalken (figuur 4.20). Door de componenten Surfaces aan of af te zetten kan de gebruiker kiezen om de optimale configuratie al dan niet te visualiseren. Door deze componenten te Baken worden de hoofden tussenbalken beschikbaar in Rhinoceros.

4.5.7

Alternatieven

Figuur 4.20: Implementatie in Grasshopper, selectie van alternatieven

Ook bij de Grasshopper variant is het mogelijk om de alternatieve plausibele oplossingen te visualiseren (figuur 4.20). Het is echter niet mogelijk om rechtstreeks een andere compositie in de lijsten te selecteren. Aan de hand van een slider kan de gebruiker het nummer van de gewenste compositie uit de lijst vormen en deze zo visulaliseren (figuur 4.21 (rode kader)).

4.5.8

GUI

Het prototype in Grasshopper bestaat uit drie functionele delen: invoer (figuur 4.21 (rood)), evaluatie en optimalisatie(figuur 4.21 (groen)) en de uitvoer (figuur 4.21 (paars)). Door in de uitvoer de preview van de optimale compositie of deze van de alternatieve configuratie te activeren, wordt respectievelijk het optimum of het alternatief gevisualiseerd.


Figuur 4.21: Implementatie in Grasshopper, GUI

81

82

HANDLEIDING

83

Hoofdstuk 5 Handleiding 5.1

Minium systeemvereisten

Google SketchUp 6 Windows XP/Vista/7

5.2 5.2.1

Installaties Installatie Google SketchUp

Op de website http://sketchup.google.com/download/gsu.html kan de laatste versie van Google SketchUp worden gedownload. Indien blijkt dat deze versie niet compatibel is met de plug-in dan kan via deze website http://support.google.com/sketchup/bin/answer.py?hl=en&answer=60107 een oudere versie worden bekomen. Nadat het bestand is gedownload, kan SketchUp, door de volgende stappen te doorlopen, ge¨ınstalleerd worden: Er moet met een gebruikersaccount dat over beheerdersrechten beschikt worden aangemeld. Dubbelklik op het EXE-installatiebestand. Bij Windows Vista/Windows 7: klik met de rechtermuisknop en selecteer ‘Als administrator uitvoeren’. Klik op ‘Volgende’ in het welkomstvenster. Op dit punt wordt er mogelijk verzocht .NET Framework te installeren. Deze software is vereist voor SketchUp Pro. Start indien nodig de computer opnieuw op nadat .NET Framework is ge¨ınstalleerd. Om de installatie van SketchUp te hervatten nadat de computer opnieuw is opgestart moet er op het SketchUp-installatiebestand worden gedubbelklikt. De procedure moet worden vervolledigd door volgende stappen te doorlopen:

84 Klik op de knop ‘Ik ga akkoord met de voorwaarden in de licentieovereenkomst’. Klik op de knop ‘Volgende’ om SketchUp op de voorgestelde locatie te installeren. Indien het programma op een andere locatie moet worden gë¨ınstalleerd, vorm het gewenste pad en klik vervolgens op ‘Volgende’. Klik op de knop ‘Installeren’ indien de instellingen voldoen, zo niet, pas de instellingen aan en klik op ‘Volgende’. Klik op de knop ‘Voltooien’ wanneer dit wordt gevraagd. Bij Windows Vista en Windows 7 moet de SketchUp Pro, na de installatie voordat de autorisatie wordt uitgevoerd, worden gesloten. Start SketchUp één keer voordat het gebruikersaccount met beheerdersrechten wordt afgesloten.

5.2.2

Installatie xml-exporter

Op de bijgevoegde CD-rom bevindt zich een map ‘xml-exporter’ waarin de basisbestanden die vereist zijn voor de ’xml-exporter’ voor SU zijn opgeslagen. Kopieër de inhoud van deze map in de map C:\Program Files \Google \Google SketchUp 8 \Plug-ins op uw computer. Om te controleren of de plug-in correct functioneert, open SU en klik op het menu ’Venster’ of ’Window’ indien de versie engelstalig is. Klik op het submenu ‘Ruby Console’, vervolgens verschijnt een dialoogvenster (figuur 5.1). Typ onderaan in de invulregel load ‘install.rb’ en druk op enter. Het dialoogvenster mag terug worden afgesloten. Vervolgens moet er op het menu ‘Invoegtoepassingen’ worden geklikt en daarna op het submenu ‘EPW-export’. Als alles goed is ge¨ınstalleerd, verschijnt het beginvenster van de exporter. Indien dit niet het geval is, probeer dan de vereiste bestanden opnieuw te kopiëren of zelfs SU opnieuw te installeren. Indien het programma na deze handelingen nog steeds niet functioneert, is het aangewezen om de ‘wxSU-library’ op een andere manier in te voeren. Kopieër de volledige inhoud van de map ‘Plug-ins’, behalve de map ‘wxSU.rb’, naar de map C:\Program Files\Google\Google SketchUp 8\Plug-ins . Surf vervolgens naar http://wxsu.sourceforge.net en download de ‘library’. Let wel op dat dit in de correcte map wordt opgeslagen. Selecteer de volgende map; C:\Program Files\Google\Google SketchUp 8\Plug-ins wanneer er wordt gevraagd de gewenste map te kiezen Tot slot, herhaal de controle zoals hierboven is besproken.

5.3 Modelleren in SU

85

Figuur 5.1: Ruby Console

5.2.3

Installatie SketchStruct

Op de bijgevoegde CD-rom bevindt zich een map ‘SketchStruct’ waarin de basisbestanden die vereist zijn voor het prototype zijn opgeslagen. In deze map bevindt zich het SketchStruct.exe bestand. Om het programma te openen, dubbelklik op dit bestand met het icoontje (figuur 5.2).

Figuur 5.2: Icoon SketchStruct

5.3

Modelleren in SU

Opdat de analyse correcte resultaten zou genereren, moet het SU-model zo nauw mogelijk aansluiten bij het berekeningsmodel. Er moet rekening gehouden worden met onderstaande aanbevelingen om in SU te modelleren.

5.3.1

Eenheden

Aangezien de eenheid van de exportbestanden meter is, is het aangeraden om in SU ook in meter te modelleren. Er kan direct in meter worden getekend of de eenheden kunnen

86 later worden aangepast. De eenheden kunnen in SU worden aangepast in het menu ‘Venster’ of ‘Window’ bij het submenu ‘Modeleigenschappen’ of ‘Preferences’. In het dialoogvenster (figuur 5.3) kan er rechts worden gekozen voor ‘Eenheden’ of ‘Units’ onder ‘Lengte Eenheden’ of ‘Length Units’ - ‘Formaat’ of ‘Format’ duid ‘Meter’ of ‘Meters’ aan.

Figuur 5.3: Eenheden

5.3.2

Gebruik van lagen

In SU kan er, zoals in de meeste modelleeromgevingen, met lagen of ‘Layers’ worden gewerkt (figuur 5.4). Het gebruik van lagen komt niet alleen de algemene efficiëntie van het modelleren ten goede, maar helpt ook tijdens het exportproces. Het is aangeraden om volgende lagen te gebruiken: buitenmuren, binnenmuren, vensters, deuren/poorten, vloer (tussen binnenruimte en fundering), plafond (tussen binnenruimtes), dak.


87

Figuur 5.4: Lagen

5.3.3

Modelleren van de geometrie

Momenteel is het zo dat de geometrie steeds in de oorsprong en volgens de positieve x-, y- en z-richting moet worden getekend. Bijkomend moet de langste zijde volgens de rode en de kortste volgens de groene as worden getekend (figuur 5.5).

Figuur 5.5: Modelleren van de geometrie

5.3.4

Modelleren van scheidingsconstructies

Modelleren in SU gebeurt door het tekenen van vlakken. Dit heeft als gevolg dat een constructie, met een bepaalde dikte, door een vlak moet worden weergegeven. Gezien de lage graad van detaillering van het model in de schetsontwerpfase en in SU, moet er bij het modelleren met enkele aandachtspunten rekening worden gehouden.

88 Aangezien een scheidingsconstructie in werkelijkheid een bepaalde dikte heeft en ze in SU als een vlak wordt voorgesteld, kan het vlak zich situeren over de ganse dikte van de scheidingsconstructie (figuur 5.6).

Figuur 5.6: verschillende posities van het vlak ten opzichte van de werkelijke muur

Er zijn vier afspraken hieromtrent:

Vertikale scheidingsconstructies die een grens vormen tussen binnen en buiten, worden als een vlak dat zich aan de buitenkant van de dragende structuur bevindt gemodelleerd (figuur 5.7, rechts).

Vertikale scheidingsconstructies die een grens vormen tussen twee binnenruimtes worden als een vlak dat zich in het midden van de dragende structuur bevindt gemodelleerd (figuur 5.7, links).

Horizontale of schuine scheidingsconstructies die een grens vormen tussen binnen en buiten worden als een vlak dat zich aan de onderkant van de dragende structuur bevindt gemodelleerd (figuur 5.8).

Horizontale scheidingsconstructies die een grens vormen tussen twee binnenruimtes worden als een vlak dat zich bevindt in het midden van de dragende structuur gemodelleerd (figuur 5.9).

Horizontale scheidingsconstructies die een grens vormen tussen binnen en de fundering worden als een vlak dat zich bevindt in het midden van de dragende structuur gemodelleerd (figuur 5.10).


89

Figuur 5.7: modelleren vlakken

Figuur 5.8: vlak dak

Figuur 5.9: vlak plafond

Figuur 5.10: vlak vloer

De volgende figuren illustreren deze afspraken. Figuur 5.11 toont de werkelijke snede, op figuur 5.12 wordt aangeduid welke lijnen in het SU-model ten opzicht van de werkelijke snede moet worden getekend.

90

Figuur 5.11: werkelijke snede

5.4 Exporteren

91

Figuur 5.12: SU-model ten opzichte van de werkelijke snede

5.4

Exporteren

Voor de evaluatie moet het model naar een xml-file worden geëxporteerd. Dit wordt bekomen door in de menubalk onder ‘Invoegtoepassingen’ op EPW-export te klikken. Het venster dat nu verschijnt, bestaat uit twee delen (figuur 5.13). Links staan zes knoppen die elke een specifieke taak uitvoeren. Rechts staat een boomstructuur die de structuur van het gebouw weergeeft. De knoppen links zijn in drie groepen verdeeld: zones creëren, vlakken toevoegen, export. Verder kan in deze versie worden gedefinieerd of er met ‘Buitenafmetingen’ of ‘Binnenafmetingen’ is getekend. Deze optie is niet relevant bij de analyse van de structuur.

92

Figuur 5.13: EPW-exporter: basisvenster

5.4.1

Zones aanmaken

Aangezien de exportplug-in initieel werd ontwikkeld om xml-bestanden te exporteren voor EPB-analyses [41] is de eerste stap van het exportproces het creëren van zones. Het aanmaken van zones gebeurt met de knop ‘Detecteer nieuwe zones’ in de linkerkolom van het basisvenster. Na deze bewerking verschijnen de vlakken, die bij elke zone horen, in de boomstructuur in het venster aan de rechterkant. Wanneer er op een gedetecteerde zone wordt geklikt, zullen de vlakken die tot deze zone behoren een rode kleur krijgen (figuur 5.14). Wanneer er een vlak wordt aangeklikt, krijgt enkel dat vlak een rode kleur (figuur 5.15). De rode kleur is enkel bedoeld om te helpen bij het opmaken van het exportbestand, het houdt niet in dat de rode vlakken geselecteerd zijn.

5.4 Exporteren

93

Figuur 5.14: zone

Figuur 5.15: vlakken

5.4.2

Constructies aanmaken

De vlakken, bekomen na het creëren van de zones, zijn ongedefinieerd (figuur 5.15). Dit wil zeggen dat ze nog geen eigenschappen hebben meegekregen. Om eigenschappen aan de vlakken te geven, selecteer de vlakken en klik vervolgens op de knop ‘eigenschappen’ (figuur 5.15). Het is nuttig om alle vlakken die dezelfde eigenschappen hebben samen te selecteren om zo in één keer de bewerking uit te voeren. Het eerder aanbevolen gebruik van ‘layers’ kan nu tijdwinst opleveren. In SU is het steeds mogelijk om alle elementen die in dezelfde laag zitten te selecteren. Dit wordt bekomen door eerst alle elementen te selecteren (door middel van de toestencombinatie crtl-A) en vervolgens op ‘bewerken’ - ‘x

94 objecten’ - ’selecteren’ - ‘alles op dezelfde laag’ te klikken. Door op de toets ‘eigenschappen’ te klikken, verschijnt het betreffende venster (figuur 5.16). In dit venster kunnen de verschillende eigenschappen per vlak worden gedefinieerd. Selecteer hiervoor het type van het constructiedeel (muur, vloer, dak ...) en wat de begrenzing is (buitenomgeving, grond ...).

Figuur 5.16: gedefinieerde vlakken

Wanneer de eigenschappen zijn toegewezen, zullen deze in de boomstructuur verschijnen in plaats van de ‘ongedefinieerde vlakken’ (figuur 5.16). Om de eigenschappen van een vlak later aan te passen kan deze bewerking worden herhaald.

5.4.3

Export

Vooraleer er kan worden overgegaan tot het exporteren, is het aangewezen om na te gaan of de eenheden zijn ingesteld in meter. Indien dit niet het geval is, moeten deze worden aangepast (zoals eerder besproken). Klik vervolgens op de toets ‘export’. Vul in het venster het pad waar het bestand moet worden opgeslagen in en de naam van het bestand (figuur 5.17). Wanneer er op ‘opslaan’ wordt geklikt, worden de nodige xml-bestanden gegenereerd.

5.5 SketchStruct

95

Figuur 5.17: exporteren

5.5

SketchStruct

Figuur 5.18: GUI

Bij het opstarten van de applicatie wordt er dadelijk een overzicht van de verschillende functionaliteiten gegeven. Het venster is opgedeeld in een eerste deel (figuur 5.18 (1)) voor

96 de visualisatie, een tweede deel (figuur 5.18 (2)) voor de verschillende invoermogelijkheden en parameters en tenslotte een derde deel (figuur 5.18 (3)) waar de analyseresultaten onder de vorm van tekst en tabellen worden weergegeven. Laad eerst de elements.xml en topo.xml bestanden die eerder uit SU zijn geëxporteerd (figuur 5.19).

Figuur 5.19: Laden van de elements.xml en de topo.xml bestanden

Voer naast deze twee .xml bestanden de doorbuigingslimiet, de houtsoort en de belasting die gekoppeld is aan het type gebouw in (figuur 5.20). De permanente belasting is afhankelijk van het eigengewicht van de vloer- of dakstructuur.

Figuur 5.20: Noodzakelijke parameters

Duw op de ‘play’ -toets om de analyse uit te voeren. (Afhankelijk van de snelheid van de computer, kan deze berekening enkele seconden duren.) Een extra parameter die al voorzien is, hoewel niet noodzakelijk voor de analyse, is de mogelijkheid om de draagrichting te veranderen (figuur 5.21). Door deze parameter na de ‘play’ -toets te plaatsen, wordt aangegeven dat deze parameter niet noodzakelijk is.

5.5 SketchStruct

97

Figuur 5.21: Veranderen van de draagrichting

Figuur 5.22: Optimale oplossing

Na de analyse zal de geoptimaliseerde configuratie, deze met het kleinste volume, worden weergegeven (figuur 5.22) in het visualisatievenster, in de lijst met plausibele oplossingen (de oplossing in het vet) en in het kader met de optimale oplossing. De hoofdbalken worden in het oranje en de tussenbalken in het rood gevisualiseerd. Parallel met het optimum wordt er een lijst met alle plausibele oplossingen bijgehouden (figuur 5.23). Door in deze lijst op een andere configuratie te klikken wordt deze gevisualiseerd.

98 In het visualisatievenster is het steeds mogelijke om te pannen of orbiten. Door op de rechtermuistoets te klikken is het mogelijk om de zoom all functie te gebruiken of om een bepaalde kijkrichting te selecteren.

Figuur 5.23: Lijst met plausibele oplossingen

BESLUIT

99

Hoofdstuk 6 Besluit De maatschappij legt aan de ontwerper steeds stengere eisen op. Hun aansprakelijkheid is bovendien evenredig aan de opgelegde tijdsdruk. Hierdoor is het belangrijk dat architecten vroeg in het ontwerp inzicht krijgen op de invloed van de ingenieursaspecten, de structuur in het bijzonder, van het ontwerp. Hoewel er zeer veel ondersteunende programma’s op de markt is die ontwerpers toelaat om hun ideeën te evalueren, zijn deze programma’s niet inzetbaar in de vroege ontwerpfases. Ze zijn te complex en daardoor tijdrovend tijdens het proces. Gezien de steeds groter wordende focus op de schetsontwerpfase en het relatief eenvoudige gebruik van SU, werden in het verleden al enkele plug-ins voor dit programma ontwikkeld maar deze focussen voornamelijk op de energieprestaties van het gebouw. Wij stelden wel een evolutie vast van structuuranalyse-programma’s in de parametrische context. Zo is er met de ontwikkeling van Karamba voor Grasshopper (Rhinoceros) een krachtig analyseprogramma voorgesteld die de parametrische ontwerper in staat stelt de nodige analyses te voeren. Deze applicatie is echter sterk afhankelijk van de modelleeromgeving en doet geen voorstellen tot optimalisatie. De conclusies uit de analysewaarden moeten dus nog steeds door de architect of ingenieur worden getrokken. Gezien al deze argumenten is er gekozen om een gebruiksvriendelijk prototype structuuranalyse en -optimalisatie voor de schetsontwerpfase te ontwikkelen. In het kader van onderhavige scriptie is er een prototype voor houtstructuren ontwikkeld. Het werken met een dergelijke applicatie moet het mogelijk maken om structuur en parameters toe te passen tijdens het ontwerp, in plaats van de analyse af te wachten na de ontwerpfase. Dit zal het ontwerpproces dus sneller en efficiënter maken alsook de ontwerpkwaliteit ten goede komen omdat de structuur al van in het begin kan worden ge¨ıntegreerd en het ontwerp dus geen drastische veranderingen meer zal moeten ondergaan in de eindfase van het proces. Een bijkomend voordeel van het prototype is dat de ontwerper snel een structuurvoorstel krijgt, zonder hiervoor een ingenieur te moeten raadplegen of zonder hiervoor de uitgebreide kennis op te bouwen voor en tijd te moeten spenderen aan alleenstaande programma’s constructie die het ontwerp eenzijdig analyseren. Het voorgestelde prototype is in zijn opzet geslaagd omdat het mogelijk is het gebouw te analyseren tijdens

100 de schetsontwerpfase. Het biedt tevens voorstellen tot optimalisatie van de structuur aan, zonder een teveel aan handelingen of tijdverlies. Bij het ontwikkelen lag de focus onder andere op het maken van een generisch algoritme en op de middelen om hiertoe te komen. Afhankelijk van de modelleeromgeving kunnen de specifieke klassen en methodes snel en eenvoudig worden aangepast. Met de implementatie van het prototype in Grasshopper is aangetoond dat het algoritme generisch is. Door de ontwerper de mogelijkheid te geven om gebruik te maken van vooraf gedefinieerde standaardgegevens, kunnen de analyses snel worden gemaakt. Naast het generische karakter is er dus ook rekening gehouden met de gebruikssnelheid van het prototype. De resultaten van de analyse worden in het visualisatievenster van de applicatie getoond. Het is echter in SU nog niet mogelijk om de in dit venster de gegevens aan te passen of om de resultaten in de modelleeromgeving te visualiseren.

6.1

Beperkingen en opportuniteiten

Zoals aangegeven in bovenstaande paragraaf dient er enerzijds nog onderzoek te worden gevoerd naar een mogelijkheid om de resultaten van de analyse terug te koppelen naar de modelleeromgeving van SU en anderzijds moet het exporteren van de gegevens uit SU worden geautomatiseerd. Dit onderzoek kan deel uitmaken van een doctoraatstudie naar de inzetbaarheid en mogelijkheid tot uitbreiding van het prototype om een betere integratie van de ingenieursaspecten in het architecturaal ontwerpproces te bekomen. Onderhavige scriptie is dan ook een uitstekende basis om de ontwikkeling van programma’s, die voldoen aan alle noden van de creatieve ontwerper, te ondersteunen. Hierbij aansluitend moet er ook nog onderzoek worden gevoerd naar meer effeciënte optimalisatie methoden dan de exhaustive search methode. Er moeten meerdere parameters tegelijk kunnen worden geoptimaliseerd alsook architecturale. Het voorbereidend onderzoek werd al gevoerd en is terug te vinden in Bijlage C. De tool is zodanig geprogrammeerd dat uitbreidingen gemakkelijk kunnen worden toegevoegd. De volgende mogelijkheden vallen in eerste instantie buiten het bestek van onderhavige scriptie maar tonen aan dat het prototype een degelijk fundament is voor verder onderzoek. Zo zou de ontwerper openingen in de dakconstructie kunnen voorzien voor een traphal of de keuze kunnen maken voor andere materialen als staal of beton. Hij zal de evaluatie kunnen maken na toevoeging van kolommen, muren en funderingen alsook overkragingen en hellende daken. Waar nu een optimalisatie wordt voorzien aan de hand van polygonen moet ook een benadering via triangulatie en dus complexere vormen mogelijk worden. Het toevoegen van esthetische en architecturale parameters kan

6.1 Beperkingen en opportuniteiten

101

zorgen voor een betere wisselwerking tussen de architecturale en ingenieursaspecten binnen het ontwerp. Als laatste moet een terugkoppeling naar de modelleeromgeving of een BIM-omgeving worden onderzocht. Tot slot mag een uitgewerkt programma de gebruiker niet beperken in zijn vrijheid, dit is uiteraard in dit prototype wel het geval.

102

HOUTSOORTEN

103

Bijlage A Houtsoorten

Figuur A.1: Specificaties vurenhout

104

Figuur A.2: Specificaties grenen

HOUTSOORTEN

105

Figuur A.3: Specificaties oregon pine / Europese douglas

Figuur A.4: Specificaties timmerhout

106

FORMULES VOOR DE DOORBUIGING

Bijlage B

Formules voor de doorbuiging

Figuur B.1: Schema formules doorbuiging

107

108

Figuur B.2: Schema formules doorbuiging

ONTWERPMETHODES

109

Bijlage C Ontwerpmethodes C.1

Inleiding

Hoewel een toenemend gebruik van de computer in het ontwerpproces merkbaar is, wordt deze enkel ingezet als een passief hulpmiddel en niet als actief onderdeel van het ontwerpproces. Dorsey stelt: ‘Most of recent developments have failed to tap the potential of the computer as a design tool. Instead, computers have been relegated largely to the status of drafting instruments, so that the ’D’ in CAD stands for drafting rather than design’ [28]. Er zijn verschillende modelleeromgevingen beschikbaar, de ene al geschikter voor een bepaalde fase dan de andere, maar veel meer dan het visualiseren wat de ontwerper tekent doen deze programma’s niet. Desalniettemin heeft de opkomst van de computer een impact gehad op het architecturaal ontwerpproces. De computer stelt de ontwerper in staat om zijn ontwerp snel aan te passen, fotorealistisch weer te geven en om er virtueel doorheen te lopen. In de Solid en Surface modellers is het zelfs mogelijk fysische eigenschappen aan het model te koppelen om zo structurele analyses op het ontwerp uit te voeren. Dit uitgebreide gebruik van de capaciteiten van de computer vindt wel enkel in de late fasen van het ontwerpproces plaats [28]. Om de geschetste problemen aan te pakken, werden in talrijke onderzoeksprojecten de mogelijkheden van computational design en Computational optimization techniques onderzocht. Onderzoekers in dit onderzoeksdomein proberen om het ontwerpproces te begrijpen en om computers in te zetten om de ontwerper te helpen tijdens dit proces. Dit heeft geresulteerd in computational design tools die heel snel een aantal mogelijkheden genereren. Er zijn verschillende methodes mogelijk om aan probleemoplossing te doen: het gebruik van algoritmen die na een eindig aantal stappen een oplossing bereiken, de iteratieve methoden die convergeren naar een oplossing en de heuristieken die bij benadering juiste oplossing genereren. De laatste decennia is een groeiende interesse merkbaar voor de heuristieken, meer bepaald de Evolutionary Algorithms (EA) [35].

110 Dit laatste algoritme is gebaseerd op analogieën met natuurlijke processen en de evolutietheorie van Darwin. De bekendste algoritmes die onder de EA vallen zijn: ‘Evolution Strategies’ (ES) ontwikkeld door Rechenberg [60] en Schwefel [69], ‘Evolutionary Programming’ (EP) ontwikkeld door Fogel [32] en ‘Genetische Algorithms’ (GA) ontwikkeld door Holland [40]. In de ingenieursapplicaties wordt ‘Artificial Intelligence’ (AI) gebruiktals instrument om tijdrovende procedures te vervangen. Het gebruik van ‘Neural Networks’ (NN) is uitvoerig bestudeerd voor de optimalisatie van constructieve structuren [56]. In wat volgt worden de werking, de voor- en nadelen van EA besproken. Voor een meer uitgebreide uiteenzetting van de specifieke algoritmes wordt verwezen naar de literatuur, voor ES: [60], [69], [21], [22] en [23], voor EP: [32] en voor GA [40].

C.2 C.2.1

Evolutionary Algorithms Opbouw

De opbouw is vergelijkbaar voor alle Evolutionary Algorithms en is gebaseerd op biologische principes. Er is steeds een willekeurige populatie die de gehele verzameling van mogelijke oplossingen voorstelt. Elke mogelijke oplossing wordt een individu genoemd. De voorstelling of codering van elk individu is een genoom of chromosoom of genotype. Elk genoom bestaat uit een reeks eigenschappen of genen. De waarde van een gen is een allel [30].

C.2.2

Basisprincipe

Elk proces start met een willekeurige populatie. Bij elke iteratie produceren de verschillende individuen een nakomeling of kind. Elk individu wordt geëvalueerd en krijgt een fitness-waarde, deze graad geeft aan hoe geschikt een bepaald individu is in de gegeven context van het probleem. Op basis van de fitness-waarde worden de individuen gekozen om de volgende generatie te produceren. Wanneer deze volgende generatie geëvalueerd is, wordt de eerste generatie geheel of gedeeltelijk vervangen door de nakomelingen, deze populatie wordt de nieuwe generatie genoemd. Tot slot wordt dit proces opnieuw doorlopen tot het gewenste resultaat, de evolutie, wordt bereikt (figuur C.1). Elk algoritme bezit procedures die zijn gebaseerd op biologische processen. Alle algoritmes zullen in de iteratie een vorm van selectie doorvoeren, enkel de goede oplossingen worden weerhouden. Alleen de selectieprocedure is niet voldoende om de initiële populatie te laten evolueren, want dan blijft de populatie steeds uit dezelfde elementen bestaan, andere technieken zoals recombinatie (crossover) en mutatie moeten ook worden toegepast.

C.2 Evolutionary Algorithms

111

Figuur C.1: Het algemeen schema van EA

C.2.3

Selectieprocedure

De selectieprocedure zorgt ervoor, door enkel de goede oplossingen te selecteren, dat de oplossingenruimte naar een optimum evolueert. Het is op deze selectie dat de volgende populatie wordt gebaseerd. De procedures die hieronder worden besproken zijn deze die het meest worden gebruikt in de algoritmes. (Voor een uitgebreid overzicht zie [5].) De fitness-proportional of roulette wheel is een stochastische selectie. De individuen worden zodanig op een lijnstuk of op een roulettewiel geplaatst dat het segment dat ze beslaan overeenkomt met de grootte van de fitness. Vervolgens wordt een willekeurig getal gegenereerd. Het segment waarbinnen dit getal valt zal bepalen welk individu wordt geselecteerd. Dit proces wordt herhaald tot het gewenste aantal individuen is bekomen [5]. In de tournament selectie wordt een groep van individuen willekeurig geselecteerd en elk individu kan meerdere keren worden geselecteerd. Vervolgens wordt het individu met de hoogste fitness-waarde geselecteerd. Dit proces herhaalt zich tot er een nieuwe populatie is gevormd [5]. De exclusieve selectie, bij deze selectie wordt enkel het beste deel van de populatie geselecteerd [5]. De ranked selectie werkt op basis van de fitness-ranking. Een voorbeeld van de ranked selectie is de linear ranking, de individuen worden eerst gesorteerde in stijgende volgorde volgens hun fitness-waarden. De kans op selectie van elk individu is gebaseerd op zijn rangschikking in de populatie en niet op basis van de effectieve fitness-waarde [80].

112

C.2.4

Reproductie

Recombinatie of crossover is een reproductie-operator die een nieuw reeks kinder vormt door het combineren van genen van de ouders (figuur C.2). One-point crossover is de meest eenvoudige vorm van recombinatie. De chromosomen worden in twee stukken opgedeeld en onderling gewisseld. Andere vormen zijn uniform crossover, shuffle crossover en crossover met reduced surrogate [5].

Figuur C.2: Recombinatie

Mutatie gaat bepaalde delen van de chromosomen van de kinderen willekeurig aanpassen (figuur C.3). Op deze manier blijft de diversiteit gegarandeerd en wordt convergentie naar lokale optima vermeden [31].

Figuur C.3: Mutatie

C.2.5

Werking

Schematische voorstelling van de werking: 1. Initialisatie van de populatie P(0).


113

2. Evaluatie van alle leden van de populatie, geven van een ‘fitness’ -score. While (de ’fitness’ -score niet voldoet of het maximum aantal iteraties niet is bereikt) { 3. Selectie van individuen om ouder te worden op basis van de ‘fitness’ -score. 4. Creatie van nieuwe individuen door recombinatie van de genen van de ouders en mutatie van de genen van de nakomelingen. 5. Evaluatie nakomelingen, geven van een ‘fitness’ -score. 6. Vervangen van alle of enkele ouders door nakomelingen. } Om te beginnen wordt een populatie P(0) ge¨ınitialiseerd. Deze populatie bestaat uit een aantal individuen die willekeurig worden gecreëerd. Elk individu bevat standaard een probleemspecifieke set van ontwerpparameters en bijkomend een set strategie-parameters [39]. Na de initialisatie worden alle leden van de populatie, op basis van hun geschiktheid om een oplossing te bieden voor het probleem, geëvalueerd. Na deze evaluatie krijgen de individuen een fitness-score, hoe hoger deze score des te geschikter het individu is om te worden geselecteerd. De selectie van ouders wordt in de volgende stap omgevormd tot nieuwe individuen, dit gebeurt door recombinatie en mutatie van de genen. Eerst zullen de genen van de ouders onderling worden uitgewisseld door de recombinatie en vervolgens zal het mutatieproces bepaalde genen muteren. Na dit proces worden de nakomelingen geëvalueerd en krijgen ze ook een fitness-score. De laatste stap in de iteratie is de selectieprocedure, de steady-state EA genoemd en de generational EA genoemd [68]. In de steady-state selectie worden de ouders niet weerhouden voor de volgende generatie P(t + 1), in de generational selectie worden de ouders wel weerhouden. Deze procedure blijft itereren tot de oplossing voldoet aan de criteria of het maximum aantal iteraties wordt bereikt [45].

C.2.6

Voor- en nadelen

De populatie moet groot genoeg zijn om tot een oplossing te komen. Inzetbaar voor bijna alle optimalisatieproblemen. Kan high dimensional, multimodal, nonlinear problems subject to linear and/or ” nonlinear constraints” oplossen [47]. Geschikt om in te zetten bij problemen met veel lokale optima. Ze zijn traag. Door het stochastisch karakter van het algoritme zijn er alleen maar ’aanvaardbare’ oplossingen. Er wordt geen absoluut optimum bereikt.

114

C.2.7

Toepassingsvoorbeeld

In wat volgt wordt een reële toepassing beschreven waarbij een GA wordt ingezet om de structuur te optimaliseren. Dit is een ontwerp van ‘wings’ die door middel van kabels aan een balkenstructuur worden bevestigd (figuur C.4). De balkenstructuur heeft een maximale belasting en er is een optimale spreiding van de belastingen gevraagd.

Figuur C.4: Maquette van het ontwerp van Arne Quinze

Hier wordt gebruik gemaakt van de ‘Galapagos evolutionary solver’ gecombineerd met Karamba, beide zijn een plug-in voor Grasshopper, Rhino3d (http://www.rhino3d.com/). De ‘fitness’ -waarde wordt bepaald door de reactiekrachten in de steunpunten. De genomen worden bepaald door de mogelijke posities van de bevestigingspunten van de kabels aan de balken. Het algoritme start met een populatie van bevestigingspunten (figuur C.5). Vervolgens worden door middel van de ‘fitness proportionate selection’ een aantal punten geselecteerd. Door recombinatie en mutatie worden nieuwe oplossingen gecreëerd met gecombineerde eigenschappen van de geselecteerde punten. Dit proces wordt herhaald tot de ‘fitness’ -waarde (hier in het bijzonder minimale reactiekrachten) een aanvaardbare waarde heeft bereikt (figuur C.6).


115

Figuur C.5: Intialisatie van het zoekproces in Galapagos

Figuur C.6: Terminatie van het zoekproces in Galapagos

Op de onderstaande figuur C.7 is duidelijk te zien dat de reactiekrachten ongeveer even groot zijn.

116

Figuur C.7: Resultaat van het zoekproces in Galapagos

BIBLIOGRAFIE

117

Bibliografie [1] Beam deflection formulae. http://www.advancepipeliner.com/Resources/ Others/Beams/Beam_Deflection_Formulae.pdf. [2] Beperking van de maximale doorbuiging. berekeningvanconstructies.be/2_89.htm.

http://www.

[3] Diamonds. http://www.buildsoft.eu/en/product/diamonds. [4] Eurocode 5 - timber. Eurocode=5.

http://www.eurocodes.co.uk/EurocodeDetail.aspx?

[5] Genetic and evolutionary algorithm toolbox for use with matlab. http://www. geatbx.com/docu/docutoc.html#TopOfPage. [6] Hout info bois. http://www.houtinfobois.be/index.php?langue_site=2. [7] Jon peddie research releases the worldwide cad market report 2012. http://jonpeddie.com/press-releases/details/ worldwide-cad-market-report-2012. [8] Pattern language. http://www.enotes.com/topic/Pattern_language. [9] Wireframe models. http://www.cs.mtu.edu/~shene/COURSES/cs3621/NOTES/ model/wireframe.html. [10] Woodforum. http://www.woodforum.be/nl. [11] Woodworks. http://www.woodworks.org/. [12] H. Achten. Ontwerp methoden 7ad02 adms 2005-2006, 2006. [13] A. Ackers, K. Edwards, and N. Roozenburg. Design guidelines support of decision making during the early stages. In Proceedings of the 10th International Conference on Engineering Design (ICED 95), pages 1477–1487, 1995. [14] J. Van Aken. Valid knowledge for the professional design of large and complex design processes, 2005.

118

BIBLIOGRAFIE

[15] C. Alexander, S. Ishikawa, and M. Silverstein. A Pattern Language : Towns, Buildings, Construction (Cess Center for Environmental). Oxford University Press, 1977. [16] D. Aliakseyeu, J B. Martens, and M. Rauterberg. A computer support tool for the early stages of architectural design, 2006. [17] D. Aliakseyeuand and J.B. Martens. Physical paper as the user interface for an architectural design tool. In Proceedings of Interact 2001, pages 680–681, 2001. [18] L. B. Archer. Systematic method for designers. 1965. [19] L.B. Archer. Design as a discipline. Design Studies, 1(1):17–20, 1979. [20] M. Asimow. Introduction to Design. Englewood Cliffs, 1962. [21] T. Back. Evolutionary algorithms in theory and practice. Oxford University Press. [22] T. Back and H.-P. Schwefel. Evolution strategies i: variants and their computational implementation. Genetic algorithms in engineering and computer science, pages 111– 126, 1995. [23] T. Back and H.-P. Schwefel. Evolution strategies ii: theoretical aspects. Genetic algorithms in engineering and computer science, pages 127–140, 1995. [24] A. Brown and F. Horton. Computer aids for design development. Computer in Architecture, Tools for Design, pages 15–24, 1992. [25] R. Chudley and R. Greeno. Heinemann, 2008.

Building Construction Handbook.

Butterworth-

[26] R. Clune, J. J. Connor, J. A. Ochsendorf, and D. Kelliher. An object-oriented architecture for extensible structural design software. Computers and Structures, 86(100–101):1–17, year = 2012, publisher = Elsevier,. [27] N. Cross. Developments in Design Methodology. John Wiley and Sons Ltd., 1984. [28] J. Dorsey and L. McMillan. Computer graphics and architecture: state of the art and outlook for the future. SIGGRAPH Comput. Graph., 32(1):45–48, February 1998. [29] C. Eastman, Jea min Lee, Yeon suk Jeong, and Jin kook Lee. Automatic rule-based chacking of builing designs, 2009. [30] A.E. Eiben and J.E. Smith. Introduction to Evolutionary Computing. Springer, 2003. [31] E. Fasoulaki. In Genetic algorithms in architecture: a necessity or a trend, 2007. [32] L.J. Fogel, A.J. Owens, and M.J. Walsh. Artificial intelligence through simulated evolution. Wiley, 1966.

BIBLIOGRAFIE

119

[33] European Committee for Standardization. Eurocode 5 Part 1,1. BSI, 1995. [34] European Committee for Standardization. Eurocode 5 Part 1,2. BSI, 2001. [35] J. Frazer. An evolutionary architecture. Architectural Association, 1995. [36] E. Goormachtigh, R. Van Caimere, K. Vancroonenburg, and L. Van den Bossche. Ontwerpmethodologie voor lage energiewoningen aan de hand van software tools, 2008. [37] W. J. J. Gordon. Synectics, the Development of Creative Capacity. Harper. [38] C. Gray, W. Hughes, and J. Bennett. The Successful Management of Design: a Handbook of Building Design Management. Centre for Strategic Studies in Construction. [39] O. Hasan¸cebi. Adaptive evolution strategies in structural optimization: Enhancing their computational performance with applications to large-scale structures. Computers and Structures, 86(1–2):119–132, January 2008. [40] J.H. Holland. Adaptation in natural and artificial systems. The University of Michigan Press, 1975. [41] T. Jonckheere. Onderzoek naar de inzetbaarheid van parametrische ontwerpstrategieën, 2009. [42] T. Jonckheere, R.Verstraeten, P. Pauwels, and R. De Meyer. Ontwikkeling van een google sketchup-plugin als ontwerpinstrument voor een energiezuinige architectuur. In IBPSA-NVL 2010 event : Simulatie voor energie-efficiénte of energieproducerende gebouwde omgeving, 2010. [43] J.C. Jones. Design Methods: seeds of human futures. John Wiley and Sons, 1970. [44] X. De Kestelier. Lecture: Computational architecture., 2010. [45] R. Kicinger, T. Arciszewski, and K. De Jong. Evolutionary computation and structural design: A survey of the state-of-the-art. Computers and Structures, 83:1943–1978, 2005. [46] S. Krish. A practical generative design method. Computer-Aided Design, 43(1):88– 100, January 2011. [47] F. Kursawe. Evolution strategies: Simple models of natural processes? In Revue Internationale de Systëmique, 1994. [48] W. Kymmell. Building Information Modeling: Planning and Managing Construction Projects with 4D CAD and Simulations. McGraw-Hill Companies, Inc., 2008.

120

BIBLIOGRAFIE

[49] B. Lawson. How Designers Think: The Design Process Demystified). Architectural, 1980. [50] B. Lawson. ’fake’ and ’real’ creativity using computer aided design: Some lessons from herman hertzberger. In In Proceedings of Creativity&Cognition’99, pages 174– 180, 1999. [51] P. Van Loon. Inter Organisational Design. Delft University Press, 1998. [52] Mirza and Nacey Research. Architects CAD survey 99. The Fees Bureau. [53] G. M. Mocko and S. J. Fenves. A survey of design-analysis integration issues. 2012. [54] Office of Information Technology (OIT). GUI Programming Standards and Conventions. Division of Information Resource Management, 2010. [55] A. F. Osborn. Applied Imagination: Principles and Procedures of Creative Thinking. Scribner. [56] M. Papadrakakis, N. D. Lagaros, Y. Tsompanakis, and V. Plevris. Large scale structural optimization: Computational methods and optimization algorithms. Archives of Computational Methods in Engineering, 8(3):239–301, 2001. [57] P. Pauwels, R. De Meyer, and J. Van Campenhout. Interoperability for the design and construction industry through semantic web technology. In Proceedings of the 5th International Conference on Semantic and Digital Media Technologies, 2010. [58] S. Pranovich. Structural Sketcher: A Tool for Supporting Architects in Early Design. Eindhoven University Press, 2004. [59] Preisinger. Parametric structural modeling user manual for version 0.9.083, 2012. [60] I. Rechenberg. Evolutionsstrategie: optimierung technischer systeme nach prinzipien der biologischen evolution. Frommann-Holzboog, 1973. [61] W. R. Reitman, M. W. Shelly, and G. L. Bryan. Heuristic decision procedures, open constraints, and the structure of ill-defined problems, pages 282–315. John Wiley and Sons, 1964. [62] H. Rittel and M. Webber. Planning problems are wicked problems. (originally published as part of ’dillemmas in a general theory of planning’). Policy Science 4, pages 155–169, 1973. [63] H.W.J. Rittel and M.M. Webber. Dilemmas in a general theory of planning. Policy Sciences, 4:155–169, 1973.

BIBLIOGRAFIE

121

[64] N. Roozenburg and J. Eekels. Produktontwerpen, structuur en methoden [Product design, structure and methods]. Lemma B.V., 1991. [65] N. Roozenburg and J. Eekels. Product Design, Fundamentals and Methods. Wiley, 1995. [66] G. P. Rowe. Design Thinking. Mit Press. [67] H. De Schepper. Meetkunde, 2007. [68] H.-P. Schwefel. Numerical optimization of computer models. Wiley. [69] H.-P. Schwefel. Kybernetische evolution als strategie der experimentellen forschung in der strömungstechnik. Diplomarbeit Technische Universität, 1965. [70] C.-K. Shene. Course: Introduction to computing with geometry notes, 2011. [71] H. A. Simon. The Sciences of the Artificial. Mit Press. [72] SmartMarket. The Business Value of BIM in North America (2009). McGraw Hill Construction, 2009. [73] M. Stefaner, E. Dalla Vecchia, M. Condotta, M. Wolpers, M. Specht, M. Apelt, and E. Duval. Mace : Enriching architectural learning objects for experience multiplicatio. In Proceedings of 2nd European Conference on Technology Enhanced Learning EC-TEL, pages 322–336, 2007. [74] T. Strobbe. Onderzoek naar de inzetbaarheid van parametrische ontwerpstrategieën, 2011. [75] G. Thierauf and J. Cai. Parallel evolution strategy for solving structural optimization. Engineering Structures, 19(4):318–324, 1997. [76] B. Tversky. What does drawing reveal about thinking. Proc. Visual and spatial reasoning in design, 1999. [77] T. van der Voordt and H. van Wegen. Architecture in use, an introduction to the programming, design and evaluation of buildings. Architectural press, 2005. [78] R. Winston. Managing the development of large software systems. In Proceedings of IEEE WESCON 26, pages 1–9, 1970. [79] R. Woodburry. Elements of Parametric Design. Routledge, 2010. [80] B.-T. Zhang and J.-J. Kim. Comparison of selection methods for evolutionary optimization. Evolutionary Optimization, 2(1):55–70, 2000.

122

BIBLIOGRAFIE

LIJST VAN FIGUREN

123

Lijst van figuren 2.1 2.2 2.3 2.4 2.5 2.6 2.7

De basis ontwerpcyclus van Roozenburg en Eekels . . . . . . . . . . . . . Watervalmodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Asimow ontwerpcyclus . . . . . . . . . . . . . . . . . . . . . . . . . . . . invloed en detail in functie van de tijd [58] . . . . . . . . . . . . . . . . . Links is het dubbelzinnige wireframe, rechts is ondubbelzinnig [9] . . . . Muur opgebouwd door één vlak, SU [48] . . . . . . . . . . . . . . . . . . Links: Muur opgebouwd door meerdere vlakken in SU, Rechts: Snede door de muur opgebouwd door meerdere vlakken in SU [48] . . . . . . . . . . 2.8 Spline met controlepunten in Rhinoceros . . . . . . . . . . . . . . . . . . 2.9 Booleaanse transformatie: subtract, intersect en union . . . . . . . . . . 2.10 CSG tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.11 Structuur van een B-rep model . . . . . . . . . . . . . . . . . . . . . . . 2.12 Links snede door volle muur in ArchiCAD, Rechts: snede door muur opgebouwd door aparte elementen, ArchiCAD [48] . . . . . . . . . . . . . .

. 7 . 8 . 9 . 16 . 17 . 18

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17

. . . . . . . . . . . . . . . . .

GUI van Finnwood . . . . . . . . . . . . . . . . . . . . Gegevens geometrie van Finnwood . . . . . . . . . . . Standaardbelastingen in Finnwood . . . . . . . . . . . Analyse in Finnwood . . . . . . . . . . . . . . . . . . . Resultaat analyse van Finnwood . . . . . . . . . . . . . GUI van Grasshopper . . . . . . . . . . . . . . . . . . . Invoer in Grasshopper . . . . . . . . . . . . . . . . . . Analyse in Grasshopper . . . . . . . . . . . . . . . . . Doorbuiging in Grasshopper . . . . . . . . . . . . . . . Output van Grasshopper . . . . . . . . . . . . . . . . . Doorbuiging, eindige-elementenmethode in Grasshopper GUI van GC . . . . . . . . . . . . . . . . . . . . . . . . GNodes en GMembers in GC . . . . . . . . . . . . . . StructuralAnalysisEngine-component van GC . . . . . Visualiseren resultaat in GC . . . . . . . . . . . . . . . resultaat van GC . . . . . . . . . . . . . . . . . . . . . GUI van BuildSoft . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . .

18 19 20 20 21

. 21 24 25 26 27 27 29 30 31 31 32 32 34 35 35 36 36 38

124

LIJST VAN FIGUREN

3.18 3.19 3.20 3.21 3.22 3.23 3.24 3.25 3.26 3.27 3.28 3.29 3.30 3.31 3.32 3.33 3.34 3.35 3.36 3.37

Invoeren steunpunten in BuildSoft . . . . . . . . . . Selecteren profiel in BuildSoft . . . . . . . . . . . . Coëfficiënten en combinatiefactoren in BuildSoft . . Analyse in BuildSoft . . . . . . . . . . . . . . . . . Resultaat van BuildSoft . . . . . . . . . . . . . . . GUI van Risa Technologies . . . . . . . . . . . . . . Steunpunten in Risa Technologies . . . . . . . . . . Belastingcombinaties in Risa Technologies . . . . . tutorial van Risa Technologies . . . . . . . . . . . . GUI van Robot . . . . . . . . . . . . . . . . . . . . Balken plaatsen in Robot . . . . . . . . . . . . . . . Sectie bepalen in Robot . . . . . . . . . . . . . . . Steunpunten in Robot . . . . . . . . . . . . . . . . Belastingen in Robot . . . . . . . . . . . . . . . . . Analyse en resultaat van Robot . . . . . . . . . . . GUI van MasterSeries . . . . . . . . . . . . . . . . Balken ingeven in MasterSeries . . . . . . . . . . . Steunpunten in MasterSeries . . . . . . . . . . . . . uniforme belastingen of puntlasten in MasterSeries . Resultaten van MasterSeries . . . . . . . . . . . . .

4.1

Prototype, het rode kader geeft aan wat door het prototype moet worden uitgevoerd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proces dat doorlopen wordt . . . . . . . . . . . . . . . . . . . . . . . . . Conceptschema Export plug-in . . . . . . . . . . . . . . . . . . . . . . . elements.xml (links) en topo.xml (rechts) . . . . . . . . . . . . . . . . . . Belastingssituatie: uniform belaste balk op twee steunpunten zonder overkraging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Laden elements.xml en topo.xml bestanden . . . . . . . . . . . . . . . . . Noodzakelijke analyse parameters . . . . . . . . . . . . . . . . . . . . . . wisselen van de draagrichting . . . . . . . . . . . . . . . . . . . . . . . . Schema doorbuiging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schema doorbuiging in het geval van de uniform belaste balk op twee steunpunten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Visualisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verschillende onderdelen . . . . . . . . . . . . . . . . . . . . . . . . . . . Klassendiagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Visualisatie in Rhinoceros . . . . . . . . . . . . . . . . . . . . . . . . . . Implementatie in Grasshopper . . . . . . . . . . . . . . . . . . . . . . . . Implementatie in Grasshopper, onderdeel invoer data . . . . . . . . . . .

4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

39 39 40 41 41 42 43 44 45 47 47 48 48 49 49 51 51 52 52 53

. . . .

61 62 64 64

. . . . .

65 66 66 67 67

. . . . . . . .

68 69 70 70 71 76 76 77

LIJST VAN FIGUREN

125

4.18 4.19 4.20 4.21

Implementatie Implementatie Implementatie Implementatie

in in in in

Grasshopper, Grasshopper, Grasshopper, Grasshopper,

onderdeel verwerking geometrische data onderdeel evaluatie en optimalisatie . . selectie van alternatieven . . . . . . . . GUI . . . . . . . . . . . . . . . . . . . .

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18 5.19 5.20 5.21 5.22 5.23

Ruby Console . . . . . . . . . . . . . . . . . . . . . . Icoon SketchStruct . . . . . . . . . . . . . . . . . . . Eenheden . . . . . . . . . . . . . . . . . . . . . . . . Lagen . . . . . . . . . . . . . . . . . . . . . . . . . . Modelleren van de geometrie . . . . . . . . . . . . . . verschillende posities van het vlak ten opzichte van de modelleren vlakken . . . . . . . . . . . . . . . . . . . vlak dak . . . . . . . . . . . . . . . . . . . . . . . . . vlak plafond . . . . . . . . . . . . . . . . . . . . . . . vlak vloer . . . . . . . . . . . . . . . . . . . . . . . . werkelijke snede . . . . . . . . . . . . . . . . . . . . . SU-model ten opzichte van de werkelijke snede . . . . EPW-exporter: basisvenster . . . . . . . . . . . . . . zone . . . . . . . . . . . . . . . . . . . . . . . . . . . vlakken . . . . . . . . . . . . . . . . . . . . . . . . . gedefinieerde vlakken . . . . . . . . . . . . . . . . . . exporteren . . . . . . . . . . . . . . . . . . . . . . . . GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . Laden van de elements.xml en de topo.xml bestanden Noodzakelijke parameters . . . . . . . . . . . . . . . Veranderen van de draagrichting . . . . . . . . . . . . Optimale oplossing . . . . . . . . . . . . . . . . . . . Lijst met plausibele oplossingen . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . werkelijke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.1 A.2 A.3 A.4

Specificaties Specificaties Specificaties Specificaties

. . . .

vurenhout . . . . . . . grenen . . . . . . . . . oregon pine / Europese timmerhout . . . . . .

. . . . . . . . . . douglas . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

78 79 80 81

. . . . . . . . . . . . . . . . . . . . muur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

85 85 86 87 87 88 89 89 89 89 90 91 92 93 93 94 95 95 96 96 97 97 98

. . . .

. . . .

. . . .

103 104 105 105

. . . .

. . . .

. . . .

B.1 Schema formules doorbuiging . . . . . . . . . . . . . . . . . . . . . . . . . 107 B.2 Schema formules doorbuiging . . . . . . . . . . . . . . . . . . . . . . . . . 108 C.1 C.2 C.3 C.4 C.5

Het algemeen schema van EA . . . . . . . . Recombinatie . . . . . . . . . . . . . . . . . Mutatie . . . . . . . . . . . . . . . . . . . . Maquette van het ontwerp van Arne Quinze Intialisatie van het zoekproces in Galapagos

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

111 112 112 114 115

126

LIJST VAN FIGUREN

C.6 Terminatie van het zoekproces in Galapagos . . . . . . . . . . . . . . . . . 115 C.7 Resultaat van het zoekproces in Galapagos . . . . . . . . . . . . . . . . . . 116

LIJST VAN TABELLEN

127

Lijst van tabellen 2.1

Lineaire benaderingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9

Evaluatie Finnwood . . . . . . Evaluatie Karamba . . . . . . Evaluatie OpenStaad . . . . . Evaluatie PowerFrame . . . . Evaluatie Risa 3D . . . . . . . Evaluatie Robot . . . . . . . . Evaluatie MasterSeries . . . . Structuuranalyse-programma’s Structuuranalyse-programma’s

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

24 28 33 37 42 46 50 55 56





EEN PROTOTYPE VAN SOFTWARE TOOL VOOR DE ANALYSE VAN GEBOUWSTRUCTUREN

Recommend Documents