DOI:10.35490/EC3.2019.188Page 164 of 490

2019 European Conference on Computing in ConstructionChania, Crete, Greece

July 10-12, 2019

AN IFC DATA PREPARATION WORKFLOWFOR BUILDING ENERGY PERFORMANCE SIMULATION

Kyriakos Katsigarakis1, Georgios Nektarios Lilis1, Georgios Giannakis1 and Dimitrios Rovas2 1Technical University of Crete, Greece

2University College London, London, UK

AbstractAccurate building energy performance simulation modelgeneration from IFC data files require the input IFC datato be correct and complete. To ensure such data qual-ity conditions, methods integrating IFC data correctnessand completeness checks, under a common architecture,are introduced. IFC data correctness is supported by theuse of a dedicated geometric error detection tool, whichidentifies and reports back to the building designer, errorsaffecting the building’s 2nd-level space boundary topology.IFC data completeness is performed by the use of a ded-icated for building energy performance simulation ModelView Definition schema. The quality checking results arereported in a BIM collaboration file format.

IntroductionThe accuracy of Building Energy Performance Simula-tion (BEPS) results is determined by the quality of itsinput data, mainly comprising the building geometry, itsconstruction’s materials, internal loads, HVAC systemsand components, weather data, operating strategies andschedules, and simulation specific parameters (Maile et al.2007).In current practice, to develop a BEPS model, modelersgather and combine 2D drawings such as Architectural andMechanical Electrical Plumping (MEP) plan views, ma-terial data and other information, and manually transformthem into the specific input data, required by the respectiveBEPS engine. This process has two strong weaknesses: a)it is very time-consuming, often requiring more time thanis available due to project’s deadlines; and b) it is a non-standardized process that produces BEPS models whoseresults can significantly vary from one modeler to an-other according to their experience (Berkeley et al. 2014),even given the same initial building design information.A methodology for automated creation of BEPS modelscould make the BEPS modeling process much more ex-pedient and therefore, less vulnerable to modeling errors.Building Information Models (BIM) are information-richrepositories that could be used to streamline and expe-dite the collection of such information. Hence, recent

research studies focus on BIM-based BEPS models gen-eration (Andriamamonjy et al. 2018, Thorade et al. 2015,Wimmer et al. 2015, Giannakis et al. 2015).BIM is an object-oriented digital representation of a build-ing, which also can capture part of the information re-quired for generating a BEPS input data file. Relevantopen-BIM data schemas include the Industry FoundationClasses (IFC) (ISO 16739-1 2018) and the green-buildingXML schema (gbXML). Concerning building geometry,IFC supports three dimensional representations, whilegbXML supports only planar geometry. For this reason, aplethora of recent studies focuses on developing a method-ology to automatically generate geometry inputs for BEPSfrom IFC files. Additionally, IFC appears to be a moresuitable choice as its rich content enables interoperabil-ity among different software environments and can easilybe updated following a building’s life cycle (Hitchcock &Wong 2011).However, applying an automated data transformation fromIFC data to input data of BEPS tools is not a straightfor-ward but a tedious task often due to imperfections of theprovided IFC files. Although commercial BIM authoringtools (RevitTM, ArchicadTM, VasariTM) support exporta-tion of IFC files, their quality is not acceptable in the con-text of BEPS input data generation. Even RevitTM, andits IFC4 Design Transfer View (DTV) exporter, whichcurrently seems to be the most mature tool, is far frombeing perfect: while IFC schema can capture data aboutmaterial thermal properties, internal gains (schedules anddensities) and 2nd-level space boundaries (Bazjanac 2010),requested from the BEPS perspective, relevant informationis missing or incorrect in the exported IFC4 DTV files.

Proposed IFC4 workflowTo examine and eliminate these IFC data imperfections,in this work an IFC4 data workflow is introduced. Thisworkflow aims at delivering error-free IFC4 files ready forBEPS input data generation. The workflow starts with theBIM preparation and the IFC data exportation processes(first block of Figure 1). Since the lack of training of theBIM designer contributes to data inaccuracies, a set of de-

Page 165 of 490

sign guidelines have been developed to help the designerto define properly all the requested information during theBIM preparation process. After the BIM data are prepared,the IFC data exportation process follows. However, due toissues mentioned above, the exported IFC file is of poorquality (as for the 2nd-level space boundary information)or lacks valuable information (as for the material thermalproperties and internal gains); for the latter, RevitTM’sIFC4 DTV exporter has been modified to correctly popu-late such information.

IFC data completeness check

IFC data geometric check

IFC data preparation and exportation

Design process

IFC exporter

Enriched IFC file

IFC data enrichment

Geometrically

correct IFC file

CBIP tool

BEPS-ready IFC file

IFC file

BCF file

MVD tool

GED tool1

2

3

Figure 1: Overview of the proposed IFC data workflow

After the BIM preparation and IFC exportation processes,the IFC4 data workflow continues in three main stages.During the first stage (IFC data geometric check) the ar-chitectural geometric content of the IFC file is examinedusing the GED tool (Lilis et al. 2015), for possible er-rors which affect the BEPS model generation process andif found they are reported in BIM Collaboration Format(BCF). In the second stage (IFC data enrichment) the IFCfile is enriched using the Common Boundary Intersec-tion Projection (CBIP) tool with the necessary for BEPS2nd-level space boundary information. Similar enrichmenttools, such as the SBT tool (Rose & Bazjanac 2015), havebeen developed using graph-based methodologies. In thefinal stage (IFC data completeness check) several checksare performed on the IFC data to ensure acceptable qualityfor BEPS input data file generation. The checks are per-formed using the Model View Defintion (MVD) Checking

tool. For its development, other supporting tools, relevantlibraries and an MVD XML for conventional BEPS havebeen created. Other attempts in this domain have beenprimarily focused on developing a MVD XML for con-ventional and advanced BEPS (Pinheiro et al. 2018). Theinitial processes and the three main stages of the workfloware described analytically in the following sections.

IFC data preparation and exportationTo help the BIM designer on creating an error-free (orerror-reduced) BIM, from which the maximum level ofBEPS information can be exported, a document thatpresents a set of design guidelines as they apply forRevitTM has been developed – similar guidelines can bedeveloped for other BIM authoring tools.The guidelines are provided as a set of modelling rules be-longing to two broad categories: Static and Dynamic Data.Static data rules cover the building geometry, constructionmaterials, glazing information, building services, and soforth, while dynamic data rules cover the specificationof time-varying parameters such as occupancy schedules,internal gains schedules, use of equipment, or occupantactions. A subset of these guidelines are briefly presentedbelow.Note here that concerning HVAC systems data representa-tion, while IFC is the most widely used openBIM schema,it suffers from limitation in the description of HVAC sys-tem in the context of BEPS. Commonly, HVAC modellingin BEPS engines require further information than whatis available in an IFC file. Hence, the presented BIMdesign guidelines, are mostly focused on building energydemands estimation aspects.

Spaces and HVAC zones

Accurate heating- and cooling-loads simulation can onlybe accomplished when spaces are created in all internalbuilding closed areas to account for the entire volume ofthe building model. Spaces should be defined for eachclosed area of the building, including unoccupied closedair volumes such as plenums. Following the definition ofspaces, a checking that they are properly bounded must beperformed using floor plans and section views, to guaran-tee that a) there are no overlaps between the space volumeand the attached building elements, and b) there are novoid volumes (common case when the space volume is notattached to building elements).HVAC zones comprise one or more spaces that have com-mon environmental or design requirements. Spaces thatare on different levels can be added to the same zone.Zones are rather important for BEPS as they define thegranularity of the approximation. Grouping spaces intozones in RevitTM is required to ensure manageable com-

Page 166 of 490

plexity of the BEPS model. When a space has not beenassigned to a zone, a new zone for this space is definedautomatically.

Material thermal properties

In a broad sense, two main material categories exist:Opaque and Transparent. Knowledge of material thermalproperty values is required in the modelling of the variousenergy transfers this includes absorbed solar shortwaveradiation flux, conduction heat transfer through walls, con-vective transfer to the space (or outside) air and fraction ofsunlight transmitted to building interiors.For Opaque materials, knowledge of the following thermalproperties is required: Thickness, Conductivity, Density,Roughness, Specific Heat, Thermal absorptance, and Solarabsorptance. Transparent materials require definition ofthe following parameters: U-factor and Solar Heat GainCoefficient (SHGC). In Revit, these material propertiescan be defined by the designer and can be subsequentlyaccessed through the Revit API. To define and retrievesuch information, the BIM designer must activate the ther-mal properties population for each material through the"Thermal" tab.Most IFC-to-BEPS methods currently use constructionand material thermal properties of building elements fromfixed predefined libraries (Thorade et al. 2015, Wimmeret al. 2015). However, as mentioned above, this informa-tion can be explicitly prescribed in the RevitTM model,and can also be represented in IFC (e.g. IfcThermalCon-ductivityMeasure for thermal conductivity). Surprisingly,the default Revit IFC-exporter is not able to export suchinformation.

Internal gains and operation schedules

Building equipment’s operation (artificial lighting andelectrical equipment), as well as the occupants’ presenceand the building infiltration rate, contribute to the overallinternal gains and can be represented as time-varying func-tions, called herein internal gains schedules and assignedto every building’s space.The IFC schema includes classes for representing the in-ternal gains schedules (IfcTimeSeries). Objects of theseclasses can be attached to individual space instances. How-ever, concerning the existing BIM-authoring tools, theseschedules can be selected from predefined variants. InRevitTM, such information can be defined in buildingand/or space scale as follows: a) define the building type,which sets a predefined template for the internal gains(schedules and densities), and its infiltration class; b) de-fine the people, artificial lighting and electric equipment(density and schedules) at each space by selecting the spacetype. At this point, it is worth-mentioning that the de-signer is allowed to edit/modify non-schedule parameters

(densities), but not modify existing schedules, since theseschedules have been defined according to relevant stan-dards (ASHRAE 90.1 2010); if a new schedule is requiredthe modeler must define a user-defined schedule and editits values properly.

IFC exporter modification

To overcome limitations of the default Revit IFC4 DTVexporter on exporting information about thermal proper-ties of each building entity’s construction material andinternal gains (schedules and densities), which have beenproperly set following the aforementioned guidelines, andto guarantee correct exportation of such information, thedefault exporter (which is an open source component) hasbeen modified to create a bespoke OptEEmAL versionthat addresses these shortcomings. The OptEEmAL IFCExporter supports the latest version of RevitTM (2018.3).

Exportation setup

Assuming that the BIM data insertion according to theguidelines and the OptEEmAL IFC exporter’s installa-tion have been accomplished, the BIM designer proceedswith the exportation setup where few of the defaults IFC-exporting options are modified properly to retrieve therequested information.The first modification is the rooms exportation’s deacti-vation. Utilizing the Revit IFC4 DTV exporter and/or itsmodified version, both spaces and rooms are exported asIfcSpace instances. While spaces definition throughoutthe models is prerequisite, rooms definition is not: in-formation that a room object could provide in not usablein the context of BEPS. Hence, to avoid duplication ofIfcSpaces’ geometry representation, the designer must de-activate the rooms’ exportation. To this direction, designermust change the IFC options by editing the rooms RevitTM

category and setting "Not Exported" in the respective "IFCClass Name".Setting the rooms as not exported elements, the file is readyto be exported: the IFC4 Design Transfer View is selectedas MVD, while a) the RevitTM property sets and b) the IFCcommon property sets exportation are activated.

IFC data geometry checkAfter the IFC file export geometric errors that affect theIFC data enrichment stage (stage 2 Figure 1), (Lilis et al.2015) must be detected automatically and corrected man-ually. These errors belong to a subset of all possible errorsin IFC data files (detected by commercial IFC data check-ing software such as Solibri Model Checker, TEKLA andothers) and a dedicated Geometric Error Detection (GED)tool have been developed for their detection.Errors that are detected by the GED tool belong to mul-

Page 167 of 490

tiple categories. For example, an architectural construc-tion (e.g. wall, slab, etc.) that intersects with a buildingspace volume, renders the 2nd-level space boundary sur-face related to this construction and space undetectable(see example in part I of Figure 2). Two intersecting wallopening volumes next to each other, attached to the samebuilding space (see example in part II of Figure 2), pro-duce 2nd-level space boundaries which also intersect witheach other (space boundary surface duplication). For all ofthese reasons, methods for detection and semi-automaticcorrection of these inaccuracies have been proposed (Liliset al. 2015).

I. Space - Wall clash

Space

Intersection

II. Wall Opening – Wall Opening clash

Space 1 Space 2

Space 1 Space 2

Space boundary duplicationIII. GED tool results

Space - space clashof a real building model.

Detected by GED tool.

Reported in BCF.

Viewed using

BIMcollab

on AutoDesk’s

Navisworks.

Figure 2: Geometric errors detected by GED tool

The GED tool reports the detected errors back to the de-signer in a BCF file format (part III of Figure 2). The BCFerror report file contains the 3D geometric definitions ofthe architectural elements involved in a geometric error aswell as the set of surfaces and line segments indicatingat the exact location of the error in the building’s threedimensional space.

IFC data enrichmentAfter the designer’s manual corrections of the aforemen-tioned remaining geometric errors, the exported IFC fileis ready to be enriched with the necessary for BEPS ge-ometric content, which is essentially the 2nd-level spaceboundary surface topology (Bazjanac 2010). This topol-ogy contains surfaces through which thermal energy flowsamong internal building spaces and the building environ-ment (air or ground) and are required in order to assesstotal thermal energy balance of the building (see examplein part II of Figure 3). This surface topology cannot beobtained directly from the geometry of the architecturalelements (e.g. walls, slabs, etc.) as the building spacesare not perfectly aligned vertically and horizontally. Addi-

tionally, most IFC exporters do not or export this topologyor they export it with errors.

I. Architectural element set II. 2nd-level space boundaries

Virtualspace

boundaries

Internal space boundaries

ExternalSpace

boundaries

III. CBIP tool results

2nd-level space boundary partitions of a slab of a real building model.

Detected by CBIP tool.

Displayed using Solibri Model Viewer.

CBIP

Figure 3: 2nd-level space boundary surface generation ofCBIP tool

Consequently, to produce this topology in a consistent andprecise way, CBIP tool has been developed (Lilis et al.2017), which performs the necessary geometric transfor-mation operations on the existing IFC architectural geo-metric content (part I of Figure 3), calculates the 2nd-levelspace boundary surfaces (part II of Figure 3) and enrichesthe input IFC file with the required geometric data of thesesurfaces and their associations to building space volumesand material constructions. As illustrated in the exampleof part III of Figure 3, CBIP correctly decomposes thefloor surface into multiple sub-surfaces depending on thelocation of the building spaces underneath the slab.Although the geometric content of the enriched IFC filemight be adequate for BEPS model generation (the neces-sary 2nd-level space boundaries are present with the correctassociations to related building elements), additional in-formation related to thermal properties of the materialsand time schedules of entities which change state (peo-ple, devices, openings, etc.), required for BEPS modelgeneration, might be missing. Consequently, an IFC datacompleteness checking stage, following the model viewdefinition approach, appears to be necessary, as describedin the following section.

IFC data completeness checkFor an IFC-to-BEPS model data transformation, presenceof certain IFC data is prerequisite. More specifically, IFCdata have to satisfy the exchange requirements of the BEPSinput data generation; hence, certain subsets of the IFCschema are validated by evaluating the IFC entities andtheir attributes in terms of existence, correctness, unique-ness and conditional dependencies (Chipman et al. 2014).There are two main approaches of developing an IFC val-idation tool. First using an IFC library, the developer canbuild static rules by querying the IFC entities and checkingtheir attributes. This approach has some weaknesses: a)it does not support reusability of the defined rules; and b)

Page 168 of 490

it requires advance programming skills to validate the re-lations of the IFC entities under a certain IFC subset. Thesecond approach is the development of an IFC validationtool that supports the Model View Definition (MVD) auto-mated checking (Zhang et al. 2015). An MVD describesthe subset of the IFC schema that is needed for a data-exchange in a specific domain, which can be formalizedusing the mvdXML open standard that has been released bybuildingSMART International. The IFC validation toolswhich support MVD checking use the mvdXML format toimport the IFC subsets known as templates and the definedrule sets known as concept to perform an automated vali-dation of the IFC data. To develop such a tool, in this worksome supporting tools and libraries have been developed,described in the following sections.

EXPRESS Parsing Tool

The proposed EXPRESS Parsing Tool is a standalone pro-gram written in Java using the code model library and issuitable to generate IFC java classes from the correspond-ing EXPRESS files which have been released by build-ingSMART International. The tool can parse successfullythe most frequently used IFC releases, from IFC2x3 TC1to IFC4x1 final. In the first step, the EXPRESS dataare transformed into in-memory objects. Consequently,the defined mapping rule set is applied on top of this in-memory representation to initialize the corresponding Javacode model. The mapping rules are summarized in Table1.

Table 1: Mapping rules between EXPRESS schema andJava model

EXPRESS Model Java ModelENTITY Java ClassSELECT Java InterfaceABSTRACT SUPERTYPE Java Abstract class

TYPE

Java ClassEnumeration classCustom list wrapperCustom array wrapperBoolean wrapper classLogical wrapper classReal wrapper classInteger wrapper classString wrapper classBinary wrapper class

INVERSE Set Collection

The Java code model has a built-in method to generate thedefined IFC classes and to organize them into packagesbased on the version of the given EXPRESS schema. EachIFC Java class implements some standard methods which

are summarized as follows:

• Public constructor without arguments: instantiates anobject of an IFC class;

• Public constructor with arguments: the constructorincludes all the defined properties (IFC attributes)as well as the properties which are defined in upperlevels (IFC abstract classes);

• Public method to initialize the properties of an IFCclass;

• Public method to initialize the collections set of theinverse properties;

• Public getters/setters for each property;• Public method to generate the step line of an IFC

class.

Furthermore, the EXPRESS Parsing Tool generates theIFC factory class which allows the instantiation of the IFCobjects by using the IFC class names.

IFC Library

The proposed IFC Library provides the possibility to parseefficiently the IFC-SPF data and to instantiate in-memorythe IFC model of the corresponding IFC file. An em-bedded API is used for the loaded objects manipulation,providing the developers with useful functionalities suchas adding new IFC instances, modifying existing instancesor querying the IFC model. The core of this library comesfrom the output of the EXPRESS Parsing Tool and is or-ganized in multiple packages to handle effectively the sup-ported versions of the EXPRESS schema. The currentversion of the IFC library can handle a wide range ofdifferent IFC schemas (IFC2x3 TC1 to IFC4x1 final). Ad-ditionally, the IFC library can initialize the properties ofthe inverse relations by adding the instance of a class tothe set collection of the inverse connected property. Theinitialization of the inverse relations is archived by callinga specific public method as listed next:

Listing 1: Part of IfcMaterialProperties classpub l i c I f c M a t e r i a l P r o p e r t i e s ( ) {}

pub l i c vo id i n v e r s e ( ) {i f ( t h i s . m a t e r i a l s != n u l l &&

t h i s . m a t e r i a l . g e t H a s P r o p e r t i e s ( ) != n u l l ) {t h i s . m a t e r i a l . g e t H a s P r o p e r t i e s ( ) . add ( t h i s ) ;

}}

Listing 2: Part of IfcMaterialDefinition classpub l i c I f c M a t e r i a l D e f i n i t i o n ( ) {

t h i s . a s s o c i a t e d T o =new HashSet < I f c R e l A s s o c i a t e s M a t e r i a l > ( ) ;t h i s . h a s E x t e r n a l R e f e r e n c e s =new HashSet < I f c E x t e r n a l R e f e r e n c e R e l a t i o n s h i p > ( ) ;t h i s . h a s P r o p e r t i e s =new HashSet < I f c M a t e r i a l P r o p e r t i e s > ( ) ;

}

pub l i c vo id i n v e r s e ( ) {}

Page 169 of 490

Using the inverse set collections, it is possible to get theIfcMaterialProperties instance from the inverse methodgetHasProperties() of the IfcMaterial class. In this exam-ple, the IfcMaterial class is subtype of the IfcMaterialDef-inition. The inverse method is called for each IFC instanceafter the deserialization process.

MVD Checking

One of the main goals of the MVD specification is to helpthe community develop BIM tools that allow the automaticvalidation of IFC data against rule sets that are based onthe mvdXML standard. Mainly, three steps are needed toachieve automatic validation of IFC data: a) the prepa-ration of the rule set (mvdXML) using buildingSMARTcertified tools such as the ifcDoc (see figure 4); b) themodel checking service that applies the given rules to theloaded IFC instances; c) the report generation service thatgenerates reports based on open standards such as the BCF.For the creation of valid mvdXML files the ifcDoc softwareis used. This software has been developed by buildingS-MART International in order to improve the consistentand computer-interpretable definition of the MVD speci-fication. The user can easily create a custom model viewand assign new concepts under it. Each concept has anapplicable entity (IFC class), a connection to an existingtemplate (subsection of the IFC schema) and the appliedrules based on logical operations (IFC entities or attributesthat are checked by type or by value under certain condi-tions).The proposed MVD checking tool is a standalone servicewritten in pure Java without having external dependenciesto third party libraries. The main goal was to achievea clean end-to-end design where the different parts areseparated based on their functionalities. Thus, the EX-PRESS Parsing Tool is used to generate the IFC Librarywhich in its turn is used internally by the model viewchecking process. There are two main features that thechecking process uses from the IFC Library: a) the IFC-SPF serialization/deserialization feature to load the IFCdata in-memory and to perform queries; and b) the inverseconnections of the IFC entities to validate the existence ofan IFC schema’s subset starting from an applicable IFCroot entity. The MVD checking tool takes as an inputthe IFC-SPF data as well as the MVD-XML data. Theoutput of the tool is the boolean result of the validationfor each given concept. The serialization of the resultscan be represented in a graphical environment or usingopen standards such as the BCF that supports workflowcommunication in BIM processes.From a BEPS viewpoint, the partition of building con-struction (interior/exterior walls, floors, roofs) and open-ing (door, window) surfaces into 2nd-level space boundary(Bazjanac 2010) surfaces is a prerequisite. This process

is performed by the CBIP tool. The result of the CBIPtools execution is the enrichment of the IFC file with rele-vant 2nd-level space boundary information (IfcRelSpace-Boundary2ndLevel class population).The 2nd-level space boundary content of the enriched IFCfile is checked by the model view checking process, usingthe following four checking rules, which are implementedunder the same concept using multiple template rules:

1. The existence of the 2nd-level space boundaries ischecked by examining the presence of the IfcRelSpace-Boundary2ndLevel class instances in the enriched IFCfile.

2. For each IfcRelSpaceBoundary2ndLevel populated in-stance, the presence of its related building element isexamined.

3. For each IfcRelSpaceBoundary2ndLevel instance, therelated building elements type, the value of the Ex-ternalOrInternal property, the corresponding spaceboundary (if the space boundary is INTERNAL) andthe parent space boundary (if the space boundary refersto an opening) are examined.

4. For each IfcRelSpaceBoundary2ndLevel instance therelating space index, is checked.

5. Finally, the last rule checks if there is an IfcRelSpace-Boundary2ndLevel instance with ExternalOrInternalproperty value "EXTERNAL_EARTH".

If any missing or invalid information is detected the cor-responding template rule fails to validate the defined pa-rameters. These parameters are summarized for differentspace boundary types (internal, external, correspondingand parent) and related building elements (wall, slab, door,window, plate, opening and virtual element) in Table 2.

Table 2: Space boundary checking rules

Applicable Boundary Corresponding ParentIFC Entity Condition Space BoundaryIfcWall Internal Missing -IfcSlab Internal Missing -

IfcDoorExternal - MissingInternal - MissingInternal Missing -

IfcWindowExternal - MissingInternal - MissingInternal Missing -

IfcPlate External - MissingInternal - -

IfcOpening External - -IfcVirtualElement External - -

Page 170 of 490

Figure 4: ifcDOC tool

As mentioned above, other IFC data that are required inthe context of BEPS include the space occupants pres-ence, artificial lighting, electrical equipment operation(which act as thermal sources in terms of BEPS) and re-lated operation schedules. These data are exported by themodified IFC RevitTM exporter by populating a new Psetclass, named Pset_Space InternalGainsDesign, assignedto each IfcSpace class. The properties of this new classare checked against the property name and the entity typeas listed in Table 3.

Table 3: Space checking template rules of Pset SpaceIn-ternalGainsDesign

Property name Entity typeOccupancySchedule IfccIreggularTimeSeriesLightingSchedule IfccIreggularTimeSeriesEquipmentSchedule IfccIreggularTimeSeriesHeatGainLighting IfcPropertySingleValueHeatGainEquipment IfcPropertySingleValueAreaPerOccupant IfcPropertySingleValueHeatGainPerOccupant IfcPropertySingleValueInfiltrationRate IfcPropertySingleValue

BEPS require a number of properties to be assigned to ma-terials for various building constructions as well. Theseproperties, depending on the material type, are: for opaquematerials Conductivity, Density and Specific Heat; fortransparent materials U-factor and Solar heat gain coeffi-cient (SHGC). Two new MVD concepts depending on thebuilding element type are applied: a) Opaque materials(e.g. walls, floors, roofs); and b) Transparent materials(e.g. windows, plates, doors).The properties under the opaque and the transparent mate-rials classes are checked against the property name and theentity type as listed in Table 4 and Table 5, respectively.

Table 4: Opaque material property rules

Property name Property typeSpecificHeatCapacity IfcPropertySingleValueThermalConductivity IfcPropertySingleValueMassDensity IfcPropertySingleValue

Table 5: Transparent material property rules

Property name Property typeVisual Light Transmittance IfcPropertySingleValueSolar Heat Gain Coefficient IfcPropertySingleValueHeat Transfer Coefficient (U) IfcPropertySingleValueThermal Resistance (R) IfcPropertySingleValue

ConclusionsThe automated BEPS model generation from IFC data hasreceived lately considerable attention. However, imperfec-tions of the provided IFC files prevent the BIM-to-BEPSdata transformation process from being widely and auto-matically applicable.The focus of this work has been the proposal of an IFCdata quality checking workflow towards populating IFCfiles ready for BEPS input data generation. The proposedworkflow consists of four main stages: a) data preparationand exportation; b) geometric data correctness check; c)data enrichment; and d) data completeness check.Describing these stages concisely, in the first stage, de-sign guidelines along with a modified IFC exporter areprovided to enable exportation of information about mate-rials thermal properties and internal gains. In the secondstage, geometric errors that affect the correct 2nd-levelspace boundaries population are automatically detectedand reported in a BCF file. These errors are corrected

Page 171 of 490

manually by the designer and an geometric error-free IFCthat includes information about materials thermal prop-erties and internal gains is exported to be processed bythe third stage; here, the IFC data are enriched with the2nd-level space boundaries data. In the final stage, a datacompleteness check is performed for the enriched IFC fileto ensure that the BEPS information that the IFC schemacould capture is present.The presented workflow has been focused strictly on datapreparation for building energy demands estimation as-pects, since HVAC data inclusion have not been thoroughlyinvestigated. A concrete implementation of such data inthe proposed workflow remains the main subject of futurework.

AcknowledgmentsThis research has been partially funded by the EuropeanCommission H2020-EeB5-2015 project “Optimised En-ergy Efficient Design Platform for Refurbishment at Dis-trict Level" under contract #680676 (OptEEmAL).

ReferencesAndriamamonjy, A., Saelens, D. & Klein, R. (2018),

‘An automated IFC-based workflow for building energyperformance simulation with Modelica’, Automation inConstruction 91, 166–181.

ASHRAE 90.1 (2010), ‘Energy standard for buildingsexcept low-rise residential buildings’, ASHRAE/IESNAStandard .

Bazjanac, V. (2010), Space boundary requirements formodeling of building geometry for energy and otherperformance simulation, in ‘Proceedings of the 27thCIB W78 Conference’, Cairo, Egypt, 16-19 November2010.

Berkeley, P., Haves, P. & Kolderup, E. (2014), Impact ofmodeler decisions on simulation results, in ‘Proceed-ings of the ASHRAE/IBPSA-USA Building SimulationConference’.

Chipman, T., Liebich, T. & Weise, M. (2014), ‘Specifi-cation of a standardized format to define and exchangemodel view definitions with exchange requirements andvalidation rules (b1. 0)’.

Giannakis, G., Lilis, G. N., Garcia, M., Kontes, G., Val-maseda, C. & Rovas, D. (2015), A methodology to au-tomatically generate geometry inputs for energy perfor-mance simulation from IFC BIM models, in ‘Proceed-ings of the 14th IBPSA Building Simulation Confer-ence’, Hyderabad, India, 7-9 December 2015, pp. 504–511.

Hitchcock, R. & Wong, J. (2011), Transforming IFCArchitectural View BIMs for Energy Simulation, in‘Proceedings of the 12th IBPSA Building SimulationConference’, Sydney, Australia, 14-16 November 2011,pp. 1089–1095.

ISO 16739-1 (2018), ‘Industry Foundation Classes (IFC)for data sharing in the construction and facility manage-ment industries – Part 1: Data schema’, InternationalOrganisation for Standardisation .

Lilis, G. N., Giannakis, G. I. & Rovas, D. V. (2017), ‘Auto-matic generation of second-level space boundary topol-ogy from IFC geometry inputs’, Automation in Con-struction 76, 108–124.

Lilis, G. N., Giannakis, G. & Rovas, D. (2015), Detectionand semi-automatic correction of geometric inaccura-cies in IFC files, in ‘Proceedings of the 14th IBPSABuilding Simulation Conference’, Hyderabad, India, 7-9 December 2015, pp. 2182–2189.

Maile, T., Fischer, M. & Bazjanac, V. (2007), ‘Buildingenergy performance simulation tools-a life-cycle and in-teroperable perspective’, Center for Integrated FacilityEngineering (CIFE) Working Paper 107, 1–49.

Pinheiro, S., Wimmer, R., ODonnell, J., Muhic, S., Baz-janac, V., Maile, T., Frisch, J. & van Treeck, C. (2018),‘MVD based information exchange between BIM andbuilding energy performance simulation’, Automationin Construction 90, 91–103.

Rose, C. M. & Bazjanac, V. (2015), ‘An algorithm to gen-erate space boundaries for building energy simulation’,Engineering with Computers 31(2), 271–280.

Thorade, M., Rädler, J., Remmen, P., Maile, T., Wimmer,R., Cao, J., Lauster, M., Nytsch-Geusen, C., Müller, D.& van Treeck, C. (2015), An open toolchain for gen-erating modelica code from building information mod-els, in ‘Proceedings of the 11th International ModelicaConference’, pp. 383–391. Versailles, France, 21-23September 2015.

Wimmer, R., Cao, J., Remmen, P., Maile, T., ODonnel,J., Frisch, J., Streblow, R., Müller, D. & van Treeck, C.(2015), Implementation of advanced bim-based map-ping rules for automated conversions to modelica, in‘Proceedings of the 14th IBPSA Building SimulationConference’, pp. 419–426. Hyderabad, India, 7-9 De-cember 2015.

Zhang, C., Beetz, J. & Weise, M. (2015), ‘Interoperablevalidation for ifc building models using open standards’,Journal of Information Technology in Construction (IT-con) 20(2), 24–39.