Naar een 'architect'-vriendelijke evaluatie van EPB en zomercomfort. by Kenny Geyskens

NAAR EEN ‘ARCHITECT’-VRIENDELIJKE EVALUATIE VAN EPB EN ZOMERCOMFORT: INTEGRATIE TUSSEN GOOGLE SKETCHUP EN MICROSOFT EXCEL

PROMOTOR: CO-PROMOTOREN:

MARC KNAPEN LIEVE WEYTJENS VINCENT MACRIS

KENNY GEYSKENS MASTER ARCHITECTUUR 2010-2012 PHL - DPT. ARCHITECTURE

Veel van de termen die door fabrikanten en verkopers worden gebruikt om hun producten te onderscheiden worden geclaimd als handelsmerk. SketchUp en Gmail zijn geregistreerde handelsmerken van Google. Windows, Microsoft Excel, Internet Explorer, Microsoft Powerpoint, Microsoft Kladblok en Visual Basic zijn geregistreerde handelsmerken van Microsoft. Mac en Mac OS zijn geregistreerde handelsmerken van Apple. EPB software Vlaanderen is een handelsmerk van Decysis. Java en JavaScript zijn handelsmerken van Sun Microsystems. IES VE is een handelsmerk van Integrated Environmental Solutions. Adobe Flash is een geregistreerd handelsmerk van Adobe Systems.

D ANKWOORD Dit werk kon slechts tot stand komen dankzij de hulp en steun van vele mensen. Als eerste wil ik Marc Knapen, Lieve Weytjens en Vincent Macris bedanken voor hun begeleiding, sturing en het grondig nalezen van deze thesistekst. Zonder hun wekelijks engagement was dit werk niet mogelijk. Daarnaast bedank ik graag Frank Vangeirt voor het gesprek waarin de eerste ideeĂŤn voor de uitwerking van de plug-in zijn ontstaan. Ik wil ook Jos Vandamme bedanken voor zijn hulp bij het realiseren van de enquĂŞte. Hiermee werd de basis van de plug-in gelegd. Graag zou ik ook Reinhart Viane en Koenraad Nys bedanken voor het wijzen op bruikbare bronnen, vooral in de aanvangfase van dit werk. Verder zou ik graag bedanken: Mijn klasgenoten voor hun bijzondere interesse en motivatie. Mathieu Lenaerts voor suggesties en het nalezen van dit werk. Mijn ouders, mijn vriendin en haar ouders voor hun steun, motivatie en interesse.

I NHOUD 1_

SAMENVATTING ...........................................................................................................................11

INLEIDING ....................................................................................................................................13

2.1_

Context + probleemstelling ............................................................................................................... 13

2.2_

Onderzoeksvraag .............................................................................................................................. 13

2.3_

Methodologie..................................................................................................................................... 13

VOORONDERZOEK.........................................................................................................................15

3.1_

Inleiding ............................................................................................................................................ 15

3.2_ Analyse van soortgelijke plug-ins ..................................................................................................... 15 3.2.1_ SuFiQuaD ................................................................................................................................................................ 15 3.2.1.1_ Algemeen ........................................................................................................................................................... 15 3.2.1.2_ Modelleereisen ................................................................................................................................................. 15 3.2.1.3_ Input van gegevens ......................................................................................................................................... 15 3.2.1.4_ Berekeningswijze .............................................................................................................................................. 16 3.2.1.5_ Output van gegevens en resultaten ............................................................................................................. 16 3.2.2_ IES VE ....................................................................................................................................................................... 16 3.2.2.1_ Algemeen ........................................................................................................................................................... 16 3.2.2.2_ Modelleereisen ................................................................................................................................................. 16 3.2.2.3_ Input van gegevens ......................................................................................................................................... 16 3.2.2.4_ Berekeningswijze .............................................................................................................................................. 16 3.2.2.5_ Output van gegevens en resultaten ............................................................................................................. 16 3.2.3_ EPSketch .................................................................................................................................................................. 17 3.2.3.1_ Algemeen ........................................................................................................................................................... 17 3.2.3.2_ Modelleereisen ................................................................................................................................................. 17 3.2.3.3_ Input van gegevens ......................................................................................................................................... 17 3.2.3.4_ Berekeningswijze .............................................................................................................................................. 17 3.2.3.5_ Tonen van gegevens en resultaten ............................................................................................................... 17 3.2.4_ SmartLab SketchUp Plugin .................................................................................................................................. 17 3.2.4.1_ Algemeen ........................................................................................................................................................... 17 3.2.4.2_ Modelleereisen ................................................................................................................................................. 17 3.2.4.3_ Input van gegevens ......................................................................................................................................... 18 3.2.4.4_ Berekeningswijze .............................................................................................................................................. 18 3.2.4.5_ Tonen van gegevens en resultaten ............................................................................................................... 18 3.3_ EnquĂŞte .............................................................................................................................................. 19 3.3.1_ Opzet....................................................................................................................................................................... 19 3.3.2_ Resultaten................................................................................................................................................................ 19 3.3.2.1_ Aantal gebruikers per besturingssysteem................................................................................................... 19 3.3.2.2_ Modelleermethodes doorheen verschillende ontwerpfases ................................................................... 20 3.3.2.3_ Algemeen gebruik ........................................................................................................................................... 23 3.3.3_ Implicaties ............................................................................................................................................................... 24 3.4_ Starten met het ontwikkelen van een plug-in voor Google SketchUp................................................. 25 3.4.1_ Ruby ......................................................................................................................................................................... 25 3.4.1.1_ Inleiding .............................................................................................................................................................. 25 3.4.1.2_ Scripts schrijven ................................................................................................................................................. 26 3.4.1.3_ Installatie van Google SketchUp plug-ins .................................................................................................. 26 3.4.2_ Bronnen .................................................................................................................................................................... 27 3.4.2.1_ Literatuur ............................................................................................................................................................ 27 3.4.2.2_ Het web.............................................................................................................................................................. 27 3.4.2.3_ Eigen interesse .................................................................................................................................................. 27

3.4.2.4_

Soortgelijke plug-ins ........................................................................................................................................ 28

ONTWIKKELING VAN DE PLUG-IN VOOR ANALYSE VAN EPB EN ZOMERCOMFORT ............................29

4.1_

Inleiding ............................................................................................................................................ 29

4.2_ Benodigde gegevens voor een evaluatie van EPB en zomercomfort.................................................. 29 4.2.1_ Geometrische gegevens ...................................................................................................................................... 29 4.2.2_ aan geometrie gekoppelde gegevens ............................................................................................................ 29 4.2.3_ bijkomende gegevens .......................................................................................................................................... 29 4.3_ Analyse van de binnenruimtes .......................................................................................................... 29 4.3.1_ Methode .................................................................................................................................................................. 30 4.3.2_ User Interface voor het bepalen van de binnenruimtes ............................................................................... 31 4.3.2.1_ Een User Interface d.m.v. Adobe Flash ....................................................................................................... 31 4.3.2.2_ Een User Interface d.m.v. Microsoft Excel ................................................................................................... 32 4.3.2.3_ Een User Interface getekend door Google SketchUp zelf ..................................................................... 35 4.4_ Analyse van de constructie-elementen .............................................................................................. 37 4.4.1_ Methode .................................................................................................................................................................. 37 4.4.2_ User Interface voor het niet gelijktijdig tonen van verschillende constructie-elementen ....................... 40 4.5_ Oriëntatie volgens de EPB.................................................................................................................. 41 4.5.1_ Bepalen van de oriëntatie van een vlak.......................................................................................................... 41 4.5.2_ Omvormen tot de oriëntatie volgens de EPB .................................................................................................. 47 4.5.3_ Solar North-tool..................................................................................................................................................... 47 4.6_ Opbouwen- en materialenbibliotheek ............................................................................................... 49 4.6.1_ Methode .................................................................................................................................................................. 49 4.6.2_ REXML: Ruby’s behandeling van XML-bestanden .......................................................................................... 50 4.6.3_ Toekennen van gedefinieerde opbouwen aan constructie-elementen ...................................................... 51 4.7_ Projectgegevens................................................................................................................................. 52 4.7.1_ Methode .................................................................................................................................................................. 52 4.8_ Berekenen en tonen van de resultaten ............................................................................................... 53 4.8.1_ Koppeling met Microsoft Excel........................................................................................................................... 53 4.8.1.1_ Een bestaand Excel-bestand op de achtergrond openen ...................................................................... 53 4.8.1.2_ Verzenden en ontvangen van data ............................................................................................................. 54 4.8.2_ Opstellen van de naar Excel te verzenden data .......................................................................................... 55 4.8.2.1_ Algemeen ........................................................................................................................................................... 55 4.8.2.2_ EPB....................................................................................................................................................................... 56 4.8.2.3_ Zomercomfort .................................................................................................................................................... 59 4.8.3_ Tonen van de resultaten aan de gebruiker ..................................................................................................... 62 4.8.3.1_ EPB....................................................................................................................................................................... 62 4.8.3.2_ Zomercomfort .................................................................................................................................................... 62 4.9_ Definitieve vormgeving van pop-up User Interfaces .......................................................................... 63 4.9.1_ jQuery...................................................................................................................................................................... 63 4.9.2_ ThemeRoller ............................................................................................................................................................ 63

VALIDATIE VAN DE PLUG-IN..........................................................................................................65

5.1_ Het validatiemodel ............................................................................................................................ 65 5.1.1_ Het validatiemodel in Google SketchUp ......................................................................................................... 65 5.1.2_ Het validatiemodel in EPB software Vlaanderen .......................................................................................... 67 5.2_ Validatieprocedure ............................................................................................................................ 68 5.2.1_ Een eerste eenvoudige validatie ....................................................................................................................... 68 5.2.2_ Een zelf aangemaakte opbouw in de opbouwenen materialenbibliotheek ......................................... 74 5.2.3_ Een ander ventilatiesysteem ............................................................................................................................... 79

5.2.4_

Een andere constructiewijze ................................................................................................................................ 81

5.3_

Besluit ................................................................................................................................................ 82

BEPERKINGEN VAN DE PLUG-IN ....................................................................................................83

6.1_ Gebruiksvriendelijkheid ..................................................................................................................... 83 6.1.1_ Modelleereisen ...................................................................................................................................................... 83 6.1.1.1_ De modelleerdikte van constructie-elementen is niet vrij: ....................................................................... 83 6.1.1.2_ Verschillende constructie-elementen moeten als een aparte groep worden gemodeleerd: ........... 83 6.1.2_ Tonen van de gegevens aan de gebruiker ..................................................................................................... 83 6.1.3_ Implementeren van Exceptions ........................................................................................................................... 83 6.1.4_ Complexiteit van het ontwerp ............................................................................................................................ 83 6.2_ Bugs................................................................................................................................................... 85 6.2.1_ Oneindige loop bij de analyse van de binnenruimtes .................................................................................. 85 6.2.2_ Falen van de aanraakdetectie .......................................................................................................................... 85 6.3_ Toekomstig onderzoek ....................................................................................................................... 85 6.3.1_ Aan geometrie gekoppelde gegevens ............................................................................................................ 85 6.3.1.1_ halfopen en gesloten bebouwing ................................................................................................................. 85 6.3.1.2_ Aangrenzende onverwarmde ruimte ........................................................................................................... 85 6.3.2_ Projectgegevens .................................................................................................................................................... 85 6.3.2.1_ Opslaan van voorgedefinieerde projectgegevens .................................................................................. 85 6.3.3_ Verschillende evaluaties met elkaar vergelijken ........................................................................................... 86 6.3.4_ Bibliotheek uitbreidingen ..................................................................................................................................... 86 6.3.4.1_ Algemeen ........................................................................................................................................................... 86 6.3.4.2_ Vloeropbouwen ................................................................................................................................................ 86 6.3.4.3_ Beglazing ........................................................................................................................................................... 86 6.3.4.4_ Importeren en exporteren van materialen en opbouwen ....................................................................... 87 6.3.4.5_ Aanpassen van door de gebruiker bepaalde opbouwen ...................................................................... 87 6.3.5_ Complexe modellen .............................................................................................................................................. 87 6.3.6_ Het vlakkenmodel ................................................................................................................................................. 87

HANDLEIDING ..............................................................................................................................89

7.1_

Minimum systeemvereisten ............................................................................................................... 89

7.2_ Workflow ........................................................................................................................................... 89 7.2.1_ Installatie ................................................................................................................................................................. 89 7.2.2_ Modelleereisen ...................................................................................................................................................... 89 7.2.3_ Tools van de plug-in ............................................................................................................................................. 89 7.2.3.1_ Algemeen ........................................................................................................................................................... 89 7.2.3.2_ Projectgegevens -tool ..................................................................................................................................... 90 7.2.3.3_ Ruimtes-tool ....................................................................................................................................................... 90 7.2.3.4_ Constructies-tool ............................................................................................................................................... 90 7.2.3.5_ resultaten-tool ................................................................................................................................................... 90 7.2.3.6_ materialen- en opbouwenbibliotheek-tool ................................................................................................. 91 7.3_

Videohandleiding: ............................................................................................................................. 91

REFERENTIELIJST ..........................................................................................................................93

8.1_

Literatuur ........................................................................................................................................... 93

8.2_

Elektronische documenten ................................................................................................................. 93

8.3_

Internet .............................................................................................................................................. 93

8.4_

Afbeeldingen ..................................................................................................................................... 95

1_ SAMENVATTING De normen betreffende de energieprestatie en het binnenklimaat (EPB) van een gebouw worden steeds strenger. Hierdoor is het belangrijk dat architecten reeds vroeg in het ontwerp inzicht krijgen op de prestatie van hun ontwerp. Hoewel de EPB software Vlaanderen1 architecten toelaat om de energieprestatie van een gebouw te evalueren, is deze tool niet bruikbaar in de vroege ontwerpfase. Dit softwarepakket is te complex en tijdrovend in gebruik. Alternatieven zijn beschikbaar. Gezien de focus op de vroege ontwerpfase en het relatief eenvoudige gebruik van Google SketchUp, werden in het verleden al enkele plug-ins voor Google SketchUp ontwikkeld die de energieprestatie en het binnenklimaat (EPB) kunnen analyseren. Deze plug-ins blijken soms onvoldoende rekening te houden met gebruiksvriendelijkheid. Ook maken zij vaak gebruik van een derde software voor de daadwerkelijke analyse. Er werd dan ook gestart met het ontwikkelen van een eigen zelfstandige plug-in waarin gebruiksvriendelijkheid en eenvoud centraal staan. Uit onderzoek blijken architecten per ontwerpfase een verschillende modelleerwijze te hanteren. Tijdens de conceptuele ontwerpfase modelleren zij a.d.h.v. een vlakkenmodel waarin enkel het gebouwvolume wordt gedefinieerd. In de voorontwerpfase daarentegen prefereren zij een modelleermethode waarbij de verschillende constructie-elementen in dikte worden gemodelleerd. Ook worden doorheen deze ontwerpfase de verschillende bouwlagen en binnenruimtes bepaald. Op basis van deze resultaten werden de eerste fundamenten van de plug-in bepaald waarop de verdere ontwikkeling is gebaseerd, namelijk het ontwikkelen van een plug-in waarbij de gebruiker de verschillende constructie-elementen in dikte modelleert. Gezien de focus op gebruiksvriendelijkheid werd ook een onderzoek gedaan naar verschillende User Interfaces. Na verschillende vormen te hebben uitgeprobeerd werd een combinatie bekomen van pop-up User Interfaces enerzijds en een User Interface getekend door SketchUp anderzijds. Hierdoor werd de visuele referentie tussen het SketchUp model en de functionaliteiten van de plug-in geoptimaliseerd. Daarnaast werd ook rekening gehouden met snelheid. Door de gebruiker de mogelijkheid te bieden om gebruik te maken van enkele vooraf gedefinieerde standaardgegevens, kan reeds zeer snel een eerste analyse van de energieprestatie en het binnenklimaat worden gemaakt. De resultaten van deze analyse worden meteen in het SketchUp-venster getoond, zonder de verplichting een derde software te openen. Naast eenvoud en gebruiksvriendelijkheid werd uiteraard ook belang gehecht aan functionaliteit. Het spreekt voor zich dat de resultaten die worden getoond aan de gebruiker ook correct moeten zijn. De resultaten die uit de plug-in voortkwamen werden d.m.v. een validatieprocedure getoetst aan de officiĂŤle EPB software. Hoewel een eenvoudig model deze validatieprocedure onderging, zijn alle bekomen resultaten volledig correct. Uiteraard is verder onderzoek nodig voor het optimaliseren van de plugin.

http://www.energiesparen.be

2_ INLEIDING 2.1_ C ONTEXT + PROBLEEMSTELLING Sinds de invoering van de energieprestatieregelgeving raken steeds meer architecten vertrouwd met de evaluatie van het energiegebruik en binnenklimaat van een gebouw. De EPB software Vlaanderen laat architecten toe om de energieprestatie van een gebouw te evalueren. Dit is een softwarepakket dat gratis door de Vlaamse Overheid ter beschikking wordt gesteld in het kader van de regelgeving. Het is verplicht deze officiële applicatie te gebruiken bij de EPB-aangifte. Hoewel de belangrijkste parameters met impact op energieprestatie en binnenklimaat (oriëntatie, volume en compactheid) van een gebouw reeds in de vroege ontwerpfase worden bepaald, is deze tool niet bruikbaar in dit ontwerpstadium. Het vereisen van een gedetailleerde input maakt dat deze tool immers te complex en tijdrovend is voor gebruik is de vroege ontwerpfases. Aangezien de normen betreffende de energieprestatie en het binnenklimaat (EPB) van een gebouw steeds strenger worden, is het belangrijk dat architecten reeds vroeg in het ontwerp inzicht krijgen op de prestatie van hun ontwerp. Daarom hebben architecten nood aan een tool die hen toelaat de energieprestatie van een gebouw op een eenvoudige en doeltreffende wijze te evalueren en dit in de vroege ontwerpfase. Idealiter wordt deze tool gekoppeld met een 3D tekenprogramma zodat de tool gemakkelijk ingezet kan worden tijdens het ontwerpen. Gezien de focus op de vroege ontwerpfase, lijkt een koppeling met Google SketchUp dan ook evident. Deze studie kadert binnen het doctoraatsonderzoek van L. Weytjens: “Design support method for energy use and summer comfort evaluations of residential buildings in early design stages”

2.2_ O NDERZOEKSVRAAG Kan er een ‘architect’-vriendelijke plug-in voor Google SketchUp worden ontwikkeld om de energieprestatie en het zomercomfort van een gebouw op eenvoudige wijze te evalueren in de vroege ontwerpfase?

2.3_ METHODOLOGIE Dit thesisonderzoek werd gestart met een grondig vooronderzoek. Daarna werd de opgedane kennis gebruikt voor het ontwikkelen van een eigen plug-in voor analyse van EPB en zomercomfort. Het ontwikkelen van deze plug-in gebeurde d.m.v. de ‘trial and error’-methode. Meerdere werkwijzen voor het achterhalen van bepaalde soorten gegevens (geometrische, aan geometrie gekoppelde en bijkomende gegevens) werden uitgeprobeerd. Ook een geschikte manier voor een koppeling met een Excel-rekenmodule te realiseren werd onderzocht. Vervolgens werd de plug-in gevalideerd a.d.h.v. een eenvoudige validatieprocedure. Tenslotte werd een besluit gevormd over de bruikbaarheid en werd het toekomstig onderzoek geformuleerd.

3_ VOORONDERZOEK 3.1_ I NLEIDING Alvorens te starten met het ontwikkelen van de plug-in voor de analyse van EPB en zomercomfort in de vroege ontwerpfase werd een uitgebreid vooronderzoek gedaan. In de eerste plaats werden soortgelijke plug-ins voor Google SketchUp (SU) geanalyseerd. De voor- en nadelen werden hierbij zorgvuldig bestudeerd inzake gebruiksvriendelijkheid. Vervolgens werd een onderzoek gedaan naar de manier waarop architecten werken met SU. Dit werd onderzocht a.d.h.v. een beknopte online enquête. Tenslotte werd onderzoek gedaan naar het daadwerkelijk programmeren van een plug-in voor SU en welke bronnen hiervoor geraadpleegd kunnen worden.

3.2_ A NALYSE VAN SOORTGELIJKE PLUG - INS 3.2.1_ SUFIQUAD 3.2.1.1_ALGEMEEN SuFiQuaD(Van Dijck 2010) (Sustainability, Financial and Quality evaluation of Dwelling types) is een plug-in geschreven door K. Van Dijck en werd ontwikkeld aan de K.U. Leuven.

3.2.1.2_MODELLEEREISEN Voor de plug-in is het vereist dat de gebruiker het model modelleert als een vlakkenmodel. Tevens worden de verschillende binnenruimtes en bouwlagen gemodelleerd. Zo een vlakkenmodel kan zeer snel worden gemodelleerd en bijgevolg is het gebouw snel gereed om de analyse uit te voeren. Op esthetisch gebied is het vlakkenmodel wel ondergeschikt aan het model waarin in dikte wordt gemodelleerd.

3.2.1.3_INPUT VAN GEGEVENS Wanneer na installatie van de plug-in SU wordt opgestart, worden automatisch 16 lagen/layers aangemaakt. De plug-in dringt zich op. De gebruiker heeft bij het starten van SU niet altijd de intentie om gebruik te maken van een bepaalde plug-in. Het automatisch opstarten van bepaalde onderdelen van een plug-in kan dan ook als hinderlijk worden ervaren. Verschillende typen constructie-elementen (daken, vloeren, muren, …) moeten door de gebruiker zelf worden onderscheiden, de plug-in herkent dit niet automatisch. De gebruiker moet ieder constructie-element in de geschikte laag plaatsen. Ook de begrenzing van een bepaald constructie-element moet door de gebruiker worden ingegeven. Dit vraagt om extra handelingen die de gebruiksvriendelijkheid niet ten goede komen. Anderzijds gebeurt het koppelen van opbouwen aan constructie-elementen door het verslepen van componenten uit de componentenlijst naar de verschillende constructieelementen. Dit is een eenvoudige manier. De visuele referentie is evident. Naast geometrische gegevens (het model) en aan geometrie gekoppelde gegevens (type constructie-element) worden in de plug-in geen andere gegevens ingegeven. Deze gegevens (bijv. type verwarming, ventilatiesysteem, …) moeten wel in een latere fase worden ingegeven. De plug-in is namelijk niet zelfstandig, maar maakt gebruik van extra software.

3.2.1.4_BEREKENINGSWIJZE Alle geometrische en aan geometrie gekoppelde gegevens worden door geĂŤxporteerd als een csv-bestand. Dit bestand wordt vervolgens door software ingeladen. Dit kan worden vergeleken met de koppeling van rekenmodule, zoals in dit werk werd gerealiseerd. In de SuFiQuaD plug-in koppeling nog niet gerealiseerd. Er werd bijgevolg geen resultaat berekend.

de plug-in een derde een Excelwerd deze

3.2.1.5_ OUTPUT VAN GEGEVENS EN RESULTATEN Omdat de koppeling tussen de plug-in enerzijds en de rekentool anderzijds nog niet werd gerealiseerd, worden geen duidelijke resultaten getoond. Enkel gebouwgeometrische gegevens worden aan de gebruiker weergegeven.

3.2.2_ IES VE 3.2.2.1_ALGEMEEN IES VE2 (Integrated Environmental Solutions: Virtual Environment) is een professionele plugin ontwikkeld door de firma IES.

3.2.2.2_MODELLEEREISEN Ook voor de plug-in is het vereist dat de gebruiker het model modelleert als een vlakkenmodel. Ook de verschillende binnenruimtes en bouwlagen worden gemodelleerd.

3.2.2.3_INPUT VAN GEGEVENS Hoewel de gebruiker het model louter met vlakken modelleert, herkent de plug-in volledig automatisch de verschillende ruimtes binnen het model. Ook kan de werkelijke locatie (bijv. Hasselt) van het model worden ingegeven als bijkomende informatie. Deze locatie wordt gebruikt voor het bepalen van de werkelijke zonnestand. Op die manier kan worden gewerkt met zeer accurate gegevens betreffende de zonnewinsten e.d. doorheen een bepaalde periode. Tenslotte kunnen zeer snel enkele gegevens betreffende de verschillende installaties worden bepaald. Ook kunnen standaard opbouwen aan de verschillende typen constructie-elementen (vloeren, daken, muren) worden gegeven. Hierdoor zijn het model en alle benodigde gegevens vlot beschikbaar voor het starten van een eerste analyse.

3.2.2.4_BEREKENINGSWIJZE De berekeningen gebeuren d.m.v. een derde software. Dit is op zich niet erg, aangezien de communicatie tussen de plug-in en deze software vlot verloopt. De resultaten zijn hierdoor snel beschikbaar.

3.2.2.5_OUTPUT VAN GEGEVENS EN RESULTATEN Na voltooiing van de analyse wordt een uitgebreid resultatenformulier aan de gebruiker getoond.

http://www.iesve.com/

3.2.3_ EPSKETCH 3.2.3.1_ALGEMEEN Voor gebruik van EPSketch 3 is het is noodzakelijk een Google account 4 (Gmail) aan te maken. Wegens de controversiĂŤle aanmeldprocedure werd deze plug-in niet getest maar gebeuren de bevindingen op basis van de handleiding5.

3.2.3.2_MODELLEEREISEN Ook voor de plug-in is het vereist dat de gebruiker het model modelleert als een vlakkenmodel. Verschillend t.o.v. voorgaande plug-ins wordt bij gebruik van EPSketch enkel het gebouwvolume gemodelleerd. De verschillende bouwlagen en binnenruimtes worden niet gemodelleerd.

3.2.3.3_INPUT VAN GEGEVENS Deze plug-in maakt gebruik van slechts 1 User Interface (UI) waarin alle functionaliteiten vervat zijn. Hoewel deze UI slordig werd vormgegeven oogt de plug-in hierdoor overzichtelijk. Alle functies van de plug-in zijn meteen zichtbaar voor de gebruiker. Per verliesoppervlak kan de gebruiker een opbouw bepalen. Daarnaast worden ook nog enkele gegevens betreffende de systemen voor ruimteverwarming en warm tapwater ingegeven.

3.2.3.4_BEREKENINGSWIJZE Het berekenen van de resultaten gebeurt op eigenaardige wijze. De plug-in stelt automatisch een rapport op dat naar een server moet worden verzonden. Hierdoor is deze plug-in niet bruikbaar zonder internetverbinding.

3.2.3.5_TONEN VAN GEGEVENS EN RESULTATEN Omdat de analyse niet op de eigen pc gebeurt maar op een server worden de resultaten niet meteen aan de gebruiker getoond. Zonder internetverbinding worden er zelfs helemaal geen resultaten getoond. In de handleiding werd geen voorbeeld getoond van een resultatenformulier waardoor hier geen mening over kan worden gevormd.

3.2.4_ SMARTLAB SKETCHUP PLUGIN 3.2.4.1_ALGEMEEN De SmartLab SketchUp Plugin werd ontwikkeld aan de Universiteit Gent door Tine Jonckheere, Ruben Verstraeten, Pieter Pauwels en Ronald Demeyer(Jonckheere, et al. 2010).

3.2.4.2_MODELLEEREISEN Bij gebruik van deze plug-in heeft de gebruiker de vrije keuze te modelleren a.d.h.v. een vlakkenmodel of een model waarin de constructie-elementen in dikte worden http://www.epsketch.be/index.html https://accounts.google.com/ 5 http://www.epsketch.be/EPSketch_handleiding_v1.0.pdf

gemodelleerd. Dit komt de gebruiksvriendelijkheid ten goede. Ook de verschillende binnenruimtes en bouwlagen worden gemodelleerd.

3.2.4.3_INPUT VAN GEGEVENS De plug-in beschikt over één User Interface waarin alle functionaliteiten van de plug-in worden ondergebracht. In de linker helft van de User Interface werden een aantal drukknoppen voorzien voor bepaalde functies van de plug-in te gebruiken. In de rechter helft wordt de opbouw van het model onder de vorm van een boomstructuur voorgesteld. Het eerste niveau van deze boomstructuur bevat alle ruimtes van het gebouw. Deze ruimtes kunnen automatisch worden bepaald. Het tweede niveau van de boomstructuur bevat alle vlakken waaruit deze ruimtes (niveau 1) zijn opgebouwd. Deze grafische voorstelling toont een duidelijk overzicht van het model. Wanneer men in deze boomstructuur op een bepaald vlak klikt, wordt het betreffende vlak in het model rood gekleurd. Vervolgens kunnen hier opbouwkundige gegevens aan worden gekoppeld. Tussen de verschillende vlakken in de boomstructuur enerzijds en de verschillende vlakken van het getekende model anderzijds is de visuele referentie niet meteen duidelijk. Er moeten enkele vlakken in de boomstructuur worden aangeklikt alvorens het juiste vlak in het model wordt gevonden. Tenslotte is er geen mogelijkheid om de User Interface (UI) te verbergen. Deze blijft altijd op de voorgrond van het scherm staan, zelfs wanneer men andere programma’s gelijktijdig opent met SU en deze vensters actief maakt. Er is enkel een knop (kruisje, rechts bovenaan) voor het sluiten van de User Interface.

3.2.4.4_BEREKENINGSWIJZE De analyse gebeurt d.m.v. een derde software. Alle geometrische en aan geometrie gekoppelde gegevens worden automatisch vanuit SU naar deze software verzonden. In deze software moeten vervolgens nog enkele bijkomende gegevens (ventilatiesysteem, verwarmingssysteem, …) worden bepaald.

3.2.4.5_TONEN VAN GEGEVENS EN RESULTATEN De resultaten van deze analyse worden in deze derde software aan de gebruiker getoond. Ook geometrische (oppervlakte, helling, oriëntatie) en aan geometrie gekoppelde gegevens (opbouwen, …) worden in deze derde software aan de gebruiker getoond.

3.3_ E NQUÊTE 3.3.1_ OPZET Eerst en vooral is het belangrijk inzicht te krijgen in de manier waarop architecten werken met SU en hoe zij hun model modelleren tijdens de vroege ontwerpfase. Dit werd onderzocht aan de hand van een beperkte online enquête. Hiervoor werd gebruik gemaakt van LimeSurvey6 , een online open-source enquête-applicatie die geïnstalleerd moet worden op de eigen webruimte. Uiteraard bestaan er ook talloze –en zelfs eenvoudigere- oplossingen waarvoor men niet over eigen webruimte moet beschikken7. De reden waarom uiteindelijk gekozen werd voor LimeSurvey is dat deze tool meer mogelijkheden biedt naar o.a. uiterlijk en vormgeving. Om een significant aantal architecten te bereiken die SU gebruiken, werd de link van de online enquête verzonden naar de volledige C3A-userclub. Op die manier werden voornamelijk architecten bereikt die ook effectief met SU werken. De enquête bleef gedurende twee weken online beschikbaar en 71 architecten hebben hierop gereageerd.

3.3.2_ RESULTATEN 3.3.2.1_AANTAL GEBRUIKERS PER BESTURINGSSYSTEEM Eerst en vooral werd onderzocht met welk besturingssysteem de meeste architecten werken. Uit het voorgaande onderzoek bleek namelijk dat er toch enkele verschillen zijn tussen SU geïnstalleerd op enerzijds een Windows omgeving en anderzijds een Mac omgeving. Van de 71 architecten bleken er 61 (86%) te werken op een PC tegenover 10 (14%) op een Mac. (Figuur 1)

Aantal gebruikers per besturingssysteem. 100%

Percentage van ondervraagden

90%

86%

80% 70% 60% Windows

50%

OsX

40% 30% 20%

14%

10% 0% FIGUUR 1: AANTAL GEBRUIKERS PER BESTURINGSSYSTEEM

6 7

http://www.limesurvey.org http://www.enquetemaken.be; http://www.thesistools.com

3.3.2.2_MODELLEERMETHODES DOORHEEN VERSCHILLENDE ONTWERPFASES Vervolgens werd ook achterhaald hoe architecten modelleren binnen SU en of er een verschil is tussen de verschillende ontwerpfases, met name de conceptuele ontwerpfase, de voorontwerpfase en de bouwaanvraagfase. Deze vraag werd gesteld aan de hand van zeven afbeeldingen waarop telkens een andere manier van modelleren wordt getoond. Aan de architecten werd gevraagd om per fase ĂŠĂŠn afbeelding te selecteren. Ook kon aangevinkt worden dat SU in de betreffende fase niet wordt gebruikt. Afbeelding 1 Deze afbeelding toont een model waarbij de buitenschildelen als vlakken worden gemodelleerd. Er wordt enkel onderscheid gemaakt tussen opake en transparante vlakken en er worden geen ruimtes getekend. De woning bestaat uit een gebouwvolume.

Afbeelding 2 Dit model wordt vrijwel op dezelfde manier gemodelleerd als het model op afbeelding 1. Het enige verschil zit in het feit dat hier ook de verschillende bouwlagen worden gedefinieerd.

Afbeelding 3 Bij deze wijze van modelleren worden alle constructieelementen getekend, zij het nog steeds als vlakken. Zowel bouwlagen als binnenruimtes worden bepaald.

Afbeelding 4 Deze modelleerwijze is gelijkaardig als afbeelding 1. Het verschil zit in het werken met diktes voor de schildelen.

Afbeelding 5 Ook hier worden de verschillende schildelen in dikte geconstrueerd en wordt er een onderscheid gemaakt tussen de verschillende bouwlagen.

Afbeelding 6 Bij deze wijze van modelleren worden alle constructieelementen in dikte gemodelleerd. Ook worden alle bouwlagen en binnenruimtes gedefinieerd.

Afbeelding 7 In deze modelleermethode wordt alles in detail uitgewerkt en getekend. Het binnenspouwblad wordt afzonderlijk gedefinieerd van het buitenspouwblad, de verschillende lagen van de vloeropbouw zijn zichtbaar, â&#x20AC;Ś

Daarnaast werd een achtste afbeelding opgenomen, om de respondenten ook de mogelijkheid te geven aan te duiden dat SU binnen een bepaalde ontwerpfase helemaal niet wordt gebruikt. Dit werd opgenomen met een volledig zwart beeld. Uit de resultaten (Figuur 2) blijkt dat de meeste architecten (44%) doorheen de conceptuele ontwerpfase modelleren volgens het principe getoond op afbeelding 1, tijdens de voorontwerpfase verkiest 41% te werken volgens de modelleermethode getoond op afbeelding 6. Het vermoeden dat SU niet wordt gebruikt in de bouwaanvraagfase wordt bevestigd, 47% geeft aan geen gebruik te maken van SU in deze fase. Er blijkt dus een duidelijk verschil in modelleermethode tussen de verschillende ontwerpfases. In het vroege ontwerp wordt een eenvoudige methode met vlakken verkozen. Naarmate het ontwerp vordert gaat men meer gedetailleerd tekenen.

Modelleermethodes doorheen verschillende ontwerpfases Percentage van ondervraagden

Conceptuele ontwerpfase 50% 45% 40% 35% 30% 25% 20% 15% 10% 5% 0%

Voorontwerpfase

Bouwaanvraag fase 47%

44%

41%

21% 14%

13% 6%

1%1% (A1) vlakken, volume

18%

14%

(A2) vlakken, bouwlagen

8% 4% 0% (A3) vlakken, ruimtes

8% 1%

10% 6% 3%

16% 13%

8% 1%1%

(A4 ) dikte, (A5) dikte, (A6) dikte, (A7) detail (A8) geen volume bouwlagen ruimtes (vb spouw) gebruik

FIGUUR 2: MODELLEERMETHODES DOORHEEN VERSCHILLENDE ONTWERPFASES

3.3.2.3_ALGEMEEN GEBRUIK Vervolgens werden nog enkele algemene resultaten bekomen (Figuur 3). Zo geeft 56% van de ondervraagden aan groepen/groups te gebruiken om constructie-elementen van elkaar te isoleren tegenover 48% die hiervoor componenten/components prefereren. 46% gebruikt groepen/groups om het volledige volume samen te voegen. De mogelijkheid om materialen te kunnen geven aan elementen wordt door 63% van de ondervraagden gebruikt. 79% geeft ook aan gebruik te maken van lagen/layers voor het niet gelijktijdig op het scherm tonen van constructie-elementen.

Algemeen gebruik 90% 79%

percentage van ondervraagden

80% 70% 60%

63% 56%

50%

46%

48%

groepen/groups om constructieelementen van elkaar te isoleren. groepen/groups voor het bouwvolume.

40%

componenten/components om constructie-elementen van elkaar te isoleren.

30%

materialen/materials.

20% 10% 0%

lagen/layers om niet alle constructie-elementen gelijktijdig op het scherm te tonen.

FIGUUR 3: ALGEMEEN GEBRUIK

Tenslotte werd de vraag gesteld of er interesse was in een plug-in voor SU om de EPB en zomercomfort reeds in de vroege ontwerpfase te evalueren. 79% van de respondenten antwoordde hier positief op. 32% van alle ondervraagden is bereid deel te nemen aan gebruikerstests voor het analyseren en optimaliseren van een dergelijke plug-in.

3.3.3_ IMPLICATIES Aangezien de plug-in bedoeld is voor gebruik in de conceptuele- en voorontwerpfase, werd op basis van bovenstaande resultaten beslist om de plug-in te construeren volgens het modelleerprincipe in afbeelding 6. Dit houdt in dat de verschillende constructieelementen van het model gemodelleerd moeten worden met een bepaalde dikte. Tevens is het vereist dat niet enkel de schildelen worden gedefinieerd maar ook dat de binnenvloeren en –muren worden gemodelleerd. Vooral voor de evaluatie van het zomercomfort is het immers belangrijk dat een onderscheid gemaakt wordt tussen de verschillende ruimtes in een woning. Deze gegevens impliceren een aantal modelleereisen welke werden genomen alvorens te starten met het ontwikkelen van de plug-in. Constructie-elementen die in dikte worden gemodelleerd bestaan uit een aantal vlakken. Om één geheel te verkrijgen moeten al deze vlakken worden gegroepeerd. Tevens moet ieder afzonderlijk constructie-element als een aparte groep worden gemodelleerd, zodat een fysiek onderscheid kan worden verkregen tussen de verschillende constructieelementen. Deze constructie-elementen kunnen van elkaar verschillen in type (schil ‘vloeren’, schil ‘muren’, binnenmuren, ramen, …) maar ook in opbouw.

3.4_ S TARTEN MET HET ONTWIKKELEN VAN EEN PLUG - IN VOOR G OOGLE S KETCHU P 3.4.1_ RUBY 3.4.1.1_INLEIDING Plug-ins voor SU worden geschreven in Ruby 8 . Dit is een object georiënteerde programmeertaal met een eenvoudige syntaxis opgebouwd uit Engelse termen. Ruby is ontworpen om het werk van de programmeur zo eenvoudig mogelijk te houden. Y. Matsumoto, de schrijver van Ruby, benadrukt dat de taal is geschreven voor mensen en niet voor machines(Matsumoto 2003): “Because computers don't mind if I must make effort to communicate with them or if it is easy to communicate with them. They don't care if I put the numbers of instruction byte sequences in a file and feed it to them to run, or if a very high level language generated the instructions. The computers don't care. We humans care about the effort we pay. Often people, especially computer engineers, focus on the machines. They think, "By doing this, the machine will run faster. By doing this, the machine will run more effectively. By doing this, the machine will something something something." They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves.” De eenvoud van de taal wordt geïllustreerd aan de hand van een eenvoudig voorbeeld. De zin (string is de correcte term) “Good evening” wordt getoond indien de variabele ‘daytime’ gelijk is aan “evening”:

daytime = “evening” puts “Good evening” if daytime == “evening”

In JavaScript zou hetzelfde script er als volgt uitzien:

var daytime = “evening”; if (daytime == “evening”){ alert(“Good evening”); }

Nogmaals hetzelfde script maar dan in Java, ook een veel gebruikte object georiënteerde programmeertaal, zou op de volgende wijze geschreven worden:

var daytime = “evening”; if (daytime == “evening”){ system.out.println(“Good evening”); }

In Ruby worden variabelen niet gedeclareerd. Tevens is het gebruik van haakjes en accolades tot het minimum herleid. Uiteraard zijn er nog vele andere aspecten die van Ruby een eenvoudige programmeertaal maken.

http://www.ruby-lang.org/en/

3.4.1.2_SCRIPTS SCHRIJVEN Net zoals veel programmeertalen kan Ruby worden geschreven in eender welke tekstverwerker. Het bestand moet enkel worden opgeslagen met de juiste extensie: ‘.rb’. Het programma “Kladblok”, dat standaard op elk Windows platform is geïnstalleerd, kan worden gebruikt voor het schrijven van Ruby scripts. Alle scripts die geschreven werden doorheen dit thesisonderzoek daarentegen, werden geschreven met behulp van Notepad++ 9 . Dit is een gratis tekstverwerker die speciaal werd ontwikkeld voor het schrijven van scripts in verschillende programmeertalen. D.m.v. kleuren die automatisch aan verschillende onderdelen van het script worden gegeven, wordt een duidelijk overzicht behouden (Figuur 4).

FIGUUR 4: NOTEPAD++ VOOR HET SCHRIJVEN VAN RUBY SCRIPTS

3.4.1.3_INSTALLATIE VAN GOOGLE SKETCHUP PLUG-INS Het installeren van plug-ins voor SU betekent niet meer dan het verplaatsen van het .rbbestand naar de “Plugins” map van SU. Voor Windows gebruikers bevindt deze map zich conventioneel op de volgende locatie: …/Program Files/Google/Google SketchUp (7,8,…)/Plugins/ Voor Mac gebruikers echter is dit: …/Library/Application Support/Google SketchUp (7,8,…)/SketchUp/Plugins/

http://notepad-plus-plus.org

3.4.2_ BRONNEN 3.4.2.1_LITERATUUR Het spreekt voor zich dat het ontwikkelen van een plug-in voor SU om EPB en zomercomfort te evalueren een hoge graad van complexiteit bevat. Een eerste vereiste om een plug-in in SU te programmeren is dan ook voldoende kennis en inzicht hebben in Ruby. Hoewel het web een enorme bron is, met nuttige informatie over quasi iedere programmeertaal, is het net die hoeveelheid aan informatie die het maakt dat het internet niet de geschikte plek is om de allereerste stappen te zetten bij het aanleren van Ruby, met het doel een plug-in voor SU te programmeren. Daarom werd er gestart met een literatuuronderzoek over het programmeren in Ruby. Een belangrijke bron hiervoor bleek het boek van M. Scarpino (2010), “Automatic SketchUp: Creating 3D models in Ruby”. In dit boek worden zowel de datastructuren van Ruby uitgelegd alsook de volledige samenwerking tussen deze taal en SU, zowel voor beginners als gevorderde programmeurs, en dit d.m.v. een aantal lessen en voorbeelden. De digitale versie (in pdf) van dit boek is gratis te downloaden10. Een tweede belangrijke bron voor het aanleren van Ruby is het boek van H. Collingbourne (2009), “The book of Ruby”. Dit boek focust niet op de interactie tussen Ruby en SU, maar biedt wel een enorme diepgang in de taal zelf. Ook van dit boek is de digitale versie (in pdf) gratis te downloaden11.

3.4.2.2_HET WEB Na het succesvol voltooien van deze lessen zou men over voldoende ervaring en kennis moeten beschikken om zich verder te verdiepen in de hoeveelheid aan informatie die kan worden gevonden op het web. Ook Google zelf beschikt over een uitgebreide API (Application Programming Interface) waarin alle relevante informatie over het programmeren van een plug-in voor SU wordt besproken 12 . Daarnaast kan men een account aanmaken op SketchUcation 13 . Dit is een forum waarop zowel ontwerpers als ontwikkelaars hun ervaringen delen en vragen beantwoorden met betrekking tot SU. In het kader van dit thesisonderzoek werd ook een account aangemaakt op Stack Overflow14, het zo genoemde: “A language-independent collaboratively edited question and answer site for programmers.” Op dit forum kunnen vragen worden gesteld die in essentie geen betrekking hebben tot SU maar zich meer richten naar de core-functies van de programmeertaal zelf, in dit geval Ruby.

3.4.2.3_EIGEN INTERESSE Tenslotte vormt eigen interesse een noodzakelijke bron. Doorheen dit thesisonderzoek werden enkele (eenvoudige) plug-ins gemaakt die niet meteen betrekking hebben op de uiteindelijke plug-in, maar wel noodzakelijk waren bij het aanleren van Ruby. Dit voor het ontwikkelen van een succesvolle plug-in om een evaluatie van EPB en zomercomfort te maken in SU. Drie van deze plug-ins worden hier kort besproken. De eerste plug-in maakt het mogelijk om verschillende soorten van entiteiten (lijnen, vlakken, groepen en componenten) eenvoudig te kunnen selecteren in een bepaalde laag. Een tweede plug-in maakt het mogelijk om zeer snel, aan de hand van code, een spiraal te tekenen in SU. De derde plug-in is tenslotte tot stand gekomen op vraag van een medestudent. Soms kan het gebeuren dat er binnen SU verschillende groepen in groepen voorkomen. Wanneer al deze groepen vervolgens in een afzonderlijke laag staan, kan dit leiden tot problemen wanneer men slechts bepaalde lagen zichtbaar wil maken. Aan de hand van deze plug-in kan worden gekozen om alle onderliggende groepen dezelfde laag te geven als de http://www.autosketchup.com http://www.sapphiresteel.com/The-Book-Of-Ruby 12 http://code.google.com/intl/nl-NL/apis/sketchup/docs/index.html 13 http://forums.sketchucation.com/ucp.php?mode=register 14 http://stackoverflow.com/users/login

geselecteerde groep. De relevantie van deze plug-ins voor dit thesisonderzoek betreft onder andere het omgaan met de ‘webdialogbox’, de meest gebruikelijke vorm van User Interface (UI) voor plug-ins. Ook het automatisch tekenen van entiteiten, waarbij hun vorm wordt bepaald d.m.v. code, werd hiermee onderzocht. Tenslotte gaf dit inzicht in hoe SU omgaat met de verschillende lagen en entiteiten van het model. De werking van deze plug-ins wordt getoond in enkele videofragmenten.

http://www.youtube.com/watch?v=3vJ_yanE8xA

http://www.youtube.com/watch?v=mpII1j617mk

http://www.youtube.com/watch?v=CIz86lAK-G0

3.4.2.4_SOORTGELIJKE PLUG-INS Een andere belangrijke bron voor de ontwikkeling van de plug-in betreft een beknopte analyse die uitgevoerd werd van soortgelijke plug-ins. Deze analyse werd in een vorig hoofdstuk (hoofdstuk 3.2_; “Analyse van soortgelijke plug-ins”) reeds besproken.

4_ ONTWIKKELING VAN DE PLUG-IN VOOR ANALYSE VAN EPB EN ZOMERCOMFORT 4.1_ I NLEIDING De analyses van EPB en zomercomfort gebeuren door het verzenden van gegevens uit SU naar Excel-rekenmodules. Deze rekenmodules voor energie (EPB) 15 en zomercomfort werden opgesteld door L. Weytjens (2011). Allereerst werd bepaald welke gegevens afgeleid moeten worden uit SU en verzonden moeten worden naar deze Excelrekenmodule. Vervolgens werd onderzocht hoe deze gegevens kunnen worden bepaald en op welke manier zij naar de Excel-rekenmodule kunnen worden verzonden. Tenslotte werd een onderzoek gedaan naar een manier voor het tonen van de resultaten aan de gebruiker. In dit hoofdstuk wordt het plug-in-traject in chronologisch verloop besproken.

4.2_ B ENODIGDE GEGEVENS VOOR EEN EVALUATIE VAN EPB EN ZOMERCOMFORT 4.2.1_ GEOMETRISCHE GEGEVENS Voor een correcte analyse van EPB moet allereerst het beschermd volume van het gemodelleerde gebouw worden bepaald. Vervolgens is het noodzakelijk om van elk schildeel de verliesoppervlakte, de helling en de oriĂŤntatie te bepalen. Bovendien moet een onderscheid worden gemaakt tussen opake en transparante constructies. Daarnaast moet een onderscheid worden gemaakt tussen muren, vloeren en daken. Op basis van de verliesoppervlaktes van de schildelen kan de totale verliesoppervlakte en dus de compactheid worden bepaald. Verder moet de bruto vloeroppervlakte bepaald worden. Voor analyse van zomercomfort is het nodig om het volume van de afzonderlijke ruimtes te kennen. Geometrische gegevens kunnen zonder tussenkomst van de gebruiker worden bepaald.

4.2.2_ AAN GEOMETRIE GEKOPPELDE GEGEVENS Bijkomend zijn er verschillende gegevens nodig die gekoppeld worden aan geometrie. Zo moet aan ieder verliesoppervlak een bepaalde opbouw (U-waarde) en een begrenzing (aangrenzende verwarmde ruimte, aangrenzende onverwarmde ruimte, de buitenomgeving, â&#x20AC;Ś) worden gekoppeld. De buitenomgeving kan afgeleid worden uit het SU-model. De andere gegevens kunnen niet rechtstreeks uit het SU-model worden bepaald, maar moeten door de gebruiker toegekend worden aan de geometrie.

4.2.3_ BIJKOMENDE GEGEVENS Naast deze geometrische en aan geometrie gekoppelde gegevens zijn gegevens nodig met betrekking tot de verschillende installaties van het gebouw en de thermische massa van het gebouw. De keuze van het ventilatiesysteem en het verwarmingssysteem zijn hier voorbeelden van. Ook deze gegevens moeten door de gebruiker worden ingevoerd of als een standaardwaarde worden bepaald. Deze gegevens zijn in tegenstelling tot de voorgaande gegevens niet rechtstreeks gekoppeld aan het 3D gebouwgeometrische model.

4.3_ A NALYSE VAN DE BINNENRUIMTES 15

Weytjens, L. EPB rekenmodule in MS Excel (PHL/Universiteit Hasselt)

4.3.1_ METHODE Bij de uitwerking van de plug-in werd gestart met de automatische herkenning en bepaling van de verschillende binnenruimtes. Dit is niet belangrijk voor een EPBberekening, maar is vooral van belang naar het zomercomfort toe. Enerzijds dient het volume van de ruimtes te worden bepaald en anderzijds moet de gebruiker kunnen specificeren of een ruimte binnen het beschermd volume valt of een aangrenzende onverwarmde ruimte is, m.a.w. of een bepaalde binnenruimte al dan niet verwarmd is. Het bepalen van de binnenruimtes gebeurt op volgende wijze: De verschillende constructieelementen worden d.m.v. ‘union’ samengevoegd tot 1 groep. De code voor het samenvoegen van twee groepen wordt samengesteld als volgt:

union_group = group1.union(group2)

Vervolgens wordt rondom deze samengevoegde groep (groep A) d.m.v. code een nieuwe groep (groep B) getekend. Groep B is iets groter dan groep A. Tenslotte wordt Groep A d.m.v. de ‘subtract method’ uit groep B ‘gesneden’. Hetgeen overblijft zijn de verschillende binnenruimtes. De code voor het snijden van groep A uit groep B wordt opgebouwd als volgt:

union_group = groupA.subtract(groupB)

De binnenruimtes worden d.m.v. code als een groep gemodelleerd, dit impliceert dat hun volume op eenvoudige wijze kan worden achterhaald:

volume = group.volume

Wel moet er rekening gehouden worden met het feit dat de interne maatvoering binnen SU in Inches gebeurt, ongeacht het feit of men modelleert in een metrisch stelsel. Voor deze omvorming biedt SU een ‘method’, namelijk ‘to_m’. Een volume is een maatvoering in de derde graad, de ‘method’ ‘to_m’ dient dan ook 3 maal te worden uitgevoerd:

volume = group.volume.to_m.to_m.to_m

Men zou ook een eigen ‘method’ kunnen schrijven om een volume, uitgedrukt in cubic inches, om te vormen tot een volume uitgedrukt in kubieke meter:

def to_metric_volume(volume) return (volume * 0.000016387064) end volume = to_metric_volume(group.volume)

Indien dit slechts eenmaal moet gebeuren, kan men ervoor opteren de waarde direct te vermenigvuldigen met de omvormingsfactor:

volume = (group.volume * 0.000016387064)

4.3.2_ USER INTERFACE VOOR HET BEPALEN VAN DE BINNENRUIMTES 4.3.2.1_EEN USER INTERFACE D.M.V. ADOBE FLASH Om de gebruiker de mogelijkheid te bieden om te bepalen of een ruimte al dan niet verwarmd is, werd in een eerste versie gebruik gemaakt van een UI, vormgegeven door middel van Adobe Flash (Figuur 5). Deze keuze werd gemaakt op basis van eerdere ervaringen hiermee. De interactie tussen Ruby en Adobe Flash gebeurt met behulp van JavaScript. De werking van de plug-in in deze fase van het onderzoek kan worden bekeken op volgend filmfragment:

http://www.youtube.com/watch?v=PxzPNL-Eiag

FIGUUR 5: ADOBE FLASH ALS USER INTERFACE

Hoewel er, mits verdere uitwerking, zeker potentie zit in het gebruik van Adobe Flash om de UI mee vorm te geven, is uiteindelijk beslist om niet verder te gaan met dit principe. Adobe Flash biedt een enorme vrijheid naar vormgeving toe, maar net die vrijheid maakt het een tijdrovend proces. Ook worden de achterliggende scripts, “actions”, geschreven in ActionScript. Het betrekken van een vierde programmeertaal (namelijk Ruby, JavaScript, Visual Basic en bijkomend ActionScript) maakt het geheel meer ingewikkeld dan nodig (Figuur 6).

FIGUUR 6: INTERNE WERKING MET ADOBE FLASH ALS USER INTERFACE

4.3.2.2_EEN USER INTERFACE D.M.V. MICROSOFT EXCEL Vanwege het belang van de koppeling tussen SU en Microsoft Excel, werd in een tweede fase onderzocht of Microsoft Excel zelf eventueel dienst zou kunnen doen als UI. Deze koppeling komt tot stand met behulp van de win32ole16 uitbreidingsbibliotheek voor Ruby. Deze bibliotheek maakt het mogelijk om win32-applicaties (PowerPoint, Excel, Internet Explorer, â&#x20AC;Ś) te openen en te bewerken doormiddel van VBA-code (Visual Basic for Applications). Bij uitvoeren van het script wordt d.m.v. code een Excel werkblad gegenereerd waarin per binnenruimte een aantal gegevens worden getoond. Het openen van Microsoft Excel gebeurt op de volgende manier:

http://ruby-doc.org/stdlib-1.9.3/libdoc/win32ole/rdoc/WIN32OLE.html

require 'win32ole.so'

#Laden van de WIN32OLE library.

excelUI = WIN32OLE.new('Excel.Application')

#Een nieuwe WIN32(Excel)-toepassing aanmaken.

excelUI.visible=true #Meteen zichtbaar maken aan de gebruiker. excelUI.DisplayAlerts=false #Geef geen foutmeldingen weer. excelUI.DisplayStatusBar=false #Verberg de statusbalk. excelUI.DisplayFormulaBar=false #Verberg de formulebalk workbookUI = excelUI.workbooks.add() #In deze toepassing een nieuw 'workbook' aanmaken. #Deze workbook heeft standaard reeds 3 'worksheets', de namen van deze worksheets moeten worden aangepast. workbookUI.worksheets(1).name = "Ruimtes" #De naam van Sheet 1 veranderen naar "Ruimtes" workbookUI.worksheets(2).name = "ConstructieElementen" #De naam van Sheet 2 veranderen naar "ConstructieElementen" workbookUI.worksheets(3).name = "Bibliotheek" #De naam van Sheet 3 veranderen naar "Bibliotheek"

Daarenboven wordt nog een tweede uitbreidingsbibliotheek gebruikt, genaamd win32API17. Deze bibliotheek laat toe om Windows zelf te kunnen manipuleren. Het is het van belang dat het Microsoft Excel-venster maximaal een kwart van het totale scherm in beslag neemt en tevens v贸贸r het SU-venster wordt getoond, om voldoende ruimte over te laten voor de visuele referentie tussen het model en de UI. De code voor het positioneren van dit venster ziet er als volgt uit:

require 'win32API.so'

#Laden van de WIN32API library.

sketchupWindow = Win32API.new('user32', 'GetActiveWindow', '', 'I').call #Haal de windowHandler op van het actieve scherm, normaal het huidige SketchUp scherm. excelWindow = Win32API.new('user32', 'FindWindow', ['P','P'],'I').call("XLMAIN","Microsoft Excel - " + $modelName) #Haal de windowHandler op van het zopas aangemaakte Excel-bestand. screenResolutionX = Win32API.new('user32', 'GetSystemMetrics', 'I', 'I').call(16) #Haal de huidige resolutie in de X-richting op. screenResolutionY = Win32API.new('user32', 'GetSystemMetrics', 'I', 'I').call(17) #Haal de huidige resolutie in de Y-richting op. Win32API.new('user32', 'SetWindowPos', ['I','I','I','I','I','I','I'], 'I').call(excelWindow,0, screenResolutionX/2, 0, screenResolutionX/2, screenResolutionY/2, 64) #Plaats het Excelvenster in het tweede kwadrant van het scherm.

De werking van de plug-in in deze fase van het onderzoek kan worden bekeken op volgend filmfragment:

http://www.youtube.com/watch?v=1pu_b97DDVk 17

http://www.rubytips.org/2008/05/13/accessing-windows-api-from-ruby-using-win32api-library/

Wanneer de gebruiker op een cel in een bepaalde rij klikt, verandert de kleur van het volume dat door deze rij wordt gerepresenteerd naar een opake variant (Figuur 7).

FIGUUR 7: MICROSOFT EXCEL ALS USER INTERFACE

Hoewel het een interessante benadering is om gebruik te maken van Microsoft Excel als UI, stoot deze manier op een aantal imperfecties. Enerzijds zijn er op esthetisch gebied niet voldoende mogelijkheden en anderzijds is de visuele referentie tussen de getekende ruimtes en de cellen in het werkblad, welke deze ruimtes voorstellen, ontoereikend. Men moet nagenoeg iedere rij afgaan om te achterhalen over welk volume het nu net gaat. Daarom werd van dit idee afgestapt. De interne werking van de plug-in zou er met deze UI uitzien als getoond op Figuur 8.

FIGUUR 8: INTERNE WERKING MET MICROSOFT EXCEL ALS USER INTERFACE

4.3.2.3_EEN USER INTERFACE GETEKEND DOOR GOOGLE SKETCHUP ZELF Uiteindelijk is een derde idee ontstaan om de tekencapaciteiten van SU zelf te gebruiken om de meest essentiële UIs vorm te geven. D.m.v. code worden naast het getekende model automatisch 2 kubussen getekend, één oranje en één blauw. Deze blokjes staan voor de verschillende keuzemogelijkheden, respectievelijk verwarmd en onverwarmd. De gebruiker selecteert eerst de ruimte(s) waarvan hij de keuze wil wijzigen (door op het SU model zelf te klikken) en klikt vervolgens op het blokje dat staat voor zijn keuze (Figuur 9).

FIGUUR 9: D.M.V. CODE WORDEN TWEE KUBUSSEN GETEKEND ALS USER INTERFACE VOOR HET BEPALEN VAN HET TYPE RUIMTE

Op deze manier is de visuele referentie evident. Deze methode is bovendien eenvoudig en snel. De werking hiervan kan worden bekeken in het volgende filmfragment:

http://www.youtube.com/watch?v=Z1qsD-v2uOU De interne werking van de plug-in met deze UI wordt getoond op Figuur 10.

FIGUUR 10: INTERNE WERKING MET EEN DOOR SKETCHUP GETEKENDE USER INTERFACE

4.4_ A NALYSE VAN DE CONSTRUCTIE - ELEMENTEN 4.4.1_ METHODE Nu de verschillende ruimtes op een efficiĂŤnte manier bepaald kunnen worden is de volgende stap het automatisch bepalen en herkennen van de bestemming van ieder getekend constructie-element. Uiteraard zou de gebruiker zelf kunnen aanwijzen welke functie ieder element bekleedt, maar om het gebruiksgemak te verhogen, werd besloten om te onderzoeken of dit automatisch kan gebeuren. Hiervoor moeten eerst de verschillende types aan constructie-elementen bepaald worden. Er worden twee hoofdtypen onderscheden, namelijk schildelen en binnenconstructies. De automatische bepaling van deze twee typen gebeurt op de volgende wijze: Ieder constructie-element is een samenvoeging van verschillende vlakken tot een groep. Van ieder van deze vlakken kan worden bepaald of deze raken aan een verwarmde ruimte, een onverwarmde ruimte, een ander constructie-element of aan de buitenomgeving. Een schildeel is dat element dat met tenminste 1 vlak aan een verwarmde ruimte grenst en met minstens 1 vlak grenst aan een onverwarmde ruimte of aan de buitenomgeving. Een binnenconstructie echter raakt met geen enkel vlak aan een onverwarmde ruimte of aan de buitenomgeving, maar enkel aan verwarmde ruimtes en andere constructie-elementen. Deze aanraakdetectie berust op volgend eenvoudig principe: Om te achterhalen of constructie-element A grenst aan ruimte B wordt er een som gemaakt van de oppervlakte van alle vlakken waaruit deze groepen zijn opgebouwd. Hierna worden beide groepen geĂŤxplodeerd om vervolgens opnieuw de som te maken van de oppervlakte van deze vlakken. Wanneer er een verschil is tussen de eerste som en de tweede som, grenst constructie-element A aan ruimte B. Het verschil in oppervlakte bepaalt tevens het aanraakoppervlak tussen beide entiteiten.

entities = Sketchup.active_model.entities som_a = 0 group_1.entities.each do |ent|; som_a += ent.area if ent.typename == “Face”; end group_2.entities.each do |ent|; som_a += ent.area if ent.typename == “Face”; end group_1.explode group_2.explode som_b = 0 entities.each do |ent| som_b += ent.area if ent.typename == “Face”; end verschil = som_a – som_b if verschil > 0 UI.messagebox (“Groep A raakt aan groep B met een oppervlakte van “ + verschil.to_s + “ m².”) end

Vervolgens worden de schildelen verder onderverdeeld in schil ’daken’, schil ’muren’ en schil ’vloeren’. Deze onderverdeling gebeurt door de helling te bepalen van dat vlak van een schildeel dat grenst aan een verwarmde ruimte. Deze helling, in graden, wordt d.m.v. volgende code bekomen:

face_angle = (Math.acos(face.normal[2])* (180/(Math::PI)))

Wanneer tijdens deze analyse de helling van een schildeel gelegen is tussen 180° en 120°, spreekt men van een schil ’dak’. Een helling met een waarde gelegen tussen 120° en 60° geeft een schil ’muur’. Als laatste zijn die schildelen met een helling van 60° tot 0° een schil ‘vloer’. Deze waarden zijn geïnverteerd t.o.v. de waarden voorgeschreven volgens de EPB (Figuur 11). Dit komt omdat de helling wordt bepaald a.d.h.v. het binnenvlak van het constructie-element. Een vloer bvb. wordt bepaald door een vlak dat naar boven is gericht. Bij en plat dak is dit vlak naar beneden gericht. Wanneer deze hellingen worden gebruikt om een analyse te maken van de EPB en zomercomfort, dienen deze uiteraard opnieuw te worden geïnverteerd.

FIGUUR 11: HELLING VAN VERSCHILLENDE CONSTRUCTIE-ELEMENTEN VOLGENS DE EPB SOFTWARE VLAANDEREN (HTTP://WWW.ENERGIESPAREN.BE)

De schildelen worden verder onderverdeeld in opake en transparante delen (beglazing). Voor deze onderverdeling wordt gekeken naar het materiaal dat aan een constructieelement toegekend is, namelijk of dit een opaak of transparant materiaal is. De code voor de volledige onderverdeling ziet eruit als volgt:

schilvloeren schilmuren_opaak schilmuren_transparant schildaken_opaak schildaken_transparant

= = = = =

[] [] [] [] []

if face_angle >= 0 and face_angle < 61 schilvloeren << construction_element elsif (face_angle >= 61 and face_angle < 121) if construction_element.material and construction_element.material.use_alpha? schilmuren_transparant << construction_element else schilmuren_opaak << construction_element end elsif (face_angle >= 121 and face_angle < 181) if construction_element.material and construction_element.material.use_alpha? schildaken_transparant << construction_element else schildaken_opaak << construction_element end end

Tenslotte werden ook de binnenconstructies onderverdeeld in binnenmuren en binnenvloeren- en plafonds. Deze onderverdeling gebeurt op dezelfde manier.

4.4.2_ USER INTERFACE VOOR HET NIET GELIJKTIJDIG TONEN VAN VERSCHILLENDE CONSTRUCTIE-ELEMENTEN Het spreekt voor zich dat, los van deze onderverdeling, aan alle constructie-elementen ook een opbouw met een bepaalde dikte en U-waarde moet worden toegekend. De meest eenvoudige manier om dit te realiseren is door een menu, waarin enkele opbouwen als keuzes zijn gedefinieerd, te tonen wanneer men een constructie-element selecteert. Ook deze UI is vrij van vormgeving. Voor het ontwerp van deze UI zou men opnieuw gebruik kunnen maken van HTML + Javascript en CSS, Adobe Flash of Microsoft Excel. Onafhankelijk van deze UI moet echter eerst een manier worden bedacht hoe de gebruiker op eenvoudige wijze er voor kan kiezen om niet alle constructie-elementen gelijktijdig op het scherm te tonen. Anders zou de gebruiker, wanneer hij een binnenconstructie wil selecteren, gehinderd worden door de schildelen die het gebouw ontsluiten. Hiervoor bleken twee mogelijke opties geschikt. Enerzijds zouden alle verschillende types aan constructie-elementen in verschillende lagen kunnen worden ondergebracht, zodat de gebruiker de keuze heeft bepaalde lagen zichtbaar of onzichtbaar te maken. Anderzijds zou er een tweede UI kunnen worden gemaakt, die de gebruiker in staat stelt om bepaalde constructie-elementen zichtbaar of onzichtbaar te maken, zonder het gebruik van aparte lagen. Deze laatste methode speelt in op het feit dat ieder ‘Drawingelement’ een ‘.visible’-method heeft:

#toon de groep: group.visible = true UI.messagebox(“De groep is nu zichtbaar.”) #verberg de groep: group.visible = false UI.messagebox(“De groep is nu verborgen.”)

Om de gebruiksvriendelijkheid van de plug-in te bevorderen werd besloten een tweede UI aan te maken voor het niet gelijktijdig tonen van alle constructie-elementen. Tevens wordt deze UI op dezelfde wijze opgebouwd als de UI voor het kiezen of een bepaalde ruimte verwarmd of onverwarmd is. Naast het model worden nu d.m.v. code zeven kubussen gemodelleerd die elk een bepaald type constructie-element representeren. Bij het klikken op een kubus, worden alle constructie-elementen van dit type verborgen en verandert de kleur van de kubus zelf naar een transparante variant (Figuur 12).

FIGUUR 12: USER INTERFACE IN SKETCHUP VOOR HET NIET GELIJKTIJDIG TONEN VAN CONSTRUCTIEELEMENTEN

Indien men nogmaals klikt op deze kubus worden al deze constructie-elementen opnieuw getoond en verandert de kleur van de kubus terug naar de opake variant. Deze UI is beduidend duidelijker en eenvoudiger voor de gebruiker dan het aanmaken van enkele nieuwe lagen. De werking hiervan kan worden bekeken in volgend filmfragment:

http://www.youtube.com/watch?v=uVVvmRiWpnk

4.5_ ORIﾃ起TATIE VOLGENS DE EPB 4.5.1_ BEPALEN VAN DE ORIﾃ起TATIE VAN EEN VLAK De oriﾃｫntatie van een vlak kan op eenvoudige wijze worden bepaald. Allereerst moet de richting van de normale op het vlak worden bepaald:

normale = face.normal

D.m.v. voorgaande code wordt een fictieve lijn met lengte 1 Inch loodrecht op de voorkant van het vlak getekend (Figuur 13).

FIGUUR 13: GRAFISCHE VOORSTELLING VAN DE NORMALE VAN EEN VLAK

Vervolgens wordt deze normale fictief verplaatst naar het nulpunt van het model, daar waar de rode, groene en blauwe as elkaar kruisen (Figuur 14).

FIGUUR 14: FICTIEVE VERPLAATSING VAN DE NORMALE VAN HET VLAK NAAR HET NULPUNT VAN HET MODEL

Nadien wordt de normale geprojecteerd op de rode (y), de groene (x) en de blauwe (z) as (Figuur 15). Hierbij wordt ook de lengte van deze projectie bepaald.

FIGUUR 15: FICTIEVE PROJECTIE VAN DE NORMALE OP DE RODE, DE GROENE EN DE BLAUWE AS

De vergelijking met de goniometrische cirkel is evident (Figuur 16):

FIGUUR 16: VERGELIJKING MET DE GONIOMETRISCHE CIRKEL

Voor het bepalen van de oriĂŤntatie van een vlak wordt enkel gekeken naar de projectie van de normale op de rode (y) en groene (x) as. Maar omdat de helling van het vlak hier een impact op heeft (de lengte van de projectie van de normale op de y- en x-as wordt namelijk beĂŻnvloed door de helling van het vlak), moet er een correctie worden toegepast. De lengte van de normale op het vlak moet zodanig worden aangepast dat de invloed van de helling vervalt. De nieuwe lengte van de normale wordt bekomen d.m.v. volgende berekening: L = 1/(sin(cos-1(Lz))) met Lz de lengte van de projectie van de huidige normale op de z-as. De lengte van de nieuwe normale wordt d.m.v. volgende code aangepast:

z = normale[2] #z = de lengte van de projectie van de huidige normale op de z-as normale.length = 1/ (Math.cos(Math.asin(z))) #pas de lengte van de normale aan.

De nieuwe lengte van de normale wordt in dit voorbeeld nu 1,41421 Inch. Wanneer de normale met deze lengte vervolgens wordt geprojecteerd op de x- en y-as, wordt een projectielengte bekomen die gelijk is aan de projectielengte van de normale op het vlak wanneer het vlak verticaal zou hebben gestaan (en de normale dus horizontaal). In het getoonde voorbeeld is de projectielengte van de nieuwe normale op de x-as gelijk aan 1 Inch. De projectielengte op de y-as blijft 0 Inch (Figuur 18):

FIGUUR 17: PROJECTIELENGTE OP DE Y-AS VAN DE NORMALE MET AANGEPASTE LENGTE

Conventioneel wijst de positieve groene as in SU de richting van het noorden aan (0°), de negatieve (stippellijn) het zuiden (180°). De positieve rode as wijst de richting van het oosten aan (90°), de negatieve het westen (270°). Het bepalen van de exacte hoek gebeurt door het toepassen van goniometrische functies op de projectielengtes van de normale op de x- en y-as d.m.v. volgende code:

#Gaat verder op voorgaande code orientatie_x = normale[1] orientatie_y = normale[0] orientatie = nil if orientatie_y > 0 orientatie = Math.acos(orientatie_x) * (180/(Math::PI)) elsif orientatie_y < 0 orientatie = 360 – (Math.acos(orientatie_x) * (180/(Math::PI))) elsif orientatie_x == 1 orientatie = 0 elsif orientatie_x == -1 orientatie = 180 end

In een eerste voorbeeld (Figuur 18) heeft het vlak een oriëntatie van 30°. De projectielengte van de (gecorrigeerde) normale op de x-as bedraagt 0,866025 Inch en 44

0,5 Inch op de y-as. Volgens voorgaande code wordt de volgende goniometrische functie uitgevoerd:

orientatie_x = 0.866025 orientatie_y = 0.5 #orientatie_y > 0 orientatie = Math.acos(orientatie_x) * (180/(Math::PI)) #orientatie = 30

FIGUUR 18: PROJECTIELENGTES VAN DE NORMALE OP EEN VLAK MET EEN ORIENTATIE VAN 30°

In een volgend voorbeeld wordt een vlak verondersteld met een oriëntatie van 135°. De projectielengte van de (gecorrigeerde) normale op de x-as bedraagt -0,707107 Inch en 0,707107 Inch op de y-as (Figuur 19). De volgende goniometrische functie wordt uitgevoerd:

orientatie_x = -0.707107 orientatie_y = 0.707107 #orientatie_y > 0 orientatie = Math.acos(orientatie_x) * (180/(Math::PI)) #orientatie = 135

FIGUUR 19: PROJECTIELENGTES VAN DE NORMALE OP EEN VLAK MET EEN ORIENTATIE VAN 135°

Als laatste voorbeeld wordt een vlak gekozen met een oriëntatie van 250°. De projectielengte van de (gecorrigeerde) normale op de x-as bedraagt -0,342020 Inch en -0,939693 Inch op de y-as (Figuur 20). De volgende goniometrische functie wordt uitgevoerd:

orientatie_x = -0.342020 orientatie_y = -0.939693 #orientatie_y < 0 orientatie = 360 – (Math.acos(orientatie_x) * (180/(Math::PI)))

#orientatie = 250

FIGUUR 20: PROJECTIELENGTES VAN DE NORMALE OP EEN VLAK MET EEN ORIENTATIE VAN 250°

4.5.2_ OMVORMEN TOT DE ORIËNTATIE VOLGENS DE EPB Hoewel de hoek van een conventionele oriëntatie ligt binnen een bereik van 0° tot 360°, wordt binnen de EPB gerekend met waarden binnen een bereik van -180° tot 180°. Het omvormen van de conventionele oriëntatie tot een oriëntatie die bruikbaar is voor de EPB geschiedt eenvoudigweg door het verminderen van de conventionele oriëntatie met 180° (Figuur 21):

orientatie_volgens_epb = orientatie - 180

FIGUUR 21: ORIËNTATIE VOLGENS DE EPB SOFTWARE VLAANDEREN (HTTP://WWW.ENERGIESPAREN.BE)

4.5.3_ SOLAR NORTH-TOOL In SU versie 8 werd een nieuwe tool toegevoegd, de Solar North-tool (Figuur 22). Deze tool geeft gebruikers de mogelijkheid handmatig de richting van het noorden te wijzigen. Het spreekt voor zich dat bij het bepalen van de oriëntatie van een vlak met deze mogelijkheid rekening moet worden gehouden. De hoek van het door de gebruiker bepaalde noorden t.o.v. het conventionele noorden (groene as) kan worden gevonden met behulp van de ‘shadow_info’-method van het actieve model:

si = Sketchup.active_model.shadow_info na = si["NorthAngle"]

Het implementeren van deze ‘NorthAngle’ bij het bepalen van de oriëntatie van een vlak gebeurt d.m.v. volgende code:

… orientatie_volgens_epb -= na #verminder de originele orientatie_volgens_epb met ‘NorthAngle’ if orientatie_volgens_epb < -180 #Wanneer orientatie_volgens_epb nu lager is dan -180 dan: orientatie_volgens_epb += 360 #Tel er dan 360 bij end#if

FIGUUR 22: SOLAR NORTH-TOOL

Het (handmatig) analyseren van de oriëntatie van een vlak en de werking van de Solar North-tool kan worden bekeken in volgend videofragment:

http://www.youtube.com/watch?v=U9U_eILNHrM Hoewel in voorgaand videofragment de oriëntatie op handmatige wijze wordt bepaald, gebeurt dit d.m.v. de plug-in automatisch.

4.6_ OPBOUWEN - EN MATERIALENBIBLIOTHEEK 4.6.1_ METHODE Voordat de gebruiker effectief bepaalde opbouwen kan koppelen aan constructieelementen, moeten eerst een aantal opbouwen worden gedefinieerd in een bibliotheek. Deze bibliotheek kan best op gelijkaardige wijze worden geconstrueerd als de bibliotheek die ook beschikbaar is in het programma EPB Software Vlaanderen. Hierin kunnen een aantal materialen worden gedefinieerd die vervolgens dienst doen als de lagen van een bepaalde opbouw. Bij installatie van deze plug-in moeten al een aantal materialen en opbouwen in deze bibliotheek worden voorzien. Daarnaast moet het voor de gebruiker mogelijk zijn om zelf een aantal materialen toe te voegen. Vervolgens moet hij ook zelf opbouwen kunnen definiĂŤren (Figuur 23) en moet er de mogelijkheid zijn om deze toegevoegde materialen en opbouwen aan te passen en te verwijderen.

FIGUUR 23: BIBLIOTHEEK: TOEVOEGEN VAN OPBOUWEN

Als drager van deze bibliotheek werd gekozen om te werken met XML-bestanden (Extensible Markup Language). Deze bestanden zijn relatief eenvoudig te begrijpen en met eender welke tekstverwerker aan te maken. Een klein deel van de standaard materialen bibliotheek is opgebouwd als volgt:

<?xml version='1.0'?> <materialen> <type naam='opake materialen'> <soort naam='hout'> <mat volumieke_massa='500' naam='Zacht hout'/> <mat volumieke_massa='700' naam='Hard hout'/> </soort> <soort naam='isolatie'>

soortelijke_warmte='1600'

lambda='0.13'

soortelijke_warmte='1600'

lambda='0.18'

soortelijke_warmte='1400'

lambda='0.035'

lambda='0.040'

</type> <type naam='niet-homogene materialen'> </type> </materialen>

De grafische voorstelling van deze bibliotheek wordt verzorgd d.m.v. een UI opgebouwd uit HTML, Javascript en CSS (hoofdstuk 4.9; “Definitieve vormgeving van pop-up User Interfaces”). Ook hier zou men kunnen kiezen voor Adobe Flash of Microsoft Excel. Maar, zoals eerder vermeld, zorgt dit voor meer complexiteit.

4.6.2_ REXML: RUBY’S BEHANDELING VAN XML-BESTANDEN Het analyseren en eventueel bewerken van de XML-bestanden doet Ruby met behulp van REXML18, een uitbreidingsbibliotheek voor Ruby. Het inladen van deze bibliotheek gebeurt als volgt:

require 'rexml/document’ include REXML

Het door Ruby laten openen van XML-bestanden gaat als volgt:

xml_file_materialen xml_document_materialen

= File.new(“xml/materialen_lib.xml", "r") #r van Read = Document.new xml_file_materialen

Na eventuele wijzigingen te hebben aangebracht in ‘xml_document_materialen’, kan dit op volgende manier worden opgeslagen in het bestand:

xml_file_materialen = File.new(“xml/materialen_lib.xml", "w") #w van Write xml_file_materialen.write(xml_document_materialen) xml_file_materialen.close

De werking van de bibliotheek doorheen de testfase kan worden bekeken in volgend videofragment:

http://www.youtube.com/watch?v=77kMwbk0F0Y 18

http://www.germane-software.com/software/rexml/docs/tutorial.html

Enkel de materialen en opbouwen die door de gebruiker zelf worden aangemaakt, kunnen bewerkt en verwijderd worden (Figuur 24). Op die manier kunnen geen standaard materialen en opbouwen per ongeluk worden gewist.

FIGUUR 24: BIBLIOTHEEK: LIJST VAN OPAKE MATERIALEN

4.6.3_ TOEKENNEN VAN GEDEFINIEERDE OPBOUWEN AAN CONSTRUCTIE-ELEMENTEN Wanneer voor een bepaald type constructie-element (schilvloeren, opake schilmuren, â&#x20AC;Ś) een opbouw is gedefinieerd in de bibliotheek, kan deze opbouw worden toegekend aan alle constructie-elementen van dit type. Het toekennen van een opbouw aan een constructie-element gebeurt op volgende wijze: Wanneer de tool voor het analyseren van de constructie-elementen actief is, klikt men op het constructie-element waarvan men de opbouw wil wijzigen. Vervolgens verschijnt er een pop-up UI op het scherm waarin d.m.v. een drukknop een bepaalde opbouw aan het constructie-element wordt gekoppeld (Figuur 25). De actieve opbouw wordt tevens d.m.v. een grijze achtergrond weergegeven.

FIGUUR 25: USER INTERFACE VOOR HET TOEKENNEN VAN OPBOUWEN AAN CONSTRUCTIE-ELEMENTEN

In deze versie van de plug-in kan enkel de opbouw van opake constructie-elementen worden gewijzigd. Bijgevolg kunnen ook enkel opbouwen voor opake constructies worden toegevoegd aan de bibliotheek. Het wijzigen van de opbouw van een constructie-element kan in volgend videofragment worden bekeken:

http://www.youtube.com/watch?v=OFMdPn9GwjE

4.7_ P ROJECTGEGEVENS 4.7.1_ METHODE Naast gebouwgeometrische gegevens (zoals oppervlaktes, volumes, oriëntatie, …) en de opbouw van de constructie-elementen, zijn ook enkele andere gegevens vereist voor de analyse van EPB en zomercomfort. De gebruiker dient te specificeren of het getekende model een normwoning, een normwoning+, een lage-energiewoning of een passiefwoning is. Dit is nodig voor de bepaling van de standaard opbouw die aan de constructieelementen wordt toegekend alvorens de gebruiker zelf een opbouw toekent. Dit laat de gebruiker toe om een eerste evaluatie te maken van zijn ontwerp in de vroege ontwerpfase, nog voordat de opbouw concreet gekend is. Hierdoor is het nodig om deze projectgegevens in te geven voordat er een opbouw aan de constructie-elementen kan worden toegekend. Daarnaast moet de gebruiker de constructiewijze aangeven, namelijk of het een woning betreft met spouwmuren (half zwaar) of in houtskelet (licht). Dit bepaalt de thermische massa van het gebouw. Tenslotte moeten enkele gegevens worden ingevuld betreffende de verschillende installaties voor warm tapwater, verwarming en ventilatie. Ook hier kan in eerste instantie gewerkt worden met standaardwaarden voor een eerste evaluatie in vroege ontwerpfase. Deze gegevens worden d.m.v. een ‘AttributeDictionary’ in het skp-bestand opgeslagen. Het aanmaken van een ‘AttributeDictionary’ en het toekennen van enkele attributen gebeuren als volgt:

model = Sketchup.active_model settings_library = model.attribute_dictionary "SETTINGS", true settings_library["type_gebouw"] = “passiefwoning” settings_library["constructiewijze"] = “houtskelet”

Ook de UI (Figuur 26) voor het ingeven van deze projectgegevens is vormgegeven d.m.v. HTML, Javascript en CSS (hoofdstuk 4.9; “Definitieve vormgeving van pop-up User Interfaces”).

FIGUUR 26: USER INTERFACE VOOR HET BEPALEN VAN ENKELE PROJECTGEGEVENS

De werking kan in volgend videofragment worden bekeken:

http://www.youtube.com/watch?v=HocA3qEf20w

4.8_ B EREKENEN EN TONEN VAN DE RESULTATEN 4.8.1_ KOPPELING MET MICROSOFT EXCEL 4.8.1.1_EEN BESTAAND EXCEL-BESTAND OP DE ACHTERGROND OPENEN In een vorig hoofdstuk (hoofdstuk 4.1.2.2; “Een User Interface d.m.v. Microsoft Excel”) werd al beperkt besproken hoe de koppeling tussen Ruby en Microsoft Excel tot stand komt d.m.v. de win32ole uitbreidingsbibliotheek voor Ruby. In dat hoofdstuk werd een nieuw Excel-bestand aangemaakt. Het openen van een bestaand Excel-bestand gebeurt op volgende wijze:

require ‘win32ole.so’ #Als win32ole nog niet is geladen moet dit nu gebeuren. excel = WIN32OLE.new('Excel.Application') #Een nieuwe WIN32(Excel)-toepassing aanmaken. workbook = excel.workbooks.open(“excel_bestand.xls") #Open “excel_bestand.xls”

Standaard wordt Excel op de achtergrond geopend. De gebruiker merkt bijgevolg niets van dit proces. Als het nodig is om het geopende Excel-bestand toch te tonen aan de gebruiker kan het vorige script worden uitgebreid met deze regel:

excel.visible=true #Maak excel zichtbaar

Het sluiten van het Excel-bestand gebeurt op deze manier:

workbook.close savechanges = false

#Sluit het Excel-bestand zonder wijzigingen op te slaan

Op deze manier is enkel het Excel-bestand gesloten, maar de Excel-applicatie blijft nog steeds geopend. Om de applicatie te sluiten wordt volgende code gebruikt:

excel.quit

#Sluit de Excel-applicatie

4.8.1.2_VERZENDEN EN ONTVANGEN VAN DATA Wanneer het correcte Excel-bestand is geopend d.m.v. de code uit vorig hoofdstuk, is het verzenden en ontvangen van data op eenvoudige wijze te realiseren. Allereerst moet het correcte werkblad worden gekozen. Het selecteren van het eerste werkblad gebeurt op volgende wijze:

worksheet = workbook.workscheets(1)

#selecteer het eerste werkblad

Ieder werkblad bestaat uit een aantal cellen (A1,A2, …). Aan deze cellen kan een waarde worden gekoppeld. Ter wijze van illustratie wordt aan cel C5 een waarde 987 gekoppeld:

waarde = 987 worksheet.range(‘C5’).value = waarde

#De waarde is 987 #Vul de waarde in in cel C5

Het lezen van de waarde van een bepaalde cel gebeurt op simultane wijze:

waarde = worksheet.range(‘C5’).value

#koppel de waarde van cel C5 aan de variabele ‘waarde’

Een volledig overzicht van alle objecten, eigenschappen en methoden voor de koppeling met Excel te verwezenlijken kan worden gevonden in het boek van S. Roman (2002): “Writing Excel Macros with VBA”.

4.8.2_ OPSTELLEN VAN DE NAAR EXCEL TE VERZENDEN DATA 4.8.2.1_ALGEMEEN Wanneer van alle ruimtes is bepaald of zij al dan niet verwarmd zijn, aan alle constructieelementen een opbouw is toegekend (al dan niet de standaard opbouw) en de projectgegevens zijn gedefinieerd, kan de analyse van EPB en zomercomfort gebeuren. Beide berekeningen geschieden d.m.v. een koppeling met een Excel-bestand; één bestand voor de EPB en twee bestanden voor het zomercomfort, afhankelijk van de gekozen constructiewijze (spouwmuur of houtskelet) in de projectgegevens. De EPB wordt berekend voor het volledige gebouw. Het zomercomfort wordt voor iedere verwarmde ruimte afzonderlijk berekend. De plug-in moet zeer snel tot een analyse van EPB en zomercomfort komen. Om dit te realiseren wordt bij het automatisch analyseren van de constructie-elementen aan ieder constructie-element een standaard opbouw gekoppeld. Aan deze standaard opbouw is geen exacte U-waarde gebonden maar een U-bereik. Dit U-bereik is afhankelijk van het gekozen woningtype in de projectgegevens. Wanneer de keuze wordt gemaakt voor ‘passiefwoning’ bedraagt dit U-bereik 0,10 – 0,15 W/m²K. Kiest de gebruiker voor ‘lage-energiewoning+’, bedraagt dit U-bereik 0,15 – 0,25 W/m²K. Bij keuze van een ‘normwoning+’ bedraagt dit U-bereik 0,20 – 0,30 W/m²K. Tenslotte wordt ook de mogelijkheid ‘normwoning’ voorzien. Bij deze keuze bedraagt het U-bereik 0,25 – 0,35 W/m²K. Voor elk type woning zullen de U-waarden doorgaans tussen deze waarden van het U-bereik liggen. Bijgevolg wordt iedere berekening twee maal uitgevoerd. Een eerste maal wordt de berekening gedaan met de minimale U-waarde van het U-bereik, een tweede maal met de maximale U-waarde van het U-bereik. De eigenlijke analyse van EPB en zomercomfort gebeurt a.d.h.v. een vlakkenmodel. Het model dat door de gebruiker in dikte werd gemodelleerd moet hierdoor worden omgevormd tot een vlakkenmodel. Logischerwijs kan worden gesteld dat alle buitenste vlakken van de gemodelleerde constructie-elementen deze rol kunnen vervullen. Dit is niet correct. In dit geval zouden er problemen optreden aan de hoeken van het model (Figuur 27).

FIGUUR 27: AANSLUITING VAN CONSTRUCTIE-ELEMENTEN IN DE HOEKEN

Het bovenste vlak van de schil ‘muur’ is in principe een schil ‘dak’. Maar omdat dit vlak behoort tot de gemodelleerde schil ‘muur’, zou bij deze methode voor het bepalen van het 55

vlakkenmodel dit vlak de opbouw van de schil ‘muur’ toegewezen krijgen. Dit is bijgevolg niet de juiste methode. Een andere wijze voor het bepalen van het vlakkenmodel werd op volgende manier bekomen: Van ieder vlak van elke verwarmde ruimte wordt nagegaan met welke oppervlakte zij raakt aan een bepaald constructie-element. Al deze gegevens (aanraakoppervlak, type constructie-element en opbouw van het constructie-element) worden als attributen gekoppeld aan dit vlak van de verwarmde ruimte. Het vlakkenmodel dat wordt gebruikt voor de analyse bestaat bijgevolg uit de verwarmde binnenruimtes. Het koppelen van attributen aan een entiteit (bvb. een vlak) wordt gerealiseerd met de volgende code:

oppervlakte = 20 #Stel oppervlakte in op 20 face.set_attribute “titel_van_de_lijst”, “naam_van_het_attribuut”, oppervlakte

Het nadien oproepen van gekoppelde attributen gebeurt op volgende wijze:

oppervlakte = face.get_attribute “titel_van_de_lijst”, “naam_van_het_attribuut”

4.8.2.2_EPB BESCHERMD VOLUME: Allereerst moet het beschermd volume van het gebouw worden bepaald. Logischerwijs zou het beschermd volume van een gebouw de totale som zijn van het volume van iedere binnenruimte en het volume van ieder schildeel. Dit is echter niet geldig voor elk model. Eén bepaald schildeel kan zowel aan een verwarmde ruimte en een niet verwarmde ruimte grenzen. Dit wordt geïllustreerd a.d.h.v. volgende afbeelding (Figuur 28).

FIGUUR 28: SCHILDELEN KUNNEN GELIJKTIJDIG AAN EEN VERWARMDE EN EEN NIET VERWARMDE RUIMTE GRENZEN.

Het deel van het schildeel dat grenst aan een niet verwarmde ruimte behoort niet tot het beschermd volume. Voor het bepalen van het beschermd volume werd een andere methode bekomen: Ieder vlak van elke verwarmde ruimte automatisch ‘gepushpulld’ met de gemiddelde dikte van alle aanrakende constructie-elementen. Een vlak dat bijv. met een oppervlakte van 4m² raakt aan een constructie-element met dikte 0,30m en met een oppervlakte van 6m² raakt aan een constructie-element met dikte 0,14m, wordt gepushpulld over een afstand van ((4m²/10m²) x 0,30m) + ((6m²/10m²) x 0,14m) = 0,204m. Wanneer alle vlakken van iedere verwarmde ruimte deze berekening hebben ondergaan, is het beschermd volume gelijk aan de som van het volume van iedere verwarmde ruimte (na het ‘pushpullen’ van ieder vlak van deze ruimten). In een eerdere versie van de plug-in werd de exacte dikte van de toegekende opbouw van het constructie-element gebruikt voor deze berekening. Wanneer vervolgens een nieuwe opbouw met een verschillende dikte werd toegekend aan een constructie-element, veranderde bijgevolg ook het beschermd volume. Maar, het is een courante methode om te modelleren a.d.h.v. buitenafmetingen. Omdat de berekening van het beschermd volume vertrekt van de maatvoering van de binnenruimtes, was het nodig een nieuwe modelleereis te implementeren. Opake schildelen moeten nu met een dikte van 0,30m worden gemodelleerd en binnenconstructies met een dikte van 0,14m. Bijgevolg wordt voor het berekenen van de waarde waarmee ieder vlak moet worden ’gepushpulld’ ook niet meer gekeken naar de werkelijke dikte van de toegekende opbouw, maar liggen deze diktes vast op 0,30m voor de schildelen en 0,07m (0,14m / 2) voor de binnenconstructies. Op deze manier wordt een correct beschermd volume bekomen en vervolgens verzonden naar de Excel-rekenmodule. TOTALE VERLIESOPPERVLAKTE: De totale verliesoppervlakte wordt bepaald a.d.h.v. buitenafmetingen. Wanneer van ieder vlak van een ruimte wordt nagegaan met welke oppervlakte zij raakt aan een schildeel of binnenconstructie, zijn dit binnenafmetingen. Deze binnenafmetingen moeten bijgevolg worden omgevormd tot buitenafmetingen. Allereerst moet de oppervlakte van het vlak worden bepaald nadat alle vlakken van de ruimte waartoe dit vlak behoort zijn ‘gepushpulld’. De oppervlakte van een vlak wordt d.m.v. volgende code bekomen:

oppervlakte = face.area

#Bepaal de oppervlakte van het vlak

Omdat SU intern rekent in Inches, is de bekomen oppervlakte in square Inches. Ook hier moet de oppervlakte worden omgevormd tot vierkante meter d.m.v. de ‘.to_m’ method:

oppervlakte = face.area.to_m.to_m

De totale oppervlakte van het vlak voordat het ‘pushpullen’ was gebeurd, is de som van alle aanraakoppervlakken van dat vlak. Vervolgens wordt een nieuwe factor bepaald; de ‘pushpull-vergrotingsfactor’. Deze factor is gelijk aan de verhouding van de oppervlakte van het vlak na ‘pushpullen’ gedeeld door de oppervlakte van het vlak voor ‘pushpullen’:

pushpull_vergrotingsfactor = face.area.to_m.to_m / oppervlakte_voor_pushpull #oppervlakte_voor_pushpull moet uiteraard worden bepaald.

De totale verliesoppervlakte van een vlak (buitenafmetingen) wordt bijgevolg bekomen door de som van de oppervlakte van alle aangrenzende oppervlakten welke raken aan een schildeel, te vermenigvuldigen met de ‘pushpull-vergrotingsfactor’. Dit is een eenvoudige voorstelling van de berekening. In realiteit is deze berekening complexer 57

omdat er ook rekening moet worden gehouden met het feit dat transparante schildelen niet onderhevig zijn aan deze pushpull-vergrotingsfactor. Beglazing wordt reeds a.d.h.v. buitenafmetingen gemodelleerd. BRUTO VLOEROPPERVLAKTE: De berekening van de bruto vloeroppervlakte gebeurt op dezelfde wijze als het bepalen van de totale verliesoppervlakte. Verschillend is dat voor deze berekening enkel de aanraakoppervlakken die raken aan schil ‘vloeren’ of binnenvloeren in rekening worden gebracht. INVULLEN VAN DE VERSCHILLENDE VERLIESOPPERVLAKKEN: Allereerst wordt er een lijst (array) gemaakt waarin per verliesoppervlak de helling en oriëntatie van dat verliesoppervlak wordt opgeslagen. Het aanmaken van deze lijst ziet er als volgt uit:

combinaties = [] #Nieuwe array genaamd ‘combinaties’ verliesoppervlakken.each do |verliesoppervlak| combinaties << [verliesoppervlak.helling, verliesoppervlak.orientatie] #Opgelet: De methods ‘helling’ en ‘orientatie’ moeten worden gedefinieerd, #dit zijn geen standaard methods! end#do

Het bepalen van de helling van een vlak van en verwarmde ruimte gebeurt d.m.v. volgende code:

def helling(face) return(Math.acos(face.normal[2])* (180/(Math::PI))) end#def

Het bepalen van de oriëntatie volgens de EPB van een vlak werd reeds besproken in een voorgaand hoofdstuk (hoofdstuk 4.5; “Oriëntatie volgens de EPB”). Wanneer twee (of meerdere) verschillende verliesoppervlakten eenzelfde oriëntatie en helling hebben komt deze combinatie meermaals voor in de “combinaties” array. Hierdoor moeten eerst alle dubbele ingaven in deze lijst verwijderd worden zodat slechts unieke combinaties van hellingen en oriëntaties overblijven. Het verwijderen van dubbele ingaven in een array ziet er als volgt uit:

combinaties = combinaties.uniq

#Verwijder alle dubbele ingaven

Tenslotte wordt per combinatie de totale verliesoppervlakte, de totale transparante verliesoppervlakte en de gemiddelde U-waarde bepaald van alle verliesoppervlakken met deze helling en oriëntatie die grenzen aan een opaak schildeel. De gemiddelde Uwaarde van deze combinatie wordt op simultane wijze bepaald als de afstand voor het ‘pushpullen’ van alle vlakken van een verwarmde ruimte bij de berekening van het beschermd volume. Enkel wordt nu niet gekeken naar de dikte van het constructie-element maar naar zijn toegekende U-waarde. Dit is een vereenvoudigde weergave, in werkelijkheid is de berekening complexer. Indien er voor deze combinatie van helling en oriëntatie een transparante verliesoppervlakte is waargenomen, moet ook de U-waarde van het glas en van het profiel worden ingevuld. In deze versie van de plug-in is het nog niet mogelijk om beglazing aan te maken in de bibliotheek. Ook is het niet mogelijk om verschillende soorten beglazing toe te kennen aan transparante schildelen. Er wordt gewerkt met een standaardbeglazing. Wanneer de gebruiker in de projectgegevens heeft bepaald dat het type woning een passiefwoning is, is de standaard U-waarde voor 58

het glas 0,6W/m²K en voor het profiel 0,8Wm²K. Dit geeft een indicatieve U-waarde van 0,87W/m²K. Bij alle andere types is de standaard U-waarde voor het glas bepaald van 1,1W/m²K en voor het profiel 2,0W/m²K. Dit geeft een indicatieve U-waarde van 1,58W/m²K. Ook de g-waarde van de beglazing is standaard bepaald op 0,6. CONSTRUCTIEWIJZE: Wanneer de gebruiker bij het bepalen van de projectgegevens aangeeft dat de constructiewijze in houtskelet is, wordt voor de berekening van de EPB met constructiewijze ‘licht’ gewerkt. Wanneer de gebruiker aangeeft dat het een constructiewijze met spouwmuren is, wordt voor de berekening gerekend met ‘half zwaar’. BIJKOMENDE GEGEVENS: Verder worden nog enkele bijkomende gegevens die ook allemaal in de projectgegevens kunnen worden aangepast in rekening gebracht en verzonden naar de Excel rekenmodule voor de analyse van de EPB.

4.8.2.3_ZOMERCOMFORT BINNENVOLUME: Het bepalen van het binnenvolume van een ruimte werd reeds besproken in een voorgaand hoofdstuk (hoofdstuk 4.1; “Analyse van de binnenruimtes”). VLOEROPPERVLAKTE: Het bepalen van de vloeroppervlaktes verloopt op eenzelfde wijze als het bepalen van de bruto vloeroppervlakte voor analyse van de EPB. Enkel wordt voor de analyse van het zomercomfort gerekend met binnenafmetingen. TOTALE VERLIESOPPERVLAKTE: De totale verliesoppervlakte van een ruimte wordt op dezelfde manier bepaald als het berekenen van de totale verliesoppervlakte voor de EPB-analyse. Ook hier wordt gewerkt met buitenafmetingen. Alle vlakken van de ruimte zullen bijgevolg eerst automatisch moeten worden ‘gepushpulld’. D.m.v. de ‘pushpull-vergrotingsfactor’ kan de totale verliesoppervlakte volgens buitenafmetingen worden bekomen. GEMIDDELDE U-WAARDE: De gemiddelde U-waarde van alle verliesoppervlakken van een ruimte worden op dezelfde manier bepaald als het berekenen van de gemiddelde U-waarde van een combinatie bij de EPB-analyse. Het enige verschil is dat bij het bepalen van de gemiddelde U-waarde voor het zomercomfort ook de transparante schildelen in rekening moeten worden gebracht. Tevens wordt er geen onderscheid gemaakt tussen verliesoppervlakken met een verschillende helling en oriëntatie. BEPALEN VAN DE VERSCHILLENDE VLAKKEN VAN EEN RUIMTE: Bij het invullen van de verschillende vlakken van een ruimte wordt er een onderscheid gemaakt tussen opake vlakken en transparante vlakken. De opake vlakken worden verder onderverdeeld in binnenmuren, buitenmuren, vloeren en daken en plafonds. De transparante vlakken worden verdeeld in ramen in buitenmuren en dakramen. Van ieder vlak van de ruimte wordt nagegaan met welke oppervlakte zij raakt aan een bepaald constructie-element. Al deze gegevens (aanraakoppervlak, type constructie-element en opbouw van het constructie-element) worden als attributen gekoppeld aan het vlak. Vervolgens wordt de som gemaakt van alle aanraakoppervlakken die raken aan een binnenmuur, een buitenmuur, een vloer, een dak of plafond, een raam in een buitenmuur en een dakraam. Omdat het voor de analyse van het zomercomfort is toegestaan te werken met binnenafmetingen, moet hier geen ‘pushpull-vergrotingsfactor’ in rekening worden gebracht. De waarden kunnen rechtstreeks naar Excel worden verzonden. Naast de oppervlakte van een bepaald opaak vlak, moeten ook de verschillende lagen van de opbouw naar Excel worden verzonden. Per laag van de opbouw wordt de dikte, de volumieke massa en de soortelijke warmtecapaciteit van de laag vereist. Hoewel de materialen- en opbouwenbibliotheek van deze plug-in hier reeds voor is geoptimaliseerd (bij het toevoegen van een materiaal aan de bibliotheek wordt ook de volumieke massa en de soortelijke warmtecapaciteit gevraagd), is dit nog niet geïmplementeerd in de 59

huidige versie van de plug-in. In deze versie is er voor ieder type opaak vlak een standaardopbouw ingegeven. Wanneer de gebruiker in de projectgegevens kiest voor een constructiewijze met spouwmuren, worden de standaard opbouwen en lagen toegekend zoals getoond in Figuur 29. Kiest de gebruiker echter voor een constructiewijze met houtskelet, worden de standaard opbouwen en lagen toegekend zoals getoond in Figuur 30.

FIGUUR 29: STANDAARD OPBOUWEN ZOMERCOMFORT: CONSTRUCTIEWIJZE SPOUWMUREN

FIGUUR 30: STANDAARD OPBOUWEN ZOMERCOMFORT: CONSTRUCTIEWIJZE HOUTSKELET

Naast opake vlakken moeten ook een aantal gegevens per transparant vlak worden ingevuld zoals: de U-waarde van het glas, de U-waarde van het profiel, de oppervlakte van het venster, de G-waarde, de helling, de oriëntatie en de schaduwfactor. De Uwaarde van het glas en profiel en de G-waarde, de helling en de oriëntatie van het venster worden op dezelfde wijze bepaald als voor de analyse van de EPB. Voor de reductiefactor voor beschaduwing werd in deze versie van de plug-in gekozen voor een coëfficiënt, namelijk 0,8.

4.8.3_ TONEN VAN DE RESULTATEN AAN DE GEBRUIKER 4.8.3.1_EPB Naast het ophalen van de resultaten uit de Excel-rekenmodule, moeten deze ook worden getoond aan de gebruiker. Ook hier werd gekozen voor een eenvoudige UI welke is vormgegeven d.m.v. HTML, Javascript en CSS (hoofdstuk 4.9; “Definitieve vormgeving van pop-up User Interfaces”) (Figuur 31). In deze UI worden naast de conventionele gegevens zoals K- en E-peil ook de gemiddelde U-waarde, het beschermd volume, de totale verliesoppervlakte, de compactheid en de bruto vloeroppervlakte getoond aan de gebruiker. Omdat de opbouw die standaard wordt gegeven aan ieder constructieelementen een U-bereik is i.p.v. een exacte U-waarde, worden het K- en E-peil en de gemiddelde U-waarde twee maal getoond, respectievelijk een minimale en een maximale waarde. De minimale waarden illustreren de resultaten berekend met de minimale waarde van het U-bereik, de maximale waarden echter illustreren de resultaten berekend met de maximale waarde van het U-bereik.

FIGUUR 31: USER INTERFACE VOOR HET TONEN VAN DE EPB RESULTATEN

4.8.3.2_ZOMERCOMFORT Een eerste visuele referentie betreffende het zomercomfort gebeurt d.m.v. het inkleuren van een ruimte in een bepaalde kleur. Deze kleur is afhankelijk van de maximale maandtemperatuur die in deze ruimte heerst. Wanneer de maximale maandtemperatuur voor een bepaalde ruimte zowel bij de berekening met de minimale U-waarde als bij berekening met de maximale U-waarde niet hoger ligt dan 26°C, wordt een groene kleur aan de ruimte gegeven. Ligt de maximale maandtemperatuur tussen 26°C en 28°C, krijgt de ruimte een oranje kleur. Vanaf 28°C wordt de ruimte in het rood getoond. Wanneer de gebruiker vervolgens op één van de ruimtes klikt, verschijnt een nieuwe pop-up UI waarin meer gegevens (binnenvolume, netto vloeroppervlakte, verliesoppervlakte, gemiddelde U-waarde en maximale maandtemperatuur) van de geselecteerde ruimte worden getoond (Figuur 32).

FIGUUR 32: USER INTERFACE VOOR HET TONEN VAN DE RESULTATEN VAN DE ZOMERCOMFORTANALYSE

4.9_ D EFINITIEVE VORMGEVING VAN POP - UP U SER I NTERFACES 4.9.1_ JQUERY Alle UIs die in de ‘WebdialogBox’ vormgegeven worden d.m.v. HTML, JavaScript en CSS maken gebruik van jQuery 19 , een open-source uitbreidingsbibliotheek voor JavaScript. jQuery bestaat in de eerste plaats om snel complex ogende websites te maken en dit met behulp van enkele ‘widgets’ 20 . Omdat ook alle UIs die gebruik maken van de ‘WebdialogBox’ in principe websites zijn, is jQuery uiterst functioneel voor het vormgeven van deze UIs.

4.9.2_ THEMEROLLER De uiteindelijke opmaak van deze UIs gebeurt d.m.v. CSS met de hulp van ThemeRoller21. Dit is een online generator voor css-bestanden, waarmee snel verschillende thema’s kunnen worden gegenereerd. Ook het thema dat gebruikt wordt door deze plug-in is hiermee gemaakt. Op volgend videofragment wordt bij wijze van illustratie de bibliotheektool getoond met een ander thema:

http://www.youtube.com/watch?v=0P4oDKGBX8o

http://jquery.com http://jqueryui.com/demos/accordion 21 http://jqueryui.com/themeroller

5_ VALIDATIE VAN DE PLUG-IN 5.1_ H ET VALIDATIEMODEL 5.1.1_ HET VALIDATIEMODEL IN GOOGLE SKETCHUP Voor de validatie van de plug-in werd een eenvoudig model aangemaakt. Het betreft een gebouw met slechts twee binnenruimtes, elk met een oppervlakte van 20,37m² (4,40m x 4,63m) De ruimtes worden gescheiden d.m.v. een binnenmuur met dikte 0,14m. Alle schildelen (buitenmuren, daken en vloeren) hebben een dikte van 0,30m. Het grondplan van het validatiemodel wordt op de volgende afbeelding weergegeven:

FIGUUR 33: GRONDPLAN VAN HET VALIDATIEMODEL

Beide ruimtes hebben een hoogte van 2,60m. Bijgevolg is het binnenvolume van iedere ruimte 52,967m³. Doordat alle schildelen 0,30m dik zijn, wordt de verliesoppervlakte voor de noorden zuidgevel (lange gevels) 32m² (10,00m x 3,20m) en 16m² (5,00m x 3,20m) voor de oosten westgevel (korte gevels). In het model worden de buitengevels als twee verschillende groepen gemodelleerd. Dit biedt namelijk de mogelijkheid om twee verschillende opbouwen te koppelen aan deze gevels. De door de gebruiker gekoppelde textuur of kleur aan een constructie-element heeft geen invloed op de analyse van EPB en zomercomfort. Op volgende afbeelding wordt het onderscheid gemaakt tussen de twee groepen die de buitengevels voorstellen door er een andere textuur aan te geven; dit is louter illustratief:

FIGUUR 34: NOORD- EN OOSTGEVEL VAN HET VALIDATIEMODEL

Beide ruimtes van het validatiemodel hebben een raam op het zuiden. Dit raam heeft een oppervlakte van 5,2m² (2,00m x 2,60m). Aan het raam werd een blauwe transparante kleur toegekend (Figuur 35). In principe kan ieder transparant materiaal aan het raam worden toegekend. De dikte van dit raam speelt geen rol, maar het raam moet wel worden gepositioneerd tot tegen het binnenvlak van het omgrenzende constructie-element.

FIGUUR 35: ZUID- EN WESTGEVEL VAN HET VALIDATIEMODEL

Wanneer beide ruimtes van het validatiemodel verwarmd zijn, is het beschermd volume gelijk aan 160m³ (5,00m x 10,00m x 3,20m). De totale verliesoppervlakte is dan 196m² en de bruto vloeroppervlakte bedraagt dan 50m².

5.1.2_ HET VALIDATIEMODEL IN EPB SOFTWARE VLAANDEREN Dezelfde geometrische gegevens van het validatiemodel in SU werden ingegeven in de EPB software:

FIGUUR 36: INVOEREN VAN HET VALIDATIEMODEL IN DE EPB SOFTWARE VLAANDEREN

5.2_ V ALIDATIEPROCEDURE 5.2.1_ EEN EERSTE EENVOUDIGE VALIDATIE In een eerste stap van de validatieprocedure wordt met de volgende gegevens gewerkt (Figuur 37):

FIGUUR 37: STANDAARD PROJECTGEGEVENS

Voor het type gebouw werd gekozen voor ‘passiefwoning’. Dit heeft een impact op de Uwaarden. Bijgevolg wordt in de plug-in een eerste berekening gedaan waarbij alle constructie-elementen een U-waarde van 0,10 W/m²K hebben. Vervolgens wordt een tweede analyse gemaakt met een U-waarde van 0,15 W/m²K voor alle constructieelementen. Voor een passiefwoning zullen de U-waarden doorgaans tussen deze standaardwaardes liggen. Voor de constructiewijze werd gekozen voor een opbouw met spouwmuren. Er werden twee baden/douches en één keukenaanrecht voorzien. Het ventilatiesysteem werd voor deze eerste validatieprocedure op systeem ‘A’ ingesteld. Tenslotte werd gekozen voor een condensatieketel. Dit zijn geen standaardsystemen voor een passiefwoning maar werden louter gekozen omwille van hun eenvoudige invoer in de EPB software. Zo werd een eerste eenvoudige stap van de validatieprocedure genomen. Deze gegevens werden ook in de EPB software ingegeven. De handmatige invoer van opbouwen in de EPB software gebeurde volgens de directe methode (Figuur 38).

FIGUUR 38: KOPPELEN VAN OPBOUWEN AAN SCHILDELEN IN DE EPB-SOFTWARE

Na voltooiing van deze validatieprocedure worden de volgende resultaten in SU aan de gebruiker getoond:

FIGUUR 39: RESULTATEN IN SKETCHUP VALIDATIEPROCEDURE 1

Zowel het beschermd volume, de verliesoppervlakte, de compactheid als de bruto vloeroppervlakte zijn correct. Ook de minimale en maximale E- en K-peilen zijn correct. Na controle in de EPB software worden volgende resultaten voor het E- en K-peil getoond in de EPB software:

FIGUUR 40: LINKS: U-WAARDE 0,10 W/M²K, RECHTS: U-WAARDE 0,15 W/M²K

Naast deze beperkte resultaten worden ook de energiebehoefte voor ruimteverwarming, de energiebehoefte voor koeling en de oververhittingsindicator nauwkeurig met elkaar vergeleken. Bij de eerste analyse (met U-waarde 0,10 W/m²K voor alle opake schildelen) worden de volgende resultaten bekomen in de EPB software: 69

FIGUUR 41: ENERGIEBEHOEFTE VOOR RUIMTEVERWARMING IN DE EPB SOFTWARE MET EEN U-WAARDE VAN 0,10 W/M²K VOOR ALLE OPAKE SCHILDELEN

FIGUUR 42: ENERGIEBEHOEFTE VOOR KOELING IN DE EPB SOFTWARE MET EEN U-WAARDE VAN 0,10 W/M²K VOOR ALLE OPAKE SCHILDELEN

FIGUUR 43: OVERVERHITTINGSINDICATOR IN DE EPB SOFTWARE MET EEN U-WAARDE VAN 0,10 W/M²K VOOR ALLE OPAKE SCHILDELEN

In de Excel-rekenmodule worden volgende resultaten bekomen:

FIGUUR 44: ENERGIEBEHOEFTE VOOR RUIMTEVERWARMING IN DE EXCEL-REKENMODULE MET EEN U-WAARDE VAN 0,10 W/M²K VOOR ALLE OPAKE SCHILDELEN

FIGUUR 45: ENERGIEBEHOEFTE VOOR KOELING IN DE EXCEL-REKENMODULE MET EEN U-WAARDE VAN 0,10 W/M²K VOOR ALLE OPAKE SCHILDELEN

FIGUUR 46: OVERVERHITTINGSINDICATOR IN DE EXCEL-REKENMODULE MET EEN U-WAARDE VAN 0,10 W/M²K VOOR ALLE OPAKE SCHILDELEN

Bij de tweede analyse (met U-waarde 0,15 W/m²K voor alle opake schildelen) worden de volgende resultaten bekomen in de EPB software:

FIGUUR 47: ENERGIEBEHOEFTE VOOR RUIMTEVERWARMING IN DE EPB SOFTWARE MET EEN U-WAARDE VAN 0,15 W/M²K VOOR ALLE OPAKE SCHILDELEN

FIGUUR 48: ENERGIEBEHOEFTE VOOR KOELING IN DE EPB SOFTWARE MET EEN U-WAARDE VAN 0,15 W/M²K VOOR ALLE OPAKE SCHILDELEN

FIGUUR 49: OVERVERHITTINGSINDICATOR IN DE EPB SOFTWARE MET EEN U-WAARDE VAN 0,15 W/M²K VOOR ALLE OPAKE SCHILDELEN

In de Excel-rekenmodule worden volgende resultaten bekomen:

FIGUUR 50: ENERGIEBEHOEFTE VOOR RUIMTEVERWARMING IN DE EXCEL-REKENMODULE MET EEN U-WAARDE VAN 0,15 W/M²K VOOR ALLE OPAKE SCHILDELEN

FIGUUR 51: ENERGIEBEHOEFTE VOOR KOELING IN DE EXCEL-REKENMODULE MET EEN U-WAARDE VAN 0,15 W/M²K VOOR ALLE OPAKE SCHILDELEN

FIGUUR 52: OVERVERHITTINGSINDICATOR IN DE EXCEL-REKENMODULE MET EEN U-WAARDE VAN 0,15 W/M²K VOOR ALLE OPAKE SCHILDELEN

Alle resultaten zijn volledig identiek in de EPB software als in de Excel-rekenmodule.

5.2.2_ EEN ZELF AANGEMAAKTE OPBOUW IN DE OPBOUWEN- EN MATERIALENBIBLIOTHEEK In deze tweede stap wordt een nieuwe opake muuropbouw aangemaakt in de opbouwenen materialenbibliotheek van de plug-in (Figuur 53). Op die manier kan ook de bibliotheek voor de opbouwen gevalideerd worden. Vervolgens wordt dezelfde opbouw aangemaakt in de EPB software (Figuur 54). Nadien wordt deze opbouw gekoppeld aan één van de opake muren van het validatiemodel in SU (Figuur 55) en in de EPB software. Alle andere constructie-elementen behouden de standaard opbouw zoals in de eerste stap. Ook de andere parameters blijven ongewijzigd.

FIGUUR 53: NIEUWE OPAKE SCHILMUUR IN DE OPBOUWEN- EN MATERIALENBIBLIOTHEEK VAN DE PLUG-IN

FIGUUR 54: NIEUWE BUITENMUUR IN DE EPB SOFTWARE VLAANDEREN

FIGUUR 55: TOEVOEGEN VAN DE NIEUW GEDEFINIEERDE OPBOUW AAN EEN CONSTRUCTIE-ELEMENT

Na voltooiing van deze stap worden de volgende resultaten in SU aan de gebruiker getoond:

FIGUUR 56: RESULTATEN IN SKETCHUP VALIDATIEPROCEDURE 2

FIGUUR 57: LINKS: U-WAARDE 0,10 W/M²K, RECHTS: U-WAARDE 0,15 W/M²K

Naast deze beperkte resultaten worden ook de energiebehoefte voor ruimteverwarming, de energiebehoefte voor koeling en de oververhittingsindicator nauwkeurig met elkaar vergeleken. Bij de eerste analyse (met U-waarde 0,10 W/m²K voor alle opake schildelen met de standaard opbouw) worden de volgende resultaten bekomen in de EPB software: 76

FIGUUR 58: ENERGIEBEHOEFTE VOOR RUIMTEVERWARMING IN DE EPB SOFTWARE MET EEN U-WAARDE VAN 0,10 W/M²K VOOR ALLE OPAKE SCHILDELEN MET DE STANDAARD OPBOUW

FIGUUR 59: ENERGIEBEHOEFTE VOOR KOELING IN DE EPB SOFTWARE MET EEN U-WAARDE VAN 0,10 W/M²K VOOR ALLE OPAKE SCHILDELEN MET DE STANDAARD OPBOUW

FIGUUR 60: OVERVERHITTINGSINDICATOR IN DE EPB SOFTWARE MET EEN U-WAARDE VAN 0,10 W/M²K VOOR ALLE OPAKE SCHILDELEN MET DE STANDAARD OPBOUW

In de Excel-rekenmodule worden volgende resultaten bekomen:

FIGUUR 61: ENERGIEBEHOEFTE VOOR RUIMTEVERWARMING IN DE EXCEL-REKENMODULE MET EEN U-WAARDE VAN 0,10 W/M²K VOOR ALLE OPAKE SCHILDELEN MET DE STANDAARD OPBOUW

FIGUUR 62: ENERGIEBEHOEFTE VOOR KOELING IN DE EXCEL-REKENMODULE MET EEN U-WAARDE VAN 0,10 W/M²K VOOR ALLE OPAKE SCHILDELEN MET DE STANDAARD OPBOUW

FIGUUR 63: OVERVERHITTINGSINDICATOR IN DE EXCEL-REKENMODULE MET EEN U-WAARDE VAN 0,10 W/M²K VOOR ALLE OPAKE SCHILDELEN MET DE STANDAARD OPBOUW

Ook tijdens deze validatieprocedure zijn alle resultaten volledig identiek in de EPB software als in de Excel-rekenmodule. Bij de tweede analyse (met U-waarde 0,15 W/m²K voor alle opake schildelen met de standaard opbouw) werden ook dezelfde resultaten bekomen tussen de plug-in en de EPB software.

5.2.3_ EEN ANDER VENTILATIESYSTEEM Deze validatieprocedure bouwt verder op de vorige stap. Het ventilatiesysteem wordt nu gewijzigd in systeem ‘C’:

FIGUUR 64: SELECTIE VAN VENTILATIESYSTEEM ‘C’ IN DE PROJECTGEGEVENS VAN DE PLUG-IN

Na voltooiing van deze validatieprocedure worden de volgende resultaten in SU aan de gebruiker getoond:

FIGUUR 65: RESULTATEN IN SKETCHUP VALIDATIEPROCEDURE 3

Deze gegevens worden opnieuw vergeleken met de resultaten uit de EPB software. Zowel het beschermd volume, de verliesoppervlakte, de compactheid als de bruto vloeroppervlakte zijn correct. Ook de minimale en maximale E- en K-peilen zijn correct:

FIGUUR 66 : LINKS: U-WAARDE 0,10 W/M²K, RECHTS: U-WAARDE 0,15 W/M²K

Naast deze beperkte resultaten werden ook de energiebehoefte voor ruimteverwarming, de energiebehoefte voor koeling en de oververhittingsindicator nauwkeurig met elkaar vergeleken. Deze resultaten zijn net zoals in voorgaande validatieprocedures volledig identiek en worden bijgevolg niet nogmaals opgesomd.

5.2.4_ EEN ANDERE CONSTRUCTIEWIJZE In deze stap werd de constructiewijze van het model in de projectgegevens van de plug-in gewijzigd in ‘houtskelet’ (Figuur 67). Dit heeft een impact op de thermische massa van het gebouw. In de EPB software wordt het type constructie van het model gewijzigd in ‘licht’.

FIGUUR 67: SELECTIE VAN ‘HOUTSKELET’ ALS CONSTRUCTIEWIJZE IN DE PROJECTGEGEVENS VAN DE PLUG-IN

Na voltooiing van deze validatieprocedure worden de volgende resultaten in SU aan de gebruiker getoond:

FIGUUR 68: RESULTATEN IN SKETCHUP VALIDATIEPROCEDURE 4

Opnieuw werden de resultaten vergeleken met de berekening in de EPB software. Zowel het beschermd volume, de verliesoppervlakte, de compactheid als de bruto vloeroppervlakte zijn correct. Ook de minimale en maximale E- en K-peilen zijn correct:

FIGUUR 69: LINKS: U-WAARDE 0,10 W/M²K, RECHTS: U-WAARDE 0,15 W/M²K

Naast deze beperkte resultaten werden ook de energiebehoefte voor ruimteverwarming, de energiebehoefte voor koeling en de oververhittingsindicator nauwkeurig met elkaar 81

vergeleken. Deze resultaten zijn net zoals in voorgaande validatieprocedures volledig identiek en worden bijgevolg niet nogmaals opgesomd.

5.3_ B ESLUIT Hoewel de plug-in ontwikkeld werd voor gebruik in de vroege ontwerpfase, werd d.m.v. voorgaande validatieprocedures aangetoond dat het bijzonder accuraat is. Uiteraard werd deze validatieprocedure doorlopen d.m.v. een eenvoudig model en kwamen niet alle aspecten van de plug-in aan bod. In een toekomstig onderzoek moeten ten eerste meerdere projectgegevens worden gevalideerd. Verder is het ook noodzakelijk dat complexere modellen deze validatieprocedure ondergaan. Deze plug-in is dan ook het product van een thesisonderzoek en moet als dusdanig worden beschouwd.

6_ BEPERKINGEN VAN DE PLUG-IN 6.1_ G EBRUIKSVRIENDELIJKHEID 6.1.1_ MODELLEEREISEN 6.1.1.1_DE MODELLEERDIKTE VAN CONSTRUCTIE-ELEMENTEN IS NIET VRIJ: Uit de enquête bleek dat architecten in de voorontwerpfase modelleren in dikte. Dit werd dan ook tot een modelleereis opgenomen. Bij aanvang van het ontwikkelen van de plug-in werd altijd voor ogen gehouden dat de dikte die wordt gegeven aan de verschillende constructie-elementen vrij moet zijn. Naarmate het ontwikkelen van de plug-in vorderde bleek dat dit niet mogelijk is. De gebruiker moet het model nog steeds in dikte modelleren maar de dikte van deze constructie-elementen is niet vrij te kiezen. Schildelen (met uitzondering van beglazing) moeten met een dikte van 0,30m worden geconstrueerd. Binnenconstructies worden met een dikte van 0,14m opgebouwd. Dit is van belang voor de correcte bepaling van het beschermd volume. Het beschermd volume wordt bepaald d.m.v. het volume van de binnenruimtes. Maar, het is een courante methode om te modelleren a.d.h.v. buitenafmetingen. Bijgevolg ondergaat het volume een bewerking zoals besproken in hoofdstuk 4.8.2; “Opstellen van de naar Excel te verzenden data”.

6.1.1.2_VERSCHILLENDE CONSTRUCTIE-ELEMENTEN MOETEN ALS EEN APARTE GROEP WORDEN GEMODELEERD: Het onderscheid tussen verschillende constructie-elementen, zowel in type (schilmuur, binnenmuur, schildak,…) als in opbouw, gebeurt door het automatisch analyseren van de gemodelleerde groepen/groups in SU. De gebruiker moet hier rekening mee houden. Alle constructie-elementen van een verschillend type en/of opbouw moeten bijgevolg ook als een aparte groep worden gemodelleerd.

6.1.2_ TONEN VAN DE GEGEVENS AAN DE GEBRUIKER In deze versie van de plug-in worden slechts een beperkt aantal gegevens aan de gebruiker getoond. In een verder onderzoek kunnen ook meer gedetailleerde gegevens zichtbaar worden gemaakt. De lagen van een opbouw of de oppervlakte van een constructie-element maar ook gegevens zoals het energieverbruik voor ruimteverwarming zijn hier voorbeelden van. Deze gegevens zijn reeds beschikbaar in de Excel-rekenmodule en gebruikte xml-bestanden. Enkel een geschikte User Interface moet nog worden ontwikkeld.

6.1.3_ IMPLEMENTEREN VAN EXCEPTIONS Momenteel werden weinig ‘exceptions’ (uitzonderingen) in de code van de plug-in ondergebracht. Deze ‘exceptions’ dienen om eventuele foutmeldingen af te handelen en ze zichtbaar te maken voor de gebruiker. Voor de gebruiker is het momenteel onduidelijk als er iets misloopt en, indien zo, waarom iets misloopt. Om een stabiele en gebruiksvriendelijke plug-in te bekomen zijn deze ‘exceptions’ uiteraard nodig. In een verder onderzoek wordt dan ook ‘foutafhandeling’ in de plug-in geïmplementeerd.

6.1.4_ COMPLEXITEIT VAN HET ONTWERP De huidige versie van de plug-in werkt nog niet voldoende voor gebouwen met complexe vormen. Schuine en ronde vormen (hellende en ronde daken, muren die niet haaks op 83

elkaar staan, …) ondervinden momenteel een afwijking bij het bepalen van het beschermd volume. In hoofdstuk 4.8.2; “Opstellen van de naar Excel te verzenden data” wordt beschreven hoe het beschermd volume wordt berekend, namelijk door het pushpullen van alle vlakken van de verwarmde binnenruimtes. Wanneer deze vlakken niet haaks op elkaar staan en vervolgens worden gepushpulld ontstaat er een afwijking in het volume. Dit wordt verduidelijkt op volgende afbeelding:

FIGUUR 70: AFWIJKING IN BESCHERMD VOLUME BIJ HET PUSHPULLEN VAN NIET HAAKS OP ELKAAR STAANDE VLAKKEN

Hoewel deze afwijking bij een woning met een beschermd volume van 800m³, een hellend dak van 40° en haaks op elkaar staande buitenmuren slechts ongeveer 1,8m³ (0,225%) bedraagt, is dit een afwijking die in een volgende versie moet worden opgelost. Een oplossing bestaat uit volgende manier: Iedere ribbe van een binnenvolume grenst aan twee vlakken. Van ieder vlak is de helling gekend en de afstand die het vlak moet worden ‘gepushpulld’. I.p.v. dit vlak te ‘pushpullen’, kunnen alle ribben in een bepaalde richting worden verschoven, afhankelijk van de richting van de normale op beide aangrenzende vlakken en de afstand die beide vlakken moeten worden ‘gepushpulld’. De term ‘pushpullen’ is in dit geval niet correct omdat het vlak niet wordt verschoven, maar iedere ribbe die dit vlak begrenst. Deze oplossing is complexer in het programmeren maar zorgt wel voor een correct beschermd volume, ongeacht de vorm van het model. Verder onderzoek is uiteraard nodig.

6.2_ B UGS 6.2.1_ ONEINDIGE LOOP BIJ DE ANALYSE VAN DE BINNENRUIMTES Hoewel de plug-in eerst nakijkt of alle groepen als een ‘manifold’ volume werden gemodelleerd, kan er toch nog iets misgaan bij het samenvoegen van al deze groepen zodat de binnenruimtes niet kunnen worden geanalyseerd. Momenteel wordt dit samenvoegen behandeld door een oneindige loop. Wanneer uiteindelijk niet alle groepen kunnen worden samengevoegd, loopt de plug-in vast. De oplossing voor deze bug is reeds bestaande, maar werd nog niet in deze versie van de plug-in geïmplementeerd. Deze oplossing bestaat uit het achterhalen van alle mogelijke combinaties voor het samenvoegen van de verschillende groepen. Wanneer één combinatie faalt, wordt overgegaan naar de volgende combinatie. Faalt deze combinatie op haar beurt ook, wordt weer overgegaan op de volgende enz… Indien alle combinaties zijn overlopen en het samenvoegen nog steeds niet is gelukt (hetgeen onwaarschijnlijk is), is er een fout in het model. Verder onderzoek is uiteraard nodig.

6.2.2_ FALEN VAN DE AANRAAKDETECTIE Wanneer twee groepen met een vlak aan elkaar raken en zij vervolgens worden geëxplodeerd, zou één van de aangrenzende vlakken moeten verdwijnen. Soms loopt dit mis en blijven beide vlakken over. Doordat de aanraakdetectie berust op het feit dat normaliter één van de vlakken moet verdwijnen, faalt in dit geval de aanraakdetectie. Ook hier werd een oplossing voor gevonden. Deze oplossing veroorzaakt wel enkele problemen in een later stadium van de plug-in waardoor ze momenteel niet werd geïmplementeerd in de plug-in.

6.3_ T OEKOMSTIG ONDERZOEK 6.3.1_ AAN GEOMETRIE GEKOPPELDE GEGEVENS 6.3.1.1_HALFOPEN EN GESLOTEN BEBOUWING In de plug-in bestaat de mogelijkheid nog niet om een aangrenzende verwarmde ruimte te selecteren. Dit is een ruimte die weliswaar verwarmd is maar niet binnen het beschermd volume valt. Dit kan voorkomen bij halfopen en gesloten bebouwing. Deze woningen kunnen bijgevolg nog niet worden geanalyseerd in deze versie van de plug-in. In een verder onderzoek wordt deze mogelijkheid onder de vorm van een derde keuzemogelijkheid bij het aanduiden van de ruimtes wel voorzien.

6.3.1.2_AANGRENZENDE ONVERWARMDE RUIMTE De huidige versie van de plug-in herkent geen verschil tussen een schildeel dat grenst aan de buitenomgeving of aan een ‘aangrenzende onverwarmde ruimte’. Nochtans is dit een bepalende factor voor de analyse van EPB en zomercomfort. In een toekomstig onderzoek wordt deze herkenning wel geïmplementeerd.

6.3.2_ PROJECTGEGEVENS 6.3.2.1_OPSLAAN VAN VOORGEDEFINIEERDE PROJECTGEGEVENS Architecten werken regelmatig met dezelfde systemen. Bijgevolg zou de mogelijkheid kunnen worden voorzien om de door de gebruiker ingestelde systemen op te slaan. Bijgevolg kunnen deze vooraf ingestelde projectgegevens opnieuw worden ingeladen. Het 85

opslaan van deze gegevens in een extern bestand dat later kan worden ingeladen is uiterst eenvoudig:

gegevens = “Bijvoorbeeld, een, string, met, alle, gegevens, gescheiden, door, een, komma” bestand = File.new(“projectgegevens.phl_epb_proj”, “w”) #extensie is vrij: .phl_epb_proj bestand.write gegevens bestand.close

De code voor het opnieuw inladen van de gegevens in dit bestand wordt opgebouwd als volgt:

bestand = File.new(“projectgegevens.phl_epb_proj”, “r”) gegevens = bestand.readline #gegevens is nu: “Bijvoorbeeld, een, string, met, alle, gegevens, gescheiden, door, een, #komma”

6.3.3_ VERSCHILLENDE EVALUATIES MET ELKAAR VERGELIJKEN Wanneer de gebruiker met de huidige versie van de plug-in een analyse van het gebouw uitvoert, worden de bekomen resultaten niet opgeslagen. Als de gebruiker het model aanpast en een nieuwe analyse doet, gaan de gegevens uit de vorige analyse verloren. Eventueel kan er na het voltooien van een analyse aan de gebruiker worden gevraagd of hij de gegevens van deze analyse wil bewaren. Vervolgens kan er automatisch een nieuwe ‘scene’ in SU worden aangemaakt waar alle gegevens uit die analyse worden opgeslagen (zowel het gemodelleerde gebouw als alle bijkomende gegevens). Wanneer de gebruiker hierna een aanpassing in het model aanbrengt, is het voorgaande model niet verloren. Na het voltooien van enkele analyses kunnen bijgevolg alle varianten van het model (en hun bijhorende resultaten) nauwkeurig met elkaar vergeleken worden.

6.3.4_ BIBLIOTHEEK UITBREIDINGEN 6.3.4.1_ALGEMEEN De materialen- en opbouwenbibliotheek van de huidige versie van de plug-in bevindt zich nog in vroege ontwikkeling. Zij werd niet voldoende uitgebreid om als volwaardige bibliotheek te fungeren en is bijgevolg slechts een hypothetische voorstelling van een ‘architect’-vriendelijke bibliotheek.

6.3.4.2_VLOEROPBOUWEN Wanneer de gebruiker in de huidige versie van de plug-in een nieuwe opbouw definieert voor de schilvloeren, wordt de U-waarde van deze vloer automatisch berekend als zijnde een vloer die grenst aan de grond. Dit heeft invloed op de overgangscoëfficiënten en bijgevolg ook op de U-waarde. Uiteraard grenst niet iedere schil ‘vloer’ aan de grond maar kan deze ook grenzen aan de buitenomgeving, een kruipkelder of een kelder. Deze mogelijkheden worden dan ook in een volgende versie voorzien.

6.3.4.3_BEGLAZING Ook het toevoegen van beglazing mag in een volledig functionele plug-in voor de analyse van EPB en zomercomfort niet ontbreken. Ook deze optie wordt in een volgende versie voorzien. 86

6.3.4.4_IMPORTEREN EN EXPORTEREN VAN MATERIALEN EN OPBOUWEN De mogelijkheid om zelf opbouwen en materialen te definiëren is reeds voorzien. Maar deze opbouwen en materialen worden enkel op de PC waarop zij werden gedefinieerd opgeslagen. Wanneer aan een constructie-element een eigen opbouw wordt toegekend en het model vervolgens op een andere PC wordt geopend waarop deze opbouw niet is gedefinieerd, kan er geen evaluatie van EPB en zomercomfort worden gemaakt van het gebouw. Aan de bibliotheek zou de mogelijkheid moeten worden gekoppeld om materialen en opbouwen te kunnen importeren en exporteren. Dit is relatief eenvoudig.

6.3.4.5_AANPASSEN VAN DOOR DE GEBRUIKER BEPAALDE OPBOUWEN Opbouwen die door de gebruiker worden aangemaakt kunnen niet meer worden aangepast maar enkel worden verwijderd. Hier is een eerder complexe wisselwerking tussen enerzijds de User Interface en anderzijds het Ruby-script en het XML-bestand voor nodig. Gezien de geringe tijd van dit thesisonderzoek werd deze optie tijdelijk buiten beschouwing gelaten. In een volgende versie is deze optie volledig operationeel.

6.3.5_ COMPLEXE MODELLEN De validatie van de plug-in geschiedt d.m.v. een uiterst eenvoudig model. Ook complexere modellen moeten deze validatieprocedure feilloos kunnen doorstaan. Om complexe modellen te kunnen valideren moeten eerst enkele bugs worden geëlimineerd. Deze bugs werden reeds besproken in een eerder hoofdstuk (hoofdstuk 6.2; “Bugs”).

6.3.6_ HET VLAKKENMODEL Uit de enquête (hoofdstuk 3.3; “Enquête”) blijkt dat architecten in de voorontwerpfase in SU het gebouw modelleren in dikte. In de conceptuele ontwerpfase blijkt dat men werkt volgens een vlakkenmodel. Daarom werd beslist om een tweede plug-in te ontwikkelen waarin wordt gemodelleerd a.d.h.v. een vlakkenmodel. Het programmeren van zo een plug-in is eenvoudiger dan het programmeren van een plug-in voor analyse van EPB en zomercomfort waarvoor de constructie-elementen in dikte worden gemodelleerd. In het vlakkenmodel worden de verschillende binnenruimtes op eenvoudige wijze achterhaald. Ook moet er geen aanraakdetectie gebeuren tussen enerzijds de vlakken van een binnenruimte en anderzijds de constructie-elementen. De opbouwen worden rechtstreeks aan het vlak gekoppeld. Tenslotte is nagenoeg de volledige methode beschreven in hoofdstuk 4.8.2; “Opstellen van de naar Excel te verzenden data” voor het achterhalen van de correcte geometrische en aan geometrie gekoppelde gegevens overbodig. Alle gegevens kunnen zonder gebruik te maken van complexe code rechtstreeks uit het gemodelleerde vlakkenmodel worden achterhaald.

7_ HANDLEIDING 7.1_ MINIMUM SYSTEEMVEREISTEN Windows XP/Vista/7 Google SketchUp 8 PRO (of een latere PRO-versie) Microsoft Excel 2007/2010

7.2_ WORKFLOW 7.2.1_ INSTALLATIE Alle bestanden en mappen die zich in de map “Plug-in” op de bij deze thesis bijgeleverde CD bevinden, moeten worden gekopieerd naar de ‘Plugins’-map van Google SketchUp. Deze map bevindt zich conventioneel op volgende locatie: …/Program Files/Google/Google SketchUp (8,…)/Plugins/

7.2.2_ MODELLEEREISEN De gebruikte tools voor het modelleren zijn vrij. Toch worden er enkele modelleereisen opgelegd: Constructie-elementen (vloeren, daken, muren, beglazing,…) worden in dikte en als groep/group gemodelleerd. Opake schildelen worden met een dikte van 0,30m gemodelleerd. Voor transparante schildelen is de dikte vrij te bepalen. Alle binnenconstructies worden met een dikte van 0,14m gemodelleerd. Constructie-elementen van een verschillend type (binnenvloer, binnenmuur, schilmuur, beglazing …) worden als een aparte groep gemodelleerd. Constructie-elementen van hetzelfde type, doch met een andere opbouw, moeten als een aparte groep worden gemodelleerd. Het binnenvlak van beglazing moet gelijk gepositioneerd worden met het binnenvlak van het/de constructie-element(en) waarin deze beglazing voorkomt. Aan beglazing moet een transparant materiaal worden toegekend. De kleur of textuur van dit materiaal is vrij te bepalen. Naast constructie-elementen die het gebouw bepalen, mogen geen andere groepen/groups voorkomen in de verschillende ruimtes van het gebouw. Alle groepen/groups die ten behoeve van deze plug-in worden aangemaakt moeten als een zuiver volume worden gemodelleerd. Er mogen geen inwendige vlakken aanwezig zijn.

7.2.3_ TOOLS VAN DE PLUG-IN 7.2.3.1_ALGEMEEN Door de plug-in worden vijf ‘tools’ beschikbaar gemaakt in een ‘toolbar’, v.l.n.r.(Figuur 71): Projectgegevens-tool Ruimtes-tool Constructie-elementen-tool Resultaten-tool Bibliotheek-tool

FIGUUR 71: TOOLBAR VAN DE PLUG-IN VOOR ANALYSE VAN EPB EN ZOMERCOMFORT

Indien deze toolbar na installatie van de plug-in niet zichtbaar is in Google SketchUp moet deze zichtbaar worden gemaakt door eerst binnen Google SketchUp op View/Beeld te drukken en vervolgens op Toolbars te klikken. Hierdoor wordt er een lijst getoond van alle beschikbare toolbars. De toolbar van deze plug-in wordt zichtbaar wanneer op “PHL – TOOLBAR” wordt geklikt.

7.2.3.2_PROJECTGEGEVENS -TOOL D.m.v. deze tool kunnen enkele bijkomende gegevens worden bepaald betreffende de constructiewijze en de verschillende installaties van het gebouw. Deze gegevens zijn nodig om een correcte analyse van EPB en zomercomfort te bekomen. Wanneer deze tool voor de eerste keer wordt gebruikt, zijn reeds enkele gegevens vooringesteld.

7.2.3.3_RUIMTES-TOOL Indien het model op correcte wijze werd gemodelleerd en hierna op de ruimtes-tool wordt geklikt, gebeurt de analyse van de verschillende ruimtes in het gebouw. Na analyse kan bepaald worden of deze ruimtes al dan niet verwarmd zijn. Naast het gebouw worden automatisch twee kubussen gemodelleerd. Deze kubussen fungeren als User Interface voor het bepalen van het type ruimte. Eerst worden de ruimtes geselecteerd waarvan het type (verwarmd of niet verwarmd) moet worden gewijzigd. Het selecteren van een ruimte gebeurt door op die bepaalde ruimte te klikken. Meerdere ruimtes kunnen ge(de)selecteerd worden wanneer de ‘SHIFT’-toets ingedrukt blijft. Wanneer men de ‘Shift’-toets ingedrukt houdt en vervolgens dubbel klikt op een ruimte, worden alle ruimtes van hetzelfde type geselecteerd. Nadat de ruimtes, waarvan het type moet worden gewijzigd, zijn geselecteerd, volstaat het te klikken op de kubus die staat voor het type ruimte waarin de geselecteerde ruimtes moeten worden gewijzigd.

7.2.3.4_CONSTRUCTIES-TOOL Alvorens deze tool kan worden gebruikt moeten de ruimtes geanalyseerd zijn. Ook moet de projectgegevens-tool reeds één maal gebruikt zijn geweest (er moeten geen wijzigen worden aangebracht in de projectgegevens maar de gebruiker moet ze wel één maal bekeken hebben). Indien hier aan is voldaan en de constructies-tool wordt geselecteerd, wordt automatisch eerst van ieder constructie-element het type bepaald (opake schilmuur, binnenvloer, schilvloer, …). Na voltooiing hiervan worden de verschillende constructie-elementen in een bepaalde kleur getoond. Naast het gebouw worden automatisch zeven kubussen gemodelleerd, elk met een andere kleur. Iedere kubus staat voor een bepaald type constructie-element. Wanneer men op een kubus klikt worden alle constructie-elementen van dit type verborgen of getoond op het scherm. D.m.v. deze tool wordt ook automatisch aan ieder constructie-element de standaard opbouw gekoppeld. Deze opbouw kan worden gewijzigd door te klikken op het constructie-element waarvan de opbouw moet worden gewijzigd. Er verschijnt dan een pop-up User Interface waarin alle beschikbare opbouwen voor dit type constructieelement worden opgesomd. Het selecteren van een bepaalde opbouw gebeurt door te drukken op de knop ‘selecteren’ naast de opbouw. Nieuwe opbouwen kunnen worden toegevoegd d.m.v. de opbouwenen materialenbibliotheek.

7.2.3.5_RESULTATEN-TOOL

Als de projectgegevens door de gebruiker werden bekeken, de ruimtes werden bepaald en de constructie-elementen werden geanalyseerd, kan de evaluatie van EPB en zomercomfort starten. Hiervoor wordt op de resultaten-tool geklikt. Deze bewerking kan enige tijd in beslag nemen. Wanneer de analyse is voltooid wordt een scherm weergegeven waarin de resultaten van de EPB worden getoond. Ook worden de verschillende verwarmde binnenruimtes opnieuw getoond, zij het met een bepaalde kleur: groen, oranje of rood. Indien de maximale maandtemperatuur van een ruimte niet hoger ligt dan 26°C wordt een groene kleur aan de ruimte gegeven, ligt de maximale maandtemperatuur tussen 26°C en 28°C krijgt de ruimte een oranje kleur. Als de maximale maandtemperatuur hoger ligt dan 28°C wordt de ruimte in het rood weergegeven. Wanneer op een bepaalde ruimte wordt geklikt worden meerdere resultaten over de ruimte betreffende het zomercomfort getoond.

7.2.3.6_MATERIALEN- EN OPBOUWENBIBLIOTHEEK-TOOL De materialen- en opbouwenbibliotheek is onderverdeeld in twee onderdelen: opbouwen en materialen. In het tabblad ‘opbouwen’ worden per type constructie-element (schil ‘vloeren’, opake schil ‘muren’, …) de voor dit type constructie-element beschikbare opbouwen getoond. Een nieuwe opbouw voor dit type constructie-element kan worden toegevoegd door op de knop ‘nieuwe (het type constructie-element) toevoegen’ te drukken. In deze versie van de plug-in kunnen enkel opbouwen worden toegevoegd voor: schil ‘vloeren’, opake schil ‘muren’, opake schil ‘daken’, binnenmuren en binnenvloeren en – plafonds. In het tabblad ‘materialen’ worden de verschillende materialen per soort (opaak, transparant, niet-homogeen) materiaal geordend. Een nieuw materiaal kan worden toegevoegd door op de knop ‘nieuw (soort materiaal) toevoegen’. Deze materialen kunnen vervolgens worden gebruikt om een nieuwe opbouw te definiëren.

7.3_ V IDEOHANDLEIDING : In het volgende videofragment wordt eerst het validatiemodel uit hoofdstuk 5.1; “Het validatiemodel” gemodelleerd. Vervolgens worden verschillende onderdelen van de plugin getoond en worden diverse analyses van EPB en zomercomfort uitgevoerd:

http://www.youtube.com/watch?v=IMvWCEcWFOk

8_ REFERENTIELIJST 8.1_ L ITERATUUR Collingbourne, Huw. "The book of Ruby." Sapphiresteel, 2009. Jonckheere, Tine, Ruben Verstraeten, Pieter Pauwels, and Ronald Demeyer. Ontwikkeling van een Google SketchUp-plug-in als ontwerpinstrument voor een energiezuinige architectuur. Gent: Universiteit Gent, 2010. Roman, Steven. Writing Excel Macros with VBA, 2nd Edition. Sebastopol: O'Reilly, 2002. Scarpino, Matthew. Automatic SketchUp: Creating 3-D Models in Ruby. Eclipse Engineering LLC, 2010. Van Dijck, Katrien. Ontwikkeling van een CAAD-tool voor de evaluatie van duurzaamheid en kosten: Gevallenstudie Google SketchUp en SuFiQuaD. Leuven: K.U. Leuven, 2010.

8.2_ E LEKTRONISCHE DOCUMENTEN Weytjens, L. EPB rekenmodule in MS Excel. PHL/Universiteit Hasselt, 2011. Weytjens, Lieve, and Griet Verbeeck. Early design support for summer comfort evaluation of dwellings: a comparison of calculation methods. Proceedings of PLEA 2011. Louvain-laneuve, 2011.

8.3_ I NTERNET Accessing Windows API from Ruby â&#x20AC;&#x201C; Using Win32API library. 05 2008, 13. http://www.rubytips.org/2008/05/13/accessing-windows-api-from-ruby-usingwin32api-library (geraadpleegd op 2010-2012). Chilkat Software. Ruby Script: Save String To File. http://www.chilkatsoft.com/braindump/ruby/ruby-script-save-string-to-file.html (geraadpleegd op 2012). "EPSketch - handleiding." EPSketch. http://www.epsketch.be/EPSketch_handleiding_v1.0.pdf (geraadpleegd op 2011-2012). EPSketch. http://www.epsketch.be/ (geraadpleegd op 2011-2012). Excel Macros (VBA) For beginners, intermediate and advanced users. http://www.excelvba.com/ (geraadpleegd op 2010-2012). Google. Google accounts. https://www.google.com/settings/ (geraadpleegd op 20102012). Google, Inc. SketchUp Ruby API. http://code.google.com/intl/nlNL/apis/sketchup/docs/index.html (geraadpleegd op 2010-2012).

Integrated Environmental Solutions. http://www.iesve.com/ (geraadpleegd op 20102012). jQuery. http://www.jquery.com (geraadpleegd op 2011-2012). LimeSurvey. http://www.limesurvey.org (geraadpleegd op 2010). Matsumoto, Yukihiro, interview by Bill Venners. The Philosophy of Ruby (09 29, 2003). Microsoft. Excel Developer Roadmap. http://msdn.microsoft.com/nlnl/office/ff458124.aspx (geraadpleegd op 2010-2012). —. Functions in Alphabetical Order. 03 25, 2010. http://msdn.microsoft.com/enus/library/Aa383688 (geraadpleegd op 2010-2012). Mullet, David. Creating an iTunes Song Inventory in Excel. 01 14, 2010. http://rubyonwindows.blogspot.com/2010/01/creating-itunes-song-inventory-inexcel.html (geraadpleegd op 2010-2012). Reed, Matt. Calling Flash AS3 functions from Javascript. 05 19, 2008. http://painteddigital.com/2008/calling-flash-as3-functions-from-javascript/ (geraadpleegd op 2010-2012). REXML Tutorial. http://www.germane-software.com/software/rexml/docs/tutorial.html (geraadpleegd op 2011-2012). Ruby. http://www.ruby-lang.org/en/ (geraadpleegd op 2010-2012). Ruby 1.9.3. http://ruby-doc.org/core-1.9.3/ (geraadpleegd op 2010-2012). Sorting "two-dimensional" arrays. 2005. http://www.webdeveloper.com/forum/archive/index.php/t-59157.html (geraadpleegd op 2011-2012). ThemeRoller. 2010. http://jqueryui.com/themeroller (geraadpleegd op 2011-2012). Turner, Alexander. Excel Constant Definitions For VBScript And JScript. 02 06, 2007. http://nerds-central.blogspot.com/2007/02/excel-constant-definitions-for-vbscript.html (geraadpleegd op 2010-2012). Vervloesem, Koen. REXML: Processing XML in Ruby. 11 09, 2005. http://www.xml.com/pub/a/2005/11/09/rexml-processing-xml-in-ruby.html (geraadpleegd op 2010-2012). Vlaamse Energieagentschap. energiesparen. http://www.energiesparen.be (geraadpleegd op 2010-2012). w3schools. JavaScript Tutorial. http://www.w3schools.com/js/. Wei, Allen. Tips – Ruby Get Current File Name. 2010. http://www.allenwei.cn/tips-rubyget-current-file-name/ (geraadpleegd op 2010-2012). win32ole: Ruby Standard Library Documentation. http://ruby-doc.org/stdlib1.9.3/libdoc/win32ole/rdoc/index.html (geraadpleegd op 2010-2012).

8.4_ A FBEELDINGEN Figuur 11: Helling van verschillende constructie-elementen volgens de epb software Vlaanderen (http://www.energiesparen.be) p. 38 Figuur 21: OriĂŤntatie volgens de epb software Vlaanderen (http://www.energiesparen.be)

p. 47