Aliakbar Kamari, Carl Peter Leslie Schultz and Poul Henning Kirkegaard Department of Engineering, Aarhus University
3 CASE STUDY – RESIDENTIAL DANISH BUILDINGS In this section we present a case study where we
Scenarios are generated by selecting action tree nodes. E.g.
to select node t0_n0_n0 we could assert the following fact:
select(t0_n0_n0).
Rather than referring explicitly to the node ID we can select nodes based on their aspects, e.g. select node N with a subject “HVAC_systems”:
select(N) :- subject(N, _, “HVAC_systems”).
Words beginning with capital letters (and not in string quotes) are ASP variables, and the underscore “_” indicates variables whose values we do not care about. ASP will find all node IDs that satisfy this rule (i.e. substituting the N variable with valid terms such as t0_n0_n0) and deduce the corresponding select facts. Similarly we can generate scenarios that necessarily do not renovate HVAC systems by adding a constraint:
:- subject(N, _, “HVAC_systems”), select(N).
..or more generally, we can constrain scenarios to not renovate any mechanical elements:
:- subject(N, "mechanical_elements", _), select(N).
These rules can be complex logical expressions giving us significant flexibility and control over the types of scenarios that are generated. Importantly, we can use constraints to easily define rich renovation typologies. E.g. we might define a typology that represents minor renovation requiring that windows are renovated and that mechanical elements are not renovated:
select(N) :- typology(minor_renovation),
subject(N, “architectural_elements”, “windows”).
:- typology(minor_renovation),
subject(N, "mechanical_elements", _), select(N).
To select this typology in scenario generation we then simply assert the fact:
typology(minor_renovation).
For our case study in Section 3 we have formalized and implemented the Horizon2020 NeZBR [23] renovation typology framework.
Our domain rules that implement action trees include:
(a) “if a node is selected then its parent must be selected”:
select(N1) :- select(N2), parent(N1,N2).
(b) “for each selected node N1, if N1 is an xor-node then exactly one child must be selected”:
1{select(N2) : parent(N1, N2)}1 :-
select(N1), node_type(N1, xor), parent(N1,_).
the corresponding ASP code is automatically generated by our internal parsers.
(c) “for each selected node N1, if N1 is an and-node with a child N2 then N2 must be selected”:
select(N2) :- select(N1),node_type(N1,and),parent(N1,N2).
Generating Optimal Scenarios. We assign valuations to facts that can order scenarios with respect to individual KPIs without needing to compute the precise KPI values. In this manner we can rapidly generate optimal scenarios that lie on the pareto front [19], i.e. by pruning scenarios that are dominated by other scenarios, thus significantly reducing the search space.
For example, to minimize energy efficiency we need to minimize a u-value attribute assigned to various features.
Single glazing windows necessarily have a higher u-value than double and triple glazing, and thus if all other aspects remain constant (such as window area) then we can order scenarios with respect to energy efficiency and glazing without deriving the exact u-value or computing the final energy efficiency KPI. E.g. the following rules expresses that if a scenario includes triple glazing for windows then the scenario gains a u-value attribute cost of 10:
attribute(“u_value”, N2, 10) :-
subject(N, "architectural_elements", “window”), ancestor(N,N2),
feature(N2, “glazing”, “triple”), select(N2).
We then ask the ASP reasoning engine to not only find consistent scenarios, but scenarios that minimize this cumulative attribute cost:
#minimize{Cost,“u_value”,N :attribute(“u_value”,N,Cost)}.
We can minimize multiple attributes simultaneously; ASP will return dominating scenarios on the pareto front.
Moreover, because the ASP search seamlessly incorporates constraints we can rapidly generate optimal diverse scenarios by optionally applying various combinations of renovation constraints and typologies. Once we have generated a set of optimal diverse scenarios, we then compute their precise KPI values using more computationally intensive simulators. Currently we are using the ICEbear simulator.
3 CASE STUDY – RESIDENTIAL DANISH BUILDINGS In this section we present a case study where we empirically evaluate our system by applying it to real renovation tasks for a large residential building case in Denmark. The scenarios are built on the basis of different typologies, primarily related to the renovation depths and level of interventions that illustrate the impact of different ambition levels regarding the European environment and economy [3, 23]. The second level of typologies link to the typologies of the existing building according to [22].
Likewise, the third level of typologies target the architectural aspects and the appearance of the renovation scenario [2], especially related to the buildings’ facades.
Typologies for Renovation Depth / Intervention. The depth of renovation refers to the extent and size of measures applied as well as level of resulting energy and emissions
reduction. It is used to generate scenarios with various depths of renovation including Minor, Moderate, Deep, and Nearly Zero Energy (NZEB) [23]. The Minor is the least ambitious and represents renovation of only the exterior walls and windows. The second is Moderate that denotes basic interventions but, at the same time, tends to be a complete renovation, including the three types of energy efficient solutions (passive, active and Renewable Energy Sources - RES solutions). The next renovation level named Deep Renovation is more ambitious than the previous two and it is aligned with renovation of the building envelope and interior elements, which has a significant result in saving Energy. Finally, the last one is the most ambitious intervention representing a NZEB Renovation and it is in line with significant use of the Renewable Energy Sources in the renovation scenario.
Existing Buildings. Typology of the existing buildings encompasses the actual conditions of the existing buildings, which are different from project to project in connection to the location and climate regions, construction class, buildings operations, building’s type and size classes, and their Heat Supply System, see [22].
Architectural Aspects. Architectural aspects are related to the typology of the façades, in connection to the major elements of the building facades. It refers to selection of the final finish material on the façade (i.e. Brick, Concrete, Wood etc.), size of the windows, add or refurbish the balconies, and also use of the sun control and shadings devices (overhangs) on the façade.
Table 1 lists the statistics of the number of concepts we defined using our action tree language, based on the above typologies. We defined 12 subjects (i.e. 12 action trees), each with a feature value count ranging from 4 to 51 values.
This resulted in the number of mutually exclusive actions per subject ranging from 4 to 10.8 million actions. The very large number of actions is due to the combinatorial character of features, i.e. introducing a new feature type with just two values can double the number of actions (when those feature values are compatible with all combinations of previously defined feature values). We then assigned attributes of production cost and u-value to feature values, ranging from 4 to 24 assigned values per subject.
The size of the scenario search space that results from these actions trees is enormous. A renovation scenario consists of, at most, one action per subject. Thus, the number of scenarios where only exterior walls are renovated is 933,120 according to Table 1. The number of renovation scenarios where every subject is renovated is calculated by multiplying the number of all action counts, i.e. approximately 3.6 x 1042. The complete scenario search space is much larger still, because not every subject is necessarily renovated, and thus we first need to count all combinations of 12 subjects, and then for each combination
of subjects multiply the number of actions of each selected subject.
Subject Number of
Feature Values Number of
Actions Number of Attributes
Table 1. Statistics of the action trees defined for the empirical evaluation of the Danish residential case study.
By using ASP we provide a mechanism to not only search through this enormous search space for optimal scenarios, but can readily incorporate constraints that refine the desired scenarios, e.g. forcing window material to be uPVC or only considering scenarios with total production costs below a given threshold.
3.1 KPIs for evaluation
Table 2 summarizes the evaluating KPIs for generated renovation scenarios in this study. We use an extended version of the hourly dynamic simulation tool ICEbear [20]
to simulate the generating renovation scenarios for the listed KPIs in Table 2. ICEbear is a tool that strives to facilitate design buildings for architects and engineers, evaluating the impact of the geometry on the indoor climate and energy demand at the same time. It is based upon algorithms for auto-generating hourly building performance data at a room level basis.
KPIs Evaluation
Energy consumption kWh/m2/year [less better]
Energy frames defined in BR18 (Danish building regulation 2018)
kWh/m2/year [less better]
Indoor Thermal Comfort % in Class I, II, III according to EN 15251 [bigger better]
Discomfort hours above 27
and 28 (°C) Number of hours [less better]
Indoor Air Quality % out of Class III according to EN 15251 [less better]
Investment Cost Price of the procurement in DKK (Danish Krone) [less better]
DF (daylight factor) 0<DF<5 [bigger better]
Daylight requirements
acco. to BR18 % > = 10 [bigger better]
View-out quality % of openings area on façade regarding adjacent buildings [client dependent]
Degree of privacy % of openings area on façade
regarding adjacent buildings [client dependent]
Degree of Satisfaction % regarding indoor thermal comfort & air quality [bigger better]
Health & Well-being % regarding Energy
improvement, indoor thermal comfort, air quality and their effects on Asthma, Allergy, and Eczema diseases [bigger better]
Table 2. Outline for the selecting criteria for evaluation of holistic renovation scenarios
3.2 Case Study Description
The selected case study is the renovation of a dwelling apartment block located in Aarhus, Denmark. The apartment block is a part of a dwelling area (see Figure 4) consisting of 27 identical apartment blocks built in 1967–
1970. The blocks and common areas went through a renovation in the period of February 2014 to September 2017. The renovation included a refurbishment of all apartment blocks, new terraced houses, and common areas.
The blocks were renovated in different styles, so they became a unit of two similar blocks. The façade types are, respectively, concrete/wood combination, and natural slate and zinc/aluminum/wood combination. The budget for the renovation of the blocks was estimated at 880 Mio. DKK.
Figure 4. The dwelling area located in Aarhus, Denmark Each apartment block consists of 32 unit apartments with similar layout, total heated floor area of 2700 m2, 340 doors, and 129 windows. Prior to performance simulations of the generating renovation scenarios, the apartment block is separated into six different types of units (as demonstrated in Figure 5), as some units are placed on different floors as well as at the gables of the block and thereby have a larger exterior wall area or roof.
Table 3 provides the surface area and u-values for walls, floor, and roof of the existing apartment. These data related to the existing condition of the renovation project are used as the required input to ICEbear [20] to simulate the energy consumption and evaluate the thermal indoor comfort.
Figure 5. Placement of the unit types (the elevation view) Unit 1 Floor Roof Windows Walls Area (m) 83.74 85.64 21.95 27.54
u-value 0.66 0.41 2.97 0.60
g-value - - 0.55 -
glass LT - - 0.65 -
frame width - - 0.06 -
frame spacer
U - - 0.03 -
window loss - - 0.06 -
Table 3. The ‘unit 1’ apartment with coherent areas and attributes 3.3 Empirical Evaluation Results
For the empirical evaluation we defined 8 cases presented in Table 4. These cases correspond to realistic scenario typologies that clients and architects deem to be plausible in the context of Danish residential renovation. We defined all categories of the NeZeR renovation depth typologies, however in the Danish context only moderate renovation depth is realistic and thus we focused on this for cases 1-5.
For each case we generated 10 optimal scenarios using ASP, and then evaluated these 10 scenarios using ICEbear to get the exact KPI valuation (see Table 5).2 The results show that this integration is highly effective and practical for semantic querying and constrained search (i.e. scenario generation with ASP) thus facilitating more effective renovation design support. The run-time for generating and evaluating 10 scenarios with a combination of typology constraints is approximately 9 seconds, with ~30% of run-time on ASP and ~70% on ICEbear.
To demonstrate the scalability of our approach with respect to semantic querying and constrained-search (i.e. before exact KPI evaluation) we ran a second round of experiments where we generated 1000 scenarios for each case. As presented in Table 6, run-time ranged between approximately 5-7 seconds per case.
2 Experiments were run on an Intel Xeon(R) CPU E5-2620 v4 desktop computer running Windows 10, with 64 GB RAM and 2.10 GHz 2.10 GHz (2) processors
Case Illustration Description 1
Moderate, Replace, (1 side) Masonry façade-Brick, Small-scale window, with balcony + overhang, flat roof, non-ground floor
2
Moderate, Refurbish, (1 side) Masonry façade-Concrete, Large scale window, with balcony + overhang, flat roof, non-ground floor
3
Moderate, Replace, (2 side) Masonry façade-Architect panels, Small scale window, with overhang, flat roof, non-ground floor
4 Moderate, Replace, (1 side) Glass
façade, with balcony as volume addition, flat roof, non-ground floor
5
Moderate, Refurbish, (2 side) Glass + Masonry façade-Concrete, Small-scale window, with balcony as volume addition + overhang, flat roof, non-ground floor
6
Minor, Replace, (1 side) Masonry façade-Brick, Small-scale window, with balcony, flat roof, non-ground floor
7
Deep, Replace, (1 side) Masonry façade-Concrete, Large scale window, with balcony as volume addition + overhang, flat roof, non-ground floor
8 NZEB, Replace, (2 side) Glass
façade, with balcony + overhang, flat roof, non-ground floor
Table 4. Cases used in the empirical evaluation.