1. Introduction
Energy simulations are an essential means of support for building-correlated actions and relate to the whole life of a building, from preliminary design to day-to-day building operations and end of life procedures. The background for this paper focuses on the use of hourly dynamic simulations at early design and operational stages to support building energy performance-related choices and/or evaluations.
EnergyPlus [
1], along with TRNSYS [
2], is one of the most common simulation tools used in the building sustainability domain to execute performance-driven energy analyses and optimization. EnergyPlus is free and open-source simulation software that works with multiple operating systems (guaranteeing cross-platform functionality) and is funded by the U.S. Department of Energy (DOE). The program has a console, and I/O are based on text files, providing many possibilities for integration and expansions. Particularly, *.idf files are used to define the building model and are based on a dictionary structure described in detail in the *.idd file associated with each software release; moreover, *.epw files contain weather information for an annual period. Several graphical interfaces have been developed to support professionals during EnergyPlus usage [
3,
4]. Among them, one can mention OpenStudio [
5], an open-source software development kit which is also funded by DOE, and DesignBuilder [
6], which is a commercial interface. Both programs are periodically updated and have multiple functionalities.
In addition to the possibilities given by the base functions of the EnergyPlus interface (geometry modelling, model visualization, simulation runs and output analyses), several projects expanded the usage of the software thanks to the development of specific interface functionalities and modules. For example, some versions of DesignBuilder allow one to consider costs, perform optimizations with chosen parameters and support CFD (computational fluid dynamic) simulations. Similarly, OpenStudio has a large set of functionalities, allowing one to largely increase the list of possible outputs and functions thanks to additional measures, e.g., to support parametric analyses—see examples reported in [
7].
Additionally, devoted tools are available to support sensitivity or parametric analyses and optimization. These may be based on graphical user interfaces (GUIs), such as jEPlus [
8] and the standard EnergyPlus IDF-Editor [
1], or scripting, such as EPPy [
9] and BESOS [
10], which is based on EPPy for *.idf handling. In particular, EnergyPlus IDF-Editor is the reference interface of EnergyPlus and allows one to modify an *.idf manually by knowing its internal structure.
JEPlus is a free open-source Java cross-platform allowing manual editing of *.idf files thanks to the possibility of assigning tags to fields that are intended to be modified. Unlike the tool proposed here, jEPlus does not support pre-defined actions, requiring the manual identification of the variables needed and a deep knowledge of the *.idf file structure, which can be rather variable, depending on the specific building model. Sample applications may be found in the literature, such as the sensitivity analysis on ventilative cooling indicators introduced in [
11].
Focusing on coding tools, the interest in developing EnergyPlus based tools to perform optimizations was underlined in recent publications. E.g., in [
12] a new application (EplusLauncher API) was described that is able to run EnergyPlus simulations and to potentially support some input changes and facilitate output analyses. Nevertheless, controlled parameters are limited to simulation running periods and temperature setpoints for all thermal zones because of the MATLAB
® code.
A previous method using MATLAB
® to perform parametric changes in EnergyPlus input files was developed in [
13] to optimize roof shapes, and the same approach was adopted to perform a large set of simulations to analyze the direct evaporative cooling potential in the Mediterranean Basin, supporting a sensitivity analysis [
14]. Although this approach is very innovative, changes in the EnergyPlus input file are performed by manually modifying the code to change different *.idf lines. Manual changes of EnergyPlus *.idf lines were also performed in previous works based on Python, supporting parametric changes of simple parameters identified by line-to-line comparisons—see the analyses on energy needs reported in [
15] combining ventilative cooling and building insulation levels—or by adopting the above-mentioned EPPy library—see, for example, ref. [
16] concerning the optimization of window-to-wall ratios in buildings.
Focusing on existing scripting-based tools, the BESOS platform (Building and Energy Systems Optimization and Surrogate-modelling) supports professionals who are developing more sustainable buildings [
17]. The platform merges EnergyPlus and EnergyHub software and can support optimization by performing parametric simulations to feed machine learning (ML) models. It also integrates different existing optimization algorithms and ML surrogate models—see, for example, BESOS correlated applications [
18,
19]. The BESOS approach is mainly based on Jupyter Notebooks; Web documents organized in cells featuring Python code; live running and visualization. It is hosted on a customized JupyterHub platform, which allows one to create scripts in order to define which *.idf fields vary parametrically, run simulations and analyze the results.
This paper introduces a new (under development) Python tool that is able to perform automatic editing and parallel runs of dynamic building energy simulations based on EnergyPlus™, supporting parametric and sensitivity analyses for different purposes. Differently from previous tools, the proposed tool aims to fill the need for simplified and more intensive *.idf file editing without requiring any user competencies in programming, as is required by other tools such as BESOS, or knowledge of file formats, as is required when working with JEPlus, EPPy or EnergyPlus IDF-Editor. Considering these limitations and that existing tools for *.idf editing are mainly based on making feasible value changes of specific building characteristics (material thickness or conductivity changes, orientation degree, etc.), more massive parametric analyses have been precluded. Indeed, the main use cases (retrofitting, design choices, free-running optimization, model verification with respect to real cases) have been impeded due to the time-wasting manual creation of multiple initial building models to feed the simulations. The proposed tool is also able to support large geo-climatic analyses while reducing simulation time and preparation time (no need to manually feed models and elaborate outputs for KPI calculations, as there is in traditional EnergyPlus graphical interfaces).
The proposed tool also includes graphical output analyses and the possibility to compute a large list of key performance indicators (KPIs), and other ones are being considered. Despite EnergyPlus already providing the possibility to compute a very large set of KPIs according to both US and European norms, a structured way of applying the same KPI computation methodology to both simulated results and data from the field is not common in the literature. Additionally, the tool is conceived to support free-running usage for buildings (potential, exploitation, controlling actions), and other functionalities, such as including buildings without mechanical systems (especially cooling ones)—e.g., historical and traditional Mediterranean buildings—in a dynamic labelling approach. Moreover, the tool also works as a library so that expert users can exploit the already present classes and methods to create different sets of code with their own approaches and expand the potentialities of the tool.
Objectives and Structure
This paper introduces the initial architecture of a new Python-based tool which is able to script existing EnergyPlus input files, support sensitivity analysis, elaborate outputs and calculate KPIs (e.g., thermal comfort, indoor air quality, free-running potential, ventilative cooling), manage parallel simulation runs with an asynchronous multiprocessing approach and support the integration of extra modules. The tool, which is named PREDYCE (Python Realtime Energy DYnamics and Climate Evaluation), was/is being developed in two stages (development actions): (i) the “DYCE” action, and (ii) the “PRE” action.
In particular, the “DYCE” action included the definition of the initial tool structure, the development of a set of methods to modify EnergyPlus inputs according to a specific action list and the addition of calculation methods for KPIs connected to building design and post-operational data elaboration. Differently, the “PRE” action includes a set of extra scripting actions, including advanced functionalities—e.g., EnergyPlus-calculated natural ventilation, the possibility of scripting the simulation flow by integrating energy management system (EMS) objects to simulate control choices and running simulations on forecasted data to maximize free-running building potential; and developing user suggestions. In this second development action, more KPIs (e.g., climate correlated analyses and climate change resilience) and extra functions to support optimization actions (e.g., to maximize the exploitation of local free-running potential) will be added. The proposed tool also includes extra components to compile EnergyPlus weather files (*.epw) and functional actions to compare measured and simulated data. This paper focuses on the “DYCE” part of the tool, describing its main structure.
Hence, the paper’s main objectives are:
- A.
To introduce the new tool, PREDYCE, supporting Python scripting for EnergyPlus runs and output elaborations focusing on the “DYCE” part of the tool.
- B.
To show simple examples of use of “DYCE” functionalities of the tool, demonstrating the tool’s capabilities in typical use cases of parametric building analysis.
This last objective is composed of three more specific objectives:
To report an experiment involving a series of EnergyPlus input coding actions using a built-in JSON approach to test retrofitting functionalities (i.e., add insulation, change insulation thickness and substitute windows) on a mechanically heated and cooled sample building, and generating regression curves connecting variations in design inputs with changes in retrieved energy needs—early design steps.
Report on a series of simulations of the same building with the same typical meteorological data (TMY) but focusing on free-running during the summer season alone. For this, simulations were performed in a second climate as well, to analyze results in a hotter area. During this test, automatic output elaboration was performed to calculate adaptive thermal comfort KPIs and to represent results using intuitive graphical outputs generated via the Python tool—early design steps.
Report on a series of simulations of one of the E-DYCE demo buildings that involved automatically feeding EnergyPlus with measured weather data and automatically comparing simulation results with monitored data retrieved by sensors—operational steps.
These three specific objectives allowed us to test the initial version of the proposed tool for basic “DYCE” functionalities considering a mechanical building scenario, a free-running summer building scenario and an simple operational scenario.
Considering the mentioned objectives, the paper is organized as follows: (i) An overview of existing state-of-the-art tools able to modify EnergyPlus input files and/or to support manual or automatic parametric simulations—see
Section 1. (ii) A materials and methods section introducing the general architecture of the tool and detailing the initial “DYCE” modules and functionalities—see
Section 2.1 (Ob. A). (iii) Descriptions of the three testing scenarios, including adopted actions and parameter variations—see
Section 2.2 (Ob. B). (iv) A section reporting and discussing the mentioned examples of use, including limitations, focalized on the outputs of the scenarios—see
Section 3 (Ob. B.a, B.b and B.c). (v) A section devoted to conclusions and future development phases—see
Section 4.
3. Examples of Use and Discussion
This section describes and discusses the three mentioned testing scenarios.
3.1. Scenario A
For Scenario A, the proposed tool was used to run a sensitivity analysis, allowing us to compare the impacts of different retrofitting choices regarding energy needs for the specific building under a Torre Pellice TMY. About 500 simulations were run for this purpose, thereby automatically generating 500 different *.idf files which differ from the base one not only in the changes of thickness values but also by the presence of new material layers which have impacts on geometry. A unique output *.csv file containing aggregated results was then used to perform classic post-analysis comparisons.
Figure 4 shows correlations between wall insulation thickness and annual energy needs for different roof insulation levels. When increasing the boundary walls’ insulation thickness, a reduction in energy needs occurred, and as expected, the first 10–15 cm of insulation had the greatest impact. More roof insulation allows for extra reductions in energy needs. Similarly,
Figure 4b analyses the impacts of wall and roof insulation thicknesses when windows are triple glazed. In the latter case, a slight reduction in net energy needs is clear due to lower U-value of triple-glazed windows.
Figure 5 shows 1D and 2D energy signatures for the best case in terms of net energy needs. For the considered case, the impact of weekly averaged global solar irradiation (not considering the nights) was very low with respect to outdoor temperature; similar results were retrieved in other studies in cold climates [
35]. Additionally, since the demo case is located in a mountainous area, the cooling system’s contribution to the net annual energy needs is not relevant. As mentioned above, the KPI module allows one to calculate KPIs with simulated data or other data, including monitored data. Focusing on the energy signature, this KPI supports data-driven building-energy-use models that account for the influences of outdoor conditions on heat consumption, to allow fast heating responses—see, for example, studies on data-driven model definitions [
36,
37]—but also will allow comparing design-driven signatures with monitored ones.
3.2. Scenario B
In the summer free-running mode scenario, the impacts of different technologies were analyzed on the demo building in both a cold (Torre Pellice) and a hot (Casaccia) Italian climate, resulting in about 1600 simulations. The weather file was used as a parameter in the specific parametric set adopted for this example.
Figure 6, for example, shows the linear impacts the adopted free-running technologies have on thermal comfort. In the colder Torre Pellice climate, the reduction of the overhang length in order to increase direct solar gains had a strong impact on reducing the number of hours in adaptive comfort category II or III, considering the bottom boundaries causing a shift to upper categories. I.e., for Torre Pellice, overhang length had the highest impact on category III (0.77), decreasing discomfort (too cold). In parallel, raising the outdoor temperature threshold (so almost never activating the shading) also led to a benefit. Instead, in the hotter Rome climate, increasing the ventilation and reducing the outdoor temperature threshold provided thermal comfort benefits in terms of point distribution in adaptive comfort model categories. For example, the increase in airflow supported a growth in hours in the comfort category I (+0.86) and a reduction in hours above a suitable temperature in categories II (−0.82), III (−0.69) and III (−0.25). This type of statistical heatmap analyses allows one to study correlations between design aspects and KPIs, while considering single and combined technologies, helping designers to find optimal early design choices or to understand the impacts that a choice may have on the building. The proposed tool performs this design support action thanks to the automatic generation and running of multiple massive simulations.
Figure 7 and
Figure 8 show in greater detail the impact of the roller shades’ activation strategy on thermal discomfort. We varied ACH and averaged on results obtained with different overhang lengths. For this test, scheduled natural ventilation was assumed in order to support early design analyses for the climate potential of ventilative cooling; nevertheless, the proposed tool also allows one to include calculated natural ventilation when needed. ACH variations support, in early design stages, different control strategies using openings for natural ventilation, which can be further detailed in advanced design stages—see [
38]—but may also represent the airflows to be contributed by a detached mechanical ventilation system. Considering Torre Pellice,
Figure 7 shows that ACM discomfort and POR (based on PMV) have opposite behaviors. This suggests, as expected, that the PMV-PPD model is more sensitive to uncomfortable hot perception, possibly accentuated by having the value closet to 1, despite the shift of hours from lower to higher adaptive comfort model categories. For Rome,
Figure 8, the two indicators show the same behavior, being positively impacted by low solar irradiation and temperature thresholds.
Figure 9 and
Figure 10 show the impact of overhang length on thermal discomfort, considering optimized values of shading control thresholds. The opposite behaviors of POR and ACM discomfort were again evident for the case of Torre Pellice. In Rome, with higher ACH values, the impact of overhang was less relevant, causing a slight increase in discomfort even.
Figure 11 shows how an optimized combination of free-running technologies allowed us to slightly warm up the house in summer in the mountainous area, and
Figure 12 shows the more interesting opposite behavior in a hotter climate, where optimized strategies allowed us to maintain indoor operative temperatures almost entirely inside adaptive comfort model category II without the need for a mechanical cooling system.
3.3. Scenario C
Figure 13 shows the simulated base model and the monitored indoor air temperatures, considering the same period of time and the same monitored weather data: the errors on the model correspond to a RMSE equal to 0.670 and an MBE equal to 0.342 for indoor air temperature. A semi-automatic verification process was performed to adjust the building model to fit data measured in June 2021—see the description in
Section 2.2. Optimized values of RMSE equal to 0.486 and MBE equal to −0.02 were then obtained, and
Figure 14a shows the calibration signature for the best case.
Figure 14b shows the distribution of measured indoor temperatures versus simulated ones in the best case: higher temperatures were better verified, whereas middle and lower ones clearly shifted, even if the calibration signature errors did not exceed 5%. Further optimization is expected during the next implementation phases of the verification part of the code.
Figure 15 instead shows optimized simulated and measured indoor temperatures over the period of time considered in the verification process. At the end of the month, it is possible to identify some days in which the simulated and monitored error gets larger, especially during hourly peaks, but it is known that those days correspond to a vacation period for the tenant, resulting in lower thermal gains in the monitored data (simulation occupancy and gains are not changed).
3.4. Discussion and Limitations
The auto-generated pool of simulations and the automatic result aggregation approach of the proposed tool allow one to easily run large sensitivity analyses that include modifications to several building and control system parameters.
At present, uses such as model verification or retrofitting require simple but detailed setups by a user, who must manually select tasks, parameters and actions to be performed in order to achieve the desired workflow and final results compiled in an input *.json file. Nevertheless, alongside the possibility of selecting specific features or combinations of features and KPIs, future usage scenarios are expected to be developed. A usage scenario is a pre-defined set of changes in the *.idf input and output KPIs that can be identified by users by a sole name (e.g., retrofit) instead of mentioning all actions (change insulation thickness, change window, etc.).
Regarding the performance, the time it took to run 500 annual simulations (including model editing, post-processing and KPI calculations) of Scenario A on a modern desktop PC (AMD Ryzen™ 7 2700X Processor) was about 5 h; 1600 summer simulations of Scenario B on a high-end server (AMD EPYC™ 7662 Processor) took about 30 min; Scenario C, which consisted of the multi-step model verification task, took about 10 min on the same server as well. For a better understanding of such benchmarks, it has to be considered that manually performing small building editing could take up to three minutes; executing every simulation one by one and comparing the results to find the best case could take up to 6 h with 150 simulations. Similarly, if we consider performing the same 150 simulations by manually changing inputs, running simulations, collecting and analyzing results, e.g., in excel, about 50 h is to be expected (20 min each). The approach offered by the proposed tool, of automatically creating and running all different buildings given the initial instructions, can reduce the working time to 20 min when using a modern high-end laptop (11th Generation Intel® Core™ i7 Processor) or even to 2 min when using a dedicated server (AMD EPYC™ 7662 Processor).
The adoption of more advanced optimization algorithms in order to reduce the number of simulations to reach the optimum will be implemented in the near future. Finally, the development of an extra functionality to pass from net to primary and source energy consumptions considering dynamic COP (coefficient of performance) is expected, in line with hourly EU standards for energy performance certification (EPC).
4. Conclusions
This paper introduced a new Python-based tool able to edit EnergyPlus inputs, manage a large set of simulations and support KPI calculations for different purposes and usage scenarios. The new tool, PREDYCE, was briefly described, and the initial functionalities were tested on a demo case of the EU H2020 project E-DYCE, which was represented by a single residential unit in a terraced house. The tool is based on three main modules: an input editor, a runner and a KPI calculator. Extra modules are under development, e.g., to support measured data actions. We intend for this tool to be used with not only user-built lists of inputs and outputs, but also to simulate pre-built scenarios (e.g., model verification, sensitivity analyses, operational suggestions and free-running potential), based on pre-created input *.json files that may be recalled via a future graphical interface. These potentialities will be the core of the following months’ expansions.
Moreover, this paper reported the outputs of the first successful simulations (testing scenarios). Scenario A demonstrated that the proposed tool includes actions able to support early design retrofit analysis, and that it may calculate simple energy performance indicators in a graphical form. Scenario B showed the potentialities of the tool for supporting free-running mode optimization, especially for summer, including some devoted KPIs and analyses. Scenario C demonstrated the potentialities of integrating both weather and environmental monitoring data for model verification and operative purposes in the data analysis pipeline. Currently, the proposed tool allows one to compare different retrofitting scenarios by building simulations to identify energy optima; nevertheless, a comprehensive approach including economic analyses is under development to align the development of the retrofitting scenario with global cost (EN 15459-1:2017 [
39]) and the cost optimal vision—see, for example, the approach in [
40,
41].
The main functionalities of the tool are in place, and during the next two years, it will be further tested in applications on a large set of demo cases based in Europe, and it will be used to support and test design methodologies and suggestions. These testing and application phases are expected to support the definition of additional actions and KPIs; the development of an API launching interface so remote users and third party servers can control the tool; the definitions of simple action combinations in scenarios; and the inclusion of extra functionalities, i.e., supporting prescient building optimizations and analyzing free-running potential exploitations. Two application development lines will be focused on: the first—supporting design choices and optimization; and the other—supporting operational choices and control evaluations. Additionally, extra functionalities, such as climate change impacts on the geo-climatic applicability of low-energy technologies, will be added in the “PRE” developing action [
42].