Input data processing for large-scale energy system modelling frameworks

This section aims to provide brief overviews of adapting the archetype building model for use in large-scale energy system modelling frameworks like Backbone and SpineOpt. In general, such frameworks are rarely designed with building modelling in mind, and as such don't support the building-specific data stored within ArchetypeBuilding and related structs without further processing. Perhaps the most important step is to understand the roles of AbstractNode and AbstractProcess as opposed to their detailed counterparts BuildingNodeData and BuildingProcessData.

The following Processing thermal nodes into AbstractNodes and Processing HVAC equipment into AbstractProcesses sections explain the aggregation and abstraction of building level data for energy-system-scale, while the Backbone input data processing and SpineOpt input data processing sections focus on the processing workflows of their respective models models.

Processing thermal nodes into AbstractNodes

BuildingNodeData has been designed to be as human-readable and understandable as possible from a building-domain point-of-view, including a plethora of different parameters related to archetype definitions, assumptions, sizing, etc. However, most of these parameters don't have counterparts in large-scale energy system models, and need to be aggregated into something meaningful. This is done via the ArchetypeBuildingModel.process_abstract_node function, aggregating all the separate categories of thermal mass, heat transfer, as well as ambient condition and external load related parameters into the bare essentials required for depicting the node in large-scale energy system modelling frameworks, represented by an AbstractNode.

As this abstraction reduces the amounts of different terms in the equations, it also happens to simplify Solving the baseline heating demand and HVAC equipment consumption, which is why the AbstractNodes are used for the calculations in the ArchetypeBuildingModel.solve_heating_demand function.

Processing HVAC equipment into AbstractProcesses

Similar to BuildingNodeData, BuildingProcessData has been designed primarily with human-readability in mind, containing multiple parameters related to coefficients of performance, sizing of the systems, etc. However, for large-scale energy system model input, these are processed to their bare essentials via the ArchetypeBuildingModel.process_abstract_system function and stored as an AbstractProcess.

Again, this abstraction happens to simplify Solving the baseline heating demand and HVAC equipment consumption, thus making use of the AbstractProcess in the ArchetypeBuildingModel.solve_consumption function.

Backbone input data processing

This section aims to provide an overview of the processing done for producing Backbone input data, explaining the logic of and functions withing src/create_backbone_input.jl.

The BackboneInput struct contains the relevant input data structure for representing the produced archetype building models within Backbone. The similarly named constructor takes as input a dictionary containing the defined building_archetype linked to its processed ArchetypeBuildingResults, loops over the archetypes, and adds them to the BackboneInput one by one. The actual processing is handled by the ArchetypeBuildingModel.add_archetype_to_input! function, which performs a lot of rather complicated manipulations to adapt the archetype building data for Backbone. For people familar with Backbone model structure, the key points are:

1. Each building_archetype is mapped into a grid.
2. Each AbstractNode is mapped into a node in the corresponding archetype grid.
3. Each AbstractProcess in each building_archetype is mapped into a unique unit.
4. System link nodes defined by building_archetype__system_link_node relationships and the associated node_name and grid_name are created to serve as connection points to potential energy system datasets.

Since ArchetypeBuildingModel.jl is based on SpineInterface.jl, the produced Backbone input is saved in its Spine Datastore format, and requires the use of Spine Toolbox and the associated tools contained within the Backbone repository in order to produce the inputData.gdx for running the model. Additionally, the backbone_utils/export_auxiliary_building_data.json exporter specification can be used for exporting useful .gdx data not directly used by Backbone.

SpineOpt input data processing

This section aims to provide and overview of the processing done for producing SpineOpt input data, explaining the logic and functions within src/create_spineopt_input.jl.

The SpineOptInput struct contains the relevant input data structure for representing the produced archetype building models within SpineOpt. The similarly named constructor takes as input a dictionary containing the defined building_archetype linked to its processed ArchetypeBuildingResults, loops over the archetypes, and adds them to the SpineOptInput one by one. The actual processing is handled by the ArchetypeBuildingModel.add_archetype_to_input! function, which essentially maps the AbstractNode and AbstractProcess parameters to their SpineOpt counterparts. For people familiar with SpineOpt, the key points are:

1. Each AbstractNode in each building_archetype is mapped into a unique node.
2. Each AbstractProcess in each building_archetype is mapped into a unique unit.
3. System link nodes defined by building_archetype__system_link_node relationships and the associated node_name are created to serve as connection points to potential energy system datasets.

Since both ArchetypeBuildingModel.jl and SpineOpt are based on SpineInterface.jl, the produced SpineOpt input data is immediately compatible. However, note that the produced SpineOpt input data only contains the data describing the modelled building stock, without all the necessary definitions to run the model in any meaningful way.