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 CO2 emissions if we consider embodied energy [1].

The decision of what we do to existing buildings can significantly impact future CO2 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 CO2 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 the best option from a multi-factor social, environmental, and economic aspect. 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 75% of GHG emissions whilst new buildings will account for 25% [6].

In Canada, as an example, the replacement rate of old buildings by new buildings is only 1-3% 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, 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).

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 [11]. 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 the building stock, which is the aspect the authors will focus on in this article. UBEM analyses the building demands in their urban context. [12] concluded in their review on urban models and tools that the building-to-building thermal and solar interactions, Urban Heat Island (UHI) or vegetation might actively modify the results of urban energy system simulations.

This building-urban interaction was considered for the first time in 2005 in the Sustainable Urban Neighbourhood modeling tool, SUNtool [13]. A thermal model of the building, coupled with Heating, Ventilation, and Air Conditioning (HVAC) and Environmental Control System (ECS) models, was integrated into the tool, also including an urban-sensitive radiation model, the Simplified Radiosity Algorithm (SRA) [14].

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.

One of the followers of Citysim is Simstadt. SimStadt is an urban workflow engine written in Java and developed by the University of Applied Sciences Stuttgart [15] 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 [16] 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 [17]. 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 provide 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 [18].

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.

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.

Two other UBEM tools that use Resistance Capacitance (RC) models as a base engine are OpenIDEAS (an open-source platform) and CEA. 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 [19,20]. 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[19] .

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 chapters 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 [11,12,21,22] [23] 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 [24]. 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 [12]. In the urban simulation tools field, GIS thematic mapping becomes a very intuitive tool for final users to access and understand results [25,26,27].

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 the review of the previous chapter, the authors think it is.

According to the authors, 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.

The authors will describe in detail a framework, the TOOLS4Cities hub that 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

3.1. General Development of a UBEM Framework to Reach Retrofit

The basis for solidly developing the retrofitting use case depends on developing a scalable, modular, non-proprietary, and usable tool. Details of the UBEM developed by the authors of this paper can be found in [28]. The current paper will explain some aspects of the software architecture. The goal is to show how such a complex use case as a building retrofit using different input data sources and processing tools is represented using the UBEM framework developed at Concordia University’s Canada Excellence Research Chair (from the CCERC), named the Tools4Cities HUB.

3.2. Structure of UBEM

3.2.1. UBEM Software Perspective

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.

The UBEM structure from the CERC uses five fundamental components: data models, models, factories, workflows, and data. Models are the representation of the properties and behaviors of a specific system. Workflows run all the models that are needed for a particular simulation. Data refers to the input data sources that enrich the UBEM and the results from the workflows developed in the UBEM.

The Appendix A develops, in detail, the software structure that we have developed to implement the new UBEM.

Figure 1. General view of the platform

Figure 1. General view of the platform

3.3. Retrofit Workflow

The retrofit workflow is a clear application of all the previously defined principles, and all the necessary steps towards the obtention of the results are defined. The retrofit workflow’s essential objective is to analyze the energetic, environmental, and economic impact of retrofitting any building in a city. The idea would, therefore, be 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, the retrofitting strategies were already predefined and homogeneous for all the buildings in the city. However, the tool’s structure would allow for the implementation of more detailed large-scale retrofitting strategies, and using heuristics to apply different strategies depending on different typologies of buildings.

3.3.1. Pipeline of Work

The main decisions regarding the pipeline of work were based on energy calculations, retrofitting scenario decisions, and economic analyses. As for energy simulation, following the structure defined in Appendix A, once a city dataset is available, a geometry factory is called, capturing all the different shapes of a city’s buildings, including the adjacencies between the buildings. The inclusion of several typologies of handlers, that can integrate and homogeneise different typologies of geospatial data, such as CityGML, geojson, 3ds and obj, facilitates the adaptability of the tool to the datasets available for every city. The archetypes of each of the different functions and vintages of the buildings are assigned in this first phase. Archetypes have been used for a long time in building simulation tools and are normally used to calculate the specific energy consumption of each building in the city, scaled to its surface [29]. However, in our case, using real geometries is prioritized as long as the quality of input geometrical datasets allows it. Nevertheless, in case some data is unknown, such as the Window to Wall Ratio, archetypes can fill the gaps. Once the geometry is captured, a construction factory is called to fill, with the aforementioned archetypes, the construction characteristics of each building. The construction factory uses, as well different handlers for different countries. At the moment, Us archetypes and Canadian archetypes have been developed. An endeavour to implement the archetypes defined in Tabula [23] is being implemented at the moment this article is being published. The usage factory comes afterward, filling the city instance with load profiles, occupancy gains, and setpoints for each building. Two usage factory handlers are available, the first based on the Canadian Energy Code [30], and the second on the Comnet profiles used by the DoE of the United States[31]. The energy systems factory is the last step of the workflow and allows for the incorporation of concrete energy systems for each of the city’s buildings. Given the usual lack of building based information for energy systems, a method assigning randomly energy systems based on the building typology and the city-scale fuel consumption data has been developed. Once the whole city is created, deciding which simulation to use is crucial. Given the size of the endeavor (city-scale, with a first test made for Montréal), the two tools that could be used were a static demand tool (Monthly Energy Balance) and a dynamic simulation tool (Energyplus). For a first proof of concept, and since the final goal of the tool was understanding energy balances and long-term impacts instead of hourly calculations, the Monthly Energy Balance was chosen, coupled with a peak load calculation tool (based on the ASHRAE Heat Balance Method [32]). Once the structure for the MEB has been developed, the orchestration of the use of dynamic building simulation results will be developed.

3.3.2. Monthly Energy Balance Workflow

The MEB workflow involves several steps. The first one, the creation and first enrichment of the digital twin of the city, is performed using the four importers previously described: Geometry, Construction, Usage, and Systems. Once these steps are finished, the first simulation tool calculates the radiation on external walls. Simplified Radiosity Algorithm (SRA) [13] 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. This calculation is performed in patches, as calculating together all the buildings belonging to the city in one run is computationally impossible. These patches overlap, allowing the selection of the surfaces with the most realistic outputs. Once this is done, all inputs required for the static calculation of the building demands are in place. So, the simulation tool (INSEL [33]) is called to perform the energy calculations. All buildings, one by one, are called, and their demands are calculated using the static model implemented in INSEL. In the third step, DHW and energy consumption are also calculated, considering the energy supply systems installed in each building. All results are saved and left available for use in the following steps.

3.3.3. Costs 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 [34], 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 [35], 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 CO2 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 CO2 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 [36]. 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.

As explained, the current structure of the central catalog model allows the connection of different datasets. In the first MVP, we connected this central catalog model to our first XML database, a simplified version of costs based on archetypes, localization of costs, and currency. A more detailed model is being prepared to include the communication of this central catalog model to external cost databases, like RSMEANS, following the structure the NRCAN BTAP team has been developing in the last years [37]. The different instances of the city and building classes, including opaque walls, transparent walls, roofs, and grounds, are used together with the values of the imported specific economic costs to evaluate the costs for each retrofitting scenario. However, it is necessary to outline that all the elements to be costed and evaluated will come from the different construction archetypes applied to each building instance (based on function or functions of the building and vintage of this building). All the endeavors dealing with the costing strategies(and even embodied CO2 strategies) in the future will depend on the first good set of archetypes developed for each concrete location. The CAPEX chapters consider the number of replacements of each of the different equipments for each of the cases during the lifetime of the analysis, given the lifetime of each of these types of equipment.

Subsidies Calculation A chapter dedicated to subsidies has been included in the calculation, including subsidies such as investment cost subsidies (divided between construction, energy systems, and renewable energy systems) or tax reduction subsidies.

OPEX Calculation In financing analysis, OPEX is normally created by adding operational and maintenance costs. The composition of operational costs of costs was developed using the same procedure. Depending on the chosen archetype, a central file with the details of energy costs (hourly, monthly, yearly) has been populated to account for the conventional specific costs. Those costs are coupled with the Monthly Energy Balance (MEB) results and the peak load calculations described in the previous sections. As for maintenance costs, the structure is the same, but the costs are assigned depending on the equipment size, which is done during the MEB+peak loads workflow.

Other costs and incomes calculation Costs related to externalities (or incomes related to the same aspect) have been included in the workflow, as well as incomes related to energy exportation to the grid.

End of life costs calculation End-of-life costs have been calculated based on [38], and a first approximation based on the different archetypes has been implemented.

3.3.4. Decision on the Retrofitting Scenarios

A 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.3.5. Structure of Results and Persistence Databases

During a workflow, the city object will instantiate the values of all the results in the adequate classes (building, thermal zone). However, these data have to be stored before the end of the workflow so as not to let it disappear. In the workflows that have, as a goal, to develop individual building simulations, the results can be analyzed via the output tool of the same Building Simulator, or an output file can be produced. However, the data storage structure is essential when dealing with massive amounts of information and when precalculating results, which is a desirable output. In the case of the TOOLS4Cities hub, a PostgreSQL database has been prepared with the outputs of some of the key KPIs of all the simulations in the city. The key KPIs have been stored in a PostgreSQL database, but since for research purposes, the input datasets are also crucial, all the data used for the simulations (construction layers, usage layers, geometry) have also been stored. Pickles have been used to reduce the space requirements for these amounts of data [39]. The pickles are meant to store a massive amount of data that won’t initially be made accessible, but that can be recovered later to understand the hypotheses behind any simulation.. Another critical step in obtaining large-scale results is the orchestrator. In Urban Building Energy Models, small chunks of the city have to be simulated to optimize the processes. The overlap between these "small packages" is vital because shading and adjacencies won’t be considered in the boundaries of those packages, and, therefore, a clear design of the overlap calculation methodologies has been put in place.

3.4. Other Features Implemented in the Tool

Other features implemented in the TOOLS4Cities hub that can allow for more in-depth analysis of retrofitting actions and methodologies in the future (but have not been included in the present article) are:

• Energyplus workflow: apart from the Monthly Energy Balance, the platform allows for the dynamic simulation of buildings using Energyplus. Tests to up to 3000 buildings have been done up to the moment, with excellent performance.
• Integration with TRNSYS. A workflow generating the template files (dck) and the building file (b18) has been implemented in the hub. Small sets of buildings are modeled (up to ten), but the capability will be extended in the following months.
• Energy systems detailed modeling tool. The capacity of the TOOLS4Cities Hub to chain two workflows has been put in practice with this use case. Once a first workflow (Energyplus workflow) has been used, the next workflow has been developed to analyze the feasibility of changing energy systems to heat pump/storage simulations.
• District Heating workflow. A double-chained workflow (based on the EP workflow) showing the ideal district heating system connection between the different buildings, following the geojson of the roads and sizing pipes, taking into account simultaneity and several building priorities, is in place (being improved at the moment).

4. Proof of Concept. Results

4.1. Implementation of retrofit scenario for Montréal

4.1.1. Geospatial Data Treatment

The first proof of concept for developing a retrofit calculation for an entire city was implemented on the island of Montréal. 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 [40], Montreal 3D buildings (LoD2 model with textures), LiDAR aerial dataset of Montreal [41], Building Footprints NRCAN [42] and Layer 2 cadastral data for disaggregated building use type [43].

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 neighboring walls in 2D and 3D.

4.1.2. Development of a Set of Archetypes

The approach of the current platform uses accurate geometries (if they are available) to build 3d models of the buildings, with their relationships with the environment (shading and adjacencies). However, some reference archetypes are needed to populate these models with constructive and usage data. The development of new archetypes has been an essential task.

4.1.3. Geometry Factory

The first step in our platform is to capture the geojson datasets (the platform can also capture CityGML, 3ds, obj datasets). Once they are captured, an extruded 3D model of the city, with its buildings and neighboring walls, is created. This is the instance city that will be used for the simulations. Even though, given the poor quality of the input data, in this initial use case, a geojson file with extruded buildings and flat roofs was used, in the cases where acceptable LoD2 and LoD3 CityGMLs are available, the platform allows for the simulation of roofs of different shapes.

4.1.4. Construction Factory

Québec, with its rich architectural heritage and diverse population, boasts many buildings. Built at different times and reflecting various architectural influences, these structures form an essential part of the city’s urban fabric. As Québec continues its journey towards sustainability and energy efficiency, it becomes imperative to understand the construction of these buildings. Building sets, or the compilation of materials and methods used to construct a building, are the fundamental elements of any architectural structure. In the case of Québec’s buildings, these building sets are remarkably varied, given its long history and the successive waves of architectural trends it has witnessed. From the masonry-clad row houses of the late 19th century to modern high-rises where glazing dominates the façade, construction techniques and materials have evolved considerably. The layering of these building assemblies, or how different materials are arranged and integrated, has a direct impact on a building’s performance, longevity, and interaction with its environment. For example, the order in which insulation, structural materials, and vapor barriers are placed can significantly influence a building’s thermal performance and resistance to harsh Quebec winters. However, defining these building assemblies and their layering comes with its own set of challenges. One of the main limitations is the lack of documentation or detailed records of the construction processes of older buildings. Over time, many original plans, material lists, and construction notes have been lost or are inaccessible. This lack of data makes it difficult to accurately define building layers, particularly for structures built in earlier eras. 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 endeavour using the datasets from BTAP [37] as a basis, we developed new constructive types based on references of academic studies [44] [45] and analysis from consultancies [46]. The compilation of the best cases of the different references can be found in Table 6 and Table 7.

Infiltration losses in a building are defined as heat losses produced by the involuntary infiltration of outside air through the building envelope, producing an untreated air renewal effect in the zone that significantly affects building heat loss. These losses can, in some cases (especially in Montréal), represent significant percentages of the total heat demand of the building. However, it is not usual to carry out a rigorous treatment of these losses when simulating buildings since constant reference values are usually used or, in the best case, variables estimated according to generic scenarios. Airtightness tests are a widespread practice in the United States and Northern Europe to determine the level of infiltration in single-family homes. However, this practice is not as widespread in large commercial buildings (including offices) due to various factors probably related to the complexity of the analysis or the underestimation of the derived effects, in addition to the fact that it is not mandatory in terms of regulations. Several methods have been used in recent years to simulate infiltrations in buildings, using values from previous results and tests. The three most widespread methods to simulate them in energy plus are the design flow, the ELA, and the flow coefficient model. The model used in the simulations is based on the NIST model, developed by [47]. This model relies on the floor values per outdoor wall. We analyzed the Energuide datasets for all residential buildings (buildings under 4 stories) (defined as IRLMs by the same Energuide). A set of 120.000 buildings was found, and a boxplot analysis (Figure 2) was developed to see the values of ACH50 (the variable shown in the Energuide dataset), before any renovations had been carried out (EVALTYPE=D). In the case of MURBs and other high-rise buildings, several academic and industry-based documents have been used [44] and [48]. These values have been implemented per decade of construction in the construction libraries. All these values have been converted into infiltration per outdoor surface to incorporate them into the NIST model. The capacity of the UBEM to understand the walls that are exposed and those that aren’t (adjacent to other buildings) will be used with the outdoor flow per area method.

Thermal bridges significantly affect building heat loss, particularly in MURBs with many balconies, which may constitute a potential condensation risk. Although the aim of the archetypes is not to simulate in detail these situations, which are very specific for each project, we have carried out an initial analysis of the impact on MURBs to be able to incorporate its effect into the overall U-value of the various building construction archetypes, particularly in facades where thermal bridges will occur. The result has pushed us to increase the U value of the walls in MURBs by a certain percentage, depending on the vintage. When LoD3 buildings are incorporated, a more detailed analysis will be implemented using the Thermal Bridge Derating (TBD) methodology [49].

4.1.5. Usage factory

The usage factory uses the National Energy Code for Buildings of Canada, which uses fixed profiles for each 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 [37], where the NRCAN team has been updating the base data sources for the tool BTAP. As detailed in Section 3, 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 [50], although it was decided not to use it for the retrofit use case.

4.1.6. Energy systems factory

For air renovation in buildings constructed after 2011, the air renovations will come directly from the NECB profiles, with heat recovery in the buildings from 2011 onwards.

Due to the lack of information available at the individual building scale, a methodology to randomly populate the energy systems factory has been implemented in the case of the HVAC factory. This methodology has established a separation between residential buildings, commercial buildings, and institutional buildings.

For the former, Figure 3 shows the primary sources and systems used to meet heating demand in Quebec residential buildings without distinguishing between single-family or multi-residential buildings. As the figure shows, electricity is the primary energy source for heating in Quebec. Not surprisingly, electric baseboard heaters are the province’s most widely used heating appliance. In addition, natural gas is another popular fuel used in the province to run furnaces and boilers, mainly in low- and high-rise apartment buildings.

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[51] was used (Figure 4). 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:

• System 1: Unitary air conditioner with baseboard heater
• System 2: Four-pipe fan coil
• System 3: Single zone packaged rooftop unit with baseboard heaters
• System 4: Single zone make-up air unit with baseboard heating
• System 5: Two pipe fan-coil
• System 6: Multi-zone built-up system with baseboard heater

4.1.7. Cost Datasets and Hypotheses

The cost datasets used for the different subchapters for the Montréal case have been based on [52] and adapted to the local currency and increases in the price of materials since the edition of the book. We are conscious of the limitations of using worldwide references for local costs. Still, as a first approximation, the values look coherent to recent studies for Canada, as will be shown in Section 4.2.4.

4.2. First Energy Results and Comparison with Real Datasets

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 authors followed 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 overall values for the full city were analyzed in the second step. The values for the simulation of the entire city have been compared with real datasets obtained from Montréal. In Table 9, we can see the overall comparison of the results for the consumption of the different fuels yearly compared to the results of the first simulation of the base case scenario. From a global perspective, the results seem quite positive for a first global test. At this moment, detailed analysis procedures and calibration processes are being made to refine the archetypes and the geospatial inputs.

4.2.1. Single Family Houses/Duplex/Triplex

We first assessed the validity of the process in two significant areas of single-family / duplex / triplex buildings in Montreal: the first is in Pointe-Saint-Charles (between Wellington, Ash, Leber and Congrégation streets), with a majority of buildings built before 1946, and the second is in Saint Leonard (between Langelier boulevard, Robert boulevard, de Guyenne street and Louis Sicard street), with buildings from the 1960s-1990s. The ColouringMontreal tool (https://nextgenerations-cities.encs.concordia.ca/colouringmontreal/), developed by the CERC team as part of the ColouringCities initiative, also helps us detect the best neighborhoods to analyze. This gave rise to a total of 500 buildings.

The results concerning the calculated building area show that the simulation input data gives 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 6 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 [53].

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, since access to the actual data for individual building consumption for these buildings is not possible, the authors compared them to the average values for single-family homes in Quebec. There is a particular bias due to Quebec’s different climates. Still, this analysis allows us to see the distance between simulated and real buildings, in this case, per square meter. We have grouped the buildings by the same groups in the National Energy Consumption Database document and extracted the heat and domestic hot water consumption data from our simulations to compare them. The data for buildings later than 1977 is not too high (less than 5% of buildings), but the trend shows us that the values obtained for the tool, concerning specific consumption per square meter, are very much in line with statistical consumption.

We have also added a comparison with 19.111 buildings from the Energuide dataset [54], filtered only for Montréal and for single-family/duplex/triplex houses. In this case, we can compare total final energy consumption with this dataset.

In both cases, the authors observe that the UBEM tool underestimates the consumption of old buildings and overestimates the consumption of new buildings. Given that the infiltrations for these types of buildings come from the Energuide dataset, the parameter to be adjusted for these buildings will be the constructive layers for both old and new buildings, especially from 1977 onwards.

Figure 8. Final specific energy in single-family/duplex/triplex buildings from Energuide dataset

Figure 8. Final specific energy in single-family/duplex/triplex buildings from Energuide dataset

4.2.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 11 of these buildings in terms of surface area and consumption. In terms of surface area, the results are uneven. The differences are significant, and in general, we observe that using the 3d models extracted from the city’s data gives us 30% more surface area than the data published by the City.

Figure 9. Comparison surface institutional buildings between city source and extracted data

Figure 9. Comparison surface institutional buildings between city source and extracted data

Concerning energy consumption (final energy), we compare the results with the municipality’s list. We note that the difference is significant in some cases, but we’re in line in order of magnitude. The impact of meteorology has been analyzed (HQ data for the MacTavish weather station in Montreal compared with the epw file used), and, at day-degree levels, the impact is less than 5%.

Figure 10. Specific final energy consumption institutional buildings

Figure 10. Specific final energy consumption institutional buildings

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 [55].

4.2.3. General Results for the Full Island

The availability of the aforementioned data from Hydro-Québec and Energir has allowed us to get the yearly data for the full island, except Westmount, where a municipal electrical company exists (Hydro-Westmount). The simulation for the full city’s final energy consumption has been compared to the data coming from Hydro Québec and Energir. Since some of the city’s final energy consumption comes from sources other than electricity or natural gas, there is a gap between those datasets. Although we understand it is a pessimistic hypothesis, we have used the data from 2015 [56] and considered no new development has been built using these fuels.

The results for the overall city in Table 9 show an 11% difference between the data we have simulated and the real data from the city. This shows a good alignment between the simulation results and the city’s global consumption. However, it should not hide the differences between real and simulated surfaces we have seen in single-family buildings. The non-validated sectors (commercial buildings) should be analysed in depth to confirm the UBEMs accuracy in evaluating their demands.

4.2.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=31,
• percentage credit=0,
• interest rate=0.04,
• consumer price index=0.04,
• electricity peak index=0.05,
• CO2 index=0.06,
• CO2 price=30 $/ton ,
• electricity price index=0.05,
• gas price index=0.05,
• discount rate=0.03,
• retrofitting year construction=2020,

To ensure the adequate robustness and speed of the full process, a test case was done to calculate the costs for a set of buildings. Although this part of the process is not cross-validated with any actual project, references such as [57] and [58] have helped us see if we were aligned with the values of use cases. A first set of economic calculations for 108 residential buildings in the second zone selected in Section 4.2.1 has been implemented with the previously established hypotheses. The results are plotted in the following figures.

Figure 11. Boxplot costs for the different scenarios

Figure 11. Boxplot costs for the different scenarios

Figure 12. Average costs and incomes per categories different scenarios

Figure 12. Average costs and incomes per categories different scenarios

Figure 13. Pareto graph for the analyzed datasets, with three retrofit levels

Figure 13. Pareto graph for the analyzed datasets, with three retrofit levels

The results show that the values mentioned above in the literature are coherent with CAPEX and OPEX of similar building types (residential)[59].

4.2.5. Visualization of the Results

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/).

The first is the single building retrofit visualizer, which shows the individual results of the base case simulation and the three retrofit options once a building in the city is selected. Although the detailed results are stored in a PostgreSQL database, an effort was made to simplify the shown data. A qualitative radar shows the best option for the single building case according to different parameters and criteria. It is plotted with KPIs for maximum peak loads, 40-year life cycle costs, and yearly energy consumption.

Figure 14. Single building retrofit front end

Figure 14. Single building retrofit front end

The second is the multiple-building retrofit tool, which can be used to select several city areas. A scatterplot comparing CO2 emissions, LifeCycle Costs, and energy consumption with the vintage of the buildings is shown to help the user decide on the best retrofit strategies for each building segment. The buildings can be selected in the scatterplot, and the different strategies can be applied to each, obtaining a final value for each retrofitting strategy (a combination of the previously defined Scenarios 0, 1, 2, and 3).

Figure 15. Multi-building retrofit selection

Figure 15. Multi-building retrofit selection

Figure 16. Multi-building retrofit current scenario analysis

Figure 16. Multi-building retrofit current scenario analysis

Figure 17. Multi-building retrofitting strategy selection

Figure 17. Multi-building retrofitting strategy selection

5. Conclusions

We presented a tool that can almost fully automatedly simulate large city areas (even in a big city such as Montréal). Unfortunately, part of the data processing must be manual, and a thorough processing effort was needed because of the errors and inconsistencies of all geospatial and constructive data sources. Nevertheless, the pipeline of the process is thought to detect those inconsistencies and, in most cases, can fill the gaps with sensible hypotheses. To fine-tune the models, we need access to much more detailed data at the temporary building level, especially in the tertiary sector. In the coming months, an initiative to capture data from the city of Montreal and evaluate it with Concordia’s tools will be set up in collaboration with the city, Hydro Québec, Energir, the Ministère de l’Environnement, de la Lutte contre les Changements Climatiques, de la Faune et des Parcs, and Concordia. In conclusion, NGCI’s new set of urban building simulation tools enables rapid analysis of the costs and carbon emissions of every building in a city. Based on archetypes for different building uses, the models make it possible to compare different renovation options. In this way, we hope to support and accelerate actions to decarbonize the municipal built environment.

6. 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 next years. The development goal is to make the framework available to the full research community and allow for integrating 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.

Appendix A.1

Appendix B.1.1. 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:

Appendix B.1.1.1. Step 1 – IMPORT

Every Workflow must first retrieve all the required data as input for the Model(s) it manages. Data sources may be in proprietary formats (for example, building geometry may be in CityGML or OBJ format, while weather information may be in EPW, TMY2 or ISO CLIM format). Whenever a new Model is integrated into the Platform, we also develop new Factory Importers if data formats are not already supported. The Import step is completed when the imported data is converted into a format that all other Workflows in the Platform can understand. This format is known as the Central Data Model and has been explained more fully previously. Sufficed it to say, once the IMPORT step is complete, all the data from external sources is now fully represented internally in the Platform,

Appendix B.1.1.2. Step 1a – PRE-PROCESS (Optional)

Some Models require that the input data retrieved from external data sources be altered in some way, before it is ready to be used by the Model. There are many examples of this: ‘Data Cleaning’ (detecting and removing erroneous values; ‘Data Calibrating’(modifying values based on auxiliary reference data); ‘Data Pruning’ (removing unnecessary data branches); ‘Data Compression’ (making the size of data more manageable). We call these steps ‘Pre-Processing’ and the Workflow is responsible for carrying these out across all of the Input Data, as required.

Appendix B.1.1.3. Step 1b – CONSTRUCT (Optional)

For some models, the Input Data itself can change the Model. For example, an INSEL Model for calculating building energy demand may depend on the building geometry. The connectedness of thermal zones and surfaces within a building directly impacts the logic connections in a building simulation Model. As a result, the Input Data must be analyzed and used to create the required building simulation Model (INSEL, Energyplus, or TRNSYS). This is done programmatically by the CONSTRUCT step of the Workflow.

Appendix B.1.1.4. Step 2 – RUN

Once the Workflow has the Input Data ready it is time to RUN the Model(s). This could be as simple as making one call to the Model with one data set. Or it could involve calling the Model multiple times with subsets of the data. For example, the Input Data may include 300 buildings in a city district, and the model can calculate them all, either using a multi-zone approach to calculate different buildings or running all the buildings in a model one by one. If the Model is a Custom Model, written in Python, the Input Data can be sent using the format described by the Central Data Model. However, if the Model is an INSEL Model, the Input Data needs to be sent using an INSEL file template. And if the Model is a 3rd Party Model (e.g. Energy Plus), the Input Data must be sent in the proprietary format(s) understood by that Model. (e.g. IDF files for Energy Plus). As with importing different data formats, the Platform helps Workflows here, providing the Factories that can easily export data to the format required. Again, whenever a new model is integrated into the platform, we also develop new factory exporters if there are any data formats that are not already supported. The RUN step is complete once the Workflow has called the Model across all the necessary Input Data.

Appendix B.1.1.5. Step 3 – RESULTS

All Models generate some result or Output Data. The workflow must collect this data so that it can be used. INSEL Models can output their data directly to the screen. They can also write their data to files (CSV and other formats). Energy Plus outputs text files. Custom Models may do any of the above or return their results programmatically. The Workflow must retrieve the Output Data from any of these sources, using Factory Importers again where necessary, and convert the Output Data once more into the format described by the Central Data Model. This allows the data to be accessed by other Models later in the same Workflow or even other Workflows after this one completes. When the Workflow calls a Model multiple times with different subsets of Input Data, the Workflow must also retrieve the results after each call, building up a full set of Output Data.

Appendix B.1.1.6. Step 4 – DELIVER

With the Output Data now retrieved and stored, the final responsibility of the Workflow is to make the data available to whoever needs it. There are multiple options here. The Workflow may write the data to output files, display the data on the screen, and ensure the data is available for new Workflows; it may ensure the data is available for 3rd party Apps. In future versions of the Platform, this part of the Workflow is expected to be more formalized. Figure A4 shows the relationship between the Central Data Model and the Factories. The next two sections explain how these both support the Workflow