GitHub

Defining archetype buildings

This section aims to go over the key components of the Input data reference and explain how these components are used to define the archetype building lumped-capacitance thermal models. The explanations remain at a pretty high level, but links to the appropriate sections of the Input data reference and Library sections are provided for readers interested in the technical details.

The building_archetype definition

The single most important object class in the definitions, as each building_archetype object essentially represents a single synthetic average archetype building lumped-capacitance thermal model to be created. In the end, the rest of the object classes used for defining different aspects of the archetype buildings are each connected to a building_archetype using the appropriate relationship classes:

The building_archetype objects also houses most of the parameters defining assumptions regarding the archetype and how it's modelled. The only mandatory parameters are the weather_start and weather_end, which are required for automatic weather data processing using ArchetypeBuildingWeather.py, while the rest of the parameters have set default values that kick in if not specified by the user. For example, the assumed shape of the building envelope can be tweaked using e.g. building_frame_depth_m, number_of_storeys, room_height_m, and window_area_to_external_wall_ratio_m2_m2. Similarly, some assumptions related to the modelling can be tweaked here, e.g. effective_thermal_capacity_of_interior_air_and_furniture_J_m2K, external_shading_coefficient, or internal_heat_gain_convective_fraction. See the Object parameters section for a comprehensive list of all the possible parameters for the building_archetype.

Ultimately, each building_archetype is processed into an ArchetypeBuilding by the main program described by the Overview of the workflow section.

The building_scope definition

Arguably the second-most important object class in the definiton, as each building_scope object describes how to aggregate the underlying building stock statistics to calculate the properties of a synthetic average archetype building. Essentially, the building_scope object tells which building_stock data to use, and which building_types, heat_sources, and location_ids to include, and from what period of time. Similar to how The building_archetype definition works, the building_scope is also defined largely by connecting the desired pieces to it using the appropriate relationship classes:

Unlike the rest of the geographical and statistical scope definitions, the temporal aggregation is handled via parameters instead of relationships. This is done to facilitate selection of the desired time periods without having to look into the underlying data to know of the exact time periods used in the statistical data. Similarly, the years for the ventilation and structural properties rarely match the time periods for the building stock statistics, and can be sampled as easily using parameters instead. For this purpose, the building_scope has the two mandatory parameters:

Ultimately, each building_scope is processed into a ScopeData by the main program described by the Overview of the workflow section.

The building_fabrics definition

The building_fabrics objects are used to define how the building_archetype envelope, interior structures, and interior air and furniture are modelled. Essentially, it defines the temperature nodes of the structural components of the building for the lumped-capacitance thermal model of the archetype. Different building_fabrics are relatively lightweight to define, but they rely heavily on The building_node definitions, which are discussed in the following subsection. Regardless, building_fabrics are simply collections of building_node using the following relationship classes:

The building_fabrics definitions help form the EnvelopeData during the data processing by the main program, described by the Overview of the workflow section.

The building_node definition

The building_node objects are used to define the temperature nodes for the lumped-capacitance thermal models, whether they be a part of the building_fabrics, e.g. building envelope structures, or the building_systems, e.g. a domestic hot water storage tank. Due to their rather abstract nature, building_nodes have quite a few different ways they can be defined, depending on the desired purpose. Regardless, the principles remain similar to above, and most of the building_node definitions are handled via the following relationship classes:

The building_node object class also contains a few important parameters. A comperehensive list can be found in the Object parameters section, but the most important ones are:

Ultimately, each building_node is processed into a BuildingNodeData (and an AbstractNode for energy system model export) by the main program described by the Overview of the workflow section.

The building_systems definition

The building_systems objects are used to define different heating/cooling systems for the archetype buildings. They are similar to building_fabrics in the sense that they rely heavily on more detailed definitions for building_nodes and building_processs via these relationship classes:

The building_node definition is already explained in the sections above, but building_processes are extremely important for building_systemss.

The building_process definition

The building_process objects are used to define energy transfer/transformation processes in the building_systems, e.g. direct electric resistance heaters or heat pumps. The important relationship classes for the definitions are:

The building_process object class also contains a few important parameters, mostly due to the potential complexity of different heat pump systems. A comperehensive list can be found in the Object parameters section, but the most important ones are:

See the ArchetypeBuildingModel.calculate_cop function for more details on how weather-dependent COPs are modelled.

Ultimately, each building_process is processed into a BuildingProcessData (AbstractProcess for the energy sysem model export) by the main program described by the Overview of the workflow section.

The building_loads definition

The building_loads objects are used to define the internal heat loads and domestic hot water demand for a building_archetype. The only relationship class necessary is the:

For building_loads, all the important information is contained in the Object parameters:

Ultimately, each building_loads is processed into a LoadsData by the main program described by the Overview of the workflow section.

The building_weather definition

The building_weather objects are used for defining weather data for a building_archetype. Of all the definitions described in this section, it is the only non-required one. In case the relationship:

is left undefined, the ArchetypeBuildingWeather.py sub-module will be used in an attempt to automatically fetch and process the weather data necessary for creating the archetype lumped-capacitance thermal model.

In case the user wants to specify the weather data exactly, the following Object parameters are required: