A Performance Evaluation of the BIM-Based Object-Oriented Physical Modeling Technique for Building Thermal Simulations: A Comparative Case Study

Abstract

The development of separate building performance simulation tools has brought about a significant need for the integration of multi-domain simulations that would enable multiple building performance analyses to be conducted from a single building model. Insufficient data integration between the tools and Building Information Modeling (BIM) currently prevents the efficient production of comprehensive building performance analyses. To overcome this problem, a multi-domain simulation tool, effective and efficient data, and a process integration methodology are all required. Object-Oriented Physical Modeling (OOPM) has emerged as a form of object-oriented modeling capable of supporting multiple domain simulations. Adoption of OOPM into building performance simulations with BIM is particularly interesting as a means of facilitating model translations between BIM and BEM (Building Energy Modeling). Specifically, complex data translation from the building topology in BIM to the space boundary conditions in BEM is both labor intensive and time consuming. This research uses case studies to investigate the feasibility of automatically translating a building topology from BIM to OOPM-based BEM. We included numerous preconditions in order to incorporate various object semantic differences into each model translation. Our research indicates that this adoption approach allows seamless model translations from BIM to OOPM-based BEM, which supports efficient and effective thermal simulations and facilitates the reuse of BIM data in multi-domain simulations.

1. Introduction

Buildings are responsible for 40% of the primary energy use in the United States [1] and the European Union [2], 36% of greenhouse gas emissions [3], and one-third of the world’s energy [4]. In addition, energy demands such as electric power and heat in the building sector have continuously increased at a rate much higher than in any other energy consumer sector [5,6]. Recent research has focused primarily on reducing greenhouse gas emissions by using sustainable forms such as solar energy and emerging technologies like Building Information Modeling (BIM) for integration into buildings [7,8,9].

The major issue with the implementation of sustainable technologies into building designs is how to effectively integrate different technologies that exist across multiple domains into a single combined system, and provide comprehensive building performance analyses from this integrated system to the building design process. For instance, the main concern with solar building design is how to integrate different technologies (e.g., building-integrated photovoltaic, solar thermal, and daylighting) into a combination of systems [10] and effectively simulate those diverse technologies to provide building performance analyses during the design phase. Thus, a holistic and integrated approach to sustainable design is needed to efficiently provide energy performance analyses based upon multiple domain simulations and in the early design phase. Such an integrated building performance simulation analysis would require the integration of multi-domain simulations to enable the completion of a building performance analysis with a single building model.

In addition, many building performance simulation (BPS) tools designed to support stakeholders’ decision-making during a building’s life cycle have evolved separately from one another. These BPS tools allow design professionals and practitioners to analyze and evaluate their building projects. Traditionally, architects and engineers have found it difficult to effectively use BPS tools because their processes are based on 2D manually-created drawings. This characteristic is necessitated by the lack of integration among the tools and between design models and building energy models. In addition, in order to provide comprehensive analyses during the design phase from a single design model, discrete analysis models must be created to fit each kind of simulation. For example, a thermal energy model considers the simplified geometry and thermal materials information in a design model; however, a daylighting simulation model requires complicated geometric building information and materials properties, including glazing transmittances.

In recent years, BIM-based BPS tools have emerged to facilitate the integration of building performance simulations into the design phase [11]. BIM-based BPS tools allow for the direct reuse of building design information to create building energy models, which eliminates redundant processes such as re-entering the building’s geometric information from the design model. While these tools have been developed to facilitate the energy model generation processes through BIM, separate analysis models still need to be prepared to satisfy each simulation engine. Moreover, while a BIM-based energy model creation tool can simplify the energy model creation process, reliable energy model creation is still labor intensive, time consuming, and error prone [12]. In this context, in order to efficiently provide comprehensive building performance analyses from a single BIM model, the integration of multi-domain simulations is necessary and a seamless model translation between BIM and multi-domain simulations must be achieved.

The Object-Oriented Modeling (OOM) approach has been studied as a possible means of supporting efficient multi-domain simulations [13]. Specifically, the Object-Oriented Physical Modeling (OOPM) methodology has emerged, which uses OOM to provide an equation-based and structured modeling system for multiple domain simulations [14]. The OOPM technique has been used in complex physical systems modeling and simulations in diverse areas such as mechanical, thermal, and control system domains.

In this research, we demonstrate our previous work in adopting an OOPM approach to BIM integration with building performance simulations, a process that facilitates multiple domain simulations from a single BIM model. We describe our previous work such as developing an interface, a data model, a physical library, a framework, and algorithm for translating building topology in the following section. Then, we present our findings regarding the feasibility of automatic building topology translations between BIM and OOPM-based building energy models; these findings stem directly from our case study research on five distinct building envelopes. We evaluated the building topology translations and developed an interface to connect BIM to an OOPM-based thermal energy simulation through the test cases focusing on the accurate data translation for building topology translations to create OOPM-based building energy models. Also, we validated the building topology translations and created OOPM-based building energy models using BIM model data by energy simulation results comparisons. We included miscellaneous preconditions in order to take account of the various semantic differences in model translation.

2. Background and Problems

2.1. Existing Building Performance Analysis Tools

Most of the current building performance analysis tools have been used to support decision making for energy efficient buildings [15]. While the DOE website lists over four hundred building performance analysis tools, not more than forty were modified for architects to use during the early design stage [16]. Moreover, only a few of those tools are commonly used in the industry and education [16,17,18,19]. eQuest [20], Energy-10 [21], CONTAM [22], and Radiance have most often been used in education [19]; however, EnergyPlus [23], Energy-10, HEED [24], and IESVE [25] have primarily been utilized in the industry [26]. Such building performance analysis tools are composed of a simulation engine used to conduct target-oriented simulations and a graphic user interface (GUI) [27,28]. The tools listed in the “Building Energy Software Tools Directory” [29] differ in terms of input, output, computer platform, and programming language used for implementation. For example, programing languages such as FORTRAN, C, and C++ have all been adopted to implement the physical processes of certain simulations in traditional building performance analysis tools such as DOE-2 [30], ESP-r [31], and EnergyPlus [13]. Test files for input and output are used to execute simulations using the DOE-2 and EnergyPlus simulation tools. Such a text file-based process is what encouraged the development of the BDL Processor for DOE-2.1E’s input and DesignBuilder, a GUI for EnergyPlus [32,33]. GUIs facilitate efficient input translation and enable practitioners and designers to reduce the amount of time spent in preparing input files [28].

However, such domain-specific engines and GUIs cannot guarantee the efficient and effective adoption of building performance simulation tools during the early design phase or a building’s life cycle due to their dependence on a wide range of simulation knowledge and comprehension of all of the building performance simulation processes [15,16,19]. Moreover, even building performance simulation professionals may find it difficult to use these tools, due to their incompatibility with their particular work process and overall level of complexity [34]. Furthermore, users must repeatedly prepare the same input information, including the building’s geometry and materials, in order to execute the multiple simulations necessary to comprehensively review a building’s performance results, because the analytical environments of the simulation engines and GUIs are not compatible.

Thus, in order to provide a more seamless integration of building performance analysis tools into the design state, these tools need: (1) the ability to seamlessly exchange data with the design model; (2) intuitive GUIs to support efficient data input and output; and (3) multi-domain simulation capability from a single building performance analysis model.

2.2. Building Information Modeling for Building Performance Analysis

BIM is used in the Architecture/Engineering/Construction (A/E/C) industry to facilitate the creation of building information and exchange that information among applications throughout a building’s life cycle. BIM is semantically-based and object-oriented; it has 3D modeling capabilities and allows users to retrieve comprehensive design model information represented by objects and their attributes through its authoring tools and standard data schemas such as IFC. In addition, BIM allows a single data model to represent multi-disciplinary information [35]. Such BIM capabilities facilitate data integration between building design and building performance simulation models.

In order to enhance data integration between building design and building performance simulation models, certain building performance simulation tools have developed BIM-based add-ins such as Green Building Studio and IESVE. While most of the interfaces facilitate building performance model creation by eliminating redundant data input, users must still create multiple simulation models to execute multi-domain simulations due to the non-integrated interfaces of the various simulation tools. Moreover, building designers and professional building performance simulators have different model translation methodologies; designers utilize BIM-based building performance simulation tools GUIs to model translations in order to create separate simulation models, but building performance simulation experts likely perform the model translations by a more traditional process [36]. To facilitate data translation between the design and building performance analysis stages, building performance simulation experts may need to adopt different modeling practices such as an object-oriented modeling approach, which enhances direct object mapping between object-based design models (BIM) and building performance simulation models.

2.3. Object-Oriented Physical Modeling

Recently, Object-Oriented Modeling (OOM) approaches have been researched to examine the ways to support efficient multi-domain simulations in order to provide comprehensive simulation results to users [13]. Especially of interest, Object-Oriented Physical Modeling (OOPM), which is based on the OOM approach, has emerged as a modeling methodology for providing equation-based and structured techniques [14]. In order to support the OOPM approach, Modelica, an object-oriented modeling language, has been developed to allow for the modeling of complex, significant, and heterogeneous physical systems [37]. Modelica enables users to represent dynamic behaviors in OOPM, including differential algebraic equations and DAE-based calculations [14]. Physically-based domains such as electrical, thermal, mechanical, and control systems have used OOPM-based modeling to demonstrate complicated physical systems. The Modelica-based OOPM approach presents a physical system’s topology in simulation models by using component-connection representation [14,38]. OOPM’s object-oriented modeling method can facilitate intuitive data mapping between BIM and OOPM.

In the following section, we will briefly explore the capabilities of existing OOPMs in diverse domains.

2.3.1. The Adaption Trend of the Modelica-Based OOPM Method in Non-Architectural Domains

The Modelica language was developed to support the modeling of hierarchical object-oriented physical systems and generalizing of previous OOM languages [38]. The Modelica language allows Modelica-based authoring tools such as Dymola [39] to automatically generate object-oriented simulation codes that facilitate model exchanges between Modelica-based OOPM models and even among Modelica libraries. In addition, Modelica-based OOPM simulation models allow multi-domain simulations within the same application model to be organized according to various model components from multiple domains such as mechanical, thermodynamic, and control systems. Such a Modelica-based OOPM simulation approach has four main features [14,38]:

• Equation-based modeling: Modelica-based OOPM models use equations instead of assigning statements. This feature enables Modelica-based OOPM to create a causal model that includes an undefined data flow direction, and therefore facilitates the reuse of created classes.
• Multi-domain modeling: Modelica-based multi-domain modeling represents and connects various physical objects from multiple domains.
• Object-oriented language: Modelica-based modeling provides an easy-to-use modeling method for developing prototypes by reusing created components.
• Software component model: Such constructs in a software component model allow for the creation and connection of components to facilitate the description of complex physical systems.

The Modelica Association [40] has created and published Modelica libraries in order to enhance the usability of Modelica. Below, we have briefly described some of the existing Modelica libraries for electrical, mechanical, and control systems.

• Modelica Standard Library [41]: The Modelica Association disseminated the Modelica standard library for free; it enables users to model electrical (including analogue, digital, and machine), mechanical (1D/3D), fluid, control system, and hierarchical-state machines (see Figure 1).
• IDEAS [42]: The IDEAS Modelica library supports the simultaneous transient simulation of electrical and thermal systems at the building and feeder levels.
• Industrial Control System [43]: The industrial Control System, an open source library, provides a series of discrete and continuous control systems (see Figure 2A). The library allows modelers to replicate and set up the majority of industrial controllers.
• Vehicle Dynamic Library [44]: The Modelon provides the Vehicle Dynamic Library as a commercial library that allows for the verification and optimization of vehicle systems designs at the early design stage. The library uses an implementation system and control design (see Figure 2B), and provides a multi-domain and entire multi-body simulation with real-time performance.

In an effort to distribute the effects of these benefits (e.g., equation-based and multi-domain models), modelers and researchers alike have adopted Modelica into these libraries by providing common model elements and terminology in order to support specific domain simulations. Modelica’s authoring tools such as Dymola [39] and OpenModelica [45] help these libraries support an integrated Modelica-based OOPM model in order to provide various simulations, solvers for specific domains, and model components to modelers.

2.3.2. Object-Oriented Physical Modeling for Building Performance Analysis

Modelica’s authoring tools allow for topological representations based on component-connection diagrams in order to support the design of the complex physical systems shown in Figure 1 and Figure 2A. The topological representations support direct matching of the structure and decomposition of the physical system’s topologies to building performance analysis models [14,38]. The need to facilitate a natural mapping between BIM and Modelica-based OOPM for building performance analysis is what inspired the development of these easy-to-use Modelica libraries [46,47]. Below, we have briefly described these libraries in terms of their use in building performance analysis:

• BuildingSystems [46,48,49]: Udk Berlin developed the BuildingSystems library as an open source for development. The library enables a modeler to model and simulate buildings and complex energy supply systems, and facilitates the transient calculations for transportation, transformation, and storage of thermal energy. The designed components and their connections in the library allow for the topological representation of simulation models.
• Modelica Buildings Library [47]: This library was developed at Lawrence Berkeley National Laboratory to support rapid prototyping and the design of building energy and control systems. The library allows modelers to conduct building performance analyses in areas such as air conditioning systems, heating and ventilation, multi-zone air flow, heat transfer between multiple zones, and contaminant transport.

2.4. Challenges in Data Translation between BIM and Modelica-Based OOPM

2.4.1. Mismatched Object Relationships and Semantics

The object-oriented modeling concept in BIM and Modelica-based BEM (Building Energy Modeling) should support intuitive and explicit data translation; however, critical issues currently block their ability to provide seamless data translation, such as mismatched object relationships and semantics. Basically, so that they correspond with the requirements of the building performance simulations, when a translation is made, the object relationships and semantics in the building design models are abstracted. For example, a building design model consists of building components including walls, floors, and roofs, whereas the components are abstracted as surfaces in a building performance simulation model so that they correspond with the heat transfer simulation. In order to achieve seamless and efficient data translation between them, consistent object semantics and classifications should be defined and implemented in both BIM and Modelica-based BEM.

2.4.2. Building Topology Translation

Generally, a certain level of abstraction from BIM models needs to be performed in the translation between BIM and BEM, due to discrepancies in the object semantics [50]. Specifically, the translation of space boundary conditions should be conducted for both BEM from BIM. However, the data translation needed to map the space boundary conditions from BIM data is a substantial activity for BEM [50]. In order to conduct the efficient and effective model translation of space boundary conditions, the following are required: the same modeling concept (such as object-oriented modeling) and a systematically implemented translation through a reliable algorithm [51].

Although the functionalities of OOPM for building performance analysis have been developed and provided as diverse libraries, future work is expected to enhance the efficient data translation, including object mapping between BIM and OOPM-based BEM. In order to utilize BIM-based OOPM BEM for building performance simulations in early design, further research works need to be conducted focusing on the development of intuitive GUIs, seamless and object-based data exchange capability, and reliable and rule-based information translation capability between BIM and OOPM-BEM.

3. Methodology

Prior to demonstrating our methodology, previous research regarding each of the procedures shown in Figure 3 was reviewed, including Yan, et al. [9], Jeong, et al. [51,52,53] and Kim, et al. [54].

• Interfacing BIM with building thermal and daylighting modeling
  Yan, et al. [9] developed system interfaces for supporting integrated BIM and BEM building thermal and daylighting simulations using a BIM application’s programming interface (API).
• Translating BIM to BEM using Model View Definition
  Jeong, et al. [52] developed a data model using a Model View Definition to support the model translation between BIM and Modelica-based BEM; they defined object mapping and the information required in the translation.
• Developing a physical BIM library for building thermal energy simulation
  Kim, et al. [54] developed a Modelica library for BIM-based building energy simulations using OOPM and the Modelica simulation language to support data model [52] implementation between BIM and Modelica-based BEM.
• A framework to integrate OOPM with BIM for building thermal simulation
  Jeong, et al. [53] demonstrated an automated framework for integrating BIM and Modelica-based BEM using BIM API and the Modelica library [54]; it simulates building energy performance and visualizes energy analysis results back into Revit, the BIM authoring tool, to provide immediate feedback to designers.
• An algorithm to translate building topology in BIM into OOPM-based BEM
  Jeong, et al. [51] created an algorithm to translate building topology in BIM into OOPM-based BEM using an object-oriented programming approach; it supports efficient object mapping of building objects in BIM into space boundary conditions in OOPM-based BEM. The implementation of the algorithm allows building topology to be translated into space boundary conditions to create an OOPM model.

Previous research has shown new methodologies for translating between BIM and OOPM-based BEM, focusing on enhancing the interoperability between two object-oriented models. In order to enhance the feasibility of the development, further work is needed to provide running data that highlight the advantages automatic BIM to OOPM-based BEM mapping can offer, such as the time that can be saved and elimination of the error-prone manual object mapping process between complex building envelope models and OOPM-based building energy models.

A case study was used to evaluate this automatic object mapping capability between building topology in BIM and space boundary conditions in OOPM-based BEM using Modelica (ModelicaBEM). Case studies, as singular “experiments,” are mostly used for theory building [55]. In order to spread an emerging theory, multiple case studies must be conducted in a series of related experiments [56]. In this context, we examined diverse test cases for this case study in order to validate the previous research, including the BIM-based ModelicaBEM framework, translation algorithm, and data model. The case studies contained three building topology translation cases and simulation results comparing the use of BIM-based ModelicaBEM models from the framework and OOPM models incorporating the LBNL Modelica Buildings library.

Next in the case study, BIM-based ModelicaBEM modeling was applied to create energy simulation models from multiple BIM models containing diverse building topologies. We adopted the BIM-to-BEM framework in Jeong, et al. [53] and the algorithm in Jeong and Son [51] for the BIM-based ModelicaBEM modeling approach. Each test case compared the simulation results of two Modelica-based OOPM models; one model was created by applying the modeling approach adopted for the evaluation, and the other was manually created by following the simulation specifications in the LBNL Modelica Buildings library. We hypothesized that if the test cases correctly represented the building topology translation in the space boundary conditions, the two Modelica-based OOPM models would generate close or at least reasonably similar simulation results. Based on the hypothesis, we verify the values of space boundary conditions in the BIM-based ModelicaBEM models by comparing with the values in the Modelica-based OOPM models. Also, we compared simulation results focusing on indoor air temperature for one year by comparing the highest and lowest temperatures between the two models in each test case. Our test case study focused on the feasibility of the automatic translation of building topology and its validation by simulation results comparison without considering specific HVAC systems, therefore, we chose the indoor air temperature value, which is basic, but one of the critical values in energy simulation results.

4. Case Study

For the case study, we conducted three test cases: a two-story building model with two windows (Test Case 1), an L-shaped building model with a window (Test Case 2), and a U-shaped building model with two windows (Test Case 3). These building models were based on the one-room model (basic building model) corresponding to the BESTEST Case 600 building, which is one of the standard ASHRAE simulation testing models used for simulation results validation. The simulation results validations for the two Modelica-based OOPM models using the BESTEST Case 600 model were already conducted [53,57].

For the test cases, we created three corresponding BIM models incorporated with the BIM authoring tool, Revit Architecture 2015, including a basic building model to represent the BESTEST Case 600 building model that was used for reference. Each test model was created to evaluate more diverse building topology translations and their simulation results validation, thus validating our hypothesis. The following sections were present for each test case: (1) building topology translation into the space boundary conditions representation in the generated BIM-based ModelicaBEM model; (2) simulation results comparisons underlining a room temperature variation without HVAC systems.

4.1. Building Topology Translation into Space Boundary Conditions

4.1.1. Reference Model Creation for the Test Cases: Creation of the Basic Building Models

For the test cases, we created three basic BIM building models: (1) the one-room model shown in Figure 4A for the BESTEST Case 600 building model, following the model description [58,59]; (2) the two-room model shown in Figure 4B; and (3) the three-room model shown in Figure 4C. From the one-room model, we created the two- and three-room models by evenly dividing the room in the one-room model; we added an interior wall and evenly divided the right room in the two-room model by adding another interior wall. The one- and three-room models are the basic models for Test Cases 1 and 2, respectively; the BIM model for Test Case 3 was created based on the one-room model and the building model in Test Case 2. Note that the validation for the building topology translations and energy simulation results comparisons of the basic models were already conducted in previous research [51,53].

4.1.2. Test Case 1: Two-Story Building Model with Two Windows

We created a BIM model based on the one-room model by adding a room (Room 2) above the room of the one-room model, as shown in Figure 5A. Room 2 consisted of four walls, a roof, and two windows (6 m²) in the south- and east-facing walls. The building components of Room 2 had the same building descriptions as the one-room model. We also added another floor between Room 2 and the lower-level room (Room 1). The floor had the same conditions as the floor component in the lower level.

Test Case 1 required a different approach from previous multiple-room building models: vertically stacked multiple rooms against horizontally-expanding multiple rooms. In BIM’s building topology, Test Case 1 represents the process of creating a new floor plan on a different level with additional building envelope components. However, in the space boundary conditions of ModelicaBEM, Test Case 1 presents a heat transfer simulation through an opaque surface between the two stories, which is similar to the heat transfer between the two rooms in the two-room model. The opaque surfaces of the interior wall in the two-room model connect the two thermal zones; however, the opaque surfaces of the floor between the two stories in Test Case 1 connect the thermal zones.

Once the developed application (see Figure 5B) for the building topology configuration was executed, it analyzed building topology to investigate which building components were shared between the rooms. In the two-room model, the command retrieved the shared building component as the wall object (Wall 181758), shown in Figure 4B. However, in the two-story building model, the command retrieved the shared building component as the floor object (Floor 189848), shown in Figure 5B, and represented the connectivity between the building components, shown in Figure 5C. The retrieval and representation of the shared building component demonstrates that the behavior of creating a new room with new building envelope components at different levels was accurately translated into the behavior of a shared slab object including two opaque surfaces between the two thermal zones in the two-story model.

According to the LBNL Buildings library specifications, the space boundary conditions for the opaque surfaces enclosing Room 2 should have been represented as specific values in the created BIM-based ModelicaBEM model shown in Figure 5D. The Floor 189848 object was identified as a shared floor between the two thermal zones; thus, one surface of the floor and the opposite surface were identified as the datConBou and surBou types, respectively. The Room 2 object consisted of two exterior walls, two walls with two windows, and one roof; therefore, the numbers of the datConExt and datConExtWin should have been 3 and 2, respectively. As shown in Figure 5D, the framework correctly represented the explicit value from the Modelica codes in the BIM-based ModelicaBEM model.

4.1.3. Test Case 2: L-Shaped Building Model with a Window

We modified the three-room building model by removing Room 3 and the corresponding building components enclosing Room 3, such as the walls, floor, and roof. In the three-room model depicted in Figure 4C, Wall 181758 and Wall 193307 are the shared walls between Rooms 1 and 3 and Room 1 and Room 2, respectively. Also, Wall 192844 is the shared wall between Rooms 2 and 3. By removing Room 3 in the three-room model, the only shared wall is Wall 193307, shown in Figure 6B. Figure 6C indicates that the command to analyze the building topology accurately retrieved the correct shared wall information, and Figure 6D shows that the represented building topology was correctly translated into the represented Modelica code through the translation framework.

Test Case 2 was similar to the two-room model, due to the elimination of Room 3 in the three-room model which, consequently, became two thermal zones. However, this test case had a building topology distinct from that of the two-room model; the walls (Wall 181758 between Room 1 and 3 and Wall 192844 between Room 2 and 3), which together are the shared wall from the three-room model, were modified from the interior walls to become the exterior walls. Once the topology conditions of the two walls are updated, the semantic of the walls to corresponding with a ModelicaBEM model, the space boundary condition for each wall needs to be updated. In other words, the transformed building topology required suitable object mapping to the space boundary conditions for ModelicaBEM model creation; thus, the value of nConExt representing the number of exterior walls except floors and roofs and nSurBou representing the number of shared walls for Room 2 needed to be increased and decreased from 3 to 4 and 2 to 1, respectively. As shown in Figure 6D, the represented Modelica code explicitly validated the translation; the final value of nConExt for Room 2 is 4 due to including the floor and roof.

4.1.4. Test Case 3: U-Shaped Building Model with Two Windows

To validate a more diverse building topology translation, we added another room in the right room object (Room 2) in Test Case 2 (see Figure 7A). The updated BIM model was similar to a U-shape and consequently consisted of three rooms. The west room (Room 1) and the middle room (Room 2) had the same dimensions as in the L-shaped model, but the east room (Room 3) had new dimensions. The Room 3 object was 4.0 m × 8.0 m × 2.7 m in length, width, and height, respectively, and had two windows of the same size as those in the one-room model; the windows were located in the east-facing wall.

The Room 3 object was comparable to that of the one-room model, except for the building’s shape and orientation. However, Test Case 3 was distinct from previous multi-room building models. The existing rooms were divided by adding interior walls instead of adding multiple rooms with additional building components. While the previous two-room, three-room, and even L-shaped model cases expanded multiple rooms by dividing the existing rooms through the installation of interior walls, Test Case 3 increased the number of rooms by adding new room objects with new building components next to the existing rooms. From the building topology point of view, Test Case 3 expanded the new room object with additional building envelope components. On the other hand, from the space boundary condition viewpoint, Test Case 3 represented a heat transfer simulation through an opaque surface between an existing thermal zone and a new thermal zone. Adding a new room object with windows to an existing building model can affect the simulation results (as compared to the L-shaped building model). We will demonstrate the differences in the following section.

The shared wall retrieval process identified the Wall 188624 object between Rooms 2 and 3 (see Figure 7B) and correctly represented its connectivity (as shown in Figure 7C). The connectivity configuration implied that the heat transfer was performed through Wall 193307, between Rooms 1 and 2, and through Wall 188624, through Rooms 2 and 3. The installation of a new exterior wall component (Wall 193740) in Room 3 enabled the interior surface of Wall 188624, which was object-oriented into Room 3, to be assigned as SurBou from datConExt (see Figure 7D3). Moreover, according to the library specifications, the interior surface of Wall 188624 object-oriented into Room 2 could be assigned as ConBou from datConExt.

These additional three test cases verify the diverse building topology translations into space boundary conditions in corresponding BIM-based ModelicaBEM models through the developed framework and implemented algorithm. The following sections demonstrate the validation of the translated BIM-based ModelicaBEM models through a comparison of their simulation results.

4.2. Simulation Results Comparisons for Each Case

We conducted thermal simulation results comparisons between BIM-based ModelicaBEM models (BIM version) and OOPM-based BEM using the LBNL Modelica Buildings library (LBNL version). The BIM version models were created through the developed framework and algorithm and the LBNL version models were modeled according to the classes and specifications of the library.

The coherent simulation and model settings were the same as those used in the previous experiment, Jeong, et al. [53], and applied across five test cases:

• The building models had no doors and consisted of building components such as exterior walls, a roof, and windows that were 6 m².
• The building envelope materials properties for the building components followed the description in Nouidui, et al. [58] and Judkoff, et al. [60].
• No internal heat gain from equipment or occupants was included in the model.
• The building had no shade and was light in weight.
• The first floor of the building model was above ground and detached from soil.
• The simulation location of the building model was Denver, Colorado, US.
• No HVAC system was installed.

In order to perform the simulations, we used a Dymola 2012 simulation application to develop OOPM models using the Modelica simulation language and LBNL Modelica Buildings library version 1.3 [61] as a simulation solver, and set the simulation interval to 3600 s for one year.

The basic building dimensions (8.0m × 6.0 m × 2.7 m in length, width, and height) were applied to all of the test cases, but the room dimensions of Test Cases 2 and 3 were different, based on the building description, in order to incorporate the removal or addition of a thermal zone. The following simulation results demonstrate an annual indoor air temperature variation without installing HVAC systems.

4.2.1. Test Case 1: A Two Thermal Zone ModelicaBEM Model Translated from the Two-Story Building Model

The indoor air temperature of the BIM-based ModelicaBEM model was almost identical to that of the OOPM-based BEM model from LBNL, as shown in the following Figures and

Table 1. Annual peak temperature comparison results for Test Case 1.

Room Name	Highest Temperature (°C)/ Date, Time	Lowest Temperature (°C)/ Date, Time
Lower Room	BIM version: 33.6 °C/19 July, 8 p.m.	BIM version: −13.2/8 January 10 a.m.
	LBNL version: 34.1 °C/19 July, 8 p.m.	LBNL version: −13.7/8 January, 10 a.m.
Upper Room	BIM version: 39.2 °C/18 July, 10 a.m.	BIM version: −16.2/8 January, 7 a.m.
	LBNL version: 39.7 °C/18 July, 10 a.m.	LBNL version: −15.6/8 January, 7 a.m.

. The lowest temperature in the lower and upper rooms of the BIM version occurred at 10 a.m. and 7 a.m. on 8 January, respectively (see Figure 8A), and the highest temperature was obtained at 8 p.m. on 19 July for the lower room and 10 a.m. on 18 July for the upper room (see Figure 8B).

The lowest temperature in the lower and upper rooms of the LBNL version was obtained at 10 a.m. and 7 a.m. on 8 January, respectively (see Figure 9A), and the highest temperature occurred at 8 p.m. on 19 July for the lower room and 10 a.m. on 18 July for the upper room (see Figure 9B).

Figure 10 shows the one-year indoor air temperature of each zone, a dry bulb outdoor temperature, and the temperature differentiation range between the two models. The simulated zones in both models had almost the same indoor air temperature variations. The indoor temperature differentiation between each model in the lower and upper rooms ranged from 0.014 °C to 0.583 °C and 0.430 °C to 0.695 °C, respectively.

The minimum indoor temperature of the lower room was −13.2 °C in the BIM model and −14.8 °C in the LBNL model for 10 a.m. on 8 January. The minimum of the upper room was −16.2 °C in the BIM model and −14.7 °C in the LBNL model for 7 a.m. on 8 January. In addition, the maximum indoor air temperature of the lower room was 33.6 °C in the BIM version and 34.1 °C in the LBNL version at 8 p.m. on 19 July; the upper room was 39.2 °C for the BIM version and 39.7 °C for the LBNL version at 10 a.m. on 18 July.

4.2.2. Test Case 2: Two Thermal Zone ModelicaBEM Model Translated from the L-Shaped Building Model

The two thermal zones in both of the L-shaped building models had nearly identical indoor air temperature changes; the four data series for the indoor air temperature were nearly indistinguishable from one another, as shown in the following Figures and

Table 2. Annual peak temperature comparison results for Test Case 2.

Room Name	Highest Temperature (°C)/ Date, Time	Lowest Temperature (°C)/ Date, Time
West Room	BIM version: 34.5 °C/19 July, 9 p.m.	BIM version: −13.8/8 January, 11 a.m.
	LBNL version: 34.8 °C/19 July, 9 p.m.	LBNL version: −13.8/8 January, 11 a.m.
East Room	BIM version: 40.2 °C/18 July, 1 p.m.	BIM version: −13.5/8 January, 7 a.m.
	LBNL version: 40.3 °C/18 July, 1 p.m.	LBNL version: −13.6/8 January, 7 a.m.

. The lowest temperature in the west- and east-facing rooms of the BIM version occurred at 11 a.m. and 7 a.m. on 8 January, respectively (see Figure 11A), and the highest temperature was obtained at 9 p.m. on 19 July for the west-facing room and 1 p.m. on 18 July for the east-facing room (see Figure 11B).

The lowest temperature in the west- and east-facing rooms of the LBNL version was obtained at 11 a.m. and 7 a.m. on 8 January, respectively (see Figure 12A), and the highest temperature occurred at 9 p.m. on 19 July for the west-facing room and 1 p.m. on 18 July for the east-facing room (see Figure 12B).

Figure 13 shows the one-year indoor air temperatures of each zone in the two models, a dry bulb outdoor temperature, and the temperature differentiation between them. The simulated zones in both models had almost same indoor air temperature variation. The indoor temperature differentiation between each model for the west- facing and east-facing rooms ranged from 0.103 °C to 0.386 °C and 0.019 °C to 0.090 °C, respectively.

The minimum indoor temperature of the west-facing rooms was −13.8 °C in both the BIM model and the LBNL model at 11 a.m. on 8 January; the minimum in the east-facing room was −13.5 °C in the BIM model and −13.6 °C in the LBNL model at 7 a.m. on 8 January. In addition, the maximum indoor air temperature in the west-facing room was 34.5 °C in the BIM version and 34.8 °C in the LBNL version at 9 p.m. on 19 July, and the east-facing room was 40.2 °C for the BIM version and 40.3 °C for the LBNL version at 1 p.m. on 18 July.

4.2.3. Test Case 3: Three Thermal Zone ModelicaBEM Model Translated from the U-shaped Building Model

The simulation results of the three thermal zones in both of the U-shaped models represent nearly the same indoor air temperature variations; the following six data series of indoor air temperature represented by the following Figures and

Table 3. Annual peak temperature comparison results for Test Case 2.

Room Name	Highest Temperature (°C)/ Date, Time	Lowest Temperature (°C)/ Date, Time
West Room	BIM version: 34.2 °C/19 July, 9 p.m.	BIM version: −14.5 °C/8 January, 11 a.m.
	LBNL version: 34.6 °C/19 July, 9 p.m.	LBNL version: −14.4 °C/8 January, 11 a.m.
Middle Room	BIM version: 33.7 °C/19 July, 9 p.m.	BIM version: −12.8 °C/8 January, 11 a.m.
	LBNL version: 34.1 °C/19 July, 9 p.m.	LBNL version: −12.7 °C/8 January, 11 a.m.
East Room	BIM version: 40.7 °C/18 July, 9 a.m.	BIM version: −16.1 °C/8 January, 7 a.m.
	LBNL version: 41.2 °C/18 July, 9 a.m.	LBNL version: −16.2 °C/8 January, 7 a.m.

show identical result patterns. The lowest temperature in the BIM model occurred at 11 a.m. on 8 January for the west-facing and middle rooms and at 7 a.m. on 8 January for the east-facing room (see Figure 14A). The highest temperature in the BIM model was obtained at 9 p.m. on 19 July for the west-facing and middle rooms and 9 a.m. on 18 July for the east-facing room (see Figure 14B). Figure 14B shows that the peak temperature date for the east-facing room was one day ahead of that of the west-facing and middle rooms, due to the windows being located in the east-facing wall.

The lowest temperature in the LBNL model was obtained at 11 a.m. on 8 January for the west-facing and middle rooms and 7 a.m. on 8 January for the east-facing room (see Figure 15A), which was the same result as those obtained from the BIM model. The highest temperature in the LBNL model occurred at 9 p.m. on 19 July for the west-facing and middle rooms and 9 a.m. on 18 July for the east-facing room (see Figure 15B), which were the same results as those obtained from the BIM model.

Figure 16 presents the one-year indoor air temperature for each zone in the two simulation models, along with a dry bulb outdoor temperature and temperature differentiation between the models. The temperature graphs represent nearly the same indoor air temperature changes between the simulated zones. The indoor temperature differentiation between each model for the west-facing, middle, and east-facing rooms ranged from 0.127 °C to 0.448 °C, 0.122 °C to 0.421 °C, and 0.040 °C to 0.529 °C, respectively.

The minimum indoor temperature in the west-facing room was −14.5°C in the BIM model and −14.4°C in the LBNL model at 11 a.m. on 8 January, and the minimum in the middle room was −12.8 °C in the BIM model and −12.7 °C in the LBNL model at 11 a.m. on 8 January. The east-facing rooms of the BIM and LBNL models had their lowest temperatures, −16.1 °C and −16.2 °C, respectively, at 7 a.m. on 8 January. In addition, the maximum indoor air temperature of the west-facing room was 34.2 °C in the BIM version and 34.6 °C in the LBNL version at 9 p.m. on 19 July. The middle room was 33.7 °C for the BIM version and 34.1 °C for the LBNL version at 9 p.m. on 19 July, and the east-facing room was 40.7 °C for the BIM version and 41.2 °C for the LBNL version at 9 a.m. on 18 July.

4.3 Temperature Comparisons

We conducted indoor air temperature comparisons for one year using BIM-based ModelicaBEM models for the west-facing rooms, which had no windows, for both the two-room and three-room models, as well as for the lower room in Test Case 1. All of the west-facing rooms had dimensions of 4.0 m × 6.0 m × 2.7 m in length, width, and height, respectively, except for the lower room in Test Case 1. The differently sized and conditioned zones were located right next to the west-facing rooms; the upper room in Test Case 1 was above the lower room. The heat transfer simulation was similar to the other cases, except for the floor and one wall.

The minimum indoor temperatures of the west-facing rooms were −12.3 °C, −12.5 °C, −13.2 °C, −13.8 °C, and −14.5 °C in the two-room, three-room, two-story, L-shaped, and U-shaped building models, respectively, on 8 January (as shown in Figure 17).

In addition, the maximum indoor temperatures of the west-facing rooms were 34.9 °C, 34.2 °C, 33.6 °C, 34.5 °C, and 34.2 °C, in the two-room, three-room, two-story, L-shaped, and U-shaped building models, respectively, on 19 July (as shown in Figure 18).

The west-facing rooms’ indoor air temperature comparison demonstrates the temperature variations that occurred from attaching different sizes of condition zones to each; the patterns of the temperature variations between the models are similar to one another except in the two-story model case, which had a steeper inclination in minimum and maximum temperature graphs.

Overall, the BIM-based ModelicaBEM models for our test cases demonstrate very similar simulation results compared with the OOPM-based BEM models using the Modelica Buildings library. This can be expected due to using the same thermal simulation engine. However, two major differences exist: the data translation approach and model structure, which can cause the different simulation results. The automatic data translation to create BIM-based ModelicaBEM models allows the reliable OOPM-based BEM models from BIM information efficiently versus manually creating OOPM-based BEM models: a reliable object mapping process based on the building topology translation algorithm and automatic building envelope translation into the BIM-based ModelicaBEM models from the developed framework, reducing human intervenes. In addition, the model structure of the BIM-based ModelicaBEM follows the semantic of architectural building models instead of the energy simulation model, which facilitates the object mapping between BIM and OOPM-based BEM.

5. Conclusions and Future Work

This paper presents a performance evaluation of the BIM-based ModelicaBEM technique for building energy simulations that was performed through a series of diverse building topology translation cases. Each test case demonstrated a distinct building topology translation between BIM and Modelica-based OOPM models in order to validate an object mapping procedure for efficient energy model translations. The test cases validated the automatic model translations developed in previous research [51,53]; they were found to save time and reduce the need for error-prone manual energy model translations.

The test cases showed the ability of the BIM API-based framework to enable automatic BIM-based ModelicaBEM model creation, which preserves direct access to BIM data and the dynamic parametric modeling approach. While the test cases were conducted based on a specific BIM authoring tool, Revit, in the future we will expand our test cases to incorporate other BIM authoring tools.

Our demonstration presents more dynamic multi-zone model translations between BIM and Modelica-based OOPM models with a high level of accuracy and efficiency. However, in order to enhance the efficiency and accuracy of this validation, more complicated and diverse real-world building projects are needed. We will expand our test cases to cover more realistic building models, including curtain wall buildings for vertical stacking cases and door-included cases to demonstrate air flow and air infiltration.