Decarbonizing buildings poses a significant challenge for urban areas. Determining which buildings should undergo retrofitting, along with the timing and methods, proves complex due to the intricate interplay between energy expenses and required investments. Although various tools have emerged in recent years to assist public and private decision-makers with these choices, none address the essential elements the authors consider. Consequently, this article introduces a newly developed tool for urban building retrofit. The tool uses a bottom-up approach, simulating each building individually while accounting for factors such as shading and neighboring structures. In a subsequent phase, three scenarios representing varying degrees of ambition were incorporated into the tool, enabling calculations of the resulting energy demand and emissions. As a further step, the initial investment and ongoing operational costs of these retrofitting scenarios were assessed through a comprehensive life cycle costing (LCC) framework. A robust, scalable framework was created and implemented to determine the LCC across multiple retrofitting scenarios in Montréal, with full details provided below.
Among the most challenging aspects of city-level decarbonization is the retrofitting of buildings. The building sector is responsible for over 35% of worldwide energy use and nearly 38% of CO2 emissions when embodied energy is included [1].
Intervention choices in the existing building stock can have a substantial impact on future CO2 emissions. Within the research community, there is considerable uncertainty about whether demolishing and constructing net-zero buildings outperforms retrofitting, largely because the latter option involves lower embodied CO2 emissions [2-4]. Nevertheless, substantial efforts are required to make retrofitting appealing to every stakeholder.
As noted in Crawford et al. [5], retrofitting appears preferable to demolition even over a 90-year lifespan. In the majority of situations, retrofitting emerges as the optimal choice when evaluated across social, environmental, and economic dimensions. Recent sources indicate that by 2050, the existing building stock will contribute at least 75% of GHG emissions, with new constructions accounting for 25% (2021 World Green Building Council. WorldGBC Net Zero Carbon Buildings Commitment) [6].
In Canada, retrofitting of low-rise residential buildings occurs at less than 1%, and for commercial buildings, 1.4% of floor area annually [7]. Despite clear objectives among most policymakers in various nations, widespread large-scale retrofitting has yet to materialize. While compelling examples of successful initiatives emerge globally when life-cycle costs are considered [8], broad implementation remains elusive for several reasons. The primary barriers [9] include gaps in knowledge and expertise, insufficient political will, inadequate policies, challenges in scaling up quickly, the enormous capital investment needed, and extended payback periods.
Several of these obstacles—particularly those tied to policy development and the knowledge deficit regarding the detailed life-cycle effects of retrofit measures [10]—could be addressed through tools such as Urban Building Energy Modeling (UBEM). The push for low-carbon, energy-efficient cities has positioned UBEM as an essential method for assessing building energy performance at the urban scale. Reinhart and Cerezo Davila [11] describe UBEM as a bottom-up, meta-scale, physics-driven engineering approach that integrates mass flow and heat transfer models to predict indoor-outdoor conditions and energy use across clusters of buildings. By incorporating interactions among buildings and their environment—such as effects from height, density, and radiation exchange—it surpasses traditional Building Energy Modeling (BEM), which focuses solely on single structures [12]. UBEM delivers valuable insights into energy use patterns at daily, seasonal, and annual scales, supporting urban planners and policymakers in evaluating energy-efficient designs, retrofit strategies, and renewable energy opportunities [13, 14]. Due to its relevance to grid integration, urban development, and emissions-reduction initiatives, UBEM serves as a key resource for sustainable urban energy strategies.
Thus, an Urban Building Energy Retrofit Tool grounded in UBEM principles represents meaningful progress, owing to its scientific foundation, modular design, scalability, and relatively low data demands for an initial approximate application to any urban area.
Over the past decade, a wide array of software solutions has appeared for simulating urban energy dynamics. These platforms aim to lower barriers to applying urban-scale energy models and improve their accessibility, yet most capture only part of the intricate nature of complete urban energy systems [15]. Urban Building Energy Models (UBEM) strive to deliver a holistic view of energy flows across an entire city — covering end-use consumption in buildings, local renewable generation, mobility patterns, and waste-related energy flows. Within this expansive research area, the majority of efforts have targeted the building stock, which constitutes the central theme of the current paper.
UBEM approaches examine building-level energy needs while embedding them in their broader urban setting, making it crucial to represent mutual influences among buildings properly and between buildings and surrounding urban features. Allegrini et al. [16], in their comprehensive survey of urban simulation frameworks, highlighted how critical inter-building effects — such as thermal coupling, solar access blocked by adjacent structures, shading from nearby facades, the Urban Heat Island (UHI) phenomenon, and the presence of urban greenery — are for producing reliable outcomes in city-wide energy simulations.
The earliest documented attempt to explicitly include such building–environment interactions (for instance, obstruction of sky and solar views by neighboring constructions) dates to 2005 with the introduction of SUNtool, the Sustainable Urban Neighborhood modeling environment [17]. SUNtool combined a detailed building thermal balance with Heating, Ventilation, and Air Conditioning (HVAC) modeling and featured a radiation computation scheme tailored to urban contexts—the Simplified Radiosity Algorithm (SRA) [18].
Drawing strong inspiration from SUNtool, yet equipped with significantly more sophisticated thermal dynamics and stochastic representations of occupant behavior, the CitySim platform marked an important evolution in UBEM capabilities. Developed using Reduced Order Models (ROMs) created at EPFL (Switzerland), CitySim supported streamlined dynamic simulations and interoperated with complementary modules, most notably the agent-based transport simulator MATSIM [19].
Another important contribution came in 2013 from the University of Applied Sciences Stuttgart with SimStadt, a Java-based urban energy workflow system [20]. SimStadt accommodates both basic extruded-footprint geometries and — whenever available — richly detailed CityGML models up to Level of Detail 2 (LoD2), which incorporate realistic roof geometries. As demonstrated in one application, the platform successfully simulated energy performance for approximately 1,000 buildings in Rotterdam, the Netherlands, using CityGML geometry [21]. A key strength of SimStadt lies in its native compatibility with EnergyADE, the CityGML extension that embeds structured thermophysical properties of constructions [22]. Like most UBEM instruments, it requires substantial upstream data preparation and produces results at monthly time steps. It currently omits mobility and transport energy linkages; however, it uniquely integrates cradle-to-grave carbon footprint evaluation (embodied carbon in construction) within a single workflow [23].
In parallel, researchers at MIT released the Urban Modeling Interface (UMI) in 2013. UMI leverages EnergyPlus as its simulation core and accepts geometric inputs prepared in Rhinoceros [24].
CityBES represents yet another EnergyPlus-based solution. It ingests CityGML files for three-dimensional building representation at LoD1 or LoD2 (with explicit roof forms) and can exploit EnergyADE to incorporate detailed thermophysical data [25].
Two further noteworthy UBEM platforms that rest on resistance–capacitance (RC) network formulations are the open-source OpenIDEAS ecosystem and the city energy analyst (CEA) suite [26]. OpenIDEAS distinguishes itself through a modular data- and workflow-management philosophy that facilitates robust preprocessing, post-processing, and integration of external pipelines. CEA goes further by embedding cost–benefit analyses, multiple data-source harmonization, transport-related use cases, greenhouse gas accounting, and automated shadow-effect calculations.
More recently, the National Renewable Energy Laboratory (NREL) introduced URBANOPT — the Urban Renewable Building and Neighborhood Optimization platform — which again employs EnergyPlus and is released as open-source software [27, 28]. URBANOPT provides daylighting and lighting simulations but leaves out mobility modeling, full life-cycle assessment, and economic optimization modules.
Developed at RWTH Aachen University, TEASER (tool for energy analysis and simulation for efficient retrofit) relies on RC modeling techniques and supports multiple schemes for tracking and reporting carbon emissions [27].
In the last few years, several promising new platforms have appeared. AutoBPS, for example, adopts a methodology closely aligned with that explored by the present authors in recent projects; it targets city-scale building-stock energy modeling with a focus on supporting large-scale energy-efficiency upgrades [29-31]. Among other recent contributions are CityBEM, which implements bespoke formulations of heat-transfer governing equations [32], and UECC, a novel resistance–capacitance framework that accounts for heterogeneous boundary conditions across construction elements and includes an efficient algorithm for beam-shadow projection on facade surfaces in high-density urban fabrics; both rely on reduced-order modeling techniques (R.O.M.) [33, 34]. Concurrently, the Dest-urban initiative (a platform extending the DeST engine for urban building energy modeling) has proposed an original data-driven strategy for deriving realistic occupancy schedules from mobility datasets [35, 36].
An overview of the historical development of these tools is shown in Figure 1.

Figure 1. Timeline of UBEM tool development
Table 1 shows the UBEM platforms and their principal application domains.
Table 1. UBEM platforms and their principal application domains
Tool | Building operations | Building life-cycle analysis | Transportation | Microclimate analysis | Waste management | Additional features |
SUNTOOL | Yes | No | No | Yes | Yes | No |
CITYSIM | Yes | No | Yes | No | No | No |
SIMStadt | Yes | Yes | No | No | No | No |
UMI | Yes | Yes | Yes | Yes | Yes | Food production, daylighting |
CityBES | Yes | No | Yes | No | No | No |
OpenIDEAS | Yes | No | No | No | No | No |
CEA | Yes | Yes | Yes | Yes | Yes | No |
UrbanOPT | Yes | No | No | No | No | Daylighting |
TEASER | Yes | No | No | No | No | No |
Dest-Urban | Yes | No | No | No | No | No |
AutoBPS | Yes | No | No | No | No | No |
UECC | Yes | No | No | No | No | No |
CityBEM | Yes | No | No | No | No | No |
Table 2 shows the Input data formats supported by major UBEM platforms.
Table 2. Input data formats supported by major UBEM platforms (sourced from all cited references)
Tool | Supported geospatial data formats | Construction-related inputs | Defined operational inputs | Solar/Shading evaluation | Microclimate capabilities | Additional features |
SUNTOOL | Custom-built interface | User-defined | Static, deterministic, and probabilistic | Yes, SRA | Yes | No |
CITYSIM | CityGML, EnergyADE | User-defined, archetype-based | Static, deterministic | Yes, SRA | No | No |
SIMStadt | CityGML, EnergyADE | User-defined, archetype-based | Static, deterministic | Yes, SRA | No | No |
UMI | Rhino3D | User-defined, archetype-based | Static, deterministic | Yes, based on Eplus | Yes (UWG) | Food production, daylighting |
CityBES | CityGML, EnergyADE | User-defined, building-specific | Static, deterministic | Yes, based on Eplus | No | No |
OpenIDEAS | CityGML, EnergyADE | User-defined, archetype-based | Static, deterministic, and probabilistic | Not well explained and detailed (missing?) | No | No |
CEA | CityGML, osm | User-defined, archetype-based | Static, deterministic, and probabilistic | Yes | Yes, EnviMET can be coupled to the models | No |
UrbanOPT | CityGML, GeoJSON, osm, IDF | User-defined, archetype-based | Static, deterministic | Yes, based on Eplus | No | Daylighting |
TEASER (part of IDEAS) | CityGML, EnergyADE | User-defined, archetype-based | Static, deterministic, and probabilistic | Not well explained and detailed (missing?) | No | No |
DeST-URBAN | Proprietary processing | User-defined, archetype-based | Very detailed. Static, deterministic, and probabilistic | Based on archetypes | No | No |
AutoBPS | CityGML, EnergyADE | User-defined, archetype-based | Static, deterministic, and probabilistic | Not well explained and detailed (missing?) | No | No |
UECCC | Not specified (appears obj) | User-defined, archetype-based | Static | Detailed shading, based on previous work | Not described | No |
cityBEM | obj | User-defined, archetype-based | Static | Yes | No |
Core simulation engines and key technical features of USEM/UBEM tools are shown in Table 3.
Table 3. Core simulation engines and key technical features of USEM/UBEM tools (sourced from all cited references)
Tool | Building a simulation engine | Energy systems calculation engine | Mobility modeling engine | Programming environment | Post-processing of outputs | Open-source framework | Temporal resolution |
SUNTOOL | R.O.M (grey-box model) | Yes | No | Java | No | No | Hourly |
CITYSIM | R.O.M (RC model) | Proprietary engine | MATSIM-c | C++ and Java | Yes | Yes | Hourly |
SIMStadt | Simplified energy balance approach | Proprietary engine | No | Java | Yes | Yes | Monthly |
UMI | Energyplus | Energyplus | Proprietary engine (Python), and walkability-based | Rhino Grasshopper (Python) | Yes | Partly dependent on Rhino. | Hourly and sub-hourly |
CityBES | Energyplus | Energyplus | No | Yes | Yes | Hourly and sub-hourly | |
OpenIDEAS | R.O.M (RC model) | Modelica | No | Python | Yes | Yes | Hourly |
CEA | R.O.M (RC model) | No | Python | Yes | Yes | Hourly | |
UrbanOPT | Energyplus | Energyplus | No | Ruby, C++, Python | Yes | Yes | Hourly and sub-hourly |
TEASER | R.O.M (RC model) | Modelica | No | Python | Yes | Yes | Hourly |
Dest-URBAN | Energyplus | Enerygplus | No | Python | Yes | Yes | Hourly |
AutoBPS | Energyplus | Energyplus | No | Python | Yes | Yes | Hourly |
UECC | R.O.M (RC model) | Proprietary | No | Proprietary tool | Yes | Yes | Hourly |
CityBEM | In-house heat transfer model | Not considered | No | CSharp | Yes | Yes | Hourly |
Capabilities for scenario definition and analysis in USEM/UBEM platforms are shown in Table 4.
Table 4. Capabilities for scenario definition and analysis in USEM/UBEM platforms (sourced from all cited references)
Tool | Integration of cost–benefit evaluation | Scenario modeling capability | User interface availability | Degree of UBEM scaling |
SUNTOOL | No | No | Yes | Low scaling-up |
CITYSIM | No | No | Yes | Low scaling-up |
SIMStadt | No | Yes | Yes | High scaling-up |
UMI | No | Yes | Yes | High scaling-up |
CityBES | Yes | Yes | Low scaling-up | |
OpenIDEAS | No | No | Low scaling-up | |
CEA | Yes | Yes | Yes | High scaling-up |
UrbanOPT | No | Yes | Yes | High scaling-up |
TEASER | No | Yes | Low scaling-up |
The various urban building energy models (UBEMs) outlined earlier have laid the foundation for advancing future urban energy system platforms.
Nevertheless, the literature survey and the accompanying tables reveal several critical research questions. A key concern is the extent to which these tools can reliably support genuine cost–benefit evaluations in the building decarbonization domain, with doubts persisting for multiple reasons. In tackling such multifaceted challenges, a recurring issue is whether the UBEMs were engineered around a specific objective and if their utility extends meaningfully beyond that original purpose.
Consequently, the adaptability and modular nature of the UBEMs discussed remain limited. While many aspire to serve as versatile, multi-purpose instruments, tools not conceived with modularity as a core principle from the outset tend to become tightly coupled to their initial application context. Each UBEM was built around a particular computational backbone, rendering it most effective within the domain for which that approach was originally optimized.
A further significant limitation lies in poor scalability to extensive building stocks or diverse geographic contexts. For instance, the majority of these platforms have been tested in only one or a handful (fewer than five) real-world applications, typically involving modest numbers of buildings. Reliance on simplified reduced-order models (as in SUNtool, CitySim, OpenIDEAS, CEA, and TEASER) often compromises result accuracy when attempting broader deployment. On the other hand, platforms employing high-fidelity dynamic simulation engines (such as UMI, CityBES, and URBANOPT) face substantial barriers to generating scenarios at truly large scales due to computational demands.
Another drawback is the restricted ability to accommodate diverse input data formats (Table 2), which necessitates repeated cleaning and reformatting of source datasets. This labor-intensive procedure can span months and severely restricts methodological expansion. Moreover, the frequent inconsistency of municipal data sources requires cross-verification and selection of the most reliable dataset before tool application—a manual step inherent to most existing UBEM workflows.
A fourth major shortcoming concerns the absence of automated data ingestion pipelines. Numerous studies [15, 16, 37-39] have highlighted the value of automating input data handling to minimize errors and reduce labor costs, as preprocessing often ranks among the most time-consuming phases [40]. The limited availability of fully open-source implementations represents an additional barrier, particularly across certain components of these UBEMs. Since UBEMs intersect multiple greenhouse gas-emitting sectors (including buildings, transportation, and water systems), overcoming disciplinary silos and incorporating promising models from various academic fields should be a priority. In some cases, dependence on proprietary software further restricts access for the broader research community.
Finally, effective dissemination and interpretation of simulation outputs have persistently posed difficulties in the realm of urban modeling tools [16]. Within this domain, GIS-based thematic maps offer an especially accessible and intuitive means for end users to explore and understand results [41-43].
The central research question emerging from the literature analysis and identified shortcomings is whether existing UBEM platforms are sufficiently flexible to meet the diverse demands of varied application contexts. Does the underlying architecture of each tool reflect—and remain constrained by—the specific use case that drove its initial creation? Examination of the preceding section reveals a strong correlation between intended application and the structural design of these platforms.
Present-day UBEM solutions typically feature custom-built pipelines for importing city-specific data, enriching it with standardized building archetype information, and generating simulation-ready inputs. Certain tools leverage open-source frameworks for this purpose, while others rely on bespoke engines and proprietary development paths. Furthermore, only a minority address cross-sectoral integration (e.g., linking buildings with transportation), and even fewer (notably just UMI) establish meaningful connections between outputs from these distinct sectors.
The principal limitations of existing tools, therefore, reside in their restricted flexibility to accommodate heterogeneous data sources and to interface with a variety of simulation engines. The ability to employ diverse simulation engines is essential for addressing multiple urban sectors and for operating at varying levels of detail within each sector. Accordingly, the newly proposed model centers on establishing a unified central data model that provides a rigorous, explicit definition of all urban processes relevant to decarbonization efforts. This central data model serves as a repository for integrating and structuring information from disparate sources. At the same time, its architecture enables the automated generation of input files tailored to different simulation software typologies, depending on the specific application context. Furthermore, it functions as a modular framework that orchestrates multiple processes, with the outputs of one process seamlessly serving as inputs to subsequent ones.
In response to the identified shortcomings, the solution entails developing an open-source, highly flexible, and rigorously structured framework that supports the ingestion and integration of multiple input file formats describing city characteristics, while also ensuring compatibility with a range of analytical tools.
This framework is designed to facilitate the creation of diverse use cases, all oriented toward enhancing the sustainability performance of urban environments. The deliberate avoidance of dependence on any single proprietary software package, in favor of constructing an integrative framework encompassing multiple tools, constitutes a fundamental design principle. Certain tools may prove more suitable than others across various use cases, and the platform is engineered to accommodate and manage such heterogeneity effectively.
Consequently, the core research question can be articulated as follows: What constitutes the essential architectural structure of an urban energy modeling platform capable of operating effectively with limited data availability while simultaneously accelerating building stock retrofitting initiatives in urban settings?
In response to this question, the framework presented in this paper — the TOOLS4Cities hub — has been developed over the past three years at the Next Generation Cities Institute of Concordia University. This framework has been applied to the specific case of an urban-scale building retrofit analysis tool.
The TOOLS4Cities UBEM framework, as previously delineated, served as the foundation for developing a dedicated tool to evaluate the feasibility and impacts of implementing large-scale retrofitting strategies across urban building stocks. This article elucidates the structural design of this retrofit tool and selected elements of its software architecture. The primary objective is to demonstrate the framework's fundamental organization and substantiate its modularity and scalability through a concrete application example. Detailed specifications of the implemented software architecture fall beyond the scope of this contribution. The developed codebase is fully open-source and publicly accessible for cloning via Git [44].
An overview of the retrofitting workflow is shown in Figure 2. This workflow forms an integral component of the broader TOOLS4Cities urban simulation platform, which is being advanced at the Next Generation Cities Institute of Concordia University with the overarching aim of enabling holistic simulation of urban systems. At the heart of this platform lies the TOOLS4Cities Hub — a cohesive collection of processing pipelines, data models, curated datasets, and standardized catalogs. The building retrofit tool integrates several interconnected modules drawn from the Hub, encompassing building energy modeling, energy systems representation, scenario definition, techno-economic evaluation of retrofit options, and advanced visualization capabilities. These constituent modules are elaborated in subsequent sections.

Figure 2. Overview of the retrofitting workflow.
The fundamental purpose of the retrofit workflow is to conduct a systematic assessment of the energy, environmental, and economic consequences of retrofitting individual buildings in an urban context. The approach entails selecting a building in the city and computing its investment costs, operational expenditures, and greenhouse gas emissions under both the baseline (no-intervention) condition and various predefined retrofitting interventions. In the initial iteration — corresponding to the Minimum Viable Product (MVP) — three principal retrofitting archetypes were implemented across the entire building stock: envelope (skin) retrofit, energy systems upgrade, and comprehensive (deep) retrofit. Nevertheless, the tool's modular architecture readily accommodates the incorporation of more granular, typology-specific large-scale retrofitting strategies and decision heuristics. For instance, older structures may require full envelope interventions, whereas newer buildings may require only window replacements or energy system modernization.
To ensure robust scalability, a sophisticated software architecture was required that would enable ongoing evolution of input datasets, seamless adaptation to alternative simulation engines, and the preservation of a consistent, rigorous ontology. As depicted in Figure 2, the UBEM component in TOOLS4Cities comprises dedicated importers and exporters, as well as an object-oriented representation of the ‘City’ entity. This ‘City’ encompasses all relevant urban objects — buildings, green spaces, road networks, and others — as derived from the user-supplied input file. The instantiation of this digital urban replica is achieved through object-oriented programming principles, wherein a central City class encapsulates diverse attributes, many of which are themselves instances of specialized classes representing distinct urban elements. Henceforth in this paper, references to the ‘City’ denote an instantiated object of the City class in the tool’s backend, capable of containing zero or more buildings and associated real-world features from any urban domain.
The principal objective underpinning the development of this UBEM workflow was to establish a neutral platform capable of exporting simulation-ready input files for external engines such as EnergyPlus or INSEL, thereby enabling their independent execution. Effective management of the requisite data streams is facilitated through a suite of formal data models and supporting catalogs [45]. A data model, in this context, constitutes a formalized, abstract schema that prescribes the organization and interrelationships of data entities within the system; it remains independent of physical storage mechanisms and serves primarily as a conceptual blueprint delineating structural and semantic connections among components.
Central to the platform’s efficacy are these data models. The limitations identified in prior UBEM implementations underscore the imperative for a coherent, well-structured data architecture. Such an architecture is indispensable for enabling transparent and efficient interactions across the diverse sectors implicated in urban decarbonization scenarios. Moreover, it empowers UBEM platforms to operate as truly versatile instruments, affording substantial adaptability and configurability to accommodate emerging requirements. The following sections outline the specific data requirements and their use within the UBEM workflow.
The initial phase of the building modeling process involves constructing a three-dimensional representation of the urban environment. Within the TOOLS4Cities Hub, such a 3D city model can be derived from multiple geospatial input formats, notably GeoJSON and CityGML. For buildings specifically, the source file must include the following essential attributes: year of construction, primary building function, and height. The workflow begins by instantiating a City object. Subsequently, this object is populated with geometric and attribute information extracted from the input file using a purpose-built importer module that systematically enriches the digital city representation.
Once the extruded geometry of urban objects has been generated, internal thermal zones within buildings are delineated. At present, each building is represented by a single thermal zone; however, alternative multi-zoning configurations are under active development.
After creating the City object, buildings must be augmented with thermophysical and construction-related properties to define realistic thermal zones. The urban modeling approach implemented in TOOLS4Cities adheres strictly to an archetype-based paradigm: construction characteristics are assigned exclusively according to the building’s predefined construction archetype. Accordingly, before initiating any UBEM simulation, the relevant set of archetypes must be established. The classification criteria employed by the Next Generation Cities Institute for archetype differentiation include building function, construction period, and prevailing climate zone. These same standards are to be applied to any new case study in which archetype definitions have not yet been incorporated into the TOOLS4Cities Hub.
Usage archetypes encapsulate information on internal heat gains and their associated time-dependent profiles. Assignment of a usage archetype to a given building is determined solely by its designated function. The profiles encompass hourly schedules for heating and cooling setpoints, HVAC system availability, occupancy presence, lighting power density, appliance electricity use, and domestic hot water draw. For each of these categories, three distinct schedule sets are defined, corresponding respectively to weekdays, Saturdays, and Sundays/public holidays. Each schedule provides hourly fractional values relative to the peak density specified for the category.
Climatic boundary conditions constitute a fundamental input for building performance simulation. Hourly values — including outdoor dry-bulb temperature, direct normal irradiance, diffuse horizontal irradiance, and related meteorological parameters — are sourced from a user-supplied weather file of arbitrary origin. Should no weather file be provided, the platform automatically retrieves and uses the standard .epw file for the geographic location under study.
Once the buildings within the City object have been fully parameterized with the requisite geometric, construction, usage, and climatic data, a suite of exporter modules — implemented as a factory pattern — generates input files tailored to various downstream simulation engines. These exporters extract relevant parameters from the central data model and transform them into the native format required by each target tool. As of version 2.0 of the framework, the following simulation engines are supported:
- Simplified Radiosity Algorithm (SRA), specifically engineered for high-resolution calculation of plane-of-array irradiance across all urban surfaces, thereby enabling detailed solar photovoltaic potential assessments.
- INSEL [46], a versatile platform capable of computing monthly and annual building energy demands employing either static or dynamic calculation methodologies.
- EnergyPlus is widely recognized as one of the most comprehensive and rigorously validated engines for simulating building energy demand and consumption.
- TRNSYS, another established reference tool for integrated modeling of buildings and associated energy systems.
The workflow further encompasses dedicated runner modules that execute the selected simulation engines externally and subsequently reintegrate the computed results into the central data model for downstream analysis (as detailed in the results section). Although certain engines share overlapping objectives (e.g., TRNSYS, INSEL dynamic mode, and EnergyPlus), the provision of multiple exporters is intentional: it promotes interoperability across research groups, enables comparative evaluation of software performance, and affords flexibility to select the most appropriate engine for any given application context. For instance, the capacity of TRNSYS and INSEL to incorporate external radiation data sources renders them particularly suitable for coupling with SRA outputs. In contrast, EnergyPlus relies predominantly on its internal solar distribution algorithms.
EnergyPlus workflow? Given that the retrofit cost estimation methodology relies exclusively on EnergyPlus, the associated workflow merits more detailed exposition. One of the principal scalability constraints identified in existing UBEM platforms stems from the prohibitive computational time required to execute detailed white-box models across large building stocks. To mitigate this bottleneck, a dedicated EnergyPlus workflow has been engineered. The process begins by exporting the fully enriched central data model into a standard IDF (Input Data File) format. In the current implementation, each building is represented as a single-zone model. To enhance performance, adjacent buildings are explicitly modeled as shading and adjacency objects within a unified IDF file.
Initial development leveraged the eppy library to generate programmatic IDF files. However, inherent characteristics of that library — notably redundant schedule replication across zones and reliance on extended data dictionaries — resulted in unacceptable slowdowns when processing more than approximately 500 buildings. Consequently, a custom, high-performance library was developed specifically to accelerate IDF creation. Although this new library requires periodic updates to maintain compatibility with evolving EnergyPlus versions, it enables efficient export of very large IDF files—an indispensable capability for city-scale simulations. Despite continued motivation for simplified models owing to simulation duration, the optimized workflow now simulates up to 3000 buildings in under 2 hours on a single Intel® Xeon® E-2400 series processor (8 cores, 95 W TDP).
SRA: The Simplified Radiosity Algorithm (SRA) implemented in the platform follows the methodology originally proposed by Robinson et al. [17]. This approach applies radiosity principles to deliver accurate, computationally efficient predictions of external irradiance (both shortwave and longwave) and internal illuminance, within a unified computational module. While the internal radiation engine in EnergyPlus is used for primary building energy simulations, the SRA module is specifically used to compute incident radiation on exterior surfaces, thereby enabling detailed assessments of solar photovoltaic (PV) potential. The SRA importer leverages imported geometric data, the thermophysical properties of the external material layers of walls and roofs, and prevailing weather conditions to determine shortwave radiation exchanges among building envelopes.
Upon completion of the simulations, a dedicated results importer module is invoked to integrate the simulation outputs back into the building objects. This step preserves the integrity of the existing City structure for subsequent analytical tasks while enriching each building with computed energy demand values.
For each geographic location under study, a systematic review is conducted to characterize the predominant energy supply systems used to meet heating, ventilation, air conditioning (HVAC), and domestic hot water (DHW) requirements. These systems encompass components related to energy generation, distribution, storage, and final heat emission. Collectively, such configurations define an energy system archetype or template, which serves as the foundational element of the energy system data model within the TOOLS4Cities Hub.
The resulting data model, illustrated in Figure 3, constitutes a comprehensive, rigorously organized schema for systematically capturing and managing the complexity of real-world energy system configurations. At its core lies the conceptual EnergySystemCatalogue, implemented as a flexible superclass with multiple specialized subclasses corresponding to the principal functional domains: generation, distribution, storage, and emission. This hierarchical structure affords considerable versatility by permitting components to be represented in either of two forms: (i) actual market-available technologies with specific technical characteristics, or (ii) generic template structures equipped with predefined nominal attributes but without assigned dimensions. This dual representation strategy yields a highly adaptable framework capable of addressing a wide range of modeling scenarios.

Figure 3. Excerpt from the UML diagram of the energy system data model. In the diagram, denotes the possibility of multiple (n) instances.
Once building-level energy demands have been determined, an appropriate energy system template is assigned to each building according to its function and construction period (vintage). Relevant technical parameters of the template components — such as the efficiency of generation units — are retrieved from dedicated .xml files containing curated energy system data. A purpose-built importer then augments the building objects with these attributes, rendering them readily accessible for subsequent energy consumption calculations across different end-use categories.
Although the spectrum of possible retrofit interventions is virtually unlimited, three distinct retrofit scenarios were initially defined as a proof-of-concept test case to validate the overall methodological framework. These scenarios are as follows:
- Scenario 0 — Business as usual: retention of the building in its current state, with envelope components unchanged and replacement of energy systems only upon reaching the end of their service life (using equipment with performance characteristics identical to the originals).
- Scenario 1 — Envelope (skin) retrofit: upgrade of the building envelope to comply with contemporary building regulations and standards.
- Scenario 2 — HVAC optimization + PV: replacement of HVAC systems with state-of-the-art technologies, combined with installation of rooftop solar photovoltaic systems wherever the unshaded roof area exceeds 70% of the total roof surface (i.e., shaded area < 30%).
- Scenario 3 — Deep retrofit: a comprehensive intervention that combines the measures of both Scenario 1 and Scenario 2.
The Life Cycle Costing (LCC) analysis is implemented through a separate, dedicated class structure. The markedly higher volatility and context-dependency of economic assumptions — compared with the relative stability of physical energy calculations — prompted the development of this parallel architecture, which interfaces closely with the core TOOLS4Cities Hub while remaining independent. This modular separation enables future extensions from an economic research perspective, including dynamic cash-flow modeling, sensitivity analysis, risk assessment (identified as a critical requirement [47]), and monetization of externalities.
The methodological framework for the economic evaluation of the retrofit scenarios integrates a standard LCC approach with explicit accounting for externalities embedded in the overall cost-modeling procedure. Life Cycle Costing, also referred to as whole-life costing or total cost of ownership analysis, evaluates the aggregate costs incurred throughout the entire service life of an asset while comparing alternative investment and operational strategies. For instance, the baseline (no-intervention) case can be contrasted with a proposed retrofit scenario by computing and comparing their respective LCC profiles. The existing condition incurs no additional capital expenditure, whereas the retrofit option entails upfront investment costs but yields reductions in annual operating expenses and, potentially, in unpriced externalities. The design and application of LCC analysis in the built environment are formalized in ISO 15686-5 [48], which defines the requisite criteria and procedures. The overarching mathematical formulation is presented in Eq.1.
(1)
Where
• CAPEX = initial capital expenditure (product acquisition + installation and commissioning costs);
• CAPEX reposition = reinvestment costs associated with the replacement of equipment at the end of its service life;
• Operational costs = variable costs related to day-to-day operation;
• Maintenance costs = variable costs associated with upkeep and repairs;
• Operational incomes = variable revenues generated during operation, e.g., feed-in tariffs from solar photovoltaic systems;
• Externalities costs = variable costs attributable to external environmental impacts, such as CO₂ or other pollutant emissions;
• cpi = consumer price index escalation rate, provided as a time series of annual values;
• epi = energy price index escalation rate, differentiated by fuel type and provided as a time series of annual values;
• extpi = externalities price index escalation rate, reflecting projected changes in future markets for externalities (e.g., carbon pricing mechanisms);
• d = discount rate applied to the retrofitting investment analysis.
CAPEX calculation
Within the developed tool, capital expenditure (CAPEX) estimation is managed through a structured data catalog. For the classification of building elements and associated site works, the UNIFORMAT II standard was adopted [49]. In the initial validation phase of the tool, a relatively low level of detail (LoD1) was employed, as the analysis adopted a high-level, global perspective on retrofit solutions. Accordingly, only incremental costs attributable to the retrofitting measures were considered, using average unit costs per surface area for the relevant building elements without differentiation among alternative technical solutions. The initial organization of the CAPEX data catalog is presented in Table 5.
Table 5. Breakdown of UNIFORMAT II cost categories implemented in the platform.
Id | Description |
B | Building shell |
B10 | Superstructure and ground-level refurbishment |
B20 | Building envelope |
B2010 | Opaque wall elements |
B2020 | Transparent wall elements |
B30 | Roof structures |
B3010 | Opaque roofing |
B3020 | Transparent roofing |
D | Building services |
D30 | Heating, ventilation, and air conditioning (HVAC) |
D3010 | Energy supply systems (PV systems) |
D3020 | Heat production systems |
D3030 | Cooling production systems |
D3040 | Distribution networks |
D3060 | Control and monitoring systems |
D3080 | Additional HVAC components (AHU) |
D50 | Electrical systems |
D5020 | Lighting installations and branch wiring |
Z | Allowances |
Z10 | Design contingency |
Z20 | Overhead costs and profit |
Considerable attention has been devoted to ensuring that simulation results are presented in an accessible, user-friendly manner to both technical and non-technical audiences. Inadequate communication and visualization of outcomes are among the most significant shortcomings of existing urban building energy modeling tools.
To address this limitation, a dedicated web-based interface displays all buildings within the city, enabling interactive exploration of the simulated data. Results are visualized through two complementary services integrated into the Citylayers test platform (https://ngci.encs.concordia.ca/citylayers/; accessed on 17 January 2025).
The initial proof-of-concept implementation of a city-wide building retrofit assessment tool was applied to the island of Montréal. Over the course of development, a comprehensive set of geospatial, construction, usage, and energy system data specific to Montréal was assembled, allowing the research team to define and calibrate multiple archetypes tailored to the local building stock. For validation purposes, the analysis focused on two predominantly residential districts and a selection of institutional buildings, with simulated outputs compared against available statistical benchmarks and real-world operational energy consumption records.
Validation of floor-area estimates and energy-consumption patterns focused primarily on single-family houses, duplexes, and triplexes. To this end, two large, low-rise residential neighborhoods in Montréal were selected. The choice of these areas was guided by the need to identify relatively homogeneous zones dominated by a limited number of building typologies for which reliable statistical reference data were available. Although both neighborhoods contain a small proportion of taller residential structures and commercial premises, more than 95% of the total built floor area in each consists of single-family homes, duplexes, and triplexes.
The first area is located in the Pointe-Saint-Charles neighborhood (bounded by Wellington Street, Ash Street, Leber Street, and Congrégation Street). It comprises 313 buildings, most of which were constructed before 1946. The second area is located in the Saint-Léonard neighborhood (bounded by Langelier Boulevard, Robert Boulevard, de Guyenne Street, and Louis Sicard Street). It includes 249 buildings, predominantly dating from the 1960s to the 1990s. The locations of the simulated zones are illustrated in Figure 4. In total, these two districts encompass 563 buildings.

Figure 4. Simulated buildings, color-coded according to construction vintage.
Following the initial round of simulations, a detailed investigation was conducted to identify and explain discrepancies between modeled and actual energy consumption values. Sources of deviation were examined from two principal perspectives: (i) uncertainties and inaccuracies in input data, and (ii) simplifying assumptions embedded in the simulation methodology. The first stage of this analysis concentrated on differences in calculated floor areas — derived from multiple municipal geospatial datasets (CityGML, GeoJSON, and land valuation records) — and on energy consumption per unit floor area.
Validation proceeded in two sequential phases. The initial phase involved a detailed examination of consumption patterns for specific building typologies supported by available metadata. Two main typologies were analyzed: single-family homes and duplexes, as well as public/institutional buildings.
The initial validation phase evaluated whether the annual simulation outputs from the two selected case-study areas aligned with observed real-world yearly energy consumption figures. The reference datasets used for comparison varied by building typology.
For single-family homes, duplexes, and triplexes, modeled results were benchmarked against aggregated data from 19,111 buildings extracted from the Energuide dataset [50]. This subset was filtered to include only Montréal properties classified as single-family houses, duplexes, or triplexes. The Energuide database provides measured annual final energy consumption for each dwelling, together with metadata on construction year and building typology.
For buildings in the tertiary (institutional) sector, validation drew upon the City of Montréal’s publicly released inventory of 186 municipal buildings, which includes metadata and reported energy consumption values [51]. Due to practical constraints, the analysis was restricted to a representative subset of 15 buildings from this inventory.
Preparation and harmonization of geospatial inputs proved exceptionally labor-intensive, primarily owing to inconsistencies and variable quality across source datasets. The final geometric database was assembled by integrating several publicly available resources provided by Natural Resources Canada (NRCan) and the City of Montréal administration, including: Montréal property assessment units [52], the Montréal 3D buildings dataset (LoD2 model with textures), Montréal LiDAR aerial survey [53], NRCan building footprints [54], and Layer 2 cadastral parcels delineating disaggregated building use types [55].
Despite the broad coverage of these source datasets, substantial discrepancies in completeness and accuracy necessitated a multi-step preprocessing pipeline: (i) subdivision of satellite-derived building footprints using cadastral parcel boundaries; (ii) refinement of building heights through integration of LiDAR measurements to enhance vertical accuracy; and, most critically, (iii) implementation of a custom overlap-detection and correction algorithm to eliminate erroneous intersections between adjacent building geometries. The resulting consolidated dataset was exported as a GeoJSON file containing corrected building heights and a core set of attributes for each structure (construction vintage, function selected from a taxonomy of over 250 categories, number of dwelling units, and number of stories). This GeoJSON was further enriched through a dedicated procedure to identify shared walls in both 2D and 3D, thereby producing a single, simulation-ready file encompassing all geometric elements required for modeling.
Validation of the processed geometry involved cross-checking the total number of dwelling units per postal code against Statistics Canada census figures. Discrepancies across the studied neighborhoods remained below 5% of total households, with the sole exception of Nun’s Island. Overall data quality from municipal sources was judged to be limited. The TOOLS4Cities geometry factory subsequently utilized the cleaned footprint and height information to generate extruded 3D building surfaces. Window-to-wall ratios were assigned automatically based on building function and vintage, while story divisions were inferred to estimate total floor area. A key feature of the geometry engine was the explicit treatment of all abutting surfaces as neighboring (adiabatic or thermally coupled) boundaries, ensuring appropriate handling of radiation exchange and heat transfer.
Another critical step involved mapping the more than 500 building function categories defined in Montréal’s tax assessment records [52] to a reduced set of modeling archetypes maintained within the TOOLS4Cities Hub. The adopted archetypes were grounded in the 17 building types originally developed by the National Renewable Energy Laboratory (NREL) and implemented in Natural Resources Canada’s BTAP tool [56].
Consistent with the overarching methodology, thermophysical construction characteristics are assigned to each building via a lookup in an archetype dictionary keyed on construction vintage. The initial Montréal-specific construction archetypes were derived from NRCan’s BTAP development, which itself built extensively upon prior NREL work. However, the vintage granularity of these inherited archetypes proved insufficient for Montréal’s context: all structures predating 1980 — representing over 65% of the city's total floor area — were assigned identical construction assemblies.
To address this limitation, supplementary sources were consulted, and a refined set of construction typologies was developed starting from the BTAP baseline [56]. These enhancements drew upon peer-reviewed academic studies [57, 58] and technical reports prepared by engineering consultancies [59]. The resulting classification distinguishes residential from non-residential buildings and further stratifies assemblies according to construction period.
Occupancy and internal load profiles for Montréal were populated using schedules extracted from the National Energy Code of Canada for Buildings (NECB) dataset. Fixed profiles were applied uniformly to each building and space type according to the predefined archetypes. Two distinct processing steps were employed: one for internal gain densities and another for time-varying schedules.
Both steps currently reference the publicly maintained repository associated with the BTAP tool [56], where the NRCan team continues to update baseline data sources.
The modular factory architecture also supports integration of external stochastic occupancy and load profiles generated according to methodologies described in Dabirian et al. [45]; however, such profiles were intentionally excluded from the present retrofit analysis to maintain methodological consistency.
Annual sectoral energy balances were utilized to apportion buildings between natural gas and electricity as primary energy carriers. For HVAC system typologies, equivalence classes were adopted directly from Table 8.4.4.7.-A of the National Energy Code for Buildings (NECB) [60]. These equivalence tables prescribe a recommended system type for each building category. The six principal system configurations considered (System 1 through System 6) are summarised in Table 6.
Table 6. Overview of the energy system typologies considered, based on NECB classifications.
Systems | System description | Fan operation | Cooling configuration | Heating configuration |
System 1 | Unitary air conditioning unit with baseboard heating | CV | Air-cooled DX with external condenser | Fuel-fired hot water boiler supplying baseboards |
System 2 | 4-pipe fan-coil system | CV | Water-cooled system with water chiller | Fuel-fired or electric resistance hot water boiler |
System 3 | Single-zone packaged rooftop unit combined with baseboard heaters | CV | Air-cooled DX | Fuel-fired or electric resistance furnace; baseboards supplied by hot water or electric resistance |
System 4 | Single-zone make-up air unit with baseboard heating | CV | Air-cooled DX | Fuel-fired or electric resistance furnace; baseboards supplied by hot water or electric resistance |
System 5 | Two-pipe fan-coil system | CV | Water-cooled system with water chiller | None |
System 6 | Multi-zone custom-built system with baseboard heater | VV | Water-cooled system with water chiller | Baseboards using an electric resistance or hydronic system with a fuel boiler |
The primary limitation of the table presented above is the lack of explicit information on the energy carriers (fuel types) used. To address this gap, an additional dataset was consulted to determine the predominant primary energy sources utilized for building heating in Québec. Figures 5 and 6 illustrate the distribution of heating fuel shares for residential and commercial buildings, respectively, based on the Survey of Household Energy Use (SHEU) conducted by Statistics Canada [61] and complementary data for commercial buildings [62].

Figure 5. Distribution of heating fuel sources for residential buildings.

Figure 6. Distribution of heating fuel sources for commercial buildings.
Analysis of building floor areas derived from geospatial inputs revealed systematically higher values compared with those reported in municipal property assessment records. The methodology’s reliance on true 3D exterior volumes led to overestimations, particularly through the inclusion of overhanging or partially covered upper-floor volumes and second-story areas. As shown in Figure 7, the average floor area computed from the geometric models exceeded the tax-assessment values by approximately 60%. This discrepancy originated primarily from limitations in the quality and consistency of the available geospatial datasets. Emerging approaches leveraging artificial intelligence (AI) and machine learning (ML) to identify and implement more accurate geometry-extraction techniques are currently under evaluation. They will be integrated into future iterations of the platform [63].

Figure 7. Comparison of floor areas between municipal tax assessment records and extrapolated GeoJSON-derived surfaces.
Recognizing that the methodology developed by the CERC team explicitly incorporates realistic geometric relationships — including shading and adjacency effects — it was decided not to simplify or abstract the 3D representations. Instead, a uniform scaling (downsizing) factor was applied to reconcile the simulated surface areas with the more reliable tax-evaluation floor-area data. This correction factor, calculated as the ratio between tax-reported and simulated areas, was subsequently applied to adjust the final simulated energy consumption values. For energy consumption validation, the modeled results were benchmarked against filtered records from the Energuide audit database, restricted to 19,111 entries for single-family, duplex, and triplex dwellings located in Montréal. As depicted in Figure 8, simulated specific energy consumption values (final energy per unit floor area) were grouped by construction vintage and compared with the corresponding Energuide subsets. Despite limited sample sizes for certain vintage cohorts, the simulated results showed strong overall agreement with the observed data across most periods. The only notable deviation occurred for buildings constructed between 1978 and 1983; however, this discrepancy was deemed less conclusive given the small number of simulated buildings in that vintage category (n = 4).

Figure 8. Specific final energy consumption in single-family, duplex, and triplex buildings: comparison between Energuide dataset and simulation outputs.
In the tertiary sector, validation focused on the City of Montréal’s publicly available inventory of municipal buildings and their reported energy consumption. A subset of 15 buildings was examined with respect to both floor area and energy use, with results summarised in Figure 9. Floor-area comparisons yielded inconsistent outcomes: in five instances, discrepancies exceeded 30%. On average, the 3D models derived from municipal geospatial sources overestimated floor area by approximately 30% relative to the City’s published figures. This systematic bias mirrored the pattern observed in the residential sector and was attributed to the relatively low level of detail (currently situated between LoD1 and LoD2) in the available 3D building models. Greater accuracy could be achieved by municipal authorities developing more consistent, higher-resolution geospatial datasets.

Figure 9. Comparison of floor areas for institutional buildings between City-published data and extracted 3D model results.
Regarding final energy consumption, modeled values were compared with the municipality’s reported figures. Significant deviations (exceeding 20% of the baseline consumption) were observed in three cases; nevertheless, the magnitude of specific energy consumption (energy per unit floor area) remained broadly consistent. Where discrepancies arose, they could generally be ascribed to differences in assumed indoor environmental conditions, operational schedules, or other unmodeled factors. The sensitivity of results to the weather data source was also assessed by comparing simulations driven by Hydro-Québec (HQ) data from the McTavish station in Montréal against those using the standard EnergyPlus weather file [64]; the resulting difference in annual energy consumption was less than 5%. Overall, the building-level validation exercise demonstrated that the tool not only provides credible energy estimates but also serves as a valuable diagnostic instrument for identifying inconsistencies and anomalies across disparate datasets (geometrical and consumption-related). This capability complements ongoing efforts in other domains that employ machine learning techniques to enhance geospatial data quality and anomaly detection [65].
Following successful validation of the methodological framework, the complete workflow was applied to quantify the effects of the three defined retrofit scenarios across the pilot areas. For the single-family, duplex, and triplex neighborhoods, the workflow automatically adjusted relevant building parameters and assigned scenario-specific cost profiles. The resulting energy performance outcomes are presented in Figures 10 and 11. In terms of final energy consumption, the analysis revealed that retrofit interventions produced the most substantial reductions in smaller, older structures, although the magnitude of savings varied across the stock. This heterogeneity may partly be attributable to the presence of adjacencies (shared walls), which reduce the relative benefit of envelope improvements in attached buildings compared with detached (stand-alone) structures. Overall, the tool's outputs indicated clear general trends in retrofit effectiveness; however, the findings also underscore the need for detailed, typology- and location-specific assessments to inform more targeted, evidence-based policy development.

Figure 10. Specific final energy consumption by floor area group across the two neighborhoods.

Figure 11. Specific final energy consumption by construction vintage group across the two neighborhoods.
In the institutional building subset, identification of consistent trends proved more challenging owing to the limited sample size and the diversity of functional uses among the buildings. Nonetheless, even within this heterogeneous group, the platform demonstrated its utility in prioritizing retrofit investments across different municipal building typologies and in identifying which scenario would deliver the greatest energy (and potentially economic) benefit for individual structures.
After computing energy consumption profiles for each building in the Montréal case study, the retrofit costing workflow was executed using the following economic assumptions and parameters:
- Analysis period = 40 years,
- Financing percentage (credit) = 0%,
- Interest rate = 0.04,
- Consumer price index escalation = 0.04,
- Electricity peak price index escalation = 0.05,
- CO₂ price = 30 $/ton,
- CO₂ price escalation index = 0.06,
- Electricity price escalation index = 0.05,
- Natural gas price escalation index = 0.05,
- Discount rate = 0.03 [66],
- Retrofitting implementation year = 2020.
The 40-year time horizon for life cycle cost (LCC) calculations was deliberately selected as a compromise: while the reference study [66] adopted 30 years, emerging European Union guidelines [67] advocate a 50-year horizon. The midpoint of 40 years was therefore chosen.
The same residential and institutional building subsets employed in the energy validation phase were used to assess the economic implications of the retrofit scenarios. Although this economic component was not directly validated against executed real-world projects, published benchmarks and case studies [68, 69] provided a qualitative check to confirm that the modeled retrofit costs fell within realistic ranges.
The two residential neighborhoods served as test beds for evaluating the economic performance of the retrofit measures under the established assumptions. Life-cycle cost outcomes for both areas are shown in Figures 12 and 13.

Figure 12. Scatter plot of life-cycle costs across the different scenarios, stratified by retrofit scenario and neighborhood.

Figure 13. Box plot of life cycle costs by cost category and construction vintage across the different retrofit scenarios.
From a life-cycle costing perspective, the analysis indicates that retrofitting measures generally yield solutions whose total costs are at least comparable to—and in many cases equivalent to—those of the baseline (business-as-usual) case—the economic attractiveness of retrofitting varied markedly by building vintage. Envelope (skin) retrofits proved particularly cost-effective for structures built before 2000. Standalone energy systems upgrades exhibited vintage-dependent viability, with newer buildings tending to offer greater economic returns from such interventions. Finally, comprehensive (deep) retrofits were not found to be economically justified, even when evaluated over the full life cycle.
For the institutional (tertiary-sector) buildings, Figure 14 presents a scatter plot of life-cycle costs for each scenario. Owing to the limited number of buildings analyzed, no vintage-stratified box plots were generated.

Figure 14. Scatter plot of life cycle costs for individual tertiary-sector buildings.
In the tertiary building subset, life cycle costs associated with the baseline scenario consistently remained lower than those of any retrofit option. The exceptionally low electricity tariffs applicable to large institutional buildings in Montréal (averaging below 0.07 CAD/kWh) render most energy-efficiency interventions economically unattractive. The modeled capital expenditure (CAPEX) and operational expenditure (OPEX) values closely align with the ranges reported in the literature for comparable building typologies [70].
Despite substantial progress in the development of the tool, several aspects warrant further refinement:
- Data quality: Simulation accuracy is highly sensitive to the quality of input geometric data used to instantiate the City object. At present, EnergyPlus simulations are restricted to LoD1 GeoJSON inputs; support for higher levels of detail is under active development.
- Data availability: Beyond quality issues, the absence or incompleteness of data across diverse building typologies poses a major challenge. Locating mutually compatible datasets for construction assemblies and usage profiles — keyed to building function — remains difficult. As previously noted, the scarcity of reliable information on existing building energy systems significantly influenced the reliability of baseline simulations.
- Multi-zoning capability: All buildings are currently modeled as single thermal zones, which constitutes a simplification that may compromise the precision in certain cases.
- Occupancy modeling: Reliance on deterministic, fixed schedules for occupancy and internal loads represents another current limitation. A stochastic occupancy-generation workflow is currently under development.
- Economic analysis: The life cycle costing (LCC) framework employs generalized economic parameters that may not fully reflect site-specific or broader market conditions.
This paper has introduced a fully automated simulation platform capable of processing large urban areas — including a major metropolitan center such as Montréal — using a white-box (physics-based) modeling approach while effectively compensating for deficiencies in low-quality input datasets. Validation exercises yielded generally satisfactory agreement between simulated and observed/statistical data. The forthcoming phase will focus on systematic parameter calibration to determine whether observed discrepancies can be mitigated through targeted adjustments to model inputs and assumptions.
The platform adopts an open-source, modular architecture that facilitates the incorporation of contributions from other researchers and supports prospective scenario analysis that integrates cross-sectoral considerations.
In summary, the TOOLS4Cities hub provides a rapid, archetype-driven means of evaluating the energy costs and carbon emissions of every building in an urban area, thereby enabling direct comparison of alternative renovation strategies. By streamlining such assessments, the tool aims to accelerate the decarbonization of municipal building stocks.
The overarching objective for the UBEM framework developed here — grounded in open-source principles, modularity, flexibility, and interoperability — is to ensure continuous evolution and enhancement in the years ahead.
Development efforts are directed toward making the platform fully accessible to the international research community and enabling seamless integration of novel workflows. While the CERC repository is publicly available for cloning and use by any researcher, adoption of the accompanying manuals and hub methodology is strongly recommended to maximize the framework’s extensibility and analytical power.
At the time of publication, the scalability and transferability of the tool are under active evaluation through additional pilot implementations in Palma de Mallorca (Spain), Québec City (QC, Canada), and Toronto (ON, Canada).
AI: Artificial Intelligence.
BTAP: Building Technology Assessment Platform.
CAPEX: Capital Expenditures.
CEA: City Energy Analyst.
CERC: Canada Excellence Research Chair for Sustainable Cities and Communities.
CityGML: City Geography Markup Language.
EnergyADE: Energy Application Domain Extension.
GHG: Greenhouse Gases.
GIS: Geographic Information System.
HVAC: Heating, Ventilation, and Air Conditioning.
IoT: Internet of Things.
LCC: Life Cycle Costing.
LiDAR: Laser Imaging Detection and Ranging.
LoD: Level of Detail.
ML: Machine Learning.
MVP: Minimum Value Product.
NECB: National Energy Code for Buildings Canada.
NRCAN: Natural Resources Canada.
NREL: National Renewable Energy Laboratory.
PV: Solar Photovoltaics.
RC: Resistance Capacitance.
ROM: Reduced Order Models.
SRA: Simplified Radiosity Algorithm.
TEASER: Tool for Energy Analysis and Simulation for Efficient Retrofit.
UBEM: Urban Building Energy Modeling.
UHI: Urban Heat Island.
UMI: Urban Modeling Interface.
URBANOPT: Urban Renewable Building and Neighborhood Optimization.
None
None
This research was funded by the NSERC under the Canada Excellence Research Chair program for Professor Ursula Eicker, and by the UNIVER/CITY2030 initiative at Concordia University, funded by the McConnell Foundation.
None
Open Access The author(s) retain copyright. This article is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. It may be shared and adapted for non-commercial purposes with appropriate attribution, an indication of changes, and distribution of adaptations under the same license. Third-party material may be subject to separate terms identified in its credit line. View the license at https://creativecommons.org/licenses/by-nc-sa/4.0/.