Automation in Construction 127 (2021) 103724

Contents lists available at ScienceDirect

Automation in Construction
journal homepage: www.elsevier.com/locate/autcon

A rule-based system to automatically validate IFC second-level space

boundaries for building energy analysis
Huaquan Ying a, Sanghoon Lee b, *
a
Faculty of Civil and Environmental Engineering, Technion - Israel Institute of Technology, Israel
b
The Department of Architectural Engineering, The University of Seoul, South Korea

A R T I C L E I N F O A B S T R A C T

Keywords: To facilitate BIM-to-Building Energy Modeling (BEM) geometric transformation, IFC provides a concept of
Second-level space boundary second-level space boundary (SB). In the current practice, however, quality issues of second-level SBs in IFC
Automated rule-based checking system models are often found, which makes it critical to evaluate their quality before retrieving them for energy
Quality check
analysis. Each second-level SB is objectified by carrying surface geometry and rich semantic data. Manually
Building information modeling (BIM)
Industry foundation classes (IFC)
checking a large number of second-level SBs thus becomes error-prone and impracticable, while automatic and
Building energy modeling (BEM) reliable approaches are still not available. This study presents an automated system to validate IFC second-level
SBs with 38 rules in terms of syntactic and semantic correctness, geometric correctness, and consistency. The test
results with an IFC model of a real-world building show that the system allows users to reliably evaluate the
quality of second–level SBs as well as conveniently locate and visualize detected geometric and non-geometric
errors.

1. Introduction
In recent decades, numerous Building Information Modeling (BIM)-
to-Building Energy Modeling (BEM) transformation processes, ap­
proaches, and tools have been developed [1]. This is mainly motivated
by the facts that, on the one hand, the traditional manual method to
create building energy models using design documentations (e.g.,
drawings, specifications, and photos) is often a time-consuming, labo­
rious, error-prone, and energy modelers’ knowledge and skill dependent
process [2,3] and that on the other hand, BIM, which provides a digital
representation of building physical and functional characteristics [4],
has the capacity of capturing building data required for BEM. Auto­
mating the utilization of BIM data for BEM can provide a promising
solution to address the limitations of the traditional method to create
building energy models.
Building geometry transformation is a fundamental but challenging
task in a BIM-to-BEM transformation process. It essentially refers to a
complex geometry simplification of a three-dimensional (3D) architec­
tural solid model into a 3D thermal surface model [5,6]. The surface
model mainly consists of a series of second-level space boundaries (SBs),
which delineate building elements (e.g., walls, slabs, roofs, windows,
doors) as planar surfaces that bound thermal spaces of the building [7].
Geometrically, second-level SBs are “heat transfer surfaces on both sides
of building elements that separate spaces” [20]. A second-level SB is an
objectified concept which includes geometric data and rich semantic
information such as the relating space and the related building element.
Industry Foundation Classes (IFC) is an open international standard for
exchanging and sharing BIM data in the architectural, engineering, and
construction (AEC) industry [8]. To facilitate the BIM-to-BEM geometric
transformation, IFC provides a capacity of capturing information re­
quirements of second-level SBs. It has become one of the most commonly
used data models to bridge BIM and BEM [1].
In the current practice, however, users often find it challenging to
obtain accurate IFC second-level SBs, especially for complex buildings.
Second-level SBs cannot be directly modelled in contemporary BIM
authoring applications and then exported into IFC, but need to be
computed based on the solid geometries of relevant BIM objects
including spaces and/or building elements. More specifically, second-
level SBs can be obtained in two ways: (1) directly exported from BIM
authoring tools such as Revit [9] and ArchiCAD [10] through the
second-level SB generation functions embedded in their IFC exporters;
and (2) extracted from BIM objects contained in an IFC model by using
second-level SB generation algorithms [11–13]. The quality of second-
level SBs thus can be affected by two aspects: the quality of relevant

* Corresponding author.
E-mail addresses: enochying@campus.technion.ac.il (H. Ying), sanghoon.lee@uos.ac.kr (S. Lee).

https://doi.org/10.1016/j.autcon.2021.103724
Received 27 August 2020; Received in revised form 16 March 2021; Accepted 18 April 2021
Available online 28 April 2021
0926-5805/© 2021 Elsevier B.V. All rights reserved.
H. Ying and S. Lee
Fig. 1. The entity for defining a second-level SB in (a) IFC2X3 TC1 schema and (b) IFC4 ADD2 TC1 schema.
BIM data (i.e., building elements and/or spaces in a native BIM or the
IFC format) and the performance of second-level SB generation func­
tions/algorithms. There are many common BIM modeling issues that
hinder the generation of accurate second-level SBs, such as duplicate or
missing building elements or space objects, geometric clashes and gaps
between spaces and their surrounding elements, and BIM object classi­
fication issues [13–15]. For the second aspect, existing second-level SB
generation algorithms have their limitations in terms of the BIM object
types and the geometrical/topological complexity that they can handle.
For instance, they often fail to process BIM objects with a curved solid
geometry [16]. A comparative analysis of the capabilities and limita­
tions of several existing second-level SB generation algorithms can be
found in Ying and Lee’s study [13].
In fact, various quality issues of IFC second-level SBs have been re­
ported in literature, including geometric errors (e.g., missing, duplicate,
and ill-formed/misplaced SBs) and non-geometric errors (e.g., missing
and inaccurate values of semantic attributes) [7,14,31,38]. These
quality issues could bring inaccuracies to the geometric input of a
building energy model and eventually cause inaccuracies in energy
simulation results. A systematic analysis of the quality issues and their
potential negative impacts on BEM is presented in Section 3. It is thus
critical to validate second-level SBs in an IFC model before extracting
and mapping them into native data models of BEM tools.
The validation of IFC second-level SBs should cover all the potential
quality issues, which essentially refer to the violation of constraints
relevant to their definition and implementation in IFC specifications.
buildingSMART [17] has officially issued Space Boundary Add-on View
(SBAV), a model view definition (MVD) to implement second-level SBs
in IFC. The SBAV includes a uniform and unambiguous IFC data struc­
ture to store their geometric and semantic information, a series of se­
mantic constraints on the attributes of relevant IFC entities involved in
the IFC data structure, as well as implementation agreements. A detailed
implementation guide was also developed for software vendors to
implement second-level SBs in their software development [18]. Both
the SBAV and the guide bind the IFC2x3 TC1 schema [19], which pro­
vides the IfcRelSpaceBoundary entity to define a second-level SB [see
Fig. 1(a)]. IFC4 specifications include a new entity named IfcRelSpace­
Boundary2ndLevel [20]. Compared to IfcRelSpaceBoundary, IfcRelSpace­
Boundary2ndLevel has two additional attributes, namely ParentBoundary
and CorrespondingBoundary [see Fig. 1(b)], to explicitly store two types
of essential relationships between two second-level SBs: the relationship
between an opening SB and its parent SB, and the relationship between
two corresponding SBs. To capture a full set of information requirements
of second-level SBs in IFC, Ying and Lee [13] have proposed to upgrade
SBAV (denoted as “upgraded SBAV” hereafter) based on the IFC4 ADD2
2
Automation in Construction 127 (2021) 103724
TC1 schema. Except the use of IfcRelSpaceBoundary2ndlevel, other main
upgrade contents include: (1) allowing to store simplified surface ge­
ometries of shading elements in the form of second-level SBs for BEM;
and (2) restricting the geometric representation of second-level SBs to a
simple polygon without holes in order to ease their use in downstream
BEM processes.
Currently, in the field of IFC model quality checking, some progress
has been made in establishing quality criteria for IFC model assessment
[21], MVD compliance checking to ensure accurate IFC-based data ex­
changes [22,23], and developing general rule-based IFC model checking
platforms (e.g., Solibri Model Checker) [24]. However, there still lack
reliable and efficient approaches/tools for IFC second-level SB valida­
tion. To address this gap, this study proposes an automatic rule-based
system to validate second-level SBs in an IFC instance file systemati­
cally and rigorously. The proposed system is developed by following the
general BIM rule checking development process presented by Eastman
et al. [24], which consists of four modules: rule interpretation, BIM data
extraction, rule checking execution, and validation result reporting. The
proposed system targets the upgraded SBAV developed by Ying and Lee
[13] due to its compatibility with the official SBAV and the IFC4 spec­
ifications. Validation rules implemented in the system are identified
from the syntactic and semantic constraints as well as implementation
agreements specified in the upgraded SBAV. These rules cover all the
types of quality issues of second-level SBs classified in Section 3.
In the remainder of this study, Section 2 reviews existing efforts
related to IFC model quality checking and second-level SB validation.
Section 3 classifies the quality issues of second-level SBs based on the
literature review and analysis of sample IFC models. Subsequently, a
rule-based validation system aiming at checking the quality issues is
developed in Section 4, followed by the system prototyping in Section 5.
Section 6 presents a case study to evaluate the performance of the pro­
posed system. Section 7 discusses limitations of the developed system
and implications for the validation of other IFC objects. Lastly, Section 8
concludes this study. For simplicity, hereafter, second-level SBs are
abbreviated as SBs.
2. Related work
With the increasing use of IFC as a standard format to exchange BIM
data among various domain professionals, checking the quality of an IFC
model has received increasing attention. Given that IFC data exchanges
are often based on specific MVDs, some efforts have focused on MVD
compliance validation, which aims to check whether the BIM data to be
exchanged are accurately and completely stored in an IFC instance file
by complying with all the semantic and syntactic constraints in the
H. Ying and S. Lee
Fig. 2. Examples of a syntactic error (a) and a semantic error (b).
target MVD [23]. To ensure robust IFC import and export functions of
software applications, buildingSMART [25] provides two IFC certifica­
tion programs for software vendors, including the IFC2x3 Coordination
View Certification and IFC4 Reference View and Design Transfer View
Certification. The programs check whether an IFC interface to be certi­
fied with an MVD conforms to relevant requirements of the target MVD
when it imports and/or exports a series of sample IFC files prepared by
the certification team in buildingSMART. Currently, the two certifica­
tion programs target three general MVDs, namely the IFC coordination
view version 2.0, the IFC reference view, and the IFC design transfer
view. However, all of them do not include the MVD concept of SBs.
Aiming at developing a general and automatic MVD compliance
validation approach, Lee et al. [22] identified types of rules dedicated to
MVD compliance checking and abstracted the logic of their checking
implementation, based on a systematic analysis of the data exchange
requirements in the American Precast/Pre-stressed Concrete Industry
(PCI) MVD [26]. The rule logic has been implemented in IfcDoc [27],
which is a tool released by buildingSMART with an initial objective of
helping users automatically generate MVD documents. Users can now
flexibly define and execute customized validation rules needed for their
own MVD validation on top of IfcDoc, as long as these rules fall in the
scope of the predefined rule logic in IfcDoc. This work made a sub­
stantial progress toward automated IFC model quality checking. How­
ever, it is limited to checking whether relevant BIM data are available,
and their forms are defined correctly in an IFC instance file, according to
the syntactic and semantic requirements in an MVD. It does not guar­
antee that the actual meaning of the correctly-formed BIM data is also
correct [21,28]. For example, this work is unable to identify whether a
SB defined as “EXTERNAL” via the InternalorExternalBoundary attribute
is really external or not. Furthermore, it does not include geometry-
3
Automation in Construction 127 (2021) 103724
related checking [28], which, however, should be one of the key con­
tents for SB validation.
Currently, several IFC viewers such as FZKViewer [29] and Solibri
Anywhere [30] are available to visually check SBs. However, this
visualization-based manual checking method is laborious and time-
consuming, and may become impractical for real-world building
models that may contain thousands or even tens of thousands of SBs.
Furthermore, according to Ying and Lee [31], there exist geometric er­
rors (e.g., duplicate SBs and inverse normal vector directions) in SBs that
cannot be visually checked in specific IFC viewers. Also importantly, this
method cannot check non-geometric issues in SBs.
Solibri Model Checker (SMC) provides a limited function to
automatically check SBs by implementing the rule “Space Bound­
aries” [32]. This rule consists of two sub-rules: (1) each SB should
have a relation to a building element; and (2) each space should have
enough SBs. The first sub-rule checks whether the value of the
attribute RealtedBuildingElement of each SB instance exists or not. For
the second sub-rule, SMC checks whether the total surface area of SBs
of a space is not less than 90% of the skin area of the space [32]. Ying
and Lee [31] have experimentally proven that the second sub-rule
implemented in SMC is not reliable and insufficient to check the
geometries of SBs. Again, SMC barely checks semantic data of SBs.
In summary, a systematic, reliable, and automated approach for
IFC SB validation is still missing. This study addresses this gap by first
investigating and classifying the potential types of quality issues in
SBs (Section 3), and then presenting a systematic rule-based vali­
dation system that can cover all these quality issues.
H. Ying and S. Lee
Fig. 3. An example of geometric errors of SBs.
3. Classification of errors in SBs
In this section, three types of SB-related errors in IFC models,
including syntactic and semantic errors, geometric errors, and consis­
tency errors, are introduced in the following three subsections, respec­
tively. These error types are identified based on literature review and the
analysis of four sample IFC models exported from BIM authoring tools,
including a syntactic one-storey model [38], a three-storey office model
[31], and a 27-storey student dormitory model and a 10-storey univer­
sity office model [13]. They serve as a basis to develop the SB validation
system. It is noteworthy that the examples used in this section are from
IFC2x3-based models, in which SBs are defined by IfcRelSpaceBoundary
rather than the IFC4 entity IfcRelSpaceBoudary2ndLevel that this study
focuses on. The reason is that almost all the current implementations of
SBs are still based on IFC2x3 specifications. However, this difference
does not affect the error classification.
3.1. Syntactic and semantic errors
The syntactic and semantic errors of SBs refer to the incompliances
with syntactic and semantic constraints in IFC specifications and rele­
vant MVDs. Fig. 2 illustrates this type of errors with two examples.
4
Automation in Construction 127 (2021) 103724
According to SBAV, the OuterBoundary attribute of an IfcRelSpaceBoun­
dary.ConnectionGeometry./…/.IfcCurveBoundedPlane instance should
refer to an IfcPolyline instance to define the polygonal geometry of a SB.
However, in the example of Fig. 2(a), that attribute refers to an Ifc­
CompositeCurve instance. Such a syntactic error would disable the
extraction of the geometric data of the SB if the extraction is conducted
by following the IFC data structure specified in SBAV. In Fig. 2(b), the
value of the Description attribute of an IfcRelSpaceBoundary instance is
missing, which, according to SBAV, should be either “2a” or “2b”. Such a
semantic error causes the loss of information essential to BEM because
this attribute indicates an important thermal feature of the SB: “2a”
means that heat transmission can occur through this SB, and “2b” means
that no heat transmission occurs through this SB. Therefore, syntactic
and semantic errors of SBs should be detected as they may bring diffi­
culties in or even disable the extraction of SBs from IFC models and may
indicate that the semantic information of SBs is incomplete or
inaccurate.
3.2. Geometric errors
Geometric errors of SBs arise from the incompliances with the
intrinsic geometric definition as well as geometry-related
H. Ying and S. Lee
Fig. 4. An example of the consistency error of a SB.
implementation agreements in relevant MVDs. For example, according
to an implementation agreement of SBAV, all non-opening SBs of a space
shall airtightly enclose that space without any gaps and overlaps [17].
Fig. 3 shows that all-sided SBs of a column are missing, resulting in that
all three spaces are not airtightly enclosed. Other frequently reported
geometric errors include duplicate SBs [14], ill-formed/misplaced SBs
[7,14], and SBs with an incorrect normal vector direction [14].
3.3. Consistency errors
A consistency error of a SB refers to the conflict or inconsistency
between the state specified by an attribute of the SB and its real state.
Fig. 4 shows a consistency error that an internal (“real state”) SB is
defined as external by the InternalOrExternalBoundary attribute of the
SB. Consistency errors can happen when the SB generation algorithm is
not reliable or robust. They should be detected as they indicate that
relevant SBs carry inaccurate information.
4. Development of the SB validation system
4.1. Validation framework and architecture of the validation system
To validate SBs in an IFC model systematically and rigorously, all
the three types of errors discussed in Section 3 should be addressed.
5
Automation in Construction 127 (2021) 103724
Fig. 5(a) presents a framework for the SB validation. It consists of three
successive validation steps, namely syntactic and semantic validation
(SSV), geometry validation (GV), and consistency validation (CV),
corresponding to each error type. Errors detected in each step should
be corrected for the next step. SSV needs to be implemented first
because the syntactic and semantic correctness of SBs ensures that
geometric and non-geometric data of SBs to be validated can be
correctly extracted, which serves as the foundation of GV and CV. GV is
implemented before CV because the geometric correctness of SBs
provides the basis for some CV contents, while consistency issues of
SBs do not affect the implementation of GV. Furthermore, the
correction of some geometric issues (e.g., some SBs are missing) may
introduce new SBs, which should also undergo the entire validation
process. Therefore, after correcting geometric issues, the updated IFC
model needs to go back to the first validation step (i.e., SSV) [see Fig. 5
(a)]. Once errors detected by all the three validation steps are fixed,
the IFC model with validated SBs is obtained.
As discussed in Section 3, errors of SBs essentially refer to the
violation of relevant constraints that SBs shall comply with. These
constraints encapsulate BIM-to-BEM geometric transformation
principles and geometry modeling requirements for energy simula­
tions in the context of IFC, which have been embedded into the
concept of SB specified by IFC4 specifications and the MVD of
upgraded SBAV. These constraints thus can be used as rules to
H. Ying and S. Lee
Fig. 5. Framework for SB validation (a) and architecture of the proposed system (b).
evaluate the quality of SB instances in an IFC model. Naturally, a
rule-based validation system is proposed to implement the validation
framework.
Fig. 5(b) shows the architecture of the proposed rule-based vali­
dation system. Corresponding to the three validation steps in the
framework, the system consists of three subsystems: the SSV subsys­
tem, the GV subsystem, and the CV subsystem. All the subsystems have
a similar system architecture, which is built by following the general
rule-based model checking process developed by Eastman et al. [24].
The system architecture consists of four functional modules, including
the rule interpretation module, the BIM data extraction module, the
rule checking execution module, and the validation result reporting
module [see Fig. 5(b)]. Each module in the three subsystems plays the
same role. The roles and functional features of all the modules are
explained as follows:
4.1.1. Module 1 for rule interpretation
Validation rules stem from the intrinsic concept of SBs as well as the
constraints and implementation agreements specified in IFC4 specifi­
cations and the upgraded SBAV. They are initially represented in a
natural language. This module converts them into computer codes so
that they are understandable and processable by computers. To be more
specific, the module includes programming language encoded algo­
rithms that implement these rules. The specific rules of the three sub­
systems and their interpretation algorithms are elaborated in Section
4.2, Section 4.3, and Section 4.4, respectively.
4.1.2. Module 2 for BIM data extraction
To validate SBs against the interpreted rules, relevant data should
be extracted from the input IFC instance file. These data can be
classified into two types: geometric and non-geometric data of SBs to
be validated and additional data required by the execution of rele­
vant rules. This module thus encompasses an IFC file parser and a set
of information extraction functions to extract all the data of interest.
6
Automation in Construction 127 (2021) 103724
Specifically, SB-related data are directly extracted based on the
unique IFC data structure (see Fig. 6) specified by the upgraded
SBAV. The second-type IFC data mainly include 3D solid geometries
of relevant building elements and space objects. Thanks to the
powerful geometry kernel of IFC parsers like IFC Engine library [37],
the triangulated polyhedron (i.e., triangle mesh) of an IFC object can
be directly generated. Based on it, other types of geometry repre­
sentations including polyhedron and axis-aligned bounding box
(AABB) can be easily obtained [13].
4.1.3. Module 3 for rule checking execution
tThis module executes the validations by applying the interpreted
rules to the extracted BIM data. Since all the rules have been converted
into computable codes by Module 1, and all the required data have
been prepared by Module 2, the rule checking execution is relatively
straightforward. The execution sequence is carefully designed based
on rules’ dependencies. A rule ra is defined as dependent on another
rule rb if the checking results of ra are affected by those of rb. To ensure
that the checking results of each rule are reliable, two principles
regarding the rule execution are introduced: 1) a rule is always
executed after the execution of its dependent rules; and 2) a rule is not
executed to SBs that already fail any dependent rules. However, these
two principles also cause an issue that SBs failing some rules lose a
chance to be checked by some other rules due to the dependencies.
This can be addressed by executing rules after correcting the errors
detected by their dependent rules.
4.1.4. Module 4 for validation result reporting
The validation results from Module 3 should be reported intui­
tively for easy reading by a human. Furthermore, since the valida­
tions aim to detect errors in SBs to facilitate error correction, only
SBs that fail validation rules and associated error explanations need
to be reported. This module thus provides a set of pre-defined
textural-format error reporting templates (see Appendix A) for
H. Ying and S. Lee Automation in Construction 127 (2021) 103724

Fig. 6. Type 1 SSV rules.

relevant validation rules, as well as geometric visualization functions

for better understanding and locating geometry-related errors (see
Table 1 Section 5).
Type 2 SSV rules.
4.2. Syntactic and semantic validation (SSV) rules and their
Entries Validation rules
interpretation
SR.1 Checking attributes of IfcRelSpaceBoundary2ndLevel instances
SR.1.1 IF RelatedBuildingElement ∈ {IfcDoor, IfcWindow, IfcOpeningElement,
IfcShadingDevice}, THEN ParentBoundary must refer to an
4.2.1. Rule identification
IfcRelSpaceBoundary2ndLevel instance. SSV aims to check whether SB instances in IFC models comply with
SR.1.2 For IfcRelSpaceBoundary2ndLevel./…/.IfcAxis2Placement3D, either the syntactic and semantic constraints specified in the IFC4 specifica­
both Axis and RefDirection are not given and therefore defaulted, or tions and the upgraded SBAV. Those constraints thus serve as sources to
both shall be given as two 3D vectors that are not parallel.
identify SSV rules. A total of 22 SSV rules are identified and classified
SR.2 Checking the existence of SBs
SR.2.1 The following building elements if available may provide SBs: walls into two types:
(IfcWall), curtain walls (IfcCurtainWall), slabs (IfcSlab), roofs (IfcRoof),
columns (IfcColumn), beams (IfcBeam), windows (IfcWindow), doors • Type 1 SSV rules: checking values of attributes of IFC entity instances
(IfcDoor), voids (IfcOpeningElement), virtual elements (i.e., space involved in defining a SB and the reference relationships between
separators; IfcVirtualElement).
SR.2.2 The following elements if available shall not provide SBs: stairs (IfcStair)
those IFC instances.
and ramps (IfcRamp). • Type 2 SSV rules: including all other rules such as rules that check the
SR.3 Checking SBs of openings values of attributes that have dependencies with other attributes.
SR.3.1 SBs of windows and doors shall refer to corresponding IfcWindow and
IfcDoor instances rather than the IfcOpeningElement instances via the
For clarity, Type 1 SSV rules are elicited from relevant IFC entities
RelatedBuildingElement attribute.
SR.4 Checking SBs of aggregate elements and attributes depicted in Fig. 6, while Type 2 SSV rules are listed in
SR.4.1 SBs of aggregate elements, including curtain walls and roofs, shall Table 1. In this study, only IFC supertype entities (e.g., IfcWall for wall)
refer to are listed, and their subtype entities (e.g., IfcWallStandardCase and Ifc­
corresponding IfcCurtanWall and IfcRoof instances rather than their WallElementedCase) are omitted. The interpretation of Type 1 and Type 2
component element instances.
SSV rules are discussed in Section 4.2.2 and Section 4.2.3, respectively.
The bold ones are categories of the validation rules and actual rules are
listed right below each category.

7
H. Ying and S. Lee
Fig. 7. Implementing Type 1 and Type 2 SSV rules on top of IfcDoc v8.8.
4.2.2. Type 1 SSV rules
All the Type 1 SSV rules are implemented on top of IfcDoc (see
Fig. 7), except the following two rules (coded as SR.0.1 and SR.0.2):
• SR.0.1: The Coordinates attribute of an IfcRelSpaceBoundary2nd­
Level./…/.IfcAxis2Placement3D.Location.IfcCartesianPoint
instance shall have three values.
• SR.0.2: The Coordinates attribute of an IfcRelSpaceBoundary2nd­
Level./…/.IfcPolyline.Points.IfcCartesianPoint instance shall have
two values.
This study adopts IfcDoc v8.8 because tests conducted by the authors
show that the MVD validation functions of newer versions (e.g., v11.2
and v12.2) are not robust and cannot always run successfully. IfcDoc
v8.8 has a limited ability to check cardinality. It only supports the op­
tions of As Schema (i.e., according to cardinality constraints of the IFC
schema), Zero (i.e., List[0]), Zero-To-One (i.e., List[0:1]), One (i.e., List
[1]), and One-To-Many (i.e., List[1:?]). It thus does not cover the car­
dinality checking situations of SR.0.1 and SR.0.2, which are hardcoded
8
Automation in Construction 127 (2021) 103724
together with Type 2 SSV rules. Error reporting templates of the two
rules are included in Appendix A. No templates are designed for the rules
implemented in IfcDoc as the tool provides user-friendly validation
result reporting functions, which are detailed in Section 6.
4.2.3. Type 2 SSV rules
Type 2 SSV rules include four rules, most of which cannot be defined
in IfcDoc v8.8. They are implemented as follows:
4.2.3.1. SR.1: Checking attributes of IfcRelSpaceBoundary2ndLevel
instances. As shown in Table 1, this rule has two sub-rules. The first IF-
THEN sub-rule (i.e., SR.1.1) checks whether or not the ParentBoundary
attribute of a SB that satisfies the IF clause refers to an IfcRelSpace­
Boundary2ndLevel instance. SR.1.2 checks the coexistence of the attri­
butes Axis and RefDirection of an IfcAxis2Placement3D instance. When
⃑ ⃑
the values of both attributes (i.e., two 3D vectors; denoted as na and nb )
exist, their parallelism is further checked: they are considered to be
H. Ying and S. Lee Automation in Construction 127 (2021) 103724

Fig. 8. Potential reference relationships between an opening and its SBs.

⃒⃒ ⃒ ⃒
⃒⃒
⃒⃒
⃒
⃒
⃒
⃒ BEM provide SBs, and SR.2.2 checks whether elements irrelevant to BEM
⃒⃒ n⃑ ∙n⃑ ⃒ ⃒ do not provide SBs. Both sub-rules are implemented by checking
⃦ ⃑ ⃦⃦ ⃑ ⃦ ⃒ − 1 ⃒ ≤ 0.0001, and the corresponding SB is
parallel if ⃒⃒⃒⃒⃦ a ⃦b ⃦ ⃒
⃦ ⃒
⃒⃒⃦na ⃦⃦nb ⃦ ⃒ ⃒ whether the inverse attribute ProvidesBoundaries of relevant elements
⃒⃒ ⃒ ⃒
refer to at least one SB instance or not. Note that the current imple­
determined to fail SR.1.2. mentation distinguishes building elements relevant or irrelevant to BEM
by their IFC instance types, which may cause false positive checking
4.2.3.2. SR.2: Checking the existence of SBs. This rule also consists of results. For example, IfcWall instances that neither bound interior spaces
two sub-rules: SR.2.1 checks whether building elements essential to nor shade the building should not provide any SBs. However, SR.2.1

Fig. 9. Potential reference relationships between a roof and its SB instances.

9
H. Ying and S. Lee Automation in Construction 127 (2021) 103724

Table 2 Textural error reporting templates of these rules can be found in Ap­
GV rules. pendix A.
Entries Validation rules
4.3.2. GR.1: Checking the geometric representation of SBs
GR.1 Checking the geometric representation of SBs
GR.1.1 The geometry of each SB shall be a simple polygon. This rule aims to check the validity of the geometric definition of
GR.1.2 Non-shading SBs and shading SBs shall be defined with a normal vector each SB. It includes two sub-rules: GR.1.1 and GR.1.2.
pointing outward the relating space and the related building element,
respectively. (1) GR.1.1: The geometry of each SB shall be a simple polygon.
GR.2 Checking the airtightness of a space
GR.2.1 Any space should be airtightly enclosed by relevant SBs that are relating
to the space. Geometrically, a simple polygon is a planar shape bounded by a
closed path which consists of non-intersecting and pairwise joined line
The bold ones are categories of the validation rules and actual rules are listed
segments. It has four geometric constraints as follows: 1) it is a planar
right below each category.
shape; 2) it is bounded by a closed polyline; 3) it has no holes; and 4) it
has no self-intersections. Fig. 10 illustrates the cases of non-simple
would still report errors for these IfcWall instances. Therefore, checking
polygons that violate these geometric constraints.
results of SR.2 require manual analysis.
As shown in Fig. 6, the geometry of a SB is schematically defined as a
2D polyline by using an IfcPolyline instance, which refers to a set of
4.2.3.3. SR.3: Checking SBs of openings. This rule checks whether the IfcCartesianPoint instances to define 2D vertices. Therefore, SBs that
RelatedBuildingElement attribute of opening SBs refer to a correct satisfy SSV rules automatically meet the first (as all vertices are 2D) and
building element instance. As shown in Fig. 8(a), for SBs of a window or the third constraints (as an IfcPolyline instance can only define a poly­
a door, the RelatedBuildingElement attribute should refer to the corre­ line). For a SB, the compliance with the second constraint is confirmed if
sponding IfcWindow or IfcDoor instance rather than the associated the following conditions hold: 1) its polyline has at least four vertices; 2)
IfcOpeningElement instance. This rule is applied to SB instances that refer the first vertex is the same as the last one; and 3) all edges of the polyline
to an IfcOpeningElement instance. For each of those SB instances, the rule are valid (i.e., any two adjacent vertices should not be the same). The
checks whether the IfcOpeningElement instance fills a window or a door
through an IfcRelFillsElement relationship. If not, the SB instance is
acknowledged to pass this rule [see Fig. 8(b)].

4.2.3.4. SR.4: Checking SBs of aggregate elements. This rule checks

whether SBs of an aggregate element (e.g., IfcRoof) refer to the element
via the RelatedBuildingElement attribute. As shown in Fig. 9, for a roof, its
SBs should refer to the corresponding IfcRoof instance rather than its
components such as IfcSlab and IfcBeam instances. This rule is imple­
mented in two steps. First, all the components of an aggregate element
are identified through the IfcRelAggregates relationship (see Fig. 9). Then
for each component, its related SBs are found through the inverse
attribute ProvidesBoundaries. All these SBs are confirmed to fail this rule.

4.3. Geometry validation (GV) rules and their interpretation

4.3.1. Rule identification

GV rules are identified according to the intrinsic geometric concept
of SBs as well as relevant implementation agreements specified in the
IFC4 specifications and the upgraded SBAV. Table 2 lists three essential
GV rules. As explained in Section 4.1, GV rules apply to SBs that satisfy
SSV rules to ensure reliable validation results. The algorithmic in­
terpretations of these rules are detailed in the following subsections. Fig. 11. Illustration of the implementation of GR.1.2.

Fig. 10. Cases of non-simple polygons: (a) non-planar polygon; (b) open polygon; (c) polygon with a hole; and (d) polygon with self-intersections.

10
H. Ying and S. Lee
Table 3
CV rules.
Entries Validation rules
CR.1 Checking the consistency of IfcRelSpaceBoundary2ndLevel.
Description/InternalOrExternalBoundary
CR.1.1 IF Description = “2a” AND InternalOrExternalBoundary = “INTERNAL”,
THEN the object on the other side of the RelatedBuildingElement of the SB
must be a space.
CR.1.2 IF Description = “2a” AND InternalOrExternalBoundary = “EXTERNAL”,
THEN the object on the other side of the RelatedBuildingElement of the SB
must be an outdoor environment.
CR.1.3 IF Description = “2a” AND InternalOrExternalBoundary = “
EXTERNAL_EARTH”, THEN the object on the other side of the
RelatedBuildingElement of the SB must be a site object.
CR.1.4 IF Description = “2b”, THEN the object on the other side of the
RelatedBuildingElement of the SB must be a non-shading element.
CR.1.5 IF Description = “Shading”, THEN the SB should not bound any interior
spaces.
CR.1.6 IF Description = “2a” AND InternalOrExternalBoudary = “INTERNAL”,
THEN CorrespondingBoundary must refer to an
IfcRelSpaceBoundary2ndLevel instance.
CR.2 Checking the consistency of IfcRelSpaceBoundary2ndLevel.
RelatingSpace/RelatedBuildingElement
CR.2.1 IF the RelatingSpace of a SB is a space object, THEN the SB must be
included by a relevant face of the RelatingSpace.
CR.2.2 IF the RelatedBuildingElement of a SB is not a virtual element, THEN the
SB must be included by a relevant face of the RelatedBuildingElement.
Note: IF the RelatedBuildingElement of the SB is a window or a door,
THEN the SB must be included by a relevant face of the
IfcOpeningElement instance that
fills the window or the door.
CR.3 Checking the consistency of IfcRelSpaceBoundary2ndLevel.
PhysicalOrVirtualBoundary
CR.3.1 IF PhysicalOrVirtualBoundary = “PHYSICAL”, THEN
IfcRelSpaceBoundary2ndLevel.RelatedBuildingElement ∕ ∈ {IfcVirtualElement,
IfcOpeningElement}.
CR.3.2 IF PhysicalOrVirtualBoundary = “VIRTUAL”, THEN
IfcRelSpaceBoundary2ndLevel.RelatedBuildingElement ∈ {IfcVirtualElement,
IfcOpeningElement}.
CR.4 Checking the consistency of IfcRelSpaceBoundary2ndLevel.
ParentBoundary
CR.4.1 IF ParentBoundary of a SB is another SB AND Description != “Shading”,
THEN the SB must be included by that SB.
CR.4.2 IF ParentBoundary of a SB is another SB AND Description = “Shading”,
THEN the SB must connect that SB.
CR.5 Checking the consistency of IfcRelSpaceBoundary2ndLevel.
CorrespondingBoundary
CR.5.1 IF CorrespondingBoundary of a SB is another SB, THEN the SB must fully
overlap that SB after projecting the SB on the plane where that SB lies.
The bold ones are categories of the validation rules and actual rules are listed
right below each category.
fourth constraint is satisfied if any of the edges do not have intersections
with the other edges unless the intersections occur at their shared
vertices. Checking this constraint involves a series of 2D line segment-
line segment intersection tests.
(2) GR.1.2: Non-shading SBs and shading SBs shall be defined with a
normal vector pointing outward the relating space and the related
building element, respectively.
Checking a non-shading SB and a shading SB by this rule is algorith­
mically equivalent. For the sake of brevity, the core algorithm implementing
this rule to a non-shading SB is explained. First, the current normal vector
⃑ essentially involves the polygon (SB)-polyhedron (space) connection
direction (nc ) of the SB is inferred from its polygon geometry (PolygonSB) by
using the Newell’s method [39]. Second, a point that lies in PolygonSB is
selected. To perform the step robustly, PolygonSB is triangulated first by
using the ear clipping method [33], and then the centroid of a triangle is
⃑
computed and used (see p in Fig. 11). Third, the point is offset along with nc
by a small distance (e.g., 10 mm) (see p′ in Fig. 11). Lastly, the spatial
relationship between the offset point and the relating space is computed by
11
Automation in Construction 127 (2021) 103724
using a point-in-polyhedron test [13] based on the AABB and triangulated
polyhedron representations of the space. If the point is checked to lie outside
⃑
the space (see p′ in Fig. 11), nc is determined as pointing outward the space
⃑
(i.e., the SB passes GR.1.2); otherwise, nc points inward the space (i.e., the
SB fails GR.1.2).
4.3.3. GR.2: Checking the airtightness of a space
This rule checks whether a set of SBs relating to a common space
airtightly bounds the space or not. This rule only applies to SBs provided
by non-opening non-shading elements as opening SBs (fully included in
their parent SBs like wall SBs) and SBs of shading elements (directly
exposed to the outdoor environment) do not contribute to enclosing
their relating spaces. Furthermore, since CR.2.2 in Section 4.4.3 uni­
formly checks SBs’ connections with their relating spaces, this rule can
be simplified to check whether the set of SBs forms a confined “space”.
This rule has been implemented in Ying and Lee [31], where a reliable
and efficient Monte Carlo ray tracing approach was developed. In this
study, the configuration of relevant algorithmic parameters follows their
recommendations [31]: adopting AABB tree-based ray tracing strategy
without tree depth limit, and setting the number of rays per triangulated
SB as 2000.
It is noteworthy that the Monte Carlo ray tracing approach works on
SBs that have a valid polygon (i.e., satisfying GR.1.1). Moreover,
although this approach can detect non-airtight spaces caused by various
geometric errors in SBs including incorrect normal vector directions, it
cannot automatically distinguish specific error types. Therefore, GR.1.2
aiming at checking incorrect normal vector directions of SBs is specif­
ically implemented.
4.4. Consistency validation (CV) rules and their interpretation
4.4.1. Rule identification
CV rules aim to check whether the state specified by each semantic
attribute of a SB instance is consistent with its real state. Table 3
summarizes 13 CV rules that involve seven semantic attributes of
IfcRelSpaceBoundary2ndLevel. Most of these rules require a SB instance
to have a valid polygon geometry and/or a correct normal vector di­
rection, i.e., having dependencies on GR.1. The algorithmic imple­
mentations of these rules are detailed in the following subsections.
Their error reporting templates can be found in Appendix A. Note that
most of these implementations involve the use of IFC geometric data in
the GCS, such as polygons (including triangulated polygons) and
normal vectors of SBs and AABBs and polyhedrons (including trian­
gulated polyhedrons) of spaces and building elements. The prepara­
tion methods of these data have been explained in Section 4.1 and
Section 4.3.2.
4.4.2. CR.1: Consistency of Description and InternalOrExternalBoundary
This rule checks the consistencies of two semantic attributes
Description and InternalOrExternalBoundary of each SB instance
together. As shown in Table 3, it consists of six IF-THEN sub-rules. The
last sub-rule (i.e., CR.1.6) can be directly implemented. The first five
sub-rules correspond to the five potential combinations of the values of
the two attributes. For each SB that has a “Shading” value for the
Description attribute, the sub-rule CR.1.5 checks whether the SB bounds
any interior spaces: if yes, it fails CR.1.5. The implementation of CR.1.5
test, the technical details of which are explained in Section 4.4.3.
For the remaining four sub-rules (i.e., CR.1.1, CR.1.2, CR.1.3, and
CR.1.4), the core of their implementations is to compute the status on
the other side of the related building element of relevant SBs (i.e., SBs
satisfying the IF clauses of the four sub-rules). For instance, a SB
satisfying the IF clauses of CR.1.1 is checked to see whether the other
side is a space. If not, the SB is acknowledged failing CR.1.1. Fig. 12
illustrates the algorithms implementing the four sub-rules.
H. Ying and S. Lee Automation in Construction 127 (2021) 103724

Fig. 12. Implementations of CR.1.1, CR.1.2, CR.1.3, and CR.1.4.

All the algorithms consist of three steps and the first two steps are
identical. First, for a SB targeted by any of the four sub-rules, the
triangulated polygon and normal vector in the GCS are prepared.
Second, the centroid of any one of the triangles is calculated and
further offset along the direction of the normal vector by a distance
(dist) slightly larger than the thickness of the related building element
(see Fig. 12). The thickness is directly extracted from the material
thickness of the related element (if available in the IFC model) or
computed based on the solid geometry of that element. In the third
step, the algorithms of the four sub-rules differ from each other. Spe­
cifically, the compliance with CR.1.1 and CR.1.3 is confirmed when
the offset centroid (oc) lies in a space (see p1′ in Fig. 12) and a site

Fig. 13. Illustration of (a) the geometric relationships of a window SB and SBs of a shading element with their parent SBs, (b) a top view of a simple building model
with a shading element, (c) SBs of the model where shading SBs are not offset, and (d) SBs of the model where shading SBs are offset.

12
H. Ying and S. Lee
Fig. 14. Illustration of two corresponding SBs (a) and their correspondence relationship checking (b).
object (see p3′ in Fig. 12), respectively. The compliance with CR.1.4 is
confirmed if oc lies in a building element (see p4′ in Fig. 12), the
relating space (when the SB is internal and has a corresponding SB; see
p5′ in Fig. 12), or an arbitrary space (when the SB is internal and
without a corresponding SB; see p6′ in Fig. 12). A SB passes CR.1.2 if oc
does not lie in any spaces, non-shading elements, and sites (see p2′ in
Fig. 12). It is noteworthy that if oc lies in a shading element (see p7′ in
Fig. 12), the SB also passes CR.1.2. In this study, building elements that
do not connect any spaces are computed as shading elements (in fact,
they also include elements fully embedded in other elements; this does
not affect the implementation of CR.1.2). Based on the point-in-
polyhedron and polyhedron-polyhedron connection tests [13], the
last step of all the above algorithms can be easily implemented.
4.4.3. CR.2: Consistency of RelatingSpace and RelatedBuildingElement
This rule consists of two sub-rules aiming to check the consistencies
of the attributes RelatingSpace and RelatedBuildingElement of each SB
instance, respectively. CR.2.1 is restricted to SBs bounding any interior
spaces [i.e., TypeOf(IfcRelSpaceBoundary2ndLevel.RelatingSpace) = Ifc­
Space]. CR.2.2 excludes SBs provided by virtual elements that do not
have geometries [i.e., TypeOf(IfcRelSpaceBoundary2ndLevel.Rela­
tedBuildingElement) = IfcVirtualElement]. Furthermore, when imple­
menting CR.2.2 for SBs of doors and windows, solid geometries of the
corresponding opening voids (i.e., IfcOpeningElement) are used because
these SBs are often generated from the voids rather than doors and
windows themselves [11,13].
The implementations of the two sub-rules are algorithmically
equivalent, both checking the connection between a polygon (i.e., the
geometry of a SB) and a polyhedron (i.e., the geometry of the relating
space for CR.2.1 or the geometry of the related building element for
CR.2.2). Here, the connection refers to the inclusion (or full overlap) of
the polygon (P) by (or with) a face (f) of the polyhedron. Such a polygon-
polyhedron connection test is conducted with two steps. First, for the
polyhedron, the faces coplanar with the polygon are identified by using
the coplanarity checking method proposed in Ying and Lee [13]. Then,
the connection test returns a true value if there exists a face among the
Area(P)
identified faces satisfying the condition: Area(PInter3D(f,P) ) ≥99.99%, where
Area is a function to calculate the area of a 3D polygon, and PInter3D
refers to the 3D polygon Boolean operator “Intersection” that computes
13
Automation in Construction 127 (2021) 103724
the polygonal boundaries of the common regions of input polygons. In
this study, Area and PInter3D are implemented by extending relevant 2D
functions in libraries NetTopologySuite v1.15.3 [34] and Clipper v6.1.3
[35] into 3D space.
4.4.4. CR.3: Consistency of PhysicalOrVirtualBoundary
This rule checks the consistency of the PhysicalOrVirtualBoundary
attribute of each SB. It consists of two IF-THEN sub-rules corresponding
to two potential values of this attribute. These two sub-rules are
implemented straightforwardly by checking whether the type of the
RelatedBuildingElement instance of each SB is correct against their THEN
clauses.
4.4.5. CR.4: Consistency of ParentBoundary
This rule checks the consistency of the ParentBoundary attribute of
relevant SBs. It consists of two sub-rules, one targeting opening SBs (i.e.,
CR.4.1) and the other targeting shading SBs (i.e., CR.4.2). Fig. 13 il­
lustrates the geometric relationships between the two types of SBs and
their parent SBs, which serve as the algorithmic basis to implement the
two sub-rules. Note that all SBs of a shading element are checked
together as they have the same parent SB.
CR.4.1 checks whether SBs of an opening (i.e., windows, doors, and
voids) are geometrically included by their parent SBs [see Window SB
and its parent Wall SB in Fig. 13(a)]. Given an opening SB (sbO) and its
parent SB (sbOP), their geometric inclusion relationship can be
confirmed if the following two conditions are satisfied: IsCoplanar(sbO,
sbOP) = true and Area(sbO )
≥99.99%, where IsCoplanar com­
Area(PInter3D(sbO ,sbOP ) )
putes the coplanarity of two 3D polygons [13]. The meaning and
implementation methods of Area and PInter3D have been explained in
Section 4.4.3.
The implementation of CR.4.2 considers two different shading SB
generation methods. The first method generates SBs of a shading
element (SE) by offsetting relevant faces of SE by the thickness (δt) of the
external building element that SE touches [15]. The resulting SBs
directly attach to some external SBs [i.e., the parent SBs; see Fig. 13(d)].
The second method does not include such offset [13]. The resulting SBs
thus have a gap (i.e., δt) with their parent SBs [see Fig. 13(c)].
For the SBs of SE in the first case, CR.4.2 checks if there exists one SB
that has an edge (i.e., a line segment) included in its parent SB (i.e., a
H. Ying and S. Lee Automation in Construction 127 (2021) 103724

Fig. 15. The user interface of the prototype application.

polygon). This check relies on the line segment-in-polygon test, which is SBs are checked together.
implemented with two steps. First, the test checks whether the line Geometrically, two corresponding SBs fully overlap with each other
segment (l) is on the plane where the polygon (p) lies by: after projecting them along with their normal directions onto a common
⃒⃑ ⃒⃑
⃒ ⃒ ⃑ plane that they are parallel to [see Fig. 14]. Thus, the implementation of
⃒L P∙n⃒ ≤ 0.0001, where L P refers to a vector starting from an endpoint
this rule includes two stages. First, the parallelism of the two SBs is
⃑
of l to a vertex of p, and n is the normal vector of p. If the first-step checked. Two parallel SBs should meet the condition:
⃒⃒ ⃒ ⃒
⃒⃒ ⃑ ⃑ ⃒ ⃒
checking passes, the test further checks whether both endpoints of l lie ⃒⃒n1 ∙n2 ⃒ − 1 ⃒ ≤ 0.0001, where n⃑ 1 and n⃑ 2 refer to the normal vectors of
⃒⃒ ⃒ ⃒
inside/on p by using the point-in-polygon test algorithm [36]. In case of
the SBs of SE generated by the second method, CR.4.2 checks whether the two SBs in the GCS, respectively. An error is reported if they are not
there exists a SB (sbc) that has a distance of δt from the parent SB (sbp). parallel. Otherwise, they proceed to the second stage by orthographi­
Here, the distance between sbc and sbp refers to the smallest value of the cally projecting them on a parallel plane, and then checking whether the
distances between the vertices of sbc and the plane of sbp. If such a SB is following two conditions are satisfied simultaneously:
Area(A) Area(B)
detected, all the SBs of SE are acknowledged to pass CR.4.2; otherwise, Area(PInter3D(A,B) ) ≥99.99% and Area(PInter3D(A,B) ) ≥99.99%, where A and B
all SBs fail CR.4.2. refer to the polygons of the two SBs after the projection.

4.4.6. CR.5: Consistency of CorrespondingBoundary 5. System prototyping

This rule checks the consistency of the CorrespondingBoundary attri­
bute of relevant SB instances. The correspondence relationship between The system functions for most of Type 1SSV rules have been imple­
two SBs is defined twice by that attribute of each one. Hence, pairwise mented on top of IfcDoc (see Fig. 7). A prototype application is also

14
H. Ying and S. Lee
Fig. 16. The test IFC model: (a) solid geometry representation; and (b) SB representation.
developed in C# to implement the remaining SSV rules and all CV and
GV rules. Fig. 15 shows the user interface of the prototype application. It
consists of several interactive components, including three toolbar
buttons and five information visualization panels, which enable users to
conveniently conduct SB validations and intuitively check the validation
results. The roles, functions, and development methods of these com­
ponents are briefed as follows.
5.1. “File”, “Validation”, and “View” buttons
The “File” button allows users to import an IFC STEP-P21 file, which
are parsed based on the embedded IFC Engine library [37]. Data
required by relevant validation rules can then be extracted by the BIM
data extraction module. The “View” button provides two modes (i.e.,
Surface mode and Wireframe mode) to visualize the geometries of SBs in
Geometry Visualization Panel (GVP). Clicking the “Validation” button
launches the validation processes.
5.2. IFC model tree panel (IMTP) and GVP
IMTP displays important information of each SB instance extracted
from the input IFC file, including instance name, semantic attributes,
and geometric data in the LCS of the SB instance and the LCS of the
relating space (see the grey-color items in IMTP in Fig. 15). All the SB
instances are organized in a hierarchical tree structure, which basically
follows the spatial structure of IFC4 ADD2 TC1 schema. GVP visualizes
3D surface geometries of SBs and solid geometries of spaces, which is
developed based on the DirectX-based viewer provided by RDF [37].
GVP employs a color-coding method to differentiate SBs of different
elements (see Fig. 15): SBs of IfcOpeningElement or IfcVirtualElement,
IfcWindow, IfcDoor, shading elements, and other elements are visualized
in red, blue, pink, deep green, and grey, respectively. In addition, spaces
are visualized in green. IMTP can bi-directionally interact with GVP: by
selecting a tree node in IMTP, all geometric items contained in its sub-
tree are displayed in GVP, and vice versa.
5.3. Rule panel (RP), rule description panel (RDP) & error reporting
panel (ERP)
RP lists all the validation rules in a tree structure. By clicking a rule in
RP, users can check the description of its sub-rules in RDP. RP also
embeds an interactive and color-coded reporting function. Once the
validation process is completed, rules in RP that detect failures, that are
fully satisfied, and that are not executed are highlighted in red, green-
yellow, and white, respectively (see Fig. 15). By clicking any rules
color-coded in red, a corresponding template-based report is automati­
cally prepared in ERP. A checking report often contains error de­
scriptions in natural language together with tree nodes that contain
15
Automation in Construction 127 (2021) 103724
names of invalid or relevant IFC instances. If such a tree node is clicked,
ERP is capable of recognizing the contained instances and locating them
in IMTP (i.e., highlight relevant nodes in IMTP in red; see Fig. 15).
6. System validation
6.1. Test model preparation
To validate the feasibility of the proposed system, an IFC model that
represents one story of a student dormitory building at the University of
Hong Kong is used [see Fig. 16(a)]. The model contains main building
elements (e.g., walls, doors, windows, opening voids, slabs, and shading
elements) essential to BEM. A total of 820 SBs [see Fig. 16(b)] were
added to the model by using an initial version of the SB generation
prototype application developed by Ying and Lee [13]. Then, the
enriched IFC model is validated by the proposed system implemented on
IfcDoc and the prototype application developed in Section 5. This sec­
tion focuses on verifying the implementation of relevant validation rules
and detected errors were not corrected.
6.2. SSV subsystem validation
SBs in the test model were first validated against relevant SSV
rules implemented in IfcDoc. Fig. 17(a) and (b) show validation re­
sults in the user interface of IfcDoc and the summary report in HTML
format produced by IfcDoc. As seen in Fig. 17(a), all the checked SB
instances are displayed in the right window, and SBs satisfying all the
relevant rules are flagged with green. The validation results show
that all SB instances in the test model pass all these SSV rules in
IfcDoc.
SBs of the test model were further validated against the SSV rules
implemented in the prototype application. As seen from RP in
Fig. 18, three SSV rules (i.e., SR.1, SR.2, and SR.3) are not fully
satisfied due to the detection of relevant issues in SB instances.
Specifically, among SR.1, the sub-rule SR.1.1 detects two SB in­
stances that lack a value for their ParentBoundary attribute (see ERP
in Fig. 18). Based on their RelatedBuildingElement attribute, the two
SBs are all provided by a void opening (i.e., IfcOpeningElement) (see
the example of a defective SB #38276 in IMTP in Fig. 18). According
to SR.1.1 (see RDP in Fig. 18), they should have a parent SB defined
via their ParentBoundary attribute. Therefore, SR.1.1 flags them as
fails correctly.
Fig. 19 shows the issues detected by SR.2 and SR.3. SR.2.1 reports
all doors in the test model that do not have any associated SBs [see
ERP in Fig. 19(a)]. These doors should provide SBs as they bound
spaces. SR.3.1 reports all SBs that refer to a void opening that fills a
door via their RelatedBuildingElement attribute [see ERP in Fig. 19
(b)]. They should refer to a door instance rather than a void opening
H. Ying and S. Lee
Fig. 17. Validation results of relevant SSV rules in IfcDoc: (a) results in the user interface; and (b) summary of results in the HTML format.
instance. Clearly, the issues reported by the two rules are naturally
the same.
6.3. GV subsystem validation
In this section, SBs in the test model are validated against the GV
rules implemented in the prototype application. As seen from RP in
Fig. 20(a), both GV rules (i.e., GR.1 and GR.2) detect quality issues in
SBs. From GR.1, the sub-rule GR.1.2 reports that one SB instance has
an incorrect surface normal vector, which points inward rather than
outward the relating space [see ERP in Fig. 20(a)]. The reported SB
instance and its surface normal vector as well as other SBs that bound
the same space with the reported SB are visualized in Matlab [see
Fig. 20(b)].
Fig. 21 shows the validation results against GR.2. A total of 5 spaces
16
Automation in Construction 127 (2021) 103724
that are not airtightly enclosed by relevant SBs are reported [see ERP
in Fig. 21(a)]. These spaces are non-airtight due to missing or floating
SBs. Fig. 21(a) shows a non-airtight space where two SBs are missing.
Fig. 21(b) displays a non-airtight space where a SB is slightly floating
from its correct position, resulting in extremely small gaps between
this SB and their adjacent SBs as visualized in Matlab [see Fig. 21(c)].
6.4. CV subsystem validation
In this section, SBs in the test model are validated against CV rules
implemented in the prototype application. As seen on RP in Fig. 22, the
model satisfies all the CV rules except CR.1, CR.2 and CR.4. In CR.1,
the sub-rule CR.1.4 detects a collection of defective SB instances (see
ERP in Fig. 22). The Description attribute values of all these SB in­
stances is “2b”. However, CR.1.4 computes that the object on the other
H. Ying and S. Lee
Fig. 18. Validation results of SR.1 in the prototype application.
side of their related building elements is neither a building element nor
a space, which means their Description attribute values should not be
“2b”. In fact, all these SB instances do not bound any thermal spaces,
but they are provided by implicit shading elements, which play a role
of a shading device but are not explicitly defined by IfcShadingDevice
(see GVP in Fig. 22). Their Description attribute values should thus be
“Shading”.
In CR.2, the sub-rule CR.2.2 detects four SB instances that do not
connect their related building elements, as seen on ERP in Fig. 23(a).
More specifically, these SB instances shifts from their locations toward
their related building elements. Fig. 23(b) illustrates the shift with one
of the SB instances (i.e., #36232). In fact, their placement deviations
cause two non-airtight spaces (i.e., #1179 and #1228), which have
been reported by GR.2 [see ERP in Fig. 21(b)].
Fig. 24 shows the validation results against CR.4, in which the sub-rule
CR.4.1 detects a total of 14 defective SB instances (see ERP in the figure).
All these SB instances are provided from windows. CR.4.1 computes that
they are not geometrically included in their parent SBs specified via their
ParentBoundary attribute. In other words, the ParentBoundary attribute
values of these SB instances are incorrect. Based on the interactive func­
tions between ERP, IMTP, and GVP, it is easy to understand the issues and
find the correct parent SBs for them (see GVP in Fig. 24).
17
Automation in Construction 127 (2021) 103724
7. Discussion
7.1. Limitations and future developments
The experiment with an IFC model of a real-world building demon­
strates the reliability, efficiency, and user-friendliness of the proposed
SB validation system. However, there are some limitations that need to
be addressed further.
First, the proposed system requires that all the interior spaces in the
input IFC model must be completely defined and there should be no
external space objects. Missing interior spaces probably indicate that
there are missing SBs as SBs are usually generated from the common
boundaries between spaces and their surrounding objects. These missing
SBs cannot be detected by the proposed system. The existence of
external spaces probably indicates that there are unnecessary SBs as
external spaces do not contribute to energy simulation. GR.2 in the
proposed system would probably report that external spaces are not
fully enclosed by relevant SBs but cannot recognize that those SBs are
from external spaces and unnecessary. In addition, the missing of inte­
rior spaces and existence of external objects may affect the results of
checking SBs of existing interior spaces against CR.1. Currently, both
cases can be manually checked by using IFC viewers (e.g., FZKViewer
H. Ying and S. Lee Automation in Construction 127 (2021) 103724

Fig. 19. Validation results of SR.2 (a) and SR.3 (b) in the prototype application.

[29]) that can visualize space objects or automatically checked by
implementing the Space Validation rule of SMC [32]. However, there
still lack methods and/or tools to automatically fix these issues in IFC
models, which needs further studies. Users can manually fix them in BIM
authoring tools and then export new qualified IFC models and further
regenerate second-level SBs, which can now be validated with the pro­
posed system.
Second, the implementation of some validation rules requires data in
addition to the SB definition, which are assumed to be correctly con­
tained in the input IFC model. For instance, the algorithm implementing

18
H. Ying and S. Lee
Fig. 20. Validation results against GR.1 in the prototype application (a) and error visualization in Matlab (b). Note: in (b), the direction of the normal vector of the SB
is from • to △.
SR.3.1 leverages the relationships (i.e., IfcRelFillsElement) between
windows/doors and the corresponding opening voids that fill them. The
implementations of GR.2.1, CR.1 and CR.2 use polyhedral geometries of
relevant spaces and/or building elements. The missing, inaccuracy, or
incompleteness of these data in the input IFC model could result in
unreliable validation results of relevant rules. Thanks to the IFC software
certification programs introduced by buildingSMART [25], most certi­
fied BIM authoring tools can reliably export these data in IFC. However,
there is a risk to fail when obtaining polyhedral geometries of relevant
IFC objects because an IFC model may contain curved objects carrying a
non-polyhedron geometry. In fact, curved BIM objects must be faceted to
generate planar SBs for BEM (no matter automatically or manually)
[16]. A problematic scenario would be that the faceting operations occur
in the automatic SB generation process, and the faceting results are not
stored in the resulting IFC model (i.e., the model enriched with SBs) to
be validated.
Third, the visualization functions of the proposed system still
have room for improvement. For instance, the current implementa­
tion of the system lacks the geometric visualization functions of
building elements and site objects. Such functions are particularly
helpful to intuitively understand the validation results of some rules
(i.e., SR.2.1, CR.1, CR.2.2, and CR.3) that involve building elements
and/or site objects. Similarly, displaying surface normal vectors of
SBs helps to better understand the errors reported by GR.1.2.
Furthermore, for the geometric errors (e.g., gaps, overlaps, over­
hangs) detected by the space airtightness checking rule (i.e., GR.2.1),
the proposed system allows users to conveniently locate and
19
Automation in Construction 127 (2021) 103724
visualize all the defective spaces (from the view of SBs) as well as the
SBs that “see” the geometric errors. However, users still need to
manually find out the exact locations of the errors (e.g., the gap oc­
curs among what SBs). This can be laborious and time-consuming
when a defective space is complex and contains many SBs. This
shortage is currently overcome by visualizing SBs of defective spaces
and the rays that detect the errors together in a Matlab program (see
Section 6.3). It would be more convenient when the proposed system
can visualize relevant rays to directly locate those geometric errors.
Fourth, GR.2 is currently implemented by using a Monte Carlo-
based ray tracing algorithm [13] that leverages a sufficient number
of random rays to examine whether each space is airtightly enclosed by
relevant SBs. It has the nature of uncertainty and may suffer from the
efficiency issue for large-scale models with a much larger number of
spaces. To address these limitations, it is worthwhile to develop a
deterministic algorithm based on the boundary representation (a solid
modeling method) principle: for a set of SBs that airtightly bound a
space, after merging all coplanar SBs, all edges in the merged set
should be shared by two SBs and do not have any isolated sections.
Fifth, more case studies using IFC models with ground truths need
to be conducted to foster the capacity and reliability of the proposed
system. The test model used in this study contains relatively limited
scenarios without ground truths. Although all the reported results are
manually confirmed as correct, it is still uncertain whether there are
any missing errors that the system fails to detect. Therefore, it is rec­
ommended to create more benchmark models with ground truths to
further verify the system, although it is practically challenging to
H. Ying and S. Lee Automation in Construction 127 (2021) 103724

Fig. 21. Validation results against GR.2 in the prototype application: (a) a non-airtight space due to missing SBs; (b) a non-airtight space due to a floating SB; and (c)
visualization of the error in (b) in Matlab. Note: the Matlab program can visualize the SBs of a space as well as the ray used to detect errors against GR.2.

create a reasonably complex benchmark model with ground truths
using BIM authoring tools currently available in the practice.
Lastly, the proposed system aims to provide users with a reliable,
efficient, and user-friendly tool to evaluate SBs in IFC models. It does not
allow users to directly correct reported errors, which, however, is
necessary to obtain accurate SBs in practical IFC BIM-based BEM pro­
cesses. Currently, users need to manually correct the errors in IFC instance
files, which requires considerable domain expertise in IFC specifications
and BEM and can be laborious and time-consuming. In fact, some errors
have the potential to be automatically corrected. For example, a SB with

20
 H. Ying and S. Lee
21

Automation in Construction 127 (2021) 103724

Fig. 22. Validation results against CR.1 in the prototype application.
H. Ying and S. Lee
Fig. 23. Validation results against CR.2 in the prototype application.
an incorrect normal vector direction can be fixed by automatically
reversing the order of the polygon vertices of the SB. For some errors,
automating the correction is challenging or even impossible. For instance,
it is difficult to automatically rectify the error that two SBs partially
overlap each other due to the difficulty in automatically inferring their
correct connection. In this case, graphical tools that allow users to directly
manipulate SBs and can store the manipulations in IFC instance files
would be particularly useful. Future work is thus suggested to systemat­
ically investigate the nature of SBs’ errors first, and then develop
correction algorithms for the errors that can be automatically corrected
and user-friendly tools for the errors that require manual operations.
7.2. Implication for the validation of other IFC relationship objects
This study presents the development of a fully automatic and sys­
tematic SB validation system. The proposed system checks not only
syntactic and semantic compliance against an MVD (i.e., SSV), but also
the correctness of SBs’ geometries (i.e., GV) and key semantic attributes
(i.e., CV). The theoretic foundation for the system development is that
SBs defined by IfcRelSpaceBoundary2ndLevel capture objectified
22
Automation in Construction 127 (2021) 103724
relationships between spaces and their surrounding elements in an IFC
model and these relationships can be automatically inferred from the
geometries of spaces and building elements. In IFC, there are also some
other similar relationship objects such as IfcRelConnectsElements,
IfcRelConnectsPorts, and IfcRelContainedInSpatialElement. The develop­
ment of the SB validation system thus can provide constructive guide­
lines and insights for researchers or software vendors of interest to
develop automatic quality assessment methods for those IFC relation­
ship objects.
8. Conclusion
Second-level SBs in an IFC model define a thermal surface view of
building geometry required for building energy modeling (BEM). The
frequently-reported quality issues in second-level SBs make their validation
necessary before extracting and utilizing them for BEM. This study pre­
sented an automatic rule-based system to systematically and rigorously
validate IFC second-level SBs. The system hardcodes a total of 38 validation
rules, which are identified from the upgraded Space Boundary Add-on View
(SBAV), covering the following three types of validation: (1) syntactic and
H. Ying and S. Lee Automation in Construction 127 (2021) 103724

Fig. 24. Validation results against CR.4 in the prototype application.

semantic validation (SSV) that checks whether second-level SB instances prepare accurate geometry in practical IFC BIM-to-BEM trans­
comply with the syntactic and semantic constraints specified in the upgra­ formation scenarios. It also enables researchers or software vendors
ded SBAV; (2) geometric validation (GV) that checks whether the geome­ to fast debug their own SB generation algorithms using real-world
tries of second-level SBs satisfy the intrinsic geometric constraints as well as complex and large-scale BIM models.
geometry–related implementation agreements specified in the upgraded
SBAV; and (3) consistency validation (CV) that checks whether the semantic Declaration of Competing Interest
attribute values of second-level SBs are consistent with their real states. To
ensure the reliability of the validation results, rule dependencies were The authors declare that they have no known competing financial
carefully considered during the implementation of the validation rules. interests or personal relationships that could have appeared to in­
The proposed system was implemented into two independent fluence the work reported in this paper.
applications: most of the SSV rules were implemented on top of Ifc­
Doc and the remaining SSV rules and all GV and CV rules were
Acknowledgments
implemented in a prototype application with a user-friendly inter­
face. The feasibility of the system was tested with an IFC model with
The work described in this paper was supported by a grant from the
SBs of a real-world building. The results show that the system enables
Research Grants Council Early Career Scheme of the Hong Kong Special
users to evaluate the quality of SBs efficiently and reliably and locate
Administrative Region, China (Project No. HKU 27203016).
and visualize the detected geometric and non-geometric issues of SBs
conveniently. The proposed system can be used by practitioners to

23
H. Ying and S. Lee Automation in Construction 127 (2021) 103724

Appendix A. Appendix

Table A1. Textural-format error reporting templates.

Rules Error reporting templates

SSV rules “SR.0.1: The Coordinates of the following IfcCartesianPoint instances do not have three values:”
“SR.0.2: The Coordinates of the following IfcCartesianPoint instances do not have two values:”
“SR.1.1: The ParentBoundary of the following SBs should refer to an IfcRelSpaceBoundary2ndLevel instance:”
“SR.1.2: The RefDirection of the following IfcAxis2Placement3D instances should be given as a 3D vector:” or “SR.1.2: The Axis of the following
IfcAxis2Placement3D instances should be given as a 3D vector:” or “SR.1.2: The Axis and Ref Direction of the following IfcAxis2Placement3D instances
should not be parallel:”
“SR.2.1: The following building element instances should probably provide SBs:”
“SR.2.2: The following building element instances should not provide SBs:”
“SR.3.1: The RelatedBuildingElement of the following SBs should directly refer to corresponding IfcWindow or IfcDoor instances:”
“SR.4.1: The RelatedBuildingElement of the following SBs should directly refer to corresponding aggregate element instances:”
GV rules “GR.1.1: The geometry of the following SBs is not a valid simple polygon:”
“GR.1.2: The normal of the following non-shading SBs points inward their relating space:” or “GR.1.2: The normal of the following shading SBs points inward their
related building element:”
“GR.2.1: The following spaces have not been airtightly enclosed by their SBs:”
CV rules “CR.1.1: The status on the other side of the related element of the following SBs is not a space. There should be errors in their Description and/or
InternalOrExternalBoundary:”
“CR.1.2: The status on the other side of the related element of the following SBs is not the outdoor environment. There should be errors in their Description and/or
InternalOrExternalBoundary:”
“CR.1.3: The status on the other side of the related element of the following SBs is not a site object. There should be errors in their Description and/or
InternalOrExternalBoundary:”
“CR.1.4: The status on the other side of the related element of the following SBs is not a non-shading element. Their Description should be “2a” or ‘Shading’ rather
than “2b”:”
“CR.1.5: The following SBs play a role in bounding an interior space. Their Description should not be ‘Shading’:”
“CR.1.6: The CorrespondingBoundary of the following SBs should refer to an IfcRelSpaceBoundary2ndLevel instance according to their Description and
InternalOrExternalBoudary:”
“CR.2.1: The following SBs do not connect their relating spaces:”
“CR.2.2: The following SBs do not connect their related building elements:”
“CR.3.1: The PhysicalOrVirtualBoundary of the following SBs should be ‘VIRTUAL’ rather than ‘PHYSICAL’:”
“CR.3.2: The PhysicalOrVirtualBoundary of the following SBs should be ‘PHYSICAL’ rather than ‘VIRTUAL’:”
“CR.4.1: The following opening SBs are not included by their parent SBs:”
“CR.4.2: The following shading SBs do not connect their base SBs:”
“CR.5.1: The following pairwise SBs do not correctly correspond to each other:”

References
[1] H. Gao, C. Koch, Y. Wu, Building information modelling based building energy
modelling: a review, Appl. Energy 238 (2019) 320–343, https://doi.org/10.1016/j.
apenergy.2019.01.032.
[2] V. Bazjanac, IFC BIM-Based Methodology for Semi-Automated Building Energy
Performance Simulation, 25th CIB W78 International Conference, Santiago, Chile,
2008, pp. 292–299. Available from: https://escholarship.org/uc/item/0m8238pj
(Last accessed: March 6, 2020).
[3] U.S. General Services Administration (GSA), GSA BIM Guide 05-Energy
Performance, Available from: http://www.gsa.gov/portal/content/102283 (Last
accessed: June 12, 2019).
[4] NBIMS-US™, Frequently asked questions about the national BIM standard-United
States: What is a BIM?, Available from: https://www.nationalbimstandard.
org/faqs#faq1 (Last accessed: January 11, 2020).
[5] V. Bazjanac, A. Kiviniemi, Reduction, Simplification, Translation and
Interpretation in the Exchange of Model Data, 24th CIB W78 International
Conference, Maribor, Slovenia, 2007, pp. 163–168. Available from: http://citesee
rx.ist.psu.edu/viewdoc/summary?doi=10.1.1.535.5530 (Last accessed: August 1,
2020).
[6] R.J. Hitchcock, J. Wong, Transforming IFC Architectural View BIMs for Energy
Simulation: 2011, 12th Conference of International Building Performance
Simulation Association, Sydney, Australia, 2011, pp. 1089–1095. Available from:
http://www.ibpsa.org/proceedings/BS2011/P_1391.pdf (Last accessed: August 5,
2020).
[7] V. Bazjanac, Space Boundary Requirements for Modeling of Building Geometry for
Energy and Other Performance Simulation, 27th CIB W78 International
Conference, Cairo, Egypt, 2010, pp. 16–18. Available from: http://www.e3lab.
org/upl/website/publication11111/spaceboundary.pdf (Last accessed: January
25, 2019).
[8] I.S.O, ISO 16739-1:2018- Industry Foundation Classes (IFC) for Data Sharing in the
Construction and Facility Management Industries, Available from: https://www.
iso.org/standard/70303.html (Last accessed: November 3, 2020).
[9] Autodesk, Export a Project to IFC, Available from: https://knowledge.autodesk.co
m/support/revit-products/learnexplore/caas/CloudHelp/cloudhelp/2020/ENU/
RevitDocumentPresent/files/GUID-14037C
31-EBAD-41A8-9099-E6DD65BB626E-htm.html (Last accessed: February 4, 2020).
[10] Graphisoft, Help Center: IFC Translators: Overview, Available from: https://help
center.graphisoft.com/user-guide/89314/ (Last accessed: February 4, 2020).
[11] C.M. Rose, V. Bazjanac, An algorithm to generate space boundaries for building
energy simulation, Eng. Comput. 31 (2) (2015) 271–280, https://doi.org/10.1007/
s00366-013-0347-5.
[12] G.N. Lilis, G.I. Giannakis, D.V. Rovas, Automatic generation of second-level space
boundary topology from IFC geometry inputs, Autom. Constr. 76 (2017) 108–124,
https://doi.org/10.1016/j.autcon.2016.08.044.
[13] H. Ying, S. Lee, Generating second-level space boundaries from large-scale IFC-
compliant Building Information Models using multiple geometry representations,
Auto. Construct. 126 (2021), https://doi.org/10.1016/j.autcon.2021.103659.
[14] T. Maile, J. O’Donnell, V. Bazjanac, C. Rose, BIM-Geometry Modelling Guidelines
for Building Energy Performance Simulation, 13th International Building
Performance Simulation Association Conference, Chambéry, France, 2013,
pp. 3242–3249. Available from: http://www.ibpsa.org/proceedings/BS2013/p
_1510.pdf (Last accessed: August 5, 2020).
[15] J. O’Donnell, T. Maile, C. Rose, M. Natasa, M. Elmer, R. Cynthia, et al.,
Transforming BIM to BEM: Generation of Building Geometry for the NASA Ames
Sustainability Base BIM, Lawrence Berkeley National Laboratory, Berkeley, USA,
2013. Available from: https://escholarship.org/uc/item/1x09b1xd (Last accessed:
August 5, 2020).
[16] H. Ying, S. Lee, An algorithm to facet curved walls in IFC BIM for building energy
analysis, Autom. Constr. 103 (2019) 80–103, https://doi.org/10.1016/j.
autcon.2019.03.004.
[17] buildingSMART, Space Boundary Add-on View, Available from: https://technical.
buildingsmart.org/standards/ifc/mvd/mvd-database/ (Last accessed: October 30,
2020).
[18] M. Weise, T. Liebich, R. See, V. Bazjanac, T. Laine, B. Welle, Implementation
GUIDE: Space Boundaries for Energy Analysis, Available from: http://www.blis
-project.org/IAI-MVD/documents/Space_Boundaries_for_Energy_Analysis_v1.pdf
(Last accessed: November 3, 2020).
[19] buildingSMART, IfcRelSpaceBoundary, Available from: https://standards.
buildingsmart.org/IFC/RELEASE/IFC2x3/TC1/HTML/ (Last accessed: October 30,
2020).
[20] buildingSMART, IfcRelSpaceBoundary2ndLevel, Available from: https://standards.
buildingsmart.org/IFC/RELEASE/IFC4/ADD2_TC1/HTML/schema/ifcproductext
ension/lexical/ifcrelspaceboundary2ndlevel.htm (Last accessed: March 30, 2019).
[21] W. Solihin, C. Eastman, Y.C. Lee, Toward robust and quantifiable automated IFC
quality validation, Adv. Eng. Inform. 29 (3) (2015) 739–756, https://doi.org/
10.1016/j.aei.2015.07.006.

24
H. Ying and S. Lee
[22] Y.C. Lee, C.M. Eastman, W. Solihin, Logic for ensuring the data exchange integrity
of building information models, Autom. Constr. 85 (2018) 249–262, https://doi.
org/10.1016/j.autcon.2017.08.010.
[23] Y.-C. Lee, C.M. Eastman, J.-K. Lee, Validations for ensuring the interoperability of
data exchange of a building information model, Autom. Constr. 58 (2015)
176–195, https://doi.org/10.1016/j.autcon.2015.07.010.
[24] C. Eastman, J.M. Lee, Y.S. Jeong, J.K. Lee, Automatic rule-based checking of
building designs, Autom. Constr. 18 (8) (2009) 1011–1033, https://doi.org/
10.1016/j.autcon.2009.07.002.
[25] buildingSMART, Software Certification, Available from: https://www.buildings
mart.org/compliance/software-certification/ (Last accessed: January 11, 2020).
[26] C.M. Eastman, R. Sacks, I. Panushev, S. Aram, E. Yagmur, Precast Concrete
Exchanges (PCI-001), PCI-Charles Pankow Foundation, Available from: http
://www.blis-project.org/IAI-MVD/, 2009 (Last accessed: August 5, 2020).
[27] buildingSMART, IfcDoc, Available from: https://github.com/buildingSMA
RT/IfcDoc (Last accessed: March 20, 2020).
[28] Y.C. Lee, W. Solihin, C.M. Eastman, The mechanism and challenges of validating a
building information model regarding data exchange standards, Autom. Constr.
100 (2019) 118–128, https://doi.org/10.1016/j.autcon.2018.12.025.
[29] KIT (Karlsruhe Institute of Technology), FZKViewer 4.9 (Build 956), Available
from, https://www.iai.kit.edu/1302.php (Last accessed: November 3, 2020).
[30] Solibri, Solibri Anywhere, Available from: https://www.solibri.com/solibri-anywh
ere (Last accessed: February 10, 2021).
25
Automation in Construction 127 (2021) 103724
[31] H. Ying, S. Lee, Automatic detection of geometric errors in space boundaries of IFC-
BIM models using Monte Carlo ray tracing approach, J. Comput. Civ. Eng. 34 (2)
(2020), 04019056, https://doi.org/10.1061/(ASCE)CP.1943-5487.0000878.
[32] Solibri, Solibri Model Checker, Available from: https://www.solibri.com/faq/c
reating-rulesets-in-smc-v9-8/ (Last accessed: June 1, 2018).
[33] D. Eberly, Triangulation by Ear Clipping, Available from: https://www.geometri
ctools.com/Documentation/TriangulationByEarClipping.pdf (Last accessed:
November 3, 2020).
[34] NetTopologySuite, Available from: https://github.com/NetTopologySuite/NetTo
pologySuite (Last accessed: March 30, 2020).
[35] Clipper-an Open Source Freeware Library for Clipping and Offsetting Lines and
Polygons, Available from: http://www.angusj.com/delphi/clipper.php (Last
Accessed: July 1, 2019).
[36] K. Hormann, A. Agathos, The point in polygon problem for arbitrary polygons,
Comput. Geom.: Theory Appl. 20 (3) (2001) 131–144, https://doi.org/10.1016/
S0925-7721(01)00012-8.
[37] RDF, IFC Engine DLL, Available from: http://rdf.bg/ifc-engine-dll.php (Last
accessed: May 1, 2019).
[38] H. Ying, S. Lee, A Framework for Rule-Based Validation of IFC Space Boundaries
for Building Energy Analysis, ASCE International Workshop on Computing in Civil
Engineering 2017, Seattle, USA, 2017, pp. 110–117, https://doi.org/10.1061/
9780784480823.014.
[39] C. Ericson, Real-Time Collision Detection, Morgan Kaufmann, San Francisco, 2004.