• No results found

Automation of Building Energy Performance Simulation with IDA ICE

N/A
N/A
Protected

Academic year: 2022

Share "Automation of Building Energy Performance Simulation with IDA ICE"

Copied!
70
0
0

Loading.... (view fulltext now)

Full text

(1)
(2)

Energy Performance

Simulation with IDA ICE

CHENGLONG FU

Master in Energy for Smart Cities Date: September 15, 2020

Supervisor: Oleksii Pasichnyi Examiner: Fredrik Gröndahl

SCHOOL OF ARCHITECTURE AND THE BUILT ENVIRONMENT Swedish title: Automation av byggnadsenergisimulering med IDA ICE

(3)
(4)

Abstract

Buildings play a central role for livability and carbon footprint of urban areas. Ambitious energy saving and emission reduction targets created a need for a new generation of decision-support methods and tools that allow for de- tailed analysis of urban energy on a large scale. Urban building energy model- ing (UBEM) that has emerged recently is an efficient approach to assess energy performance of multiple buildings and system effects from urban energy inter- ventions. However, the further upscale of UBEMs is significantly limited due to the lack of automation for building energy performance (BEP) simulations required for such models in large amounts.

This thesis aimed to explore challenges for automation of BEP simula- tions, and to develop a prototype tool that would serve as a middleware be- tween UBEM and BEP simulation engine, focusing on the IDA ICE simula- tion software. The result of this thesis is icepy — a tool for automation of BEP simulations in IDA ICE. It uses IDA ICE API and Lisp scripting to pro- vide interaction between UBEM process and IDA ICE in order to generate initial simulation model (IDM), execute simulation and manage results in an automated way. Being implemented as a Python package, it allows to modify multiple IDMs or export simulation results with a few lines of code. The de- veloped tool has been tested and validated for the case building in Minneberg, Stockholm. The automation capabilities provided by icepy has allowed to per- form sensitivity analysis for building design parameters as was demonstrated for the window-to-wall ratio (WWR) and three various algorithms for window distribution. The resulting tool has limited functionality as it addressed build- ing envelopes which is only one component of building simulation. However, it has proved to be an efficient approach to automate simulation process and has shown a good potential for further development of such tools.

Keywords: IDA ICE, automation, building energy performance simula- tion, urban building energy modeling, Python.

(5)

iv

Sammanfattning

Byggnader spelar en central roll för urbana områdens levbarhet och koldi- oxidavtryck. Ambitiösa mål för energibesparing och utsläppsminskning har skapat ett behov av en ny generation beslutsstödmetoder och verktyg som möjliggör detaljerad analys av städers energianvändning i stor skala. Urban byggnadsenergimodellering (UBEM) har nyligen utvecklats och är ett effek- tivt tillvägagångssätt för att bedöma energiprestanda för flera byggnader och systemeffekter för olika energiåtgärder inom den urban miljön. Den ytterligare uppskalningen av UBEM är dock begränsad på grund av bristen på automa- tion av simulering som är inriktade på byggnadsenergiprestanda (BEP), vilket krävs för att hantera stora byggnadsbestånd.

Det här examensarbetet syftar till att utforska utmaningar med automati- sering av BEP-simuleringar och att utveckla en prototyp som ska fungera som en mellanprogramvara mellan UBEM och BEP-simuleringsmotorer, med fo- kus på IDA ICE(som är en simuleringsprogramvara). Resultatet av examens- arbetet är icepy, som är ett verktyg för att automatisera BEP-simuleringar i IDA-ICE. Icepy använder IDA ICE API och Lisp-skript för att tillhandahålla interaktion mellan UBEM-processen och IDA ICE för att generera en initi- al simuleringsmodell (IDM),utför själva simuleringen och slutligen hanterar resultatet på ett automatiserat sätt. Genom att icepy implementeras som ett Pythonpaket kan den modifiera flera IDM:er och även exportera simulerings- resultat med några få kodrader. Området Minneberg i Stockholm har använts i en fallstudie för att validera och testa verktyget. Automatiseringsfunktionerna i icepy har möjliggjort känslighetsanalyser för olika byggnadsdesignparametrar, exempelvis studerades påverkan av olika värden på förhållandet mellan fönster och väggar genom användning av tre olika algoritmer för fönsterdistributio- ner. Det utvecklade verktyget har begränsningar i funktionalitet framförallt på grund av att enbart byggnadens ytterskal studerades i byggnadsenergisimule- ringarna. Verktyget har dock visat sig vara ett effektivt tillvägagångssätt för att automatisera simuleringsprocesser, vilket visar på en god potential att också vidareutveckla dessa verktyg.

(6)

Acknowledgement

This thesis work constitutes my final course as a master student at KTH Royal Institute of Technology in Stockholm and Katholieke Universiteit Leu- ven, Belgium. It is conducted as a part of the EIT InnoEnergy master pro- gramme in Energy for Smart Cities funded sponsored the European Union.

This thesis is the greatest task in my study life so far. It’s challenging, tough for me, but ultimately meaningful. I would like to express my greatest appre- ciation to Mr. Oleksii Pasichnyi, Dr. Olga Kordas, Dr. Tim Johansson, Dr.

Andreas Kissavos from EQUA AB and anyone who supported me throughout the whole work process. This thesis would not have been possible without their continuous guidance and valuable feedback, which always encouraged me.

When the thesis is being written, the world is experiencing a crisis with tremendous impact. I sincerely believe that mankind can work together to overcome this crisis.

A special thank to my family. I am grateful to have my greatest parents and my lovely sister.

(7)

Contents

Abstract iii

Sammanfattning iv

Acknowledgement v

List of Figures ix

List of Tables x

Abbreviations xi

1 Introduction 1

1.1 Background . . . 1

1.2 Problem Definition . . . 2

1.3 Aims and Objectives . . . 3

2 Theory 4 2.1 Urban Building Energy Modeling (UBEM) . . . 4

2.1.1 Methods and Platforms . . . 4

2.1.2 Input Data . . . 5

2.1.3 Building Archetypes . . . 6

2.2 Building Energy Performance Simulation . . . 7

2.2.1 Building Energy Balance . . . 7

2.2.2 BEP Simulation Engines . . . 8

2.2.3 Building Information Modeling (BIM) . . . 8

2.2.4 Development of Automated BEP Simulation . . . 8

2.2.5 Sensitivity Analysis . . . 10

2.2.6 Window-To-Wall Ratio . . . 10

vi

(8)

3 Method 12

3.1 IDA ICE . . . 12

3.1.1 IDM Model Tree . . . 13

3.1.2 IDA ICE API . . . 13

3.1.3 Lisp Scripting . . . 16

3.2 Python . . . 19

4 Result : Icepy - A Python Package 20 4.1 Overview . . . 20

4.2 Baseline IDM Model Generation (I) . . . 21

4.3 Simulation IDM Model Generation (II) . . . 22

4.3.1 User Input Data . . . 22

4.3.2 Zone Management . . . 23

4.3.3 Windows and Doors Setup . . . 24

4.4 Automated Simulation (III) . . . 25

4.5 Results Management (IV) . . . 25

4.6 Sensitivity Analysis: WWR . . . 27

4.7 Test . . . 29

4.8 Statistical Analysis of test results . . . 31

4.8.1 Computational Time Analysis . . . 31

4.8.2 Energy Consumption Analysis . . . 33

5 Discussion 35 5.1 Usability of Icepy . . . 35

5.2 Combined IDA ICE API and Lisp Solution . . . 36

5.3 Limitations . . . 38

6 Conclusion and Future Work 39 A IDA ICE API Function List 45 B Tree Structure of a Sample IDA ICE Model (IDM) 47 C Default Characteristic Settings for an IDM in IDA ICE 48 D Data Used in Minneberg I Test 52 D.1 Table building . . . . 52

D.2 Table model . . . . 52

D.3 Table simulation . . . 53

E Icepy Functions 54

(9)

List of Figures

2.1 Data categories required for UBEMs (Monteiro et al. 2018) . . 6

2.2 Energy balance of a building object (Åberg 2014) . . . 7

2.3 Workflow of automated simulation tool (Nageler, Mach, et al. 2019) . . . 10

3.1 IDA ICE user interface . . . 13

3.2 Tree structure of an IDM model . . . 14

3.3 The Diff-Script interface in IDA ICE . . . . 16

3.4 Sample Lisp script for adding a window . . . 17

3.5 Geometry of a window located on a wall . . . 17

3.6 Sample Lisp script for adding a door . . . 18

3.7 Geometry of a door located on a wall . . . 19

4.1 Workflow of icepy . . . 21

4.2 CSV file of parameters for windows used for a sample building 22 4.3 Left: the baseline IDM for a sample building; Right: the man- aged IDM with 5 floors and a ceiling height of 3 meters per floor. The building envelope is colored beige and zones are brown. . . 24

4.4 MySQL database diagram. The foreign keys are marked in azure. . . 26

4.5 Scene view of a building in Odenplan, Stockholm . . . 28

4.6 Upper: proportional window distribution; Middle: fixed win- dow height distribution; Lower: multiple standard windows distribution (WWR=0.25 for all 3 scenarios) . . . 29

4.7 Detailed flow diagram of icepy on Minneberg I (Step 1 - gen- erate baseline IDM model (I); Step 2 & 3 - generate simulation IDM model (II); Step 4 - run simulation (III); Step 5 - results management (IV)) . . . 30

viii

(10)

4.8 IDM model generated for the Minneberg I case building (pro-

portional windows distribution, WWR=0.35) . . . 31

4.9 Comparison of accumulated computational time in 3 WWR distribution scenarios in terms of time consumed (second) and WWR values. (Proportional distribution - green; fixed height distribution - blue; multiple standard windows distribution - red) 32 4.10 Comparison of time of simulation execution processes in 3 WWR distribution scenarios in terms of time consumed (sec- ond) and WWR values.(Proportional distribution - green; fixed height distribution - blue; multiple standard windows distribu- tion - red) . . . 32

4.11 Comparison of simulated anaul total energy consumption (kW h) in 12 months in 3 WWR distribution scenarios in terms of en- ergy consumed and WWR values. (Proportional distribution - green; fixed height distribution - blue; multiple standard win- dows distribution - red) . . . 33

4.12 Comparison of total energy consumption (kW h/m2) per area in 12 months in 3 WWR distribution scenarios in terms of en- ergy consumed and WWR values. (Proportional distribution - green; fixed height distribution - blue; multiple standard win- dows distribution - red) . . . 34

5.1 Overview of Urban Building Energy Modeling . . . 35

C.1 Global data . . . 48

C.2 Building defaults . . . 49

C.3 Energy meters . . . 49

C.4 Ground proprieties . . . 49

C.5 Infiltration . . . 50

C.6 Extra energy and losses . . . 50

C.7 System parameters . . . 51

C.8 Standard air handling unit . . . 51

(11)

List of Tables

2.1 Optimal WWR values and corresponding DA and UDI in four orientations for buildings in Oslo (Goia 2016) . . . 11 3.1 IDA ICE API functions used in this thesis . . . 15 4.1 Python dictionary format of windows and doors . . . 23 5.1 Comparison of times to change the width and height of 10

windows using the API-only method and the combined API- Lisp method . . . 37

x

(12)

Abbreviations

API Application Programming Interface

BEM Building Energy Modeling

BEP Building Energy Performance

BIM Building Information Modeling

CAD Computer Aided Design

CSV Comma-Separated Values

DA Daylight Autonomy

DOM Document Object Modeling

GHG Greenhouse Gas

GUI Graphical User Interface

HVAC Heating, Ventilation, and Air Conditioning IDA ICE IDA Indoor Climate Energy

IDM IDA ICE Model

IFC Industry Foundation Classes

SDK Software Development Kit

UBEM Urban Building Energy Modeling UDI Useful Daylight Illuminance

WWR Window-to-Wall Ratio

(13)
(14)

Introduction

1.1 Background

The United Nations predicted that urban areas are projected to house over 60 percent of people globally (around 5,167 billion) by 2030 (United Nations 2018). Today, the world’s cities are growing in both size and number. Urban- ization in Europe is leading in the world. Around 75 percent of population have chosen to live in urban areas in the European Union (EU) (European Environ- ment Agency 2017). While cities are the motors of economy, they demand energy and resources heavily and encounter livability problems such as pollu- tion, water and emissions. Cities matter the whole Europe. Sustainable cities is a part of EU climate strategy (European Union 2020a). EU 2030 climate and energy framework targets at least 40% cuts in greenhouse gas emissions compared with EU-20-20-20 target (ibid.). While emissions from industries and transportation vary among cities, the urban building sector is always the largest energy consumer and is responsible for 36% of the EU CO2emissions (Reinhart and Davila 2016; European Union 2020b).

In order to manage greenhouse gas emissions reduction and building effi- ciency improvement for neighbourhoods, city governments and experts should differentiate between different categories of buildings and between new and existing buildings. All new buildings must be nearly zero-energy buildings from 2021 (European Union 2014). Existing buildings are recommended to apply retrofitting measures of building elements like walls, roofs, heating and cooling systems. Before scaling up renovations of the building sector, cities need to better understand what current and future effects the energy retrofitting measures and infrastructure change might have. The overall energy flows

1

(15)

2 CHAPTER 1. INTRODUCTION

can be analyzed with the help of information and communication technology (ICT). Urban building energy modeling (UBEM) (Reinhart and Davila 2016) and building energy performance (BEP) simulation are expected to become key planning tools to evaluate building efficiency when designing new build- ings or retrofitting existing buildings (Oller et al. 2018).

UBEM can be divided into physics-based approach and data-driven ap- proach (Coakley, Raftery, and Keane 2014). Physics-based approach uses de- tailed physical models to predict the behaviour of the building. Data-driven approach produces models by accurately monitored data from the building. As a physics-based approach, BEP simulation uses a computer-based, mathemat- ical model to perform the energy calculation over one year. Detailed building energy balance calculations are carried out based on properties of the individ- ual buildings and dynamic external inputs.

Detailed physical models are accurate and stable in energy consumption calculation, but it is time consuming to develop models at the urban scale (Li et al. 2020). Hence, the development of an automated BEP simulation method is required to accelerate modeling and simulation.

1.2 Problem Definition

BEP simulation engines namely EnergyPlus, DOE2, TRNSYS and IDA ICE are widely used for UBEM. The typical usage case of these software is that energy modelers collect geometry, usage and construction data and enter the available information into the software. But, if expanding district to ur- ban realm, the manual input process becomes extremely time consuming and costly (Nageler, Zahrer, et al. 2017). The underlying challenge requires a tool to automate the BEP simulation workflow. Such automated workflows would allow to transform the buildings’ datasets into detailed models, to run simula- tions accordingly to and analyze simulation results.

The application of the automated tool can reduce time needed for manual input and parameterize simulation tools (Nageler, Mach, et al. 2019). There- fore, a new methodology for automated BEP simulation is demanded so that multitude buildings modeling can be implemented efficiently.

(16)

1.3 Aims and Objectives

In this degree project, we want to investigate how to automate the process- ing of BEP simulations upon user requirements and compile results. The idea is to develop a new middleware tool to connect and interact with the BEP sim- ulation engine. IDA ICE is chosen as the target BEP simulation engine. More specifically, we would like to answer the following questions:

• What are the main approaches to automate BEP simulation process?

Which stages in the entire BEP simulation process can be automated?

• How to automatically import existing building data, run simulation and manage results?

• How the automation of sensitivity analysis can be implemented? Take an example of WWR analysis.

• What are the advantages and limitations of automated BEP simulations using IDA ICE?

(17)

Chapter 2 Theory

2.1 Urban Building Energy Modeling (UBEM)

Urban areas are growing in both developing countries and industrialized countries. Predicted scenarios estimate that five billion people will live in ur- ban areas by 2030 (Papa, Gargiulo, and Zucaro 2016). The development of urbanization meets climate change, and energy sustainability issues. Urban energy models aim to address these issues (Hong, Chen, Luo, et al. 2020).

The concept of UBEM is to apply physical and mathematical models to more than several buildings in a particular district. Energy performance of building standards are widely used for design development and retrofitting operation (Hensen and Lamberts 2012). Accurate quantification of urban energy de- mand can support urban energy-saving design (Li et al. 2020).

2.1.1 Methods and Platforms

Several UBEM methods have been developed. UBEM (Reinhart and Davila 2016) simulates individual buildings in a city and estimates energy demands.

CityBES (Hong, Chen, Lee, et al. 2016) is an urban energy modeling platform which automates the workflow and integrates urban data models. It takes the current energy usage data of the city as the baseline and analyzes the city’s energy efficiency.

Reinhart and Davila (2016) developed a method to create a reliable urban building energy model on campus level projects. The model required several data sets as input including climate data, building geometry, construction and

4

(18)

usage schedules. The paper discussed the necessity of automated modeling for several dozens buildings. It proposed a method to speed up the process of UBEM. It enumerated few automated systems for simulation workflows such as SUNTOOL and CITYSIM.

SUNTOOL (Robinson, Campbell, et al. 2007) is a modeling software for simulating urban environmentally sustainability to support urban designers.

SUNTOOL integrated radiation models, reduced thermal models, stochastic models (windows, lights, electrical appliances, etc.). The building was the

"energy center" and "energy source" models are children of it. Nevertheless, SUNTOOL relied on an intelligent defaults dataset to define simulation set- ting, which was a black box for modelers. The annual simulation time in- creased linearly with the number of buildings and zones.

CITYSIM (Robinson, Hald, et al. 2009) is the successor to SUNTOOL.

Thermal models, radiation models, behavioural models and plant models were integrated in order to achieve a good compromise between data availability, modeling accuracy and computational overheads. CITYSIM’s thermal model was based on a resistor-capacitor network. Compared to simulation software for individual buildings , construction material was one of attributes that were not considered.

2.1.2 Input Data

All urban building energy models rely on some forms of data. The BEP simulation approach is determinant of the input data requirements (Monteiro et al. 2018). The 6 main categories of data needed for the UBEM can be seen in Figure 2.1.

Local climate and weather data, which contain information such as the outside temperature, relative humidity and solar irradiance are needed. Geom- etry data consists of information on the buildings’ geometry and shape. Con- struction data include information on the buildings’ construction, such as the material that constitute the building envelope. Information on the buildings’

systems contains the technical equipment that is being used in the building, such as HVAC systems. Information on the buildings’ operations are associ- ated to the occupants, their behaviors and their preferred settings.

(19)

6 CHAPTER 2. THEORY

Figure 2.1: Data categories required for UBEMs (Monteiro et al. 2018)

2.1.3 Building Archetypes

UBEM models depict the current state of urban buildings and predict their evolution. It is difficult to build detailed energy models for all buildings.

Hence, a widespread modeling technique used is to represent a group of simi- lar buildings with a building archetype (Sokol, Davila, and Reinhart 2017). A building archetype is characterized by a complete set of building characteristic data, environmental measures and HVAC characteristic data.

Data mentioned above can be gathered from a variety of sources. Stan- dardized protocols, public databases, building plans, interviews of building representatives, and field team observations are used to collect data. Due to high-uncertainty of occupant behaviour and preferences, however, it is erro- neous to use single values of usage schedules for a building archetype. Occu- pancy schedules can be defined probabilistically as Markov chain models with data derived from travel surveys, time-use surveys or building audits (Aerts et al. 2014).

The implementation of the building archetype relies on a combination of various tools. Sokol, Davila, and Reinhart (2017) stated a case study for a set of residential buildings in Cambridge, US. In this case, geometry properties were transformed into 3D models using Grasshopper in Rhinoceros. The char- acteristics of each archetype were defined in an XML file format. A Python program was written to automate the processing of IDF files from 3D mod- els and XML files. The simulation processes were executed in EnergyPlus.

(20)

Simulation results were analyzed in R.

2.2 Building Energy Performance Simulation

Building energy performance (BEP) simulations use computer-based, math- ematical models to perform the energy calculation over one year (Coakley, Raftery, and Keane 2014). In theory, the BEP simulation uses the first law of thermodynamics to consider detailed heat and mass balance. Heat transfer within and across components is also considered. Detailed calculation of the building energy balance are carried out based on the properties of the building and dynamic external inputs.

2.2.1 Building Energy Balance

A building with the external surface as the insulation is an energy balance object (see Figure 2.2). Energy gains contain electricity, space heating, cool- ing and etc. Energy losses are mainly heat losses exiting the building (Åberg 2014).

Figure 2.2: Energy balance of a building object (Åberg 2014)

In BEP simulations, above energy gains and losses are summarized as 6 main categories of energy data, namely climate, geometry, construction, sys- tems, and operation. These categories are consistent as that of data needed for the UBEM in Section 2.1.2.

(21)

8 CHAPTER 2. THEORY

2.2.2 BEP Simulation Engines

In decades of development, a number of BEP simulation engines have been introduced. IDA Indoor Climate and Energy (IDA ICE) is one of most well-known dynamic building energy simulation engines. It is a widely-used software for BEP simulation in Sweden (EQUA 2020b). Researchers and en- gineers can evaluate building efficiency by setting up building energy models in IDA ICE (Kalamees 2004).

There are also many other simulation engines, for example, EnergyPlus, DOE2, and TRNSYS. EnergyPlus is a free building energy modeling engine funded by Department of Energy, US, which supports simulation for thermal zones, HVAC systems, and climate (Department of Energy, US 2020). Ener- gyPlus stands out for its free, open source and cross-platform features. Devel- opers around the world have implemented a lot of digital tools to navigate and control EnergyPlus for automated tasks.

2.2.3 Building Information Modeling (BIM)

Building information modeling is a digital representation of characteris- tics of buildings supported by a number of computer aided design (CAD) tools (Construction Industry Council 2013). Building information models cover multiple aspects of building data such as geometry, quantities and properties of building components (Kamel and Memari 2018). BIM is often associated with Industry Foundation Classes (IFC), a data format used to describe in- formation from the architectural, engineering and construction industry (Van- lande, Nicolle, and Cruz 2008). IFC files are capable to store the data related to energy simulation.

2.2.4 Development of Automated BEP Simulation

A large number of developers around the world are implementing automa- tion using the simulation engine, EnergyPlus. A number of digital tools have been developed to perform various EnergyPlus functions in automated mode.

One of these digital tools is eppy, which is implemented in Python environ- ment (Santosh Philip 2019). It allows to develop and modify EnergyPlus mod- els with compact Python scripts. It also reads data from output files from an EnergyPlus simulation run.

(22)

A semi-automated BEP simulation tool (Bazjanac et al. 2011) developed in Lawrence Berkeley National Laboratory automates data acquisition and trans- formation for BEP simulation from the IFC data model of buildings. Three components are covered, i.e. building geometry simplification, HVAC char- acteristics transformation, and internal loads generation. The data acquisition and transformation are the main focus.

Kamel and Memari (2018) developed ABEMAT, Automated Building En- ergy Modeling and Assessment Tool, using BIM and modified EnergyPlus source code. EnergyPlus is the BEP simulation engine used for accurate en- ergy performance outputs. The core process is named as BIM-to-BEM inter- operability process. ABEMAT is focused on building envelope components such as windows and walls. Energy simulation outputs can be obtained in text files.

Nageler, Mach, et al. (2019) introduced their tool as an interface between IDA ICE and a PostgreSQL database (see Figure 2.3). It is implemented in Java programming language. The database stores input data, assigned data, simulation results and reusable data. The reusable data (such as wall materi- als, room height, usage profiles) remain consistent in multiple dynamic simu- lations. The tool assigns building types based on input data including building geometry, construction year and the land utilization plan. One building type combines one category of reusable data. The tool then executes lisp-based scripts to import input data and assigned data, model buildings automatically and run dynamic simulations. IDA ICE write simulation results into text files.

Java scripts read and write results into the PostgreSQL database.

The model cores of IDA ICE are written in Lisp language (EQUA 2020b), and Lisp-based script commands allow modelers to simulate buildings on the command line. However, Lisp language has been criticised for its poor read- ability and steep learning curve (Steele 1990). Furthermore, IDA ICE pro- vides API functions in C programming language through a dynamic-link li- brary idaapi2.dll. All available API functions are listed in Appendix A. The project will investigate how the functions of the BEP simulation software can be accessed with IDA ICE API.

(23)

10 CHAPTER 2. THEORY

Figure 2.3: Workflow of automated simulation tool (Nageler, Mach, et al.

2019)

2.2.5 Sensitivity Analysis

In BEP simulation, the variation of different parameters can lead to dif- ferent changes to the simulation results. For instance, a change of 0.1 in the absorption coefficient caused a 0.28 difference in the calculated mean temper- atures of a glazed balcony in Hilliaho’s findings (Hilliaho, Lahdensivu, and Vinha 2015). Sensitivity analysis aims to develop understanding of the rela- tionship between input parameters and output parameters. Parameters with the greatest influence on energy use of the building are identified. Differential sen- sitivity analysis can be used to determine the total uncertainty band. The equa- tion for differential sensitivity analysis is the root mean squared summation of individual uncertainties due to each input parameter (Coakley, Raftery, and Keane 2014). Monte-Carlo sensitivity analysis is a computational algorithm to determine the total uncertainty band by perturbing all the input parameters at the same time.

2.2.6 Window-To-Wall Ratio

Investigations show that window-to-wall ratio (WWR) has an impact on the energy balance of a building (Goia 2016). It is possible to find an optimal WWR value which would bring the most significant energy saving potential.

Kheiri and Arch (2013) studied window area and climates in four locations around the world. Energy for heating and cooling were taken into account in simulations. The results showed that the WWR had an optimum value ranging from 0.20 to 0.32. A higher WWR could cause a nonlinear increase in thermal

(24)

energy loads and a decrease in lighting loads.

A similar research activity is presented in the article written by Goia (2016).

The paper demonstrates that each orientation and climate requires a dedicated optimum WWR. For buildings in very different climates, most of the optimal WWR values were in a range, i.e. 0.30<WWR<0.45. In particular, simula- tions for a building in Oslo showed that the optimal WWR values for north-, west-, east- and south-facing facades were 0.40, 0.40, 0.41, 0.56, respectively (ibid.). Results are illustrated in Table 2.1. It is worth noting that the opti- mal WWR values is defined to minimize the energy use for heating, cooling and artificial lighting. The corresponding daylight autonomy (DA) and useful daylight illuminance (UDI) were calculated as well.

Table 2.1: Optimal WWR values and corresponding DA and UDI in four ori- entations for buildings in Oslo (Goia 2016)

South North West East

Optimal WWR 0.56 0.40 0.40 0.41

Daylight autonomy(%) 66 53 57 58

Useful daylight illuminance(%)

22 0 12 13

(25)

Chapter 3 Method

3.1 IDA ICE

IDA ICE is a BEP simulation software developed by EQUA Simulation AB (EQUA 2020b). It covers thermal models, airflow network models and climate models of buildings. The model library is written in the Neutral Model Format (Kalamees 2004) which is a language for modeling the dynamical systems in equation-based simulators. The successor, Modelica, is also implemented in the IDA simulation environment (Sahlin, Grozman, and EQUA 2003). The mathematical models of IDA ICE were developed by KTH Royal Institute of Technology in Stockholm and Helsinki University of Technology with the first version released in 1998.

The latest version is IDA ICE 4.8 SP2 (EQUA 2020a). Its user interface is shown in Figure 3.1. The IFC data model can be imported and used to build an IDA ICE model directly. For simplicity, IDA ICE model is called IDM. It also supports optimization and sensitivity analysis for input parameters in the software.

Many studies have conducted the validation of IDA ICE. For instance, Hilliaho, Lahdensivu, and Vinha (2015) stated that IDA ICE can reach the highest modeling accuracy with a detailed zone model and a window structure.

The correctness of source data is important since wrong input parameters have great impact on the results.

12

(26)

Figure 3.1: IDA ICE user interface

3.1.1 IDM Model Tree

The data structure of an IDA ICE model (IDM) is represented as a hierar- chical tree. The tree structure has a root value and subtrees of children with a parent node, represented as a set of linked nodes (Knuth 2005). The tree of an IDM starts from the building object and then goes down to the level of building body, zones, HVAC components, etc. These components are highly relevant to data categories discussed in Section 2.1.2. A simplified IDM model tree is illustrated in Figure 3.2. The complete tree structure of an IDM can be found in Appendix B.

It is possible to walk through the entire tree by calling the children of nodes.

Objects of each node have attributes made up of names and values. In IDA ICE, manipulation of the IDM structure is performed with the help of the Lisp language. The data objects described above can be set up with Lisp script commands. The methods of Lisp scripting are discussed in Section 3.1.3.

3.1.2 IDA ICE API

IDA ICE API functions are provided by a dynamic-link library idaapi2.dll in the expert edition of the software. With direct calls to API functions, we can load an IDM into IDA ICE, and perform operations with Python scripts.

The communication between IDA ICE and the external program is conducted by IDA Message Broker Service. The process is recognized by a process ID or API ID.

(27)

14 CHAPTER 3. METHOD

Figure 3.2: Tree structure of an IDM model

EQUA provides an API manual documentation. According to the docu- mentation, there are 52 functions available in 4.8 (see Appendix A) which can be divided into 3 categories. The first category concerns connections with IDA ICE, while the second concerns the management of IDM data objects.

The last category contains functions that invoke special features of the soft- ware. A summary of functions that have been investigated and applied to this thesis project is given in Table 3.1.

(28)

Table 3.1: IDA ICE API functions used in this thesis

Category Function Description

Connections connect_to_ida Perform the connection to the IDA message broker.

call_ida_function Call any IDA function with given parame- ter values in json format.

ida_disconnect Terminate the connection to IDA message broker.

get_err Return the latest error produced in the func- tions.

Model Tree Management

childNodes Return a json list of child nodes to node.

hasChildNodes Return true/false depending on whether node has any child nodes.

findNamedChild Return the object of the child that has a par- ticular name.

childNodesLength Return the number of child nodes of node.

cloneNode Clone and inserts the node.

setAttribute Set the attribute of node to value given by the json structure.

getAttribute Return the value of the attribute of node.

Special Features

openDocument Open the building specified in path. Return the building object.

saveDocument Save the building object to a path.

runSimulation Run simulation for the building object.

pollForQueuedResults Return a list where the first element is true/- false and the second is the result.

getZones Return a list of the node’s zones.

runIDAScript Execute a general IDA script with node as base object.

copyObject Make a copy of node node and name it with new name.

printReport Writes a report to the out path.

getIDAStatus Return the present status of IDA, like Idle, Simulating, Finished, Terminated, etc.

(29)

16 CHAPTER 3. METHOD

3.1.3 Lisp Scripting

The modeling core of IDA ICE is written in Lisp language. Therefore, data objects in an IDM are also set up using Lisp commands. The structure of a command is described as below:

(command argument1 argument2 ...)

Actions in the software’s graphical user interface (GUI) correspond to ex- ecuting commands. In IDA ICE GUI, inserting data objects, modifying pa- rameters and running simulations correspond to the execution of a list of Lisp commands. We can use a tool Diff-Script in the GUI to review executed com- mands. The interface is shown in Figure 3.3. A Lisp compiler is also included as a tool in IDA ICE. It is an entry point for scripts that automates the execu- tion of tasks in IDA ICE. Scripts regarding operations for building envelope component (window, door and zone) have been investigated.

Figure 3.3: The Diff-Script interface in IDA ICE

Scripting for Windows

According to the IDM model tree discussed in Section 3.1.1, a window object is a child of a wall while the wall is a child of a zone. In order to update a window, we need to follow the data structure. The entry point for updating the building object is UPDATE statement. Then we find a zone and a wall by their names. The constructors for zone and wall are CE-ZONE and

(30)

ENCLOSING-ELEMENT, respectively. A sample script for adding windows to WALL_13 and WALL_15 in Zone 1 is illustrated in Figure 3.4.

Figure 3.4: Sample Lisp script for adding a window

Figure 3.5: Geometry of a window located on a wall

The constructor of window is CE-WINDOW, followed with name and type. Users can name the windows by themselves. It is important to note that there are two types of window, WINDOW and DET-WINDOW. DET- WINDOW stands for detailed window which differentiates with WINDOW in GLAZING material. DET-WINDOW allows to select GLAZING material

(31)

18 CHAPTER 3. METHOD

from a list. It includes "Double Clear Air (WIN7)", "Single Clear Air (WIN7)"

etc. The list is built-in in IDA ICE. The geometry is defined with X, Y, DX, DY. As shown in Figure 3.5, (X, Y) is the relative position of the lower left corner of the window in two-dimensional coordinates of the wall. DX is the length in the horizontal direction and DY is the length in the vertical direction.

Both DX and DY have default values, 1.2 and 1.5, respectively. Some other parameters can also be specified or be set in default, for instance, LIGHT- LEVEL, CD_LO, OPENING-CONTROL and RECESS.

Scripting for Doors

The content of the script for a door component is similar to that for a win- dow component. As given in Figure 3.6, we find a door on WALL_13 of Zone 1 in the order, building object - Zone 1 - WALL_13 - Door. The constructor of door is OPENING, followed with its name and type OPENING. The geometry is defined with X, Y, DX, DY. As shown in Figure 3.7, (X, Y) is the relative position of the lower left corner of the window in two-dimensional coordinates of the wall. The default value of Y is 0. DX is the length in the horizontal di- rection and DY is the length in the vertical direction. DX and DY have default values, 0.8 and 2, respectively. Some other parameters can also be specified or be set in default, for instance, CD_LO and OPENING-CONTROL.

Figure 3.6: Sample Lisp script for adding a door

(32)

Figure 3.7: Geometry of a door located on a wall

Scripting for Zones

Zone is an area enclosed by several walls and aggregated with thermal bridges. In theory, it is possible to add door and window components to any wall as long as they do not overlap. Each addition of a component leads to an extension of a thermal bridge. The parameter of the thermal bridge for a window component is WIN-PERIM-LEN. That for a door component is OPENING-PERIM-LEN. The script for a zone contains two parts, ENCLOSING- ELEMENT (WALL) and AGGREGATE (THERMAL-BRIDGES).

3.2 Python

Python (Van Rossum and Drake Jr 1995) is a dynamic typed programming language, that supports both object oriented and functional programming. Its syntax is intended to be highly readable, and often uses English keywords rather than special characters (Kuhlman 2009). It also uses white space in- dentation, instead of curly braces which is common in other languages.

Python is widely used as an extension language. The Python library win32- process and ctypes enables the IDA ICE process in Windows 32-bit environ- ment and call API functions. As for Windows 64-bit environment, the Python library subprocess shall be used instead of win32process.

(33)

Chapter 4

Result : Icepy - A Python Pack- age

4.1 Overview

The proposed solution is a new automated tool, icepy, that interacts with IDA ICE via API calls. Icepy is a package programmed in Python that utilizes external Python packages from the Pypi repository. Icepy itself is also avail- able in the Pypi repository at https://pypi.org/project/icepy/.

The latest version as of July 21, 2020 is 0.0.6. Starting from baseline IDMs (see section 4.2), users can use icepy to search for and modify IDMs. In the current version, the operation is limited to building envelope components which are included in the construction category of data for UBEMs (see Sec- tion 2.1.2). More specially, here is a list of available functions:

• Make changes of IDMs in building envelope components including zones, windows and doors.

• Make changes of windows according to WWR.

• Run simulation automatically for a number of IDMs.

• Extract simulation results and retrieve data.

• Perform sensitivity analysis of computational time and energy consump- tion.

The workflow of icepy automated tool and components involved are illus- trated in Figure 4.1. Due to the current limitations of IDA ICE API, icepy

20

(34)

Figure 4.1: Workflow of icepy

does not support the approaches to import IFC file or generate baseline IDM.

Icepy interacts with IDA ICE via API functions to generate IDMs required for simulation, run the simulation and export its results. Moreover, icepy allows to retrieve data and do sensitivity analysis. The following sections explain its process and components in detail.

4.2 Baseline IDM Model Generation (I)

Icepy works with a baseline IDM which contains the bare minimum re- quired to be able to run BEP simulation successfully. The minimal require- ments are a verified building envelope, valid zones inside the building enve- lope, a basic HVAC system and other characteristic settings.

A verified building envelope can be generated manually with IFC files via the IFC import module in IDA ICE GUI. Upon the requirement of the base- line IDM, one or several zones should also be created manually. It is worth mentioning that multiple zones should always be inside the building shape and should not overlap with each other.

Since the functionality of icepy is limited to building envelope compo- nents, data input for the HVAC system and other characteristic settings can be either replaced by default settings or edited manually. The default settings of a HVAC system and other characteristics for IDMs in IDA ICE are listed in Appendix C.

(35)

22 CHAPTER 4. RESULT : ICEPY - A PYTHON PACKAGE

4.3 Simulation IDM Model Generation (II)

The second stage is to generate simulation IDM by adding building enve- lope components and floors. Icepy contributes to adding these components in an automated and fast way according to user input data. The user input data and the baseline IDM need to be fed to icepy. And the output of this stage is the simulation IDM that is ready for simulation. The whole stage can be di- vided into two parts, zone management, and windows and doors setup. They are discussed in the following subsections.

4.3.1 User Input Data

User-defined input data consists of basic building information and simu- lation characteristics. The basic building information includes total building height, number of floors, ceiling height per floor, and wall width list. Each simulation IDM has only one value or one list for above-mentioned parame- ters. The first three parameters are used for zone management (discussed in Section 4.3.2). One can insert these numeric values (total building height, number of floors, ceiling height per floor) and a Python list of numeric values (wall width list) directly into icepy.

Simulation characteristics are datasets that contain design parameters for windows and doors. Initially, icepy reads these parameters into Python dictio- nary data type which is used for windows and doors setup (discussed in Section 4.3.3). As shown in Table 4.1, name of attributes and data types of values in the python dictionaries are structured. Items in the table are discussed in Sec- tion 3.1.3. Some items are mandatory and some are not.

Figure 4.2: CSV file of parameters for windows used for a sample building

(36)

Table 4.1: Python dictionary format of windows and doors

Components Attributes Data type of values Mandatory or not

Windows wall_name String YES

win_x Float YES

win_y Float YES

win_dx Float NO

win_dy Float NO

detailed Boolean NO

glazing Integer (0,1,2) NO

shading String NO

recess Float (0-2) NO

Doors wall_name String YES

door_x Float YES

door_y Float NO

door_dx Float NO

door_dy Float NO

construction Integer(1-4) NO

schedule Integer (0,1,2) NO

ela Float(0-1) NO

Manual input of Python dictionaries is time consuming for massive win- dows and doors components. Therefore, icepy also contains a Comma-Separated Values (CSV) file import module. The CSV files are translated to Python dic- tionary format. The format of CSV files should also follow the format de- scribed in Table 4.1. Figure 4.2 shows a sample of CSV file of parameters for windows used in a sample building.

There is another method to add windows to the simulation IDM by setting WWR. It is regarded as sensitivity analysis. The method and several algo- rithms will be discussed in Section 4.6.

4.3.2 Zone Management

Icepy has capabilities for managing zone properties based on the input of basic building information. The baseline IDM initially has one or more zones on the ground floor with a standard height of 2.6 meters due to the de- fault setting in IDA ICE. The zoneclone.py in the icepy package can enter the number of floors and the ceiling height per floor, calculate the floor height and ceiling height of each zone. Then IDA ICE API function getZones() is used to retrieve existing zones. API function copyObject() creates copies of exist-

(37)

24 CHAPTER 4. RESULT : ICEPY - A PYTHON PACKAGE

ing zones. API functions setAttribute() and getAttribute() set the calculated floor heights and ceiling heights to corresponding zones. Finally, a copy of the managed model is saved to the particular file path on the computer.

Figure 4.3: Left: the baseline IDM for a sample building; Right: the managed IDM with 5 floors and a ceiling height of 3 meters per floor. The building envelope is colored beige and zones are brown.

In Figure 4.3, the baseline IDM for a sample building and the managed model are compared. The model have one zone for each floor. It is set up to have 5 floors and a ceiling height of 3 meters per floor.

4.3.3 Windows and Doors Setup

We have investigated two methods in icepy to setup windows and doors, API-only method and combined API-Lisp method. API-only method uses a couple of API functions, such as childNodes(), setAttribute() and getAt- tribute(), to modify attributes of windows and doors. It directs to the target object firstly, and then set attributes. The API-only method is limited to setup numeric values. Furthermore, the setup operations are only for existing win- dows or doors. It is not possible to copy an object from another wall. The limitations of this setup method have led to the study of new methods.

The combined API-Lisp method is put forward for creating and modify- ing windows and doors in IDMs. The Python file Winstrc.py can process the design parameters for windows for a zone and generate the subordinate Lisp scripts while the file doorstrc.py does the same with doors’ design parame- ters. As mentioned in Section 4.3.1, icepy has a CSV file import module to

(38)

translate CSV files into Python dictionary format. Or users can input required dictionaries of the design data directly in the program. After that, zonestrc.py assembles the above scripts into a structured Lisp script that contains the re- quested designs of windows and doors for the zone. The content of the script follows the structure described in Section 3.1.3. It is also possible to com- bine Lisp scripts for multiple zones into one. Icepy can call an API function, runIDAScript() to execute the external Lisp scripts. The executed results are validated to prevent errors.

4.4 Automated Simulation (III)

IDA ICE allows to run a simulation of BEP within 12 months period and deliver a detailed energy report with energy consumption estimation and peak power estimation. In general, time required in the simulation process is several times more than time required for the generation of a simulation IDM. Before calling runSimulation() API function, icepy checks the status of IDA ICE. Its status should be ideal before simulation runs. After initializing simulation runs, icepy starts to monitor the processing of simulations. Due to the uncer- tainty of IDA ICE software, manual intervention is required if the simulation process is interrupted. If the simulation is accomplished successfully, icepy is able to reports two types of computational time, time for simulation execution and accumulated computational time. The former is the time required in the simulation process while the latter adds up the time required in the simulation stage and the time for the simulation IDM model generation. These two values can be used for computational analysis. Moreover, HTML-format energy re- ports can be extracted and saved as the target file by path provided to the API function printReport().

Several simulation IDMs can be simulated one after another. Icepy can manage such an automated simulation process for these models from a list of file paths.

4.5 Results Management (IV)

In IDA ICE, simulation results are presented once the simulation has been completed successfully. IDA ICE reports results for the whole building as well as for individual zones. Results for the whole building consist of the

(39)

26 CHAPTER 4. RESULT : ICEPY - A PYTHON PACKAGE

building’s energy consumption, the energy balance and the delivered energy.

Results for each individual zones are also presented. Icepy calls an API func- tion, printReport(), to extract the simulation results in HTML-format and save to a particular file path.

The extracted simulation results in HTML format reflect several energy consumption tables for the building. The energy consumption can be divided into several categories. In the end, a total is shown as ’Grand Total’. In icepy, an external library, Beautiful Soap (V4) (Richardson 2007), is used to scrape information from the HTML report. Total energy consumption (KW h) in 12 months and total energy consumption per area (kW h/m2) are scraped and converted into Python data frame format. The scraped data can be stored in a database and used for statistical analysis.

Database Server

In order to store simulated energy consumption data and data on compu- tational time, icepy provides methods for connecting to MySQL, a free open- source database system (Widenius, Axmark, and DuBois 2002). MySQL is a relational database management system. It presents the data to the user as relations.

Figure 4.4: MySQL database diagram. The foreign keys are marked in azure.

Figure 4.4 shows the structure of the implemented MySQL database. The table building stores basic building information for baseline IDMs. The building model is assigned a unique id which corresponds to bid in other ta- bles. Information of simulation IDMs upon users’ inputs is stored in the ta-

(40)

ble model including ceiling height per floor (ceiling_ht), number of floors (num_floor), operation date time (datetime), etc. The specified scenario is noted in note. The id in the table is compatible with sid in other tables. After the automated simulation stage and results management stage, simulation re- sults including computational time and energy consumption data are stored in simulation table. The columns are WWR value (wwr_ratio), total sim- ulation time consumed (total_time), time consumed for simulation process- ing (simu_time) for computational analysis, estimated energy consumption (kwh), etc.

4.6 Sensitivity Analysis: WWR

Window-to-wall ratio (WWR) has impact on the energy saving potential in the parameters sensitivity analysis (see Section 2.2.6). It is also a major part in icepy. A list of WWR values are projected for a baseline IDM and therefore, windows with corresponding dimensions are inserted into the simu- lation IDMs one after other. It is assumed that the same WWR value is set for each wall regardless of the orientation and other situations in order to simply the process. Three algorithms were implemented to calculate window dimen- sions.

The first one provides proportional distribution of windows, where height and width of window are set proportional to height and width of the wall through the square root of WWR:

W indow W idth×W indow Height = W all W idth×W all Height×W W R (4.1) W indow W idth = W all W idth ×√

W W R (4.2)

W indow Height = W all Height ×√

W W R (4.3)

In the proportional distribution scenario, windows are placed in the middle of the walls. However, an on-site visit to a number of buildings in Odenplan, a central area of Stockholm, exposed the gap between architectural design and theoretical analysis. Figure 4.5 shows that for a typical building, the window height is always set to a fixed value, 1.5 meters and the window is located 0.8 meters above the floor. Furthermore, it is more realistic to place several stan- dard windows (1.5m × 1.2m) instead of a single window in the middle on a wall. Therefore, two new algorithms for window distribution were developed.

(41)

28 CHAPTER 4. RESULT : ICEPY - A PYTHON PACKAGE

Figure 4.5: Scene view of a building in Odenplan, Stockholm

The second algorithm follows the distribution scenario with fixed window height. It sets 1.5 meters for all windows. Position of inserted window is set 0.8 meters above the floor on a wall. The variation in the window width thus reflects the WWR value:

W indow Height = 1.5m (4.4)

W indow W idth × 1.5m = W all W idth × W all Height × W W R (4.5) W indow W idth = W all W idth × W all Height × W W R

1.5m (4.6)

The last algorithm inserts multiple standard windows (1.5m × 1.2m) to a wall according to the provided WWR value. The total area of windows is calculated based on the WWR value. Then, we divide the total area by the stan- dard window area. The number of standard windows is the quotient while the remainder forms a non-standard window. All the windows are evenly placed on a wall.

T otal W indow Area = W all W idth × W all Height × W W R (4.7) Standard W indow = 1.5m × 1.2m (4.8) T otal W indow Area

Standard W indow = N umber Of Standard W indows+

N on − standard W indow Area

(42)

Figure 4.6 illustrates three scenarios for window distribution on the same wall with WWR of 0.25. The upper proportional window distribution sce- nario distributes one single window in the middle. And the middle fixed win- dow height distribution scenario has one single window with fixed height. The lower inserts two standard windows and one non-standard window. The ratio of the sum of the window areas to the wall area is 0.25 as well.

Figure 4.6: Upper: proportional window distribution; Middle: fixed win- dow height distribution; Lower: multiple standard windows distribution (WWR=0.25 for all 3 scenarios)

Separate IDM is generated for each window distribution and different WWRs.

Afterwards, simulation and reporting stages are executed for all generated IDMs.

4.7 Test

We tested and validated the application of icepy on a building in Minneberg area (Minneberg I), following the typical workflow of icepy. A detailed work- flow is shown in Figure 4.7. The first stage was to generate baseline IDM model manually. The baseline IDM of Minneberg I was generated from the IFC file and the height of the whole building was 22.5 meters. Apart from the building envelope and components, all the other systems and characteristics

(43)

30 CHAPTER 4. RESULT : ICEPY - A PYTHON PACKAGE

were set default, such as HVAC system, extra energy losses and so on. These default settings are illustrated in Appendix C.

Figure 4.7: Detailed flow diagram of icepy on Minneberg I (Step 1 - generate baseline IDM model (I); Step 2 & 3 - generate simulation IDM model (II);

Step 4 - run simulation (III); Step 5 - results management (IV))

Then we generated the simulation IDMs. This stage is divided into step 2 and step 3 in the flow diagram in Figure 4.7. Zone management was firstly done in the second stage. The number of floors was set to 5 and the ceiling height per floor to 3 meters. Zones are generated with the number of floors and the ceiling height. In order to analyze sensitivity of WWR, WWR value lists were used for windows setup. Three distribution scenarios were all con- sidered in the windows setup. The WWR value lists were applied to the model in the form of proportional distribution, fixed height distribution and multiple standard windows distribution. It should be noted that the WWR value list for proportional distribution and fixed height distribution was [0.1, 0.15, 0.2, 0.25, 0.3, 0.35, 0.4, 0.45, 0.47] while the WWR value list for multiple standard windows distribution was [0.3, 0.4, 0.45]. A total of 21 copies of the simu- lation IDMs were generated. An example of generated IDM of Minneberg I

(44)

with WWR 0.35 in proportional distribution scenario is shown in Figure 4.8.

Figure 4.8: IDM model generated for the Minneberg I case building (propor- tional windows distribution, WWR=0.35)

Icepy provides functions to simulate these models for 12 months automat- ically, to report simulation results and to store results into a MySQL database.

These operations correspond to step 4, and step 5 in Figure 4.7.

4.8 Statistical Analysis of test results

Simulation information and results for Minneberg I test (see Section 4.7) are provided in Appendix D. Two external Python libraries, Pandas (The pan- das development team 2020) and Plotly (Plotly Technologies Inc. 2015), were used to do statistical analysis.

4.8.1 Computational Time Analysis

The entire IDA ICE simulation process consists of mathematical model generation and simulation execution. Two types of computational time are collected after each simulation process. Figure 4.9 compares the accumulated computational time in three WWR distribution scenarios that were carried out in the Minneberg I test. And the time of executing simulation in 3 scenarios are compared in Figure 4.10.

(45)

32 CHAPTER 4. RESULT : ICEPY - A PYTHON PACKAGE

Figure 4.9: Comparison of accumulated computational time in 3 WWR dis- tribution scenarios in terms of time consumed (second) and WWR values.

(Proportional distribution - green; fixed height distribution - blue; multiple standard windows distribution - red)

Figure 4.10: Comparison of time of simulation execution processes in 3 WWR distribution scenarios in terms of time consumed (second) and WWR val- ues.(Proportional distribution - green; fixed height distribution - blue; multiple standard windows distribution - red)

In general, the accumulated computational time and time of simulation execution process follow almost the same trends in each scenario. In both proportional and fixed height distribution scenario, the accumulated computa- tional time remained constant for approximately 163 seconds when the WWR values increased, i.e. change of window dimensions. The time of simula- tion execution process was approximately 160 seconds. We can conclude that

(46)

the dimension of windows does not significantly influence the computational time. In the multiple standard windows distribution scenario, the accumulated simulation time and the time of the simulation process increased significantly with increasing WWR values. According to the definition of the multiple stan- dard window scenario, the increase of WWR value led to the increase of the number of standard windows (1.5m × 1.2m) on the walls. We conclude that the number of windows of the building was proportional to the computational time in IDA ICE simulation processes. For instance, for WWR value 0.4, the accumulated computational time in the multiple standard windows distribu- tion scenario was 2413.65 seconds which was approximately 13 times higher than that both in the proportional distribution scenario and the fixed height distribution scenario.

Figure 4.11: Comparison of simulated anaul total energy consumption (kW h) in 12 months in 3 WWR distribution scenarios in terms of energy consumed and WWR values. (Proportional distribution - green; fixed height distribution - blue; multiple standard windows distribution - red)

4.8.2 Energy Consumption Analysis

The total energy consumption (kW h) in 12 months and the energy con- sumption per area (kW h/m2) for Minneberg I in three WWR distribution sce- narios are shown in Figure 4.11 and Figure 4.12. The increase of WWR val- ues resulted into simultaneous increase of simulated annual total energy con- sumption for all three window distribution scenarios with difference of less than 1%. For example, if WWR value was 0.4, total energy consumption in the proportional distribution scenario was 749.5 thousand kW h, and that in

(47)

34 CHAPTER 4. RESULT : ICEPY - A PYTHON PACKAGE

the fixed height distribution scenario was 749.2 thousand kW h. Total energy consumption in the multiple standard windows distribution scenario was 747.3 thousand kW h. The difference calculations were:

1 − 747.3k

749.5k = 0.29%

1 − 749.2k

749.5k = 0.04%

The energy consumption per area in 12 months in 3 WWR distribution scenarios share the same identities as above (see Figure 4.12). If we combine conclusions from computational time analysis and conclusions of energy con- sumption analysis, a brief summary can be stated. The energy consumption of the building increases with the window-to-wall ratios of walls, regardless of the number of windows. However, increasing the number of windows leads to an increase of computational complexity, which leads to the extension of computational time.

Figure 4.12: Comparison of total energy consumption (kW h/m2) per area in 12 months in 3 WWR distribution scenarios in terms of energy consumed and WWR values. (Proportional distribution - green; fixed height distribution - blue; multiple standard windows distribution - red)

(48)

Discussion

5.1 Usability of Icepy

Icepy is developed as an automated tool to perform efficient BEP simu- lations with IDA ICE, which are required for more advanced UBEMs. The overview of the advanced UBEM workflow is shown in Figure 5.1. Users can utilize icepy to create and modify IDMs with a few lines of script, which re- leases human modelers from vast amounts of manual work.

Figure 5.1: Overview of Urban Building Energy Modeling

Icepy provides the interaction with the simulation engine IDA ICE in an automated and fast way. It is not only designed for one specific project. Users are welcome to implement icepy for their own automated BEP simulations with IDA ICE. Since the package is published as open-source, it allows for further development of new tools reusing the already developed code. Both the source code and the Python package are available in the Github repository

35

(49)

36 CHAPTER 5. DISCUSSION

and the Pypi repository.

The fruitful collaboration with EQUA engineers on this thesis project was helpful in orienting the development of icepy and provided a deeper under- standing of IDA ICE and its API functions.

The usability of icepy has been validated in the test case of Minneberg I.

Icepy allowed to generate required simulation IDMs with structured user input data. It interacted with IDA ICE software dynamically. Every time after API calls, the result from IDA ICE was pooled and the model was validated. The execution of simulation and export of results were launched with a few lines of script. Furthermore, the sensitivity analysis for WWR was conducted in the test. Icepy utilized a list of WWR values to create windows in 3 window distribution scenarios for the IDM.

5.2 Combined IDA ICE API and Lisp Solution

Icepy enables automated processing of user inputs and simplifies the gen- eration of the IDA ICE simulation model. Icepy plays the role of a bridge between user input and IDA ICE. Communication takes place via IDA ICE API functions. During the whole project, we investigated a lot how to use API functions to communicate properly and efficiently. Using API function calls is heavily utilized in the icepy package throughout the whole automated work- flow.

However, some tasks cannot be sufficiently performed if we only call API functions due to the certain limitations of API in the current version of IDA ICE. Therefore, Lisp scripting is used as an additional method. Hence, icepy is a combined API and Lisp solution for automation of BEP simulations.

Since the simulation modeling core of IDA ICE is written in Lisp language, Lisp scripting has significant advantages in generating IDMs. As discussed in Section 4.3.3, Lisp scripting allows to create new building envelope compo- nents and to modify existing building envelope components, while API func- tions can only modify existing components. Moreover, the execution time for the combined API-Lisp method was shorter than that for the API-only method as was shown for the process of modifying existing windows. A short test was done to prove the difference in execution time.

(50)

In general, when asking icepy to change the width and height of 10 win- dows on multiple walls in a zone, it takes the following steps for the API-only method: (1) findNamedChild to direct the zone; (2) findNamedChild to di- rect the first wall; (3) findNamedChild to direct the window; (4) setAttribute to change the width; (5) setAttribute to change the height (6) loop (2)(3)(4)(5) for another 9 times. Alternatively, if the combined API-Lisp method is used, there are three steps: (1) Generate lisp scripts by icepy; (2) runIDAScript to execute the lisp scripts; (3)IDA ICE Processing. The short test measured the time it took to call API function and the time it took to process Lisp scripts.

It was reported that the time to call various API functions was close to 0.4 seconds. And the time of processing Lisp scripts increased with the number of scripts. In practice, the script to modify 10 windows took no more than 2 seconds. There may not be much of a difference when you change the prop- erties of 1 window. However, when there are 10 windows or more, there is an obvious difference. It is worth noting that software processing time changes on different computers. The values here are for reference only. Table 5.1 com- pares the time it takes to change the width and height of 10 windows using two methods.

Table 5.1: Comparison of times to change the width and height of 10 windows using the API-only method and the combined API-Lisp method

Steps API-only method Elapsed time

Combined API-Lisp method Elapsed time 1 findNamedChild to the zone 0.4s generate lisp scripts 0.5s 2 findNamedChild to the wall 0.4s runIDAScript to execute the

lisp scripts

0.4s 3 findNamedChild to the win-

dow

0.4s processing 0.5s

4 setAttribute to change the width

0.4s - -

5 setAttribute to change the height

0.4s - -

6 loop 2,3,4,5 for 9 times 1.6s * 9 - -

Total 16.4s 1.4s

We conclude that the combined API-Lisp method outperforms the API- only method. It took more than 16 seconds for the modification of 10 windows using the API-only method while the combined API-Lisp method spent no more than 2 seconds. However, both methods have been kept in icepy package.

Users can decide which method shall be implemented.

References

Related documents

The main findings reported in this thesis are (i) the personality trait extroversion has a U- shaped relationship with conformity propensity – low and high scores on this trait

If there were to be added many more functions with similar function names, only using the container rule might result in many false matches, especially with permuted function order.

Dwelling C’s new heating system (gas central heating &amp; a gas fire) has a lower delivered energy than the old heating system (gas fire, two heat pumps, radiators and heating

SLJ = Standing long jump, WAnT PP = Wingate anaerobic test peak power, WAnT PP/BW = Wingate anaerobic test peak power/body weight, WAnT MP = Wingate anaerobic test mean power,

As final result, the allowable tolerance tells to the modeller that he/she has to asses carefully environment parameters, thermal loads from free sources and panel radiator,

,i aaa aaa aa a 2 , a iaaae,a aaaaaa aeeaaaa aaaa eaaea aea aaaaaaa aeaaeaa a aaaa ,a ,aaneaaaaeaa aaea aaa,a aa,aa.. aaaa aaaea aea aaa aaa,aaea neaa aaaaa aaaaeaea aaa,a

alla barn är olika men här är det så tydligt att man inte ens behöver fundera om man skall planera något, att man kopierar något i fem exemplar för att man har fem elever, utan

And the heaters are not equipped with any regulation valve, which means that the energy is used for heating without any regulation and when the temperature is higher than the