The Urban Building Energy Retrofitting Tool: An Open-Source Framework to Help Foster Building Retrofitting Using a Life Cycle Costing Perspective. First Results for Montréal

1. Introduction

One of the most demanding segments of urban-scale decarbonization is building retrofits. The building sector accounts for more than 35% of global energy consumption and almost 38% of CO₂ emissions if we consider embodied energy [1].

The decision of what we do to existing buildings can significantly impact future CO₂ emissions. In the scientific community, there are significant doubts that demolishing and rebuilding net zero is a better option than retrofitting because of the reduced CO₂ embodied emissions of the latter option [2,3,4], but a strong effort must be made to ensure that it can be attractive to all stakeholders.

According to [5], even after 90 years of lifetime, retrofitting seems a better option than demolishing. In most cases, retrofitting seems to be the best option from a multi-factor social, environmental, and economic perspective. According to recent references, the stock of existing buildings will account for 75% of GreenHouse Gases (GHG) emissions, whilst new buildings will account for 25% (2021 World Green Building Council. WorldGBC Net Zero Carbon Buildings Commitment). According to recent references, the stock of existing buildings will account for at least 75% of GHG emissions while new buildings will account for 25% [6] until 2050.

In Canada, the retrofitting for low-rise residential buildings is less than 1%, and, for commercial buildings, 1.4% of floor area per year [7]. However, although the goal seems clear for most policymakers in different countries, massive and large-scale retrofitting is not happening. Very interesting examples of successful case studies have been happening worldwide if life cycle costs are taken into account[8], but large-scale implementation is not successful for several reasons. The most significant reasons [9] are the knowledge gap, the expertise gap, the lack of political commitment, inadequate policies, the speed to scale up, the huge necessary investment capital, and the long return on investment.

Some of those, especially the ones related to policymaking and the knowledge gap, linked to the lack of detailed life cycle information on the impact of these measures [10], could be overcome using tools such as Urban Building Energy Modelling (UBEM). The demand for low-carbon and energy-efficient urban development has made UBEM a crucial technique for evaluating the energy efficiency of buildings at the city scale. Reinhart and Cerezo Davila [11] define UBEM as a bottom-up, meta-scale, physics-based engineering model that combines mass flow and heat models to forecast indoor-outdoor environmental conditions and energy consumption for groups of buildings. Considering interdependencies between buildings and their surroundings, such as the impacts of height, density, and radiation exchange on energy consumption, it goes beyond conventional Building Energy Modelling (BEM), which concentrates on individual structures [12]. By offering insights into energy consumption patterns at the daily, seasonal, and annual levels, UBEM helps urban planners and decision-makers assess energy-efficient designs, retrofit options, and renewable energy potential [13,14]. UBEM is a vital instrument for sustainable urban energy planning because of its applications in grid integration, urban planning, and carbon reduction strategies.

Therefore, an Urban Building Energy Retrofit Tool based on UBEMs could be a step forward thanks to its scientific, modular, and scalable approach and ease of application to any city, given the reduced datasets necessary to implement it in a first rough approach.

2. Literature Review on UBEM and Retrofit Tools

2.1. Existing Urban Modelling Tools

Many tools have been developed in the last years to model energy flows in cities, trying to simplify the use and access to urban energy models but covering only partially the complexity of the energy system [15]. The so-called UBEM aims to provide understanding in all aspects of a city’s energy flows, from building energy "consumption" to on-site renewable "production", including traffic or waste management. Within this broad field, many have focused on building stock, which is the aspect the authors will focus on in this article.

UBEM analyses the building demands in their urban context, and it is important to consider their interactions within urban areas with other buildings and other urban area objects. In their review paper on urban models and tools, Allegrini et al. [16] pointed out the importance of building-to-building thermal and solar interactions, i.e. the importance of adjacencies between buildings and the shading of different buildings caused by neighboring surfaces, Urban Heat Island (UHI) or urban vegetation and their impacts on the results of urban energy system simulations.

This interaction between a building and other objects in an urban area, like another building that causes shading views from façades to the sky and sun, was considered for the first time in 2005 in the Sustainable Urban Neighbourhood modeling tool, SUNtool [17]. A thermal model of the building, coupled with Heating, Ventilation, and Air Conditioning (HVAC) was integrated into the tool, also including an urban-sensitive radiation model, the Simplified Radiosity Algorithm (SRA) [18].

Heavily inspired by SUNtool, but further refined with more rigorous thermal and behavioral models was the comprehensive software CitySim. Citysim was a step forward with respect to previous UBEM tools, and it used a Reduced Order Models (ROM) developed at EPFL in Switzerland. The tool also allowed for the calculations with a simplified Dynamic Simulation Tool and integrations with other tools, like the transportation tool MATSIM[19].

Another tool developed later was Simstadt. SimStadt is an urban workflow engine written in Java and developed by the University of Applied Sciences Stuttgart [20] in 2013. SimStadt can use both simplified geometry (extrusion of footprint) and, when available, it can use City Geography Markup Language (CityGML) format for detailed geometry (Level of Detail (LoD) 2) while considering the roof shapes. A study done by [21] modeled about 1000 buildings in Rotterdam, Netherlands, using the geometry format of CityGML. SimStadt benefits from the direct integration of , which contains thermophysical building attributes in a machine-readable format as an extension of CityGML [22]. Like other UBEM tools, SimStadt requires several preprocessing steps of input data to be suitable for energy analysis and has monthly output resolution. Finally, it does not account for transportation and mobility calculations and their connection with the UBEM. However, it provides life-cycle analysis using embodied carbon for building construction in a seamless tool [23].

At the same time, the Urban Modeling Interface (UMI) was developed at MIT in 2013, using EnergyPlus as the energy simulation engine. The input geometry used in the UMI is provided by Rhinoceros software.[24]

CityBES was also developed running EnergyPlus as the simulation engine, but in this case, using the City Geography Markup Language (CityGML) format for 3D urban building modeling in LoD1 and LoD2 (considering the roof shapes). It can also be linked to EnergyADE for using the thermophysical building attributes.[25].

Two other UBEM tools that use Resistance Capacitance (RC) models as a base engine are OpenIDEAS (an open-source platform) and CEA [26]. The former uses an interesting approach to structure the entering data sources and the workflows to allow good input preprocessing, output postprocessing, and workflows to happen outside the main structure of the tool. CEA is one tool that integrates more aspects, including several input sources, incorporating cost-benefit analysis, transportation use cases, and greenhouse gas emissions. Shadow analysis is also incorporated.

Urban Renewable Building and Neighborhood Optimization (URBANOPT) is one of the latest tools developed by the National Renewable Energy Laboratory (NREL). This tool uses EnergyPlus and is open-source [27,28]. It also contains lighting simulation but does not include transportation/mobility, life cycle, or cost-benefit analysis.

The Tool for Energy Analysis and Simulation for Efficient Retrofit (TEASER), developed at Aachen University (RWTH), is based on RC models, and it looks at several carbon emission accounting strategies[27] .

In the last years, new developments have been made. An example of one of the tools that incorporates a similar approach to the one that the authors have undertaken in the last years is AutoBPS, A tool for urban building energy modeling to support energy efficiency improvement at city-scale [29]. Two other interesting recent developments in this field are CityBEM [30], based on own developed heat transfer equation methods and UECC [29], based on reduced order models (R.O.M). In parallel, an interesting approach to infer occupancy for UBEMs using mobility-related data has been undertaken by the tool Dest-urban (Development of a Platform of Urban Building Energy Modeling Based on DeST) [25]. A chronology to the tools is shown in Figure 1.

A summary of the different UBEM tools and their main aspects has been elaborated and is shown in Table 1, Table 2, Table 3 and Table 4.

2.2. Gaps to Be Overcome

The different UBEMs described in the previous sections have established the seed for deploying relevant future urban system energy tools.

However, several research questions arise from the literature review and the tables mentioned. The capacity of these tools to answer real cost-benefit questions from the building decarbonization sector is often under doubt for several reasons. When dealing with such complex problems, the usual question is whether the UBEMs are designed with a goal in mind and whether they will be useful for more than this goal.

The capacity, therefore, for the aforementioned UBEMs for adaptability and modularity is small. Although they try to be multi-faceted tools, the design of a tool, if not considered modular from the beginning, tends to be adapted to the use case for which it was first developed. Each UBEM was developed with a back-end calculation methodology in mind, which is applicable in the field for which this methodology is useful.

Another important aspect is the lack of scalability to a large number of buildings and different locations. For example, most of the aforementioned tools have been applied to one or a few (under 5) use cases and, in most cases, linked to a small set of buildings. The use, in some cases, of simplified Reduced Order Models (Suntool, CitySIM, OpenIDEAS, CEA, TEASER), the quality of the results for the use of very simplified models makes it difficult to extend to . Conversely, using detailed dynamic simulation tools (UMI, CityBES, UrbanOPT) makes it hard to develop large-scale scenarios.

These tools lack of capacity to deal with several types of input datasets (as seen in Table 2) make it necessary to clean and adapt the input data sources every time. This is a highly cumbersome process that sometimes takes months and limits the scaling up of the methodology. The typically incoherent input datasets from cities also make it necessary to compare several sources of information and choose the cleanest, which, in the cases of most current UBEMs, is a process that has to happen before using the tools.

The fourth is the lack of data input automation. Many authors [15,16,31,32,33] have delved deeply into the relevance of data input automation, which reduces the chance of input errors and also human costs as the data processing is, in most cases, one of the highest time consumers [34]. Lack of open source developments is also an issue, at least in some aspects of the different UBEM. UBEMs deal with very different sectors of GHG emitters (buildings, transportation, water), and the will to break the silos and integrate attractive models from academia in all those fields should be the goal. The development of UBEMs using proprietary software can partially block researchers from accessing these tools.

As a last point, clear communication of results has long been an issue in using urban simulation tools [16]. In the urban simulation tools field, GIS thematic mapping becomes a very intuitive tool for final users to access and understand results [35,36,37].

2.3. Reasons for the Development of a New Model

The research question that arises from the literature review and the gap detection is whether the current UBEM tools are designed to address the challenges required by different use cases. Is the structure behind the development of each UBEM conditioned by the use case for which each UBEMs was developed? After reviewing the previous chapter, I found a clear link between the use case and the structure of the tools.

The current tools have developed ad-hoc solutions to enter city-based data, populate them with structured information about building archetypes, and directly produce the necessary building simulation input. Some of them have done so using open-source structures, but some others have focused on their engines and developments. Moreover, very few are working in different sectors (such as buildings and transportation), and even fewer (only UMI) are linking the results of those different sectors.

The main problems lay, therefore, in the flexibility of these tools to capture different types of data sources and to use different simulation tools. Using different simulation tools is crucial for working with different sectors and working at different levels of detail in each sector. The new developed model is, thus, based on creating a central data model with a clear definition of all the processes in cities that could be used for decarbonization. This central data model would be where different sources of information would be stored and structured, and the structure could produce the necessary input files for different typologies of software, depending on the use case. It would also be the framework that could allow different processes to store information and chain different software, using the output of one process as an input for the following.

Therefore, the answer to all those gaps is creating an open-source, flexible, and structured framework that allows multiple input files of city characteristics and tools to be used and integrated.

This framework should allow for the development of different use cases, all related to improving the sustainability of cities. The non-adherence to any concrete software, but the decision to create a framework to integrate them all is essential for this purpose. Some tools will be preferable to others when analyzing several use cases, and the platform will deal with them.

So, the research question comes to understanding the essential structure of an Urban Energy Modeling tool with limited data that can help foster retrofitting the building stock in cities.

As an answer to this question, the framework described in the present paper, the TOOLS4Cities hub, has been developed in the last three years, and the application of this framework to the concrete case of an Urban Scale Retrofit Tool.

3. Materials and Methods

The previously defined TOOLS4Cities UBEM framework is the basis for developing a tool to analyze the potential of deploying large-scale retrofitting strategies in cities. The current paper will explain the structure of the retrofit tool and some aspects of the software architecture. The goal is to show the framework’s basic structure and prove its modularity and scalability with a use case. The details of the implemented software structure are out of the scope of this paper, and interested readers can refer to Appendix A to familiarize themselves with details of the software architecture. The developed code is open source and available for cloning in the git [38].

3.1. General Overview

The general overview of the retrofitting workflow is shown in Figure 2. The workflow is part of the TOOLS4Cities urban simulation platform, developed at the Next Generation Cities Institute of Concordia University, aiming to simulate urban areas holistically. The main part of this simulation platform is a set of pipelines, data models, datasets, and catalogs called the TOOLS4Cities Hub. The building retrofit tool comprises building modeling, energy system modeling, scenario selection, techno-economic assessment of scenarios, and visualization modules using different parts of the TOOLS4Cities Hub. These modules will be explained in detail in the following sections.

The retrofit workflow’s essential objective is to analyze the energetic, environmental, and economic impact of retrofitting any building in a city. The idea is to pick any building in a city and get the investment costs, operational costs, and environmental emissions of leaving the building as-is or implementing some pre-defined retrofitting strategies. In the first approximation (or Minimum Value Product (MVP)) to the retrofit workflow, three basic retrofitting strategies were implemented (skin retrofit, energy systems retrofit, and deep retrofit) for all the buildings of the city. However, the tool’s structure would allow for more detailed large-scale retrofitting strategies and heuristics to apply different strategies depending on the different typologies of buildings. As an example, probably the oldest buildings might require a complete skin retrofit, but maybe the newest will only require changing windows or retrofitting the energy systems.

3.2. Building Energy Modeling Workflow

For good scalability, a comprehensive software structure has to be developed to allow for the evolution of the datasets and the adaptation to different tools while maintaining a robust ontology. As shown in Figure 2, the UBEM structure of the TOOLS4Cities consists of importers, exporters, and a representation of the ’City’ with as many objects, like buildings, green spaces, roads, etc., that come from the input file the user provides. The creation of this city replica is made possible through object-oriented programming where a ’City’ class includes different attributes, some of which are objects from other classes that represent different city objects. Therefore, from this point onward, in this paper, when ’City’ is referred to, it is an object from the ’City’ class in the tool’s backend, which can have 0 to many buildings and other real objects in any urban area.

The objective in developing the UBEM workflow was to provide a platform where the input file for running different simulation tools like EnergyPlus or INSEL could be exported, and these tools could be run externally. The handling of the needed data is made possible through different data models and catalogs [39]. A data model is a formalized framework that defines how data is structured and represented within a system. It is distinct from the data itself and does not dictate where it is physically stored. Instead, it serves as an abstract blueprint that helps us understand the relationships and interactions among all the data components within the system.

At the core of the platform are the Data Models. Addressing the gaps mentioned above in existing UBEM models highlights the critical need for a well-organized data structure. Such a structure is essential to facilitate clear and effective interactions among various sectors involved in urban decarbonization use cases. Furthermore, it will enable UBEM tools to function as versatile, multi-purpose instruments, allowing for adaptability and customization of the final tool to meet evolving requirements. The following sections explain what data are needed and how they are used in UBEM workflow.

3.2.1. Building Geometry

The first step in modelling buildings is creating a 3D city model. In the TOOLS4Cities Hub, the 3D model could be generated from different formats, including GeoJSON and CityGML. In the case of buildings, the input file must have information about the year of construction, building function, and height. First, an instance from the ’City’ class is created in this process. Then, it is populated with the city object information from the input file using a specifically designed importer to enrich the city with data from the geometry file.

Once the extruded model of the city objects is created, the internal zones of buildings are defined. Currently, each building has a single internal zone, but different modes of multi-zoning are being developed.

3.2.2. Construction

After creating the ’City,’ the buildings need to be enriched with physics or construction data to create the thermal zones inside the building. The whole process of urban modelling in the TOOLS4Cities is archetype-based, meaning that the buildings are enriched with construction data purely based on their construction archetype. Therefore, before starting the UBEM process, the sets of archetypes need to be created. The standards followed by the Next-Generation Institute in distinguishing archetypes are based on their function, period of construction, and climate zone. Therefore, this standard must be followed in new case studies where their archetypes still need to be created in the TOOLS4Cities Hub.

3.2.3. Usage

The usage archetypes contain data on a building’s internal gains and profiles. These archetypes are assigned to a building solely based on the building’s function. The profiles refer to the heating and cooling setpoint schedules, HVAC availability, occupancy, lighting, appliance usage, and domestic hot water consumption. For each category, 3 sets of schedules are defined and used for weekdays, Saturdays, and Sundays/holidays. The schedules contain hourly fractions of the density values for the mentioned categories.

3.2.4. Weather

The climatic data is an essential part of building modeling. The hourly outdoor temperature, direct normal irradiance, diffuse irradiance, etc., values are read from a weather file that could come from any source. If the user provides no weather file, that location’s ’.epw’ file will be downloaded automatically and used for simulations.

3.2.5. Modeling Tools

Once the ’City’ buildings are enriched with the required data for modeling, a factory of different exporters could export the input file for different simulation tools. The exporters capture the necessary data from the central data model, which describes the city’s parameters, and convert them into input data files for different software. At the moment, version 2.0 of the framework is exporting data models to the following simulation tools:

• Simplified Radiosity Algorithm (SRA), a tool designed to calculate the plane of array irradiance on all surfaces, allows for a detailed radiation calculation to deploy solar photovoltaic analysis.
• INSEL [40], a tool which is capable of calculating the monthly and yearly energy demands for the buildings of the city using a static and dynamic methodology
• EnergyPlus, one of the best known and extended tools to calculate energy demand and consumption of buildings
• TRNSYS, another one of the reference tools for building and energy system simulation.

The process includes running methodologies, which run the different tools and then store the results back in the central data model, as the results paragraph will define. Although some of the tools have the same objectives (TRNSYS, Insel dynamic and EnergyPlus), the inclusion of the different exporters has been made to facilitate the integration of different research teams to the methodology, as well as to compare the capacities of each software, and be able to pick each of them depending on the use case. As an example, the capacity of TRNSYS or INSEL to integrate external sources of radiation seems interesting as an option to integrate the SRA methodology into a simulation engine. EnergyPlus, on the other hand, has an internal radiation methodology.

EnergyPlus Workflow

Given that the retrofit costing methodology only involves using Energyplus, we have explained in more detail the methodology used for Energyplus. One of the aforementioned gaps is the scalability to a large number of buildings, and one of the main reasons is the long computing times that running white box models take. One of the software developments to speed up the process has been the Energyplus workflow. The EnergyPlus workflow exports the central data model with all the details of the buildings into an IDF file. Buildings are modeled as one-zone models in the current version. To speed up the process, buildings are created in the idf as zones of the building, but incorporating the shadings and adjacencies between the different zones. The eppy library was initially used to create idf files, but the software characteristics of the library (repeating the different schedules per zone and having to access extended dictionaries) caused that when simulating more than 500 buildings, the idf creation was significantly slowing down the process. Therefore, a new library has been developed to reduce the exporting time. It will have to be updated for different versions of Energyplus, but it allows for large-size IDF exporting, which is essential for Urban Simulations. Although the main reason for the use of more simplified models is the time used in the simulation of white box models, the current improved process can simulate up to 3000 buildings in less than 2 hours using a 1x Intel® Xeon® E-2400 processor, up to 8 cores at 95W.

SRA

The simplified radiosity algorithm used by the tool uses the methodology developed by [17], that applies radiosity to predict external irradiance (shortwave and longwave) and internal illuminance in an accurate and very efficient way, in a single computational module. Although for the Energyplus simulation, the internal radiation calculation engine is used, the SRA is used to calculate the radiation on surfaces to implement solar PV calculations. The SRA importer makes use of the geometry imported and the physical characteristics of the materials at the external layers of the walls, together with the weather data, to calculate the short wave radiation exchange between external walls and roofs

3.2.6. Results

After running the simulations, the Results importer is used to enrich the buildings with the results of the simulations. This step helps us to use the ’City’ structure as it is for further analysis, but this time, buildings have energy demands.

3.3. Energy System Modeling

For each location, research is done to identify the dominating energy systems used to supply HVAC and DHW demands. These systems comprise energy generation, distribution, storage, and heat emission components. All these systems together form an energy system archetype or template. This explained structure is the basis of the energy system data model in the TOOLS4Cities Hub.

The created data model (Figure 3) functions as a thorough and well-structured framework intended to record and handle the intricacies of energy system setups methodically. The "EnergySystemCatalogue," a conceptual entity that functions as a flexible library with multiple subclasses, is at the centre of it. These subclasses, divided into areas including distribution, generation, storage, and emissions, are essential for providing specifics about particular components. The versatility of the model is demonstrated by its capacity to represent components in two different ways: real-world components available on the market or template structures with predefined attributes and no assigned size. This two-pronged strategy produces a flexible framework that can handle various situations.

Once the energy demands are calculated, the energy system template is assigned to the building based on its function and vintage. The associated data of the template components, like the efficiency of generation components, will be retrieved from different ’.xml’ files that contain energy system data. An importer enriches buildings with data that can be easily used to calculate energy consumption in any area.

3.4. Retrofitting Scenarios

Although set of three retrofit scenarios for the first retrofit workflow have been established as a first test case to validate the full methodology. These scenarios are the following:

• Scenario 0, Business as usual: current status of the building, with its skin, but replacing the energy systems once its lifetime is finished (with the same performance as the original).
• Scenario 1, Skin retrofit: the building’s envelope has been updated to current legislation.
• Scenario 2, HVAC systems optimization + PV: an update on HVAC systems to best available technologies is done, coupled with using the available roof space for Solar Photovoltaics, in case the shaded area is less than 30% of the total area.
• Scenario 3, Deep retrofit: a scenario including both previous scenarios

3.5. Costing Workflow

In the case of the Life Cycle Costing (LCC) process, we have dealt with them in a separate Classes structure. The different nature of economic hypotheses, which are much more volatile than energy calculations, has pushed the team to develop a parallel structure coupled with the hub structure. This parallel structure will allow for further analysis, from the perspectives of economic scientists, like implementing dynamic cash flow modeling with sensitivity and risk analysis, a topic that has been detected as essential [41], or monetizing the externalities. The methodological approach for the economic analysis of the retrofit scenarios comprises the general LCC framework approach and the evaluation of externalities included in the general cost modeling methodology. LCC analysis, also known as total cost accounting, compares full costs during their useful life while defining alternative investment options in buildings or operating activities. For example, a baseline case can be compared with a potentially attractive one using the LCC of a retrofit scenario. LCC can showcase the different cost allocations of both scenarios, given that one of them already exists and does not imply extra investment costs. The new proposed scenario implies an extra investment but, on the other hand, minimizes yearly costs and, potentially, other externalities. LCC analysis design and practice is standardized in ISO 15686-5 [42], establishing the necessary criteria for analyzing Life Cycle Costing in the built environment. The global formulation is shown in equation (1)

$$\begin{array}{c}\hfill LCC=CAPEX-Subsidies+\\ \hfill \sum _{i=nyears}{\displaystyle \frac{{\sum }_{k=chaptinvest}CAPE{X}_{repositionk}{(1+cpi)}^i}{{(1+d)}^i}}+\\ \hfill \sum _{i=nyears}{\displaystyle \frac{{\sum }_{j=nfuels}Operationalcostsj{(1+epi)}^i}{{(1+d)}^i}}+\\ \hfill \sum _{i=nyears}{\displaystyle \frac{{\sum }_{l=nconcepts}Maintenancecostsl{(1+cpi)}^i}{{(1+d)}^i}}+\\ \hfill \sum _{i=nyears}{\displaystyle \frac{{\sum }_{m=nincomes}Operationalincomesm{(1+epi)}^i}{{(1+d)}^i}}+\\ \hfill \sum _{i=nyears}{\displaystyle \frac{{\sum }_{n=nextern}Externalitiescostsn{(1+extpi)}^i}{{(1+d)}^i}}+\\ \hfill {\displaystyle \frac{Endoflifecosts{(1+cpi)}^i}{{(1+d)}^i}},\end{array}$$

where

• $CAPEX$ = initial investment (product acquisition + installation and commissioning);
• $CAPE{X}_{reposition}$ = investment cost for the reposition of the equipment after the end of life of the equipment;
• $Operationalcosts$ = refers to the variable costs of operation;
• $Maintenancecosts$ = refers to the variable costs of maintenance;
• $Operationalincomes$ = refers to the variable incomes of operation, i.e. solar PV feed-in tariff;
• $Externalitiescosts$ = refers to the variable costs of externalities, like CO₂ or other emissions;
• $cpi$ = consumer price index increase. series of yearly values
• $epi$ = energy price index increase, which depends on the fuel type. series of yearly values
• $extpi$ = externalities price index increase, which depends on the future externalities market, such as CO₂ markets
• d = discount rate for the retrofitting

CAPEX calculation In our tool, we are using a data catalog structure to calculate the CAPEX costs. In the case of CAPEX, UNIFORMATII has been chosen as the format to classify building elements and related site work [43]. The level of detail used in the first validation of the tool is significantly low, as the solutions are looked at from a global perspective. Within this LoD1, and for the sake of the first tests, only additional costs of the retrofitting have been considered, with average values per surface of the different elements, not distinguishing different solutions. The first structure of the data catalog for CAPEX costs is shown in Table 5.

3.6. Visualization of Outputs

A significant effort has been made in the presentation and accessibility to the results for the general public. As mentioned in Section 2.2, this is one of the big gaps we detected in other tools.

A web page showing all the buildings in the city is used to facilitate access to the city-simulated data and let the user interact with the data. The results are shown using two different services in the Citylayers test web page (https://nextgenerations-cities.encs.concordia.ca/citylayers/).

4. Results and Discussion

4.1. Case Study: Montreal

The first proof of concept for developing a retrofit calculation for an entire city was implemented on the island of Montréal. Over time, various geospatial, construction, usage, and system data were collected for Montreal to enable the tool development team to create different archetypes. To validate the process, a focus has been put to analyse two residential areas and a set of institutional buildings and compare the results of the tool with statistical and real operational data.

4.2. Selected Areas

To validate the surface and consumption for single-family houses, duplexes, and triplex, we focused on two big residential low-height areas in Montréal. The choice of the two sectors was to find homogeneous areas that could be compared with a concrete typology of building, for which we could have statistical data. Although in the two chosen neighbourhoods there were some taller buildings and some commercial buildings, more than 95% of the built surface in both is occupied by single-family, duplex and triplex buildings. The first is in Pointe-Saint-Charles neighbourhood (between Wellington, Ash, Leber and Congrégation streets), with a total of 313 buildings, most of which were built before 1946. The second subset of buildings are located in Saint Leonard neighbourhood(between Langelier boulevard, Robert boulevard, de Guyenne street and Louis Sicard street), with a subset of 249 buildings from the 1960s-1990s. Figure 4 shows the zones that have been simulated. This gave rise to a total of 563 buildings.

Following the results of the first simulations, we analyzed in detail the origin of the differences between simulated and actual consumption. The sources of error were analyzed from two points of view: (i) input data and (ii) simulation assumptions. In the first stage, the analysis focused on discrepancies in area calculated by our tool, based on the city’s various geospatial data sources (CityGML, geojson, and land valuation data) and consumption per square meter.

The validation was done in two steps: the first was the consumption data analysis for specific typologies of buildings for which we had available metadata. We analyzed the data about two typologies of buildings: single-family homes/duplexes and public buildings.

The first level of validation checks whether the yearly results from the two use cases match real yearly consumption data. The sources of this data used as a comparison set are different.

For the single-family homes/plexes, the values to which the urban simulation has been compared has been a set of 19.111 buildings from the Energuide dataset [44], filtered only for Montréal and for single-family/duplex/triplex houses. This dataset gives yearly final energy consumption data for all the houses, and metadata for the year of construction of the buildings and the typology of buildings is described in the metadata.

For tertiary sector buildings, we analyzed the list of 186 municipal buildings published by the City of Montreal, with metadata and their energy consumption [45]. For the process of validation, we focused only on a subset of 15 buildings.

4.2.1. Geometry Data

The geospatial data cleaning process has been extremely time-consuming, especially because of the deficient quality of the input datasets and the necessary data cleaning. The dataset was created by combining several open-source datasets provided by NRCan and the Montreal city government (Montreal property assessment units [46], Montreal 3D buildings (LoD2 model with textures), LiDAR aerial dataset of Montreal [47], Building Footprints NRCAN [48] and Layer 2 cadastral data for disaggregated building use type [49].

However, even if the initial datasets were quite complete, the differences in quality and completeness have forced us to follow specific necessary steps, like (i) splitting the satellite-derived footprints based on information from the city’s cadastral parcel data, (ii) correcting building heights using LiDAR data, improving the accuracy of the analysis and, especially, (iii) incorporating an algorithm to detect and clean the overlap between the buildings. The final integrated result was a geojson database, with corrected building heights and an essential number of characteristics of each building (vintage, function, out of a list of more than 250 functions, number of households, number of stories). This geojson database was finally refined with a methodology to recognize neighbouring walls in 2D and 3D. This process has been used to generate a unique geojson file that contains all the necessary elements for the building simulated. The data has been validated by comparing the number of households by postal code from the census of Canada and the number of households resulting from the footprints and the heights. The difference in all the neighborhoods, except from Nun’s Island, is less than 5% of the total number of households. The quality of this set of data from the city is poor. The geometry factory from the TOOLS4Cities has used the footprint and height data to generate 3D surfaces for all the buildings. Depending on the function and vintage of the building, a window-to-wall ratio has been assigned to each of the buildings; the same process has been applied to the division of buildings into stories to understand the total surface of the buildings. An essential aspect of the process is that all the surfaces in contact with other surfaces have been considered neighboring surfaces, and they will be simulated as such for radiation and thermal purposes. One of the important aspects of the geometry factory is assigning a building archetype to each of the functions that the Montréal dataset of functions has. More than 500 building functions are described by the tax evaluation data [50], and they were converted into the set of archetypes developed in the hub. The archetypes used are based on the 17 archetypes developed by NREL and used by the BTAP tool[51] developed by Natural Resources Canada.

4.2.2. Construction Data

As explained in the general methodology, the tool uses a dictionary of archetypes that, given the vintage of each building, populates the constructive characteristics of each building. The first archetypes developed for Montréal were based on the developments of NRCAN for the BTAP tool, which inherits a significant amount of work done by NREL. Those archetypes, however, have a limited amount of vintage buckets regarding constructive solutions. For example, all the buildings before 1980 (which, in Montréal, account for more than 65 percent of the overall surface) are considered to have the same construction type. For that, several sources have been consulted, and, based on an initial effort using BTAP data sets [51] as a basis, we developed new constructive types based on references from academic studies [52,53] and analysis from consultancies [54]. The result has been a compilation of different constructive types depending on if the building is residential or non-residential and on the vintage of the building. The detailed constructive types used for the Montréal use case (and developed, as well, for other climates) can be found in Table A1 and Table A2, in Appendix B.

4.2.3. Usage Data

For Montreal, the National Energy Code for Buildings of Canada dataset, which uses fixed profiles for each building, is used as the basis to populate the usage data for all types of buildings and spaces, based on the previously defined archetypes per building. We have two steps, one for the gains and another for the profiles. Those separate steps currently use a direct link to the repository of [51], where the NRCAN team has been updating the base data sources for the tool BTAP. As detailed in section , using public online data is a decision from the authors to reduce the maintenance costs of the Tools4Cities hub and allow for continuous updating.

Moreover, the factory structure already allows the integration of external stochastic generation profiles derived from [39], although it was decided not to use it for the retrofit use case.

4.2.4. Energy System Data

For the latter, the yearly balance in each sector was used to divide the buildings by gas and electricity consumption. Regarding the systems typologies, the NECB equivalence[55] from table Table 8.4.4.7.-A was used. These typologies show that a concrete HVAC system typology is suggested for every type of building. The systems, from System 1 to System 6 are shown in Table 6.

The main challenge in using the table above is that the energy source is not mentioned. Therefore, another data source was used to find the primary energy sources used in building consumption in Quebec. Figure 5 and Figure 6 show the share of different fuels in the heating system from the Survey of Household Energy Use (SHEU) conducted by Statistics Canada [56] and from the [57] for commercial.

4.3. Geospatial and Energy Consumption Validation for Montreal

4.3.1. Single Family Houses/Duplex/Triplex

The results concerning the building area inferred from the geospatial inputs show higher values than the actual values obtained through property valuation data. The fact that the methodology captures the 3d exterior volume incorporates errors such as overestimating the surface area of second floors or incorporating partially covered outer volumes into the analysis. Figure 7 shows that the average floor area calculated with the models is 60% higher than the values extracted from the property data. The lack of good data is at the root of this error. Some novel methodologies are being applied to detect cleaner methodologies via AI and ML and will be incorporated into future platform developments [58].

Given the fact that the methodology developed by the CERC uses real geometry, including shadings and adjacencies, and scaling down these geometries without losing the geometrical links, the CERC team has decided to incorporate a downsizing factor based on the value of the real surface from tax evaluation data and apply the factor between the surface tax data and the simulated surface data to the final energy results. Regarding energy consumption, as described in the methodology, the simulation data has been compared to a set of data coming from Energuide audits. More than 19.111 values were filtered for the typology of simulated buildings located in Montréal. The values for the Energuide cases are compared by vintage groups with the simulated cases in Figure 8. Although some vintages have relatively limited data, the values obtained with the simulation are very aligned in most cases. Only the vintage between 1978 and 1983 shows significantly different values, but the limited number of buildings simulated for this vintage (4) makes it less significant.

4.3.2. Institutional Buildings

For tertiary sector buildings, we analyzed the list of buildings published by the City of Montreal and their energy consumption. We evaluated 15 of these buildings regarding surface area and consumption in Figure 9. In terms of surface area, the results are uneven. In 5 cases, the differences are more than 30% of the surface. Overall, using the 3d models extracted from the city’s data gives us 30% more surface area than the data published by the City. The reason behind this seems the same as in the residential building case and is linked to a low Level Of Detail in the current 3d data sources (currently between LoD1 and LoD2); this can be improved if the city agents develop better and more coherent geospatial models.

Concerning energy consumption (final energy), we compare the results with the municipality’s list. We note that the difference is significant (more than 20% of the base case consumption) in 3 cases, but we align with the magnitude of specific energy consumption. When we don’t match the results, the difference may be attributed to indoor environmental quality issues or other discrepancies from the assumed operating conditions. The impact of using different weather data files has been analyzed (HQ data for the MacTavish weather station in Montreal compared with the Energyplus file used in the simulations [59]), and the difference between using one or the other is less than 5%. The results from the validation for individual buildings show that the tool can also be used to find inconsistencies between different datasets. The fact of having a tool that can help fill the gaps and detect anomalies in consumptions and geometrical data seems an exciting capability, complementary to the tasks that are being done using Machine Learning (ML) techniques in other areas of geospatial data treatment [60].

4.3.3. Energy Impact of Retrofitting Scenarios in Single-Family Buildings

Once the methodology was validated, we tested the full workflow, analyzing the impact of the three retrofit scenarios on the pilot cases. For the single-family/duplex areas, the impact of the three retrofitting scenarios was analyzed, and the workflow automatically updates the different parameters and assigns different costs to the scenarios. The results are shown in Figure 10 and Figure 11. Regarding energy consumption, we see that the impact of retrofitting is more critical in small and older buildings, although there is no complete homogeneity. The fact that some buildings have adjacencies and, therefore, the impact of retrofitting affects them less might have an influence. Standalone buildings will benefit more from retrofitting. The results from the tool show that, even if some trends are clear and there is no need for a detailed analysis, the real impact of the measures in different typologies and locations of these buildings has to be analyzed for more focused policy-making.

4.3.4. Energy Impact of Retrofitting Scenarios in Institutional Buildings

In the case of institutional buildings, trends are more complicated to detect, given the small number of buildings and the different uses between them. Nevertheless, within the different building sets, we see that a tool such as ours can be used to prioritize investments in specific typologies of municipal buildings and to see which scenario would be more beneficial depending on the different buildings.

4.4. Economic Results

Once the energy consumption for each building in Montréal has been calculated, the retrofit costs workflow has been implemented with the following economic parameters:

• number of years=40,
• percentage credit=0,
• interest rate=0.04,
• consumer price index=0.04,
• electricity peak index=0.05,
• CO₂ price=30 $/ton ,
• CO₂ price index=0.06 (increase of CO2 price),
• electricity price index=0.05,
• gas price index=0.05,
• discount rate=0.03[61],
• retrofitting year construction=2020,

The number of years for calculating the Life Cycle Costs has been established in 40 years. The decision was taken because, although the [61] used 30 years, the new proposed EU [62] aims at calculations using 50 years. The midpoint of 40 years was chosen.

We have used the same sets of buildings in the validation phase to evaluate the economic impact of the different measures in the final set of buildings. Although this part of the process is not cross-validated with any actual project, references such as [63] and [64] have helped us see if we were aligned with the real economic costs of retrofitting.

Small Residential Buildings

The two residential neighborhoods have helped us understand the economic impact of retrofitting with the previously established hypotheses. The results for the Life Cycle Costs of both areas are plotted in Figure 12 and Figure 13.

We observe that from a Life Cycle perspective, retrofitting the building brings solutions that, at least, have the same costs as the base case. The impact of the retrofitting is different depending on the vintage of the building.

We observe that skin retrofit is interesting for buildings built before 2000. Energy systems retrofit alone is interesting depending on the vintage; the newer buildings are, generally, more interesting from an energy systems perspective. As a last point, deep retrofits don’t seem economically feasible, even from the Life Cycle perspective.

Tertiary Buildings

In the case of tertiary buildings, Figure 14 shows a scatter plot of the Life Cycle costs of the buildings under different scenarios; given the small size, no boxplot depending on vintage was produced .

In the case of tertiary buildings, the Life Cycle Costs of the base case are lower than any of the retrofitting scenarios. The low electricity prices in large buildings in Montréal (under 0.07 CAD/kWh on average) make it very difficult to implement economically feasible energy efficiency solutions. The results show that the values mentioned above in the literature are coherent with CAPEX and OPEX of similar building types[65].

5. Research Limitations

Despite the efforts done in the development of the tool, there are still some aspects that need to be improved:

• Data quality: The simulation results heavily depend on the quality of the geometry data used to create the ’City.’ Currently, only LOD1 geojson files can be used for running EnergyPlus simulations, which should be improved soon.
• Lack of data: In addition to data quality, the existence of data for all different types of buildings is a big challenge. Also, finding compatible datasets for construction and usage based on the building function is another problem. Moreover, as mentioned in the text, there is not enough data about the existing energy systems in buildings, which affects the base case simulations heavily.
• Multi-zoning: Currently, all buildings are simulated as a single zone. This is one of the tool’s limitations, which could affect the simulation results.
• Occupancy modeling : The utilization of fixed schedules for modeling occupancy is another tool limitation. The stochastic occupancy modelling workflow is currently under development.
• Economic Analysis: Life Cycle Costing (LCC) analysis used generalized economic parameters, which might not be representative for broader applications or for specific local economic conditions.

6. Conclusions and Next Steps

We presented a tool that can fully automatedly simulate large city areas (even in a big city such as Montréal) using a white-box approach and filling the gaps related to low-quality input datasets. The process of validation of the results has been generally satisfactory. However, the next stage of parameter calibration will be initiated in the following months to understand if the discrepancies between simulated data and real/statistical data can be adjusted by changing specific parameters.

This tool uses an open-source modular approach that allows for the integration of the work of other researchers on the topic and the analysis of future building scenarios considering cross-sectoral criteria.

In conclusion, the TOOLS4Cities hub enables rapid analysis of the costs and carbon emissions of every building in a city. Based on archetypes for different building uses, the models allow for comparing different renovation options. In this way, we hope to support and accelerate actions to decarbonize the municipal built environment.

7. Future Steps

The goal for the UBEM that we have developed, based on open-source criteria, modularity, flexibility, and integrability, is that it never stops evolving in the following years.

The development goal is to make the framework available to the full research community and allow for the integration of new workflows. Although any researcher can use the repository from the CERC, clone it, and use it mainly, we encourage using the manuals and the hub methodology to increase the tool’s capabilities.

The scalability of the tool is being proved at the time of the publication of this paper, with new pilot cases being developed in Palma de Mallorca (Spain), Québec City (Québec, Canada), and Toronto (Ontario, Canada).

Development of workflows

Once the pieces of the structure have been developed, the composition between its parts is to be defined. So far, we have considered a generalized Workflow and noted how its primary role is to manage the flow of data from external sources to one or more Models, which it runs and then collects their resulting output data.

Looking at more details, workflows need to do several specialized things to carry out this role. The schema above includes more workflow components, explaining the different workflow relationships. The schema also shows a series of numbered steps. These are the fundamental steps that every Workflow needs to take, regardless of which Model it is managing. The different steps followed by workflows are: