Automation in Construction 105 (2019) 102832

Contents lists available at ScienceDirect

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

Holistic clash detection improvement using a component dependent T

network in BIM projects
Yuqing Hua, , Daniel Castro-Lacouturea, Charles M. Eastmanb
⁎

a
School of Building Construction, Georgia Institute of Technology, Atlanta, GA 30332, United States of America
b
School of Architecture, Georgia Institute of Technology, 245 4th St NW, Atlanta, GA 30332, United States of America

ARTICLE INFO ABSTRACT

Keywords: Building information modeling (BIM) has been increasingly used for design coordination, and clash detection is
Clash detection one important application. However, some studies argued that BIM-enabled clash detection contains many ir-
Component dependent network relevant clashes. This paper proposes to use network analysis to improve clash detection from a holistic view
Bounding volume hierarchy because a building is an inseparable whole and the dependency relations between building components influ-
IFC
ence the impacts of clashes. A building component network centered on clash objects is built to represent
component dependency. To build the network, this paper determines three kinds of spatial dependent: clash,
impact, and connection. For clash relations, the paper further distinguishes four types: intersection, penetration,
penetration through, and containment based on the intersection curves of clash objects. To improve generality,
Industry Foundation Classes (IFC) models are used to query geometric information and bounding volume
hierarchy (BVH) structures are used to eliminate irrelevant comparison for expediting the query process. The
paper tests the network method on a real project for improving clash detection and confirms that the method
helps to identify irrelevant clashes in four scenarios and reduces 17% of irrelevant clashes. In addition, the paper
uses the network to automatically group relevant clashes, thereby decreasing > 50% of the clashes initially
reported. The paper also shows the function of the component dependent network to analyze the surrounding
environment of clashes and identify central components for supporting clash correction.

1. Introduction
A building consists of thousands of components that spatially de-
pend on each other. One of the key activities during design is to co-
ordinate the layout of these components. Building information mod-
eling (BIM) has been increasingly used for design coordination and one
of its most widely used applications is automatic clash detection [1].
Because of the visual and parametric features of BIM, it improves the
efficiency of the task. However, some researchers disclosed the limita-
tions of BIM-enabled clash detection methods and mentioned that the
automatic method has lower precision than manual methods. Hartmann
[2] mentioned that the automatic method detected numerous irrelevant
clashes because no changes are needed for these clashes in the design or
construction phases. Wang (2014) found 50% of clashes as irrelevant in
a particular project. Mehrbod et al. [3] also found a large number of
irrelevant clashes existing in their case studies and pointed out that
coordinators needed to closely examine clash reports before proposing
them at design coordination meetings. In practice, some projects can
detect millions of clashes, so being able to automatically cleaning out
irrelevant clashes is important for design coordination and the success
of BIM applications.
Recent research efforts have tried to improve the quality of clash
detection, for example, improving modeling accuracy or reorganizing
model structure from modeling aspects [2,4], improving clash detection
algorithms [10], or using historical data to improve clash detection
from a knowledge management perspective [5–7]. Current software
such as Naviswork Manage provides a function to select clashes based
on rules on the properties of clash objects. However, studies argued that
improving algorithms cannot prevent irrelevant clashes [8]. Re-
organizing models and improving model accuracy increase workload of
BIM staff. Knowledge management methods need a long time to work.
In addition, these improvement methods did not consider the depen-
dent nature of building components and they view clashes one-by-one,
which decrease their capability to identify irrelevant clashes. Consider
the following example scenarios from real projects:
Scenario 1. Duplicate clashes. Current software detects duplicate
clashes. For example, in Fig. 1a, one pile is intersected with a duct.

⁎
Corresponding author.
E-mail addresses: yhu390@gatech.edu (Y. Hu), daniel.castro@design.gatech.edu (D. Castro-Lacouture), eastman@design.gatech.edu (C.M. Eastman).

https://doi.org/10.1016/j.autcon.2019.102832
Received 18 February 2019; Received in revised form 18 April 2019; Accepted 29 April 2019
Available online 25 May 2019
0926-5805/ © 2019 Elsevier B.V. All rights reserved.
Y. Hu, et al.
Duct Insulation
Pipe Insulation
Pipe Insulation
a b
Fig. 1. Irrelevant clash examples (clash objects were marked as red and green).a. Clash with insulations
b. Clash with the interior duct
c. Clash between connected components.
(For interpretation of the references to color in this figure legend, the reader is referred to the web version of this article.)
However, Navisworks detects four related clashes: the insulation of
the pipe is intersected with the insulation of the duct (Fig. 1a), the
insulation of the pipe is intersected with the duct (Fig. 1b), the pipe
is intersected with the insulation of the duct, and the duct is inter-
sected with the duct. Only the clash between insulations needs to be
retained because if it is solved, the other three clashes will auto-
matically disappear. Deleting these duplicate clashes depends on the
relationships between clash objects and their nearby objects (i.e.,
duct and its insulation), not just the properties of clash objects.
Scenario 2. Two logically connected pipe segments intersect with
each other, as shown in Fig. 1c. This scenario is detected as a clash
by Navisworks. However, the clash is a modeling error that does not
require further discussion. Such clash is difficult to identify by the
properties of clash objects without considering their logically con-
nected relations.
Cleaning out irrelevant clashes improve the precision of the clash
detection. The above scenarios are difficult to identify by only con-
sidering the properties of clash components without considering the
dependent relations between building components. In addition, some
clashes are dependent on each other by sharing the same components.
Instead of solving them one by one, automatically grouping them to-
gether is more efficient. Therefore, this paper decides to use the existing
clash detection results as the start point and improve clash detection by
considering the dependent relationships between building components
without increasing the workload of project teams.
The project aims to construct dependency structures among
building components and uses a component dependent network to
improve clash detection by cleaning out irrelevant clashes, grouping
related clashes, identifying central components, and analyze the sur-
rounding environment of clashes. In this paper, irrelevant clashes
consist of clashes that do not require changes, and clashes that have a
clear solution, which only relates to clash objects and will not impact
other building components, for example, small pipes penetrating
through a wall and the solution consisting of opening a hole on the wall.
In addition, the paper discusses hard clashes among MEP disciplines
and clashes between MEP and the structure discipline because the de-
finition of hard clash is accurate and unambiguous, and MEP co-
ordination is a major challenge in complex projects, and their clashes
with structure elements are main concerns in projects [9].
2. Related works
Since the precision problem of automatic clash detection has been
identified in many projects, some studies were conducted to improve
the precision of clash detection from technical and management levels.
In the technical aspect, Helm et al. [10] proposed to use IFC structure
and improve clash detection algorithms as one solution. However,
2
Automation in Construction 105 (2019) 102832
Pipe Segment
Duct
Pipe Segment
c
Akponeware & Adamu [8] has pointed out that the efforts to improve
algorithms did not mitigate the situation that a large number of irre-
levant clashes existing in clash detection results. Hartmann [2] argued
that a well-organized model can help to improve the performance of
clash detection. They used Dutch classification norm's NEN 2634 to
reorganize the project BIM model and conducted comparative tests to
compare the performance of clash detections by manual methods, au-
tomatic methods based on an unorganized model, and a reorganized
model. However, they did not find a statistically significant improve-
ment by using the reorganized model. Ciribini, Ventura, & Paneroni [4]
argued to improve modeling accuracy, which help to improve clash
detection, but it increases the workload for BIM staff.
In the management aspect, the most direct method is to require
coordinators pre-review clash detection results. Mehrbod et al. [3] built
a taxonomy of design coordination issues and classified clashes based
on their causes. Pre-processing clashes based on the taxonomy improve
the design coordination process. However, manually classifying clashes
is time-consuming and it requires that coordinators have extensive
project experience. Rather than focusing on one project, some studies
argued that the improvement should be a continuous process from a
knowledge management perspective. Love & Smith [11] perceived that
every error should be viewed as a learning opportunity for preventing
future errors. To capture the knowledge of the clash management
process, Wang & Leite [7] built a clash management schema and de-
signed a prototype to capture relevant information. However, the
question about how to use the knowledge to clean out irrelevant clashes
is still not resolved. To fill the gap, Hu & Castro-Lacouture [5] explored
the feasibility of using machine-learning methods to distinguish re-
levant and irrelevant clashes by using historical data. Their method can
be used to filter clash detection results and improve the precision of
clash detection. However, the method needs a large amount of data to
construct a solid and generalized classification model, and how to au-
tomatically collect data is still an issue. The real application of the
method still needs time, and its accuracy (around 80%) needs to be
improved. Therefore, how to improve clash detection quality with
limited data and without increasing workload of project participants
needs to be addressed.
This paper proposes that the dependent relationship between
building components can be used to improve clash detection. In fact, a
building is an inseparable whole and the impacts of one clash will be
changed based on its surrounding conditions. One clash in a congested
area can generate a more serious impact than putting it in an area that
contains enough free space. Wang and Leite [7] emphasized that in-
stead of attributes relating to clash objects, clash context attributes are
important for improving clash management. Clash context information
describes the nearby topological environment around a clash and in-
cludes three types: location, spatial relations, and available space [7].
However, some of these attributes lack clear definitions and
Y. Hu, et al.
quantitative standards. For example, spatial relations have different
types, and which one is important for managing clashes and how to
query them from BIM models are still undefined. In addition, the re-
lationship between clash context and irrelevant clashes is understudied.
Dependency relationship can be divided into two types: spatial re-
lationship and spatial-time relationship. In a clash context, spatial-time
relationship means that correcting one clash may cause new clashes in
the future. The consideration of this dependency will bring a time di-
mension to clash research, which in nature consists of predicting de-
sign. In real projects, design coordination is conducted in a sequential
way and early coordinated objects have high priority, which means that
when correcting current clashes, project participants do not need to
worry about post-emerging elements since they are less informative
than current objects [12]. This kind of coordination strategy supports
our research to focus on spatial dependency other than on both kinds of
dependencies. The objective of this research is to identify spatial rela-
tions that relate to clash management among building components,
design algorithms to query these relations from BIM model files and
discuss applications of the dependency structure for improving clash
detection.
3. Methodology
Network theory is applied to analyze dependent relations between
building components because it focuses on relationships in addition to
the properties of a single object and it is beneficial to generate an
overall picture instead of limiting to isolated points [13]. A Network
consists of nodes and relationships among them [14]. This paper con-
structs a component dependent network (CDN) that uses building
components as nodes and their dependent relations as edges. Specifi-
cally, the methodology framework contains four steps, as shown in
Fig. 2. The first step is to identify important spatial relations for clash
management, then discuss the method to query these relations from
BIM models, construct the component dependent network based on
these relations and save them into a database for analysis. The final step
is to test the method on a real project to improve clash detection results.
3.1. Component dependent network
3.1.1. Relations in component dependent network
Spatial relations between components were analyzed to define their
relationships and used as edges in a network. Spatial relations contain
three types: topological, orientation, and distance relations [15]. The
definition of various spatial relations and query methods from previous
studies were summarized in Table 1 of the Appendix. Topological re-
lations define whether two objects intersect and how they intersect.
Orientation relations depict the directional relations of two objects, for
example, a column located in the east of the door. Distance relations
calculate the distance between two objects, and generally, it requires
querying the maximum distance or the minimum distance.
Topological relations have different classifications based on
Identify Related Spatial Dependency
Relations
Design Algorithms to Query Dependent
Relations from models
Construct Dependency Network and
Save into Database
Design Potential Applications based on
Networks and Test on Real Projects
Fig. 2. Methodology framework.
3
Automation in Construction 105 (2019) 102832
application requirements. In the computing graphics field, they usually
use the 9-intersection model (9-IM) to formalize topological relations
[15,16]. In the 9-IM model, each object (Object A) is defined by three
subsets {A0, ∂A, A−}, which represents interior, boundary, and external
set of A. 9-IM is defined by the following matrix intersection:
A0 B 0 A0 B A0 B
I= A B0 A BA B
A B0 A BA B
Based on the matrix, eight types of typological relations are defined:
disjoin, contains, inside, equal, meet/touched, cover, covered by, and
overlap [17]. It was argued that in the engineering field, it is un-
necessary to distinguish the intersection part involving boundary or not
[17]. Therefore, the cover and covered by relations were placed into the
within and contains relations respectively. When looking into the six
relations: disjoin, contains, within, equal, touch, overlap, it is easy to
find that contains and within are the same by replacing the reference
object. Without distinguishing the reference object, Nguyen and Oloufa
[18] combined them together into containment relations and classified
topological relations into five categories: adjacency, separation, con-
tainment, intersection, and connectivity. However, it is difficult to
distinguish adjacency and connectivity based on his definition. There-
fore, Khalili and Chua [19] only considered four relations: connectivity,
containment, separation, and intersection. In the definition, hard clash
refers to containment and intersection relations.
Instead of considering the two relations in clashes, Nepal et al. [20]
argued that it is necessary to distinguish penetration from a common
intersection. They defined that penetration is a special type of inter-
section, which indicates that one object passes through another object.
This paper adopted the distinction because penetration and intersection
may cause different correction methods. If penetration did not influence
structural safety or aesthetic requirements, it can be solved by opening
one hole without moving any objects. This kind of clashes can be fil-
tered out. Thus, this study classified five kinds of topological relations:
separation, connectivity, containment, intersection, and penetration.
However, separation is a kind of “no relations”, so this paper will not
discuss this kind of topological relations. Therefore, four topological
relations are included in this paper.
The classifications of orientation and distance relations are rela-
tively simple. In distance relation calculation, the reference point is
important. One can calculate the center-to-center, center-to-boundary,
or boundary-to-boundary distance by choosing different reference
points. Orientation relations usually discuss six directions based on the
world or the local coordinate system [17,20,21]. The six directions are
parallel to the three orthogonal axes of a 3D coordinate system. Even
though researchers name these directions in a different way, the nature
of them is the same. It can be north of, south of, east of, west of, above
and below. In addition to the six directions, Borrmann et.al dis-
tinguished relax orientation relation and strict relation [22]. Strict re-
lation requires that the target object entirely be covered by the re-
spective direction partition based on the reference object, while relax
relations return true if part of the target object falls into the partition.
They also discussed the difference of orientation relation definitions
between the projection-based model and the halfspace-base model. The
projection-based model extrudes the reference object to decide the or-
ientation relation, while the halfspace-based model simplified object
representation in Axis-align bounding box and divided space into two
parts based on the box.
This study used the projection-based model and chose the relax
definition method because the projection-based model generates more
accurate results and the relax relations will include all impacted objects
if moving a reference object with a pre-defined direction. In the process
of correcting one clash, one needs to consider orientation and distance
relations simultaneously to decide whether nearby objects will be im-
pacted by adjusting the location of clash objects. Therefore, this
Y. Hu, et al.
Table 1
Spatial relations in clash context.
Spatial relations Type
Orientation & distance relations Impact Relation
Topological relations Clash Relations Intersect
Penetration
Containment
Connection Relation
research summarized the two relations into “impact relation”. In con-
clusion, we discussed five kinds of spatial relations: connectivity, con-
tainment, intersection, and penetration, and impact relations, as shown
in Table 1. Containment, intersection, and penetration are summarized
into clash relations because they all indicate that physical overlaps
exist.
3.1.2. Methods to query spatial relations
The method to query spatial relations can be divided into two types:
attribute-based and geometric-based. The attribute-based method
queries spatial relations based on pre-defined relation classes. Khalili
and Chua [19] used pre-defined relations in IFC, such as “If-
cRelConnectsElements” and “IfcRelVoidsElement” to query topological
relations. The success of this method highly depends on the quality of
model data because some of these classes are empty in most case in IFC
files. The geometric-based method captures spatial relations based on
the geometrical representation of objects. The most commonly used
geometrical representation is boundary representation (B-rep). The
geometric primitives in this representation are faces, edges, and ver-
tices. Querying the spatial relations of two objects consists of calcu-
lating relations between faces, edges, and vertices of them. Nguyen and
Oloufa [18] and Nepal et al. [20] discussed how to query topological
relations based on these primitives. In addition, parameter-based re-
presentation is also used in project models because building compo-
nents contain many common shapes, for example, cuboid and cylinder.
Instead of using many primitives, common walls, columns, and slabs
can be represented by several parameters. Nepal et al. [20] used the
parameter representation method to query orientation relations. Com-
pared with B-rep, the computing cost of using parameters is lower but it
is only feasible for simple objects, while B-rep can be used in complex
objects. However, the computing cost of the primitive-based method
can be very high when building components are complex or the number
of components is large. In order to reduce irrelevant calculations and
decrease the cost of each test, a hierarchy structure is used in the spatial
relations query process.
A hierarchy structure can be built by space-based splitting methods
or object-based splitting methods, and their corresponding re-
presentatives are octree structure and bounding volume hierarchy
(BVH) [23]. The octree structure uses one bounding box covering all
components as one root node, and it recursively splits nodes into eight
octants if a node is not totally inside one component or outside of all
components [21]. The tree stops growing when the accuracy meets
requirements. The BVH tree can be classified into axis-aligned bounding
IfcRelConnectsElements
RelatingElement RelatedElement
(INV) ConnectedTo S[0:?] (INV) ConnectedFrom S[0:?]
1,1 IfcElement 1,1 IfcElement
The two elements are
logically connected
Fig. 3. Express graph of IFC entities (IfcRelConnectsElements, IfcRelConnectsPortToElement, IfcRelConnectsPorts).
4
Automation in Construction 105 (2019) 102832
Descriptions
Move one object along a direction in a certain distance will impact another object.
Two objects physically overlap with each other (non-penetration)
One object penetrates another object
One object is inside another object
Two objects connect with each other
box (AABB) BVH, oriented bounding box BVH, convex hull BVH, sphere
BVH, and so on, based on the primitives in the tree structure. Among
them, AABB-BVH is widely used because the computing costs of cal-
culating AABB and the spatial test base on two AABBs are low. Some
publications compared the topological, orientation, and distance
queries separately by using AABB-BVH and octree structure and con-
cluded that AABB-BVH tree is faster than octree structure [17,24]. In
order to improve generality, we do not assume that building compo-
nents have simple shapes, so we used the primitive-based method that
each building component is represented by a triangle mesh. In addition,
a BIM model can contain thousands of components. Therefore, an
AABB-BVH structure is applied to expedite the query process.
3.1.2.1. Connection relations. Instead of querying geometric-based
connection relations, we query logical connections because they are
functional constraints in design and when correcting clashes, the logic
constraints cannot be violated. In addition, logically connected objects
may have overlap (see Fig. 1c) and this kind of clashes result from
modeling issues other than design errors and coordination is
unnecessary for them, which should be classified as irrelevant clashes.
This paper used the pre-defined relationship in IFC to find logical
connections. The entities related to connections include the following,
as shown in Fig. 3:
• IfcRelConnectsElements: it describes connectivity between ele-
ments. It contains relating elements and related elements.
• Flow segments usually connect by ports. Therefore, this paper also
uses IfcRelConnectsPortToElement, IfcPort and IfcRelConnectsPorts
to query connection relationships.
The related components can be acquired through analyzing relating
elements and related elements in the attributes of
IfcRelConnectsElements. However, IfcRelConnectsElements may be
empty in some cases. Therefore, this paper also uses
IfcRelConnectsPortToElement, IfcPort, and IfcRelConnectsPort to
identify connection relations because the MEP flow system usually uses
these entities to reflect connectivity. The express graphs of these enti-
ties are shown in Fig. 3.
3.1.2.2. Impact relations. Impact-relation is a combination of
orientation and distance relations. Given a reference object, querying
one impact relation consists of calculating whether there is one object
located at a certain distance of a given direction of the reference object.
IfcRelConnectsP RelatedElement
1,1 IfcElement
ortToElement
RelatingPort
(INV) ContainedIn The two
elements are
(ABS) logically
IfcPort connected
RelatedPort
(INV) ConnectedFrom S[0:?]
IfcRelConnects RealizingElement
1,1 IfcElement
Ports
Y. Hu, et al.
Impacted object
Maximum distance
Minimum distance
Movement direction
Reference object
Fig. 4. Attributes of impact relations.
The input of this operator contains a reference object, a project model,
an array of potential directions, and an upper limit of tested distance. In
the clash management context, clash components were chosen as
reference objects. Since clash components need to be changed to
solve clashes, the impact relations will represent which objects will
be impacted by these clashes components if we move them. The upper
limit of distance is to control the scope of the clash impact because it is
unnecessary to test all objects located along the moving trajectory of
the reference object. As for the output, impact relations need to record
two distances under a given direction. One is the minimum distance
that we move the reference object along the given direction touching
the target object. The other is the maximum distance that we move the
reference object, while still touches the target object.
Therefore, one impact relation contains five attributes: a target
object, an impacted object, a movement direction, the minimum dis-
tance, and the maximum distance, a 2D example shown in Fig. 4. Dis-
tance attributes depend on the movement direction. One impact rela-
tion contains multiple movement directions and corresponding
maximum and minimum distances. Six directions based on the world
coordinate system are selected as start points. The six directions are
positive Z-axis (AxisZP), negative Z-axis (AxisZN), positive X-axis (Ax-
isXP), negative X-axis (AxisXN), positive Y-axis (AxisYP), and negative
Y-axis (AxisYN). They are chosen because project participants tend to
follow horizontal and vertical directions and these directions were
widely used in previous research [17,21]. The six directions are also
used in clash relations.
Two steps were conducted to query impact relations. A preliminary
test was conducted to eliminate irrelevant comparisons. The pre-
liminary test identified objects whose AABB boxes have overlaps with
the plane that was perpendicular to the examined direction, known as
strict directional relations [22], as shown in Fig. 5 (Object B was
eliminated from the potential list because of no overlap between pro-
jections). In addition, this step eliminated objects located in the oppo-
site direction of the reference object (Object C) and those objects whose
Object B
Its projection are not
overlapped with the
reference object
Moving into
detailed test
Reference Object
Fig. 5. Preliminary test for impact relations.
Automation in Construction 105 (2019) 102832
minimum distance between its AABB and the AABB of the reference
object is larger than the upper limit of tested distance (Object D). The
preliminary test was conducted based on a world BVH structure. The
root node of the world BVH tree contained all the building components
in a model, and each leaf of the tree contained the AABB box of one
component. The tree structure quickly eliminated branches that did not
meet directional or distance requirements and return potential im-
pacted-object lists. Detailed tests were conducted between potentially
impacted objects and the reference object. Without loss of generality,
objects were represented by triangle meshes. Detailed tests need to
calculate the minimum distance and maximum distance between any
triangle pairs from the reference object and examined objects. To
eliminate irrelevant tests, this study used AABB-BVH tree structure to
represent these objects. The root node of the tree was an AABB covering
one object and each leaf node contained one triangle of the object.
The tree structure expedited computation by eliminating un-
promising branches. The paper used priority-first search to traverse a
tree because this step needs to calculate distances, and it is reasonable
to assume that the distance between the children node pair tends to be
larger when the distance between the parent node pair is larger. Two
criteria were used to decide whether a branch is unpromising: 1)
Intersection rule: if the projections of the two nodes on the plane per-
pendicular to the examined direction have no overlap, the branch is
unpromising because the maximum and minimum distances only exist
between two triangles whose projections overlapped on the perpendi-
cular plane. 2) Distance rule: if the potential minimum or maximum
distance is worse than the current best distance, the algorithm stops
deeper traversing this branch. In order to fully exploit the distance rule,
the algorithm separately computed maximum and minimum distance
because usually, one node pair cannot own the current maximum dis-
tance as well as the current minimum distance. The minimum distance
was computed first and if the distance was larger than the upper limit
distance, the object was removed from the impact list.
The maximum distance calculation is used as an example to in-
troduce the algorithm. The input of the algorithm contains AABB-BVH
representations of both objects and the examined direction. The algo-
rithm started with the root node pair. It calculated the maximum dis-
tance (maxR) and minimum distance (minR) between them, set
bestSolution equal to minR, saved the pair into a priority queue, and
used the distance maxR as a comparator. For the pairs in the priority
queue, the algorithm first branched the node pair with the highest
comparator, which helped to quickly reduce irrelevant tests. For each
pair, the algorithm checked whether the two AABB boxes overlap on
the perpendicular plane. If they are overlapped, it will calculate the
maximum distance (MD), and if the MD is smaller than the current best
solution, the node pair is unpromising, and algorithms will not check its
children pairs. Otherwise, the algorithm will push their children node
pairs into the priority queue. If both nodes are leaf nodes, the algorithm
Object D
The distance is larger
than limit distance
Upper limit L
Object A
Movement Direction
Object C
Located in the opposite Direction
5
Y. Hu, et al.
will check whether the projections of two triangles in the nodes are
overlapped in the plane perpendicular to the examined direction. If
they are, it will calculate the distance between them and if the distance
is larger than the best solution, the algorithm will update the best so-
lution to the distance. In addition, the algorithm set a condition to early
stop traversing: if the bestSolution is equal to maxR, the traversal stops.
The early stop condition works because the bestSolution cannot be
larger than the maximum distance between root nodes.
The pseudo code for calculating maximum distance in impact re-
lations is shown in Fig. 1 of Appendix. The time complexity of the al-
gorithm is O(n), where n is the number of nodes for the tree with more
nodes. TestBoxOverlap tests whether the projections of two AABB boxes
are overlapped, while TestTriangleOverlap checks whether the projec-
tion of two triangles are overlapped. CalculateBoxDistance calculates
the distance between two AABB boxes along the examined direction,
while CalculateTriangleDistance consists of calculating the distance
between two triangles. Since the axes of AABB boxes are parallel or
perpendicular the examined direction, the overlap checking and the
distance calculation for boxes are easy by comparing coordinates of
their vertices. The calculations related two 3D triangles are also well-
structured in previous studies based on Gilbert-Johnson-Keerthi algo-
rithm [25] with a near constant time.
3.1.2.3. Clash relations. Navisworks Manage was used to detect clashes
and export results that include the ID of clash objects. In addition to
clash objects, distance information and clash type were calculated for
clash relations. Distance information refers to how far one object at
least needs to move to solve the clash along a given direction. An
example is shown in Fig. 6. In fact, calculating distance information is
equal to calculate the maximum distance between two objects in a
given direction. This paper used the above algorithm to calculate it.
Clash types are intersection, penetration, and containment. This paper
further distinguished penetration and penetration through. Fig. 7a and
b are examples that are respectively penetration and penetration
through. The key to distinguish clash types is to calculate the
intersection curve between the boundaries of two checking objects. If
the intersection curve is closed in one plane, the clash type is
penetration (Fig. 7). If they form closed curves in more than one
plane, the clash type is penetration through (Fig. 7b). If there is no
closed curve in one plane, the type is intersection (Fig. 7c). If there is no
intersection curve, the clash type refers to containment.
To decide whether a coplanar closed intersection curve exists, graph
theory was used. The idea was to view every intersection point on the
boundary as a node, and the intersection lines as edges. Fig. 8 shows the
procedures to distinguish clash types. The first step is to check whether
intersection points exist. If not, the clash is containment. Otherwise,
checking whether all intersection points are coplanar. If they are, the
clash is penetration. Otherwise, the paper calculated strongly connected
components (SCC) in the intersection graph rather than check all circles
because calculating all simple circles in a graph is much more expensive
Component B
Move Distance
along negative Z-
Negative Z-axis axis
Component A
Fig. 6. Attributes for clash relations.
6
Automation in Construction 105 (2019) 102832
than check SCC. In addition, SCC guarantees at least one simple circle
existing in it. SCC is a sub-graph that every node is reachable from any
other nodes in it. SCCs of a graph is calculated by Kosaraju's algorithm
with O(V + E) time, where V is the number of nodes and E is the
number of edges in the SCC [26]. If only one of the SCC exists, the clash
type is intersection since single SCC means the intersection curves are
closed and non-coplanar (Fig. 7c). Otherwise, the clash type is pene-
tration through because more than one coplanar closed curves exist.
There is a limitation on the algorithm: when the intersected surfaces
of both clash objects are curved surfaces, this algorithm cannot work.
For example, the algorithm will detect the clashes in Fig. 9 as inter-
section other than penetration through. In fact, it can be argued that
this result is acceptable in real projects. The reason to make this dis-
tinction is to eliminate clashes that do not need further discussion.
However, components with curved surfaces usually belong to special
elements. Paying extra attention to discuss clashes among these objects
is acceptable.
3.2. Neo4j database
In order to use the dependent information for clash management,
this information was saved into Neo4j Database. Neo4j is a graph da-
tabase that is designed for relation data, which complies with the
nature of the component dependent network. Neo4j database consists of
three elements: node, relation, and property. Both nodes and relations
can have properties. Building components were used as nodes and re-
lations contain clash, connection, and impact relations. Properties that
relate to a single component was associated with the certain node. Ifc
GlobalID of the component, the name of IFC entity of the component,
the system of the component, and the size information of the compo-
nent were saved as the properties of nodes. The size information in-
cludes the axis-align bounding box of the component and the original
size information, such as diameter and length. Clash type is one prop-
erty of the clash relation. The distances calculated for relations are
properties for different relations. The properties for node and relations
are summarized in Table 2. The Neo4j 3.3.4 Community server is used
for this project, the Neo4jDotNetDriver is used to query the Neo4j da-
tabase from. Net, and Cypher is used as the query language.
4. Case study
4.1. Project introduction
The test building is a five-story student residence hall with a total
gross floor area of around 4700-square-meter located in a public uni-
versity and accommodating 285 beds. The project started in Dec 2014
and was completed in Aug 2018. BIM was used in this project for design
coordination and clash detection. The proposed method in this paper
was applied to MEP and structure discipline. The project team detected
312 clashes using Navisworks Manager 2017. The discipline composi-
tion of these clashes is shown in Fig. 10a.
The overall process of building the component dependent network is
shown in Fig. 11. Clash object lists were exported from Navisworks.
Components geometric and non-geometric properties were extract from
IFC files. Logically connected component lists were recorded based on
IFC files. Clash distance and type were calculate based on geometric
information. For each clash, the paper checked whether the two clash
components impact other components and the method did not check
the impact relations between directly connected components and
overlapped components. If they were, corresponding distance in-
formation was calculated, and impact relations were created. In this
specific case, the upper limit distance for impact relations was set as
1 m, which was larger than the minimum clash overlap distance
(0.74 m) in the test case, to make sure that all the potential impacted
objects are included in the impact relation calculation. The upper limit
distance can be changed based on the user's consideration. Finally, the
Y. Hu, et al. Automation in Construction 105 (2019) 102832

a b c
Fig. 7. a Penetration
b Penetration through
c. Intersection
Illustration: red lines are the intersection lines between two components. (For interpretation of the references to color in this figure legend, the reader is referred to
the web version of this article.)

by one. 302 of them were correct, accounting 97%, which indicates that
Start
the proposed method is quite reliable for distinguishing clash type.
Fig. 12 shows a part of the component dependent network of the
building. The whole network contains 13,556 nodes and 58,084 edges,
No
Exist intersection points which reflect the connection, clash and impact relations between
building components. In the graph, each node represents one building
components. The size and the color of nodes depend on their degree:
Yes
the larger of the degree, the bigger of the size, and the greener of the
Yes color.
All points coplanar Penetration

No 4.2. Potential applications based on the component dependent network

Calculate strongly Three potential applications were developed to improve clash de-
connected component tection: cleaning out irrelevant clashes, automatically grouping related
(SCC)
clashes, checking surrounding environment of clashes and identify
Yes central components. This paper mainly analyzed four scenarios of ir-
Penetration
More than one SCC relevant clashes identified by observing real projects. Cleaning out ir-
through
relevant clashes helps project participants to focus on important clashes
No and improve the efficiency of design coordination. Automatically
Containment intersection grouping related clashes reduces the number of clashes and facilitates
project participants to think about clash solutions in a more integrated
End way. Understanding the surrounding environment of clashes and
identifying central clash components help project participants to cor-
Fig. 8. Flowchart for distinguishing clash types. rect clashes and localized clash changes.
Query based on Neo4j database was used to realize these functions
and cypher was used as the query language. Five basic statements were
used in the query sentence: match, where, set, return, create. “Match”
identifies certain connection patterns in the network, “where” con-
strains the properties of nodes and edges, “set” consists of changing
existing or adding new properties, “return” defines the information that
a user interested, and “create” consists of creating new nodes or rela-
tions. In addition, aggregation functions were used to calculate ag-
gregated data, for example, “collect” use for returning a list and “min”
returning the minimum value. “Case” is condition expression and
“with” is used to combine query parts.

Fig. 9. Curved intersection surfaces.

paper checked whether clash components and their impacted compo-
nents belong to the connection list. The connection relations were built
if they connected with other components. After capturing three de-
pendent relations, the paper constructed component dependent net-
works and saved the network into Neo4j database. The paper used c# in
visual studio 2017 with .Net framework 4.6.1 to conduct these proce-
dures. In this case, IFC and Navisworks files were exported from Revit.
It can be from other software.
The percentage of each clash type is shown in Fig. 10b. Automatic
classification of clash types was compared by manually reviewing one
4.2.1. Cleaning out irrelevant clashes
Two scenarios of irrelevant clashes were mentioned in the in-
troduction part: logically connected components intersecting with each
other, and duplicate clashes related to insulations of MEP flow seg-
ments.
Scenario 1: Duplicate clashes.
To query the duplicate clashes between insulations and flow seg-
ments, insulation relations were set into building components. One IFC
entity, called “IfcRelCoversBldgElements”, captures this information.
However, this entity is usually empty in IFC files. Therefore, node

7
Y. Hu, et al. Automation in Construction 105 (2019) 102832

Table 2
Element summary for a building component dependent network.
Elements Properties

Node: each node represents a building GlobalID, IFCType, System Type, Boundary Box Coordinates (minX, minY, minZ, maxX, maxY, maxZ), Component Size Property
component
Relations Clash relation Minimum move distance of two clash components in six directions corresponding to the project world coordinate system
(AMoveAxisXP, AMoveAxisYP, AMoveAxisZP, AMoveAxisXN, AMoveAxisYN, AMoveAxisZN; BMoveAxisXP, BMoveAxisYP,
BMoveAxisZP, BMoveAxisXN, BMoveAxisYN, BMoveAxisZN;)
Connect relation No other properties
Impact relation Movement direction (one of the six directions corresponding to project world coordinate system, AxisXP,
AxisYP，AxisZP，AxisXN，AxisYN，AxisZN), The minimum and maximum distances between the impacted component (BLimit,
ULimit) and the clash component in the direction

250
197
200 37,
161
Clash Number

150 12%
91 Penetration_through
100
91, 29% Intersect
184, 59% Penetration
50 20
5
0
Fire Plumbing Structure Electrical Mechanical
Protection
Discipline Name

a b
Fig. 10. a. Clash discipline summary
b. Clash type summary.

Construct Component Dependent Network

Extract information of all components Distinguish Intersect,

Query Clash Relations Penetration, penetration
• Geometry information input Generate BVH tree for
IFC files through, and containment
(triangle mesh) each Components
input
• Create connect list (connected components are Query Impact Relations
identified by Ifc )
• Other properties of components (property set,
e.g.globalID system type, size and IFC entity )
Check whether connect Yes
Revit file Query Connect
Lists of clashes list contains clash and
Relations
input export impacted components
Navisworks
File
Generate Component
Dependent Network

Save into Neo4j

Database

Fig. 11. The overall process to generate a component dependent network.

properties and relations were used to identify insulation relations. In
the IFC structure, insulations are defined by IFCCovering entity. The
insulation must have impact relations with the object that it protects,
the AABB of the insulation should cover the AABB of the protected
object, and the two objects should belong to the same system.
Therefore, these features were used to set the insulation relations by the
query sentence Q1 in Table 3. In the query, n1 and n2 represent two
components and “r” is a relation between them. If two components
comply with pre-defined requirements, the query added a new property
to each of them to record insulation relations.
After setting insulation relations, the paper queried whether dupli-
cate clashes exist. If a covered object has clashes with other objects
(clash_d), its insulation must intersect with the same objects and clash_d
can be labeled as irrelevant and Q2 in Table 3 is the query sentence. The
query returned 18 irrelevant clashes and Fig. 13a shows an example of
them.
Scenario 2: Logically connected component intersecting with each
other.
The research team noticed that IFC files usually did not capture the
connection relations between insulations. Since we identified insulation
relations in Scenario 1, if the two flow segments connect and insulations
exist, we created the connection relations between their insulations by
Q3 in Table 4. After complementing the connection relations, Q4 was
used for query clashes between logically connected component. The
condition that r1.Type is null was used to clean out scenario 1. This
query generated two results, Fig. 13b is one example and the type of
clash was set as irrelevant and the solution was set as a modeling issue.
In addition, two other scenarios that can be classified into irrelevant
clashes were identified:
Scenario 3: MEP flow segments or fitting penetrating into the MEP
terminal. It was found that Navisworks detects clashes between MEP

8
Y. Hu, et al. Automation in Construction 105 (2019) 102832

Fig. 12. The component dependent network for the test case.

flow segments with their terminal equipment. However, this situa-
tion is a common and acceptable practice that should be cleaned
out. In the IFC structure, MEP terminals are represented as
“IFCFlowTerminal”, “IFCDistributionControlElement” or
“IFCBuildingElementProxy”. Flow segment and fitting are re-
presented as “IFCFlowSegment” and “IFCFlowFitting”. Considering
some flow segments and fittings owning insulations, the paper also
included “IFCCovering”. In addition, the two clash objects should
belong to the same system. Q5 in Table 5 was used for this query and
it returned 11 clashes that were set as irrelevant. Fig. 14 shows
examples of these clashes.
Scenario 4: Flow segments penetrating structure elements. From the
observations of construction projects, the research team found that in
practice, structure engineers typically set a standard to decide which
flow segments of MEP are allowed to penetrate the structure elements,

Table 3
Query sentence for irrelevant clash scenario 1.
Function descriptions Query example in Neo4j

Q1. Set insulation relations
Q2. Query duplicate clashes
Sentence: match (n1)-[r:ImpactRelationship]-(n2) where n1.IFCType = “IFCCovering” and n1.maxZ≥ n2.maxZ and n1.maxX≥ n2.maxX and
n1.maxY≥ n2.maxY and n1.minZ≤n2.minZ and n1.minX≤n2.minX and n1.minY≤n2.minY and n1.System = n2.System set
n1.insulated = n2.GlobalID and n2.insulation = n1.GlobalID
Sentence: match (n1) -[r1:ImpactRelationship]- (n2), (n2)- [r2:ClashRelationship]- (n3) where n1.IFCType = “Covering” and
n1.insulated = n2.GlobalID set r2.Type=”irrelevant” return distinct r2

Duct insulation
Supply Air Duct
Insulation

Pipe Supply Air Duct

Air supply duct Insulation

a b
Fig. 13. a. Scenario 1
b. Scenario 2.

9
Y. Hu, et al. Automation in Construction 105 (2019) 102832

Table 4
Query sentence for irrelevant clash scenario 2.
Function descriptions Query example in Neo4j

Q3. Add connection relations between
insulations.
Q4. Identify clashes between logically
connected components
Sentence: Match (n1)-[r:ConnectRelationship]-(n2) where exists(n1.insulation) and exists(n2.insulation) with n1, n2 optional
match (n3) where n3.GlobalID = n1.insulation optional match (n4) where n4.GlobalID = n2.insulation create
(n3)-[:ConnectRelationship]- > (n4)
Sentence: Match (n1) – [r1: ClashRelationship]- (n2), (n1) – [r2:ConnectionRelationship]- (n2) where r1. Type is null set
r1.Type=”irrelevant” and r1.Solution=”Modeling_issue” return distinct r1

Table 5
Query sentence for irrelevant clash scenario 3.
Function descriptions Query example in Neo4j

Q5. Identify clashes between flow segments Sentence: match (n1)-[r1:ClashRelationship]-(n2) where (n1.IFCType = “IFCFlowTerminal” or
and its terminal n1.IFCType = “IFCDistributionControlElement” or n1.IFCType = “IFCBuildingElementProxy”) and
(n2.IFCType = “IFCFlowSegment” or n2.IFCType = “IFCFlowFitting” or n3.IFCType = “IFCCovering”) and
r1.ClashType = “Penetration” and n1.System = n2.System and r1.Type is null set r1.Type=”irrelevant” return distinct r1

Fig. 14. Irrelevant clashes scenario 3.

Table 6
Query sentence for irrelevant clash scenario 4.
Function descriptions Query example in Neo4j

Q6. Check small flow segments penetrate
structure elements.
Sentence: match (n1)-[r1:ClashRelationship]-(n2) where (n1.IFCType = “IFCSlab” or n1.IFCType = “IFCWallStandardCase”)
and (r1.ClashType = “Penetration_through” or r1.ClashType = “Penetration” and ((n2.Diameter > 0 and
n2.Diameter < 0.25) or (n2.height*n2.width < 0.05 and n2.height*n2.width > 0) or ((n2.maxZ-n2.minZ)*
(n2.maxY-n2.minY) < 0.05) or ((n2.maxZ-n2.minZ)* (n2.maxX-n2.minX) < 0.05) or ((n2.maxX-n2.minX)*
(n2.maxY-n2.minY) < 0.05)) set r1.Type=”irrelevant” and r1.Solution=”open_hole” return distinct r1

such as walls or slabs from the safety perspective. The standard usually
refers to the size of flow segments, for example, diameter < 25 cm or
cross-section area < 0.05 m2 in the test project. There is no need to
discuss how to solve these clashes and the solution consists of opening a
hole in the corresponding location. Therefore, filtering out these clashes
and marking their solutions facilitate clash management. This query
needs to control the IFC entity name of one clash object as “IFCSlab” or
“IFCWallStandardCase”, the clash type as “Penetration” or “Penetration
through” and the size of another clash object. To define size, if original
size attributes (diameter or (height and width)) exist, the paper used
them. Otherwise, the AABB box was used to define size. Therefore, Q6
in Table 6 was used to identify required clashes and set them as irre-
levant and their suggested solutions as open_hole. This query identified
22 clashes.
The four scenarios identified a total of 53 clashes. To validate the
precision, each queried clash was manually reviewed and all of them
complied with the designed scenarios. To use the method, users do not
need to write the above query, as they just need to select whether they

10
Y. Hu, et al. Automation in Construction 105 (2019) 102832

into the properties of nodes.

Group 2
Clash 1
Clash 2
Clash 3
Clash 2
Clash 1
Group 1
Fig. 15. Clashes sharing the same building component.
want to ignore the above scenarios. They can also change the size of the
object penetrating the structural elements in Scenario 4. After ignoring
the above clashes, the number of clashes decreased to 259, which is a
17% reduction.
4.2.2. Group related clashes
The component dependent network can be also used for auto-
matically grouping clashes. Some clashes are interdependent and
should be discussed together. This approach decreases the number of
clashes and reduces the time for manually grouping clashes, which
improves clash management efficiency. The idea is to group clashes that
share the same components, as shown in Fig. 15. Sharing the same
components from a graph view means nodes are connected by clash
relations. Therefore, grouping clashes is equivalent to identify disjoint
sets in the graph connected by the remaining clashes (except clashes in
the above four scenarios). Neo4j graph algorithm library was used to
query disjoint sets. Q7 in Table 7 was used to set the id of disjoint sets
The query returned 91 groups and the group size distribution is
shown in Fig. 16a. The largest group contains 80 clashes. The reason for
the large group is that these clashes are related to structure elements,
such as walls or slabs that are very large and connected by many
components. If we ignored the clashes with structure elements before
grouping then, 191 MEP clashes were grouped into 92 sets and the
largest group contained 9 clashes, as shown in Fig. 16b. Fig. 15 shows
two examples of groups. From Fig. 15, we can see that it makes sense to
solve these clashes together other than separately. From the above
analysis, it can be concluded that grouping based on the component
dependent network facilitates reducing the number of clashes in clash
reports and grouping related clashes together helps users to think about
some overall solutions.
Clash 3
4.2.3. Check nearby environment for a clash and decide central components
In addition to cleaning out irrelevant clashes and grouping related
clashes, the network used to analyze the surrounding environment for a
certain clash, which supports the clash resolution process. The sur-
rounding environment for a clash can have three levels: 1) whether
there are other components around the clash and how many of them; 2)
which one is the nearest component to a clash component; 3) whether
the clash component has enough room to move in a certain direction.
Table 8 contains query examples for these questions, which provides
overall analysis for all clashes (Q8) and specific information for a cer-
tain clash (Q9 and Q10). Q8 ordered clashes by the number of its im-
pacted components, which reflects the congestion level of the sur-
rounding environment of a clash. Fig. 17 is the histogram of the number
of impacted components for clashes. Fig. 18 show two examples.
Fig. 18a represents a clash only impacted two other components and
the clash in Fig. 18b impacted 122 other components. It is easy to find
that Clash 156 located in a more crowded area. Generally, crowded
environment will complicate clash resolutions and solving a clash in
these areas may impact many other components. Therefore, filtering
these clashes out and fixing them first decreases information un-
certainty and facilitate design coordination. Q9 was used to find the
nearest components for a clash component, and Fig. 19a is geometric
representation for the result of the specific case. In addition to the

Table 7
Query sentence for grouping clashes.
Function descriptions Query example in Neo4j

Q7. Identify disjointed clashes Sentence: call algo.unionFind(‘match(n) return id(n) as id’, ‘match(n1)-[r1:ClashRelationship]-(n2) where r1.Type is null return id(n1) as
source, id(n2) as target’, {graph: “cypher”, write: true})

60 57 70
58
60
50
Group Number
Group Number

50
40
40
30
30
20 14 20 15
10 5 10 5 3 3 4 3
2 3 1 3 1 1 1 1 1
0 0
1 2 3 4 5 6 7 8 9 12 80 1 2 3 4 5 7 8 9
The Number of Clashes in a Group The Number of Clashes in a Group
a b
Fig. 16. a. Clash group result with structure discipline
b. Clash group result without structure discipline.

11
Y. Hu, et al.
Table 8
Query examples for clash surrounding environments analysis.
Function descriptions
Q8: Count impacted components near a clash and order clash in
decreasing of the number of impacted components
Q9: Query the nearest components for a clash component and
return the distance.
Q10: For a certain clash component, checking whether there is
enough room for moving it along a certain direction to avoid a
certain clash
nearest components, checking whether there is enough room to move is
also important for clash management. Q10 was used for this check and
Fig. 19b is the geometric representation for the test example.
To support clash resolution, the clash component network can be
used to analyze the central components. Degree centrality is a key in-
dicator to measure the position of a node in one network [27]. The
individual degree of centrality is equal to the number of edge incidents
to the individual. In this test case, it consists of the number of clashes
that one component is involved in. Components that involve many
clashes should be paid more attention in the design coordination pro-
cess. It may relate to critical clashes that need a lot of discussions.
Meanwhile, it also provides the possibility to solve multiple clashes by
changing one component. In neo4j database, the following sentence
calculates the degree centrality of clash components and returns them
in descending order “MATCH (n1)-[r:ClashRelationship]-(n2) where
r.Type is null return n1.GlobalID, count(n2) as degree order by degree
desc”.
Fig. 17. Histogram of clash impacted components.
Automation in Construction 105 (2019) 102832
Query example in Neo4j
Sentence: MATCH (n1) - [r:ClashRelationship1] - > (n2) where r.Type is null with n1, n2, r optional match
(n1) - [r1:ImpactRelationship] - > (n3) with n1,n2,n3,r optional match (n2) - [r2:ImpactRelationship]
- > (n4) return distinct r.ID, size(collect(distinct n4.GlobalID) + collect(distinct n3.GlobalID)) as impact
order by impact desc
Sentence: MATCH (n1) - [r:ClashRelationship1] - (n2), (n1)-[r1:ImpactRelationship]- > (n3) where r.Type
is null and r.ID = 139 return r1.BLimit, r1.Direction order by r1.BLimit limit 1
Result: r1.Blimit = 0.0943, r1.Direction=”AxisZN”
(we use Clash 139 as an example)
Sentence:Match (n1) – [r1:ClashRelationship]- (n2), (n1) – [r2:ImpactRelationship]- > (n3) where
n1.GlobalID = “32pVXjknD4qhBfxePw5hsZ” and r2.Direction = “AxisXP”
and r1.ID = 78 return Case r1.A
When n1.GlobalID then r1. AMoveAxisXP < min(r2.BLimit)
Else r1. BMoveAxisXP < min(r2.BLimit)
End as EnoughRoom
Result: False
(the assumption is that if the clash distance for a clash component in a given direction is larger than the
minimum distance between the component with its nearby components, there is no enough room for the
component in the given direction)
5. Discussions
The accuracy issue of BIM-enabled clash detection has been ob-
served in many projects. However, few solutions were proposed to
clean out irrelevant clashes without increasing the workload of project
teams. Some software tried to pre-process clashes based on the prop-
erties of clash components, but they ignored that building components
depend on each other and a clash is a spatial relation in nature. The
dependent relations between building components is important for pre-
processing clashes and improve the quality of clash detection. Firstly,
the paper identified three types of spatial relations: clash, connection,
and impact relations that are useful for the clash cleaning process and
designed algorithms to capture these relations. It was argued that cla-
shes should be divided into different types based on the topological
relations between clash components because they may lead to different
clash resolution strategies. The argument was supported in the test case,
in which the clash type classification combined with other information
facilitate the identification of irrelevant clashes (i.e., irrelevant clashes
Scenario 3 and Scenario 4). Impact relations combined with component
bounding box coordinates were used to identify insulation relations.
The insulation relations consist of two functions: 1) identify duplicate
clashes (Scenario 1), and 2) supplement connection relations since
connectivity between insulations were usually missing in model files.
Connection and clash relations were used together to identify modeling-
caused irrelevant clashes because logically connected components
should not overlap (Scenario). In the test case, the proposed method
identified 53 irrelevant clashes out of 312 clashes, which accounted for
17%.
Identifying irrelevant clashes was based on the analysis of compo-
nent relations. To play the role of the network, the paper proposed to
group clashes based on a clash component network. Clashes were linked
by sharing the same components. Grouping connected clashes provides
two advantages: 1) decrease number of clashes; 2) provide the basis for
project teams to discuss overall solutions for related clashes. In the test
project, 191 MEP clashes were included into 91 sets. In addition, the
impact network was used to analyze the environment of clashes. The
number of impacted components related to a clash was used to rank
clashes. The larger the number, the more congested area a clash is lo-
cated. This kind of application helps project teams to focus on serious
clashes and improve the efficiency of design coordination meetings.
Checking nearest components of a clash, deciding whether enough
12
Y. Hu, et al. Automation in Construction 105 (2019) 102832

Clash 109 impacts two Clash 156 impacts 122

other components other components

a. A clash example in uncrowded area b. A clash example in congest area

Fig. 18. Examples of clash impacted components
a. A clash example in uncrowded area
b. A clash example in congest area.

room exists for it, and identifying components involving multiple cla-
shes serve for the clash resolution process. In the test project, the pro-
posed method showed the feasibility to clean out automatic clash de-
tection results and provided support for clash resolution based on the
building component dependent network.
6. Conclusions
The paper proposed a new perspective to view clashes by con-
sidering the interdependent nature of building components. Through
capturing three dependent relations from BIM models, a component
dependent network was constructed, which involved the network
thinking into the clash management field. Many analyses can be con-
ducted from the network. This paper mainly focused on using the net-
work to pre-process clash reports by cleaning out irrelevant clashes,
grouping relevant clashes, identify central components, and analyzing
nearby environment of clashes. These applications were tested on a real
project, which significantly reduced the number of clashes. The query
examples for analyzing the surrounding environment for clashes were
also represented in this paper for supporting clash resolutions.
Network theory was used to improve clash detection, but identi-
fying problems is the first step; how to solve these clashes is also im-
portant. Clashes depend on each other spatially. Correcting one of them
may impact the solution of other clashes and they will also impact
nearby objects, which can cause new clashes if there are no systemically
strategies to correct them. Therefore, how to use the network to support
clash resolutions and find the globally optimized solutions can be the
future research direction. In addition, this paper focused on hard cla-
shes, but how to use the network idea to improve active clash man-
agement for supporting the construction process or soft clash manage-
ment for supporting facility management deserves further discussion.
Finally, even though the proposed method was tested on one project
and verified its feasibility, more tests in different types of projects can
be conducted to improve the generality of the method in the future.

Required distance for

moving in AxisXP
direction 0.121 m

The nearest component Clash 139

to the duct
distance=0.094m
Minimum distance for
nearby components in
this direction is 0.066

a. Nearest component example b. Enough room comparison example

Fig. 19. Geometric representation of clash component
a. Nearest component example
b. Enough room comparison example.

13
Y. Hu, et al. Automation in Construction 105 (2019) 102832

Appendix A

Table 1
Spatial relations definition and query method summary.

Spatial rela- Relation categories Explanation Reference Original geome- File Method
tion type trical representa- format
tion of
source
data

Topological Adjacency Define relationships between vertex and Nguyen Point, line, face CAD Non-hierarchy geometric method: Use
Relations Separation face. and Oloufa model the relationships between vertex and
Containment Adjacency: One component is adjacent to, [18] face to decide the topological relations,
Intersection next-to, above, or below the other and he defined this as relation index.
Connectivity Separation: Components are separate
from each other
Containment: One component is inside in
the other
Intersection: One component intersects
the other
Connectivity: One component connects to
the other
Connectivity Containment He classified topological relations based Khalili and Attribute-based IFC Attribute-based: Topology-driven
Separation on Nguyen's classification and subsumed Chua [19] method and did model method. In fact, he used pre-defined
Intersection adjacency in connectivity. not consider geo- relationships in IFC file to define these
metric represen- relationships.
tation
9-intersection model Formal 9-IM contains eight relations: Solihin Multiple repre- IFC Hierarchy geometric method: Using
disjoint, touch, equal, within, contains, [21] sentations: B-rep, model octree methods to test intersections,
overlap, cover, and covered. AABB box overlap, contains, inside, covers,
coveredBy and equal relations. Use
boundary face to test meet relations.
Build one master tree for a whole
building other than individual tree.
Intersect, disjoint, and penetra- Compared with traditional 9-IM relations. Nepal et al. Point and Line Revit Non-hierarchy geometric method:
tions This paper distinguished intersect and [20] model Separating Axis Theorem to detect in-
penetrations. tersect. Penetration is tested based in-
tersect predicate and object type (wall
and duct)
Revised 9-intersection model: six Define topological relationship based on Borrmann B-rep / Hierarchy geometric method: Octree-
relations: disjoint, touch, equal, the relationships between interior and and Rank based method
within, contains, overlap boundary of objects. Revised 9-IM sub- [24] AABB-based BVH tree
sumes cover and covered by under within Daum and
and contain because the researchers think Borrmann
object's interiors or boundaries overlap [28]
has no big difference in the engineering
field.
Distance Rela- Center-to-center distance/clear Distance related relations [20] Point and Line Revit Parameter-based: Calculate distance
tions distance (face to face distance) model between central point and boundary
face
Minimum/Maximum distance, Distance related relations Borrmann B-rep / Hierarchy geometric method: Two
predicates about is closer or is et al. [24] kinds of methods: Octree and AABB-
farther based BVH tree were compared
Orientation r- North of, south of, east of, west of, Directional relationships between 3D ob- [17] B-rep / Hierarchy geometric method: Halfsapce
elations above, and below jects. based method
projection-based method: slot tree (a
revised octree). Each object has an
individual octree.
Above, below, left of, right of, Directional relationships between 3D ob- Solihin B-rep / Hierarchy geometric method: Octree
front of, behind of and directly jects. [21]
above, directly below, directly
leftOf, directly rightOf, directly
front, directly behind
north, south, east or west direc- Directional relationships between 3D ob- Nepal et al. using circle to re- Revit Parameter-based: Ray-intersect method
tion. jects. [20] present column model

14
Y. Hu, et al.
Fig. A1. Algorithm for calculating the maximum distance of impact relations.
References
[1] Cao, D., Wang, G., Li, H., Skitmore, M., Huang, T., & Zhang, W. (2015). Practices
and effectiveness of building information modelling in construction projects in
China. Autom. Constr., 49(PA), 113–122. https://doi.org/https://doi.org/10.1016/
j.autcon.2014.10.014
[2] T. Hartmann, Detecting design conflicts using building information models: A
comparative lab experiment, Proceedings CIB W78 2010: 27th International
Conference - Cairo, Egypt, 16–18 November, 2010, pp. 16–18 Retrieved from
15
Automation in Construction 105 (2019) 102832
http://itc.scix.net/cgi-bin/works/Show?w78-2010-57.
[3] S. Mehrbod, S. Staub-french, N. Mahyar, P. Fellow, M. Tory, T. Software, P. Alto,
Beyond the clash: investigating BIM-based building design coordination issue re-
presentation and resolution, Journal of Information Technology in Construction 24
(2019) 33–57 Retrieved from http://www.itcon.org/2019/3.
[4] A.L.C. Ciribini, S.M. Ventura, M. Paneroni, Automation in construction im-
plementation of an interoperable process to optimise design and construction
phases of a residential building: a BIM pilot project, Autom. Constr. 71 (2016)
62–73, https://doi.org/10.1016/j.autcon.2016.03.005.
[5] Hu, Y., & Castro-Lacouture, D. (2018). Clash relevance prediction based on machine
Y. Hu, et al.
learning. J. Comput. Civ. Eng., 33(2), 04018060. https://doi.org/https://doi.org/
10.1061/(ASCE)CP.1943-5487.0000810
[6] L. Wang, F. Leite, Knowledge discovery of spatial conflict resolution philosophies in
BIM- enabled MEP design coordination using data mining techniques: a proof-of-
concept, Computing in Civil and Building Engineering 91 (2013) (2013) 399–404
Retrieved from https://doi.org/10.1061/9780784413029.053.
[7] L. Wang, F. Leite, Formalized knowledge representation for spatial conflict co-
ordination of mechanical, electrical and plumbing (MEP) systems in new building
projects, Autom. Constr. 64 (2016) 20–26 https://doi.org/10.1016/j.autcon.2015.
12.020.
[8] A.O. Akponeware, Z.A. Adamu, Clash detection or clash avoidance? An investiga-
tion into coordination problems in 3D BIM, Buildings 7 (3) (2017) 1–28, https://
doi.org/10.3390/buildings7030075.
[9] Korman, T. M., Fischer, M. A., & Tatum, C. B. (2003). Knowledge and reasoning for
MEP coordination. J. Constr. Eng. Manag., 129(6), 627–634. https://doi.org/
https://doi.org/10.1061/(ASCE)0733-9364(2003)129:6(627)
[10] van den Helm, P., Böhms, M., & van Berlo, L. (2010). IFC-based clash detection for
the open-source BIMserver. Computing in Civil and Building Engineering,
Proceedings of the International Conference. Nottingham University Press,
Nottingham, UK, 30. Retrieved from http://bimserver.org/wp-content/uploads/
sites/6/2010/11/Helm_Clashdetection.pdf
[11] Love, P. E. D., & Smith, J. (2016). Toward error Management in Construction:
moving beyond a zero vision. J. Constr. Eng. Manag., 142(11), 04016058. https://
doi.org/10.1061/(ASCE)CO.1943-7862.0001170.
[12] G. Lee, J.W. Kim, Parallel vs. sequential cascading MEP coordination strategies: a
pharmaceutical building case study, Autom. Constr. 43 (2014) 170–179, https://
doi.org/10.1016/j.autcon.2014.03.004.
[13] S.P. Borgatti, D.S. Halgin, On network theory, Organ. Sci. 22 (5) (2011) 1168–1181
Retrieved from https://doi.org/10.1287/orsc.1100.0641.
[14] P. Chinowsky, J. Diekmann, V. Galotti, Social network model of construction, J.
Constr. Eng. Manag. 134 (October) (2008) 804–812 Retrieved from https://doi.org/
10.1061/(ASCE)0733-9364(2008)134:10(804).
[15] Clementini, E., & Di Felice, P. (1996). A model for representing topological re-
lationships between complex geometric features in spatial databases. Inf. Sci.,
90(1–4), 121–136. https://doi.org/10.1016/0020-0255(95)00289-8.
[16] M.J. Egenhofer, R.D. Franzosa, Point-set topological spatial relations, Int. J. Geogr.
Inf. Syst. 5 (2) (1991) 161–174 https://doi.org/10.1080/02693799108927841.
16
Automation in Construction 105 (2019) 102832
[17] A. Borrmann, E. Rank, Topological analysis of 3D building models using a spatial
query language, Adv. Eng. Inform. 23 (4) (2009) 370–385 https://doi.org/10.1016/
j.aei.2009.06.001.
[18] Nguyen, T.-H., & Oloufa, A. A. (2001). Computer-generated building data: topolo-
gical information. J. Comput. Civ. Eng., 15(4), 268–274. Retrieved from https://
doi.org/10.1061/(ASCE)0887-3801(2001)15:4(268).
[19] A. Khalili, D.K.H. Chua, IFC-based graph data model for topological queries on
building elements, J. Comput. Civ. Eng. 29 (3) (2015) 04014046 https://doi.org/
10.1016/j.enbuild.2017.11.046.
[20] M.P. Nepal, S. Staub-French, R. Pottinger, A. Webster, Querying a building in-
formation model for construction-specific spatial information, Adv. Eng. Inform. 26
(4) (2012) 904–923 https://doi.org/10.1016/j.aei.2012.08.003.
[21] W. Solihin, A Simplified BIM Data Representation Using a Relational Database
Schema for an Efficient Rule Checking System and its Associated Rule Checking
Language, Georgia Insititute of Technology, 2016 Retrieved from http://hdl.handle.
net/1853/54831.
[22] A. Borrmann, E. Rank, Specification and implementation of directional operators in
a 3D spatial query language for building information models, Adv. Eng. Inform. 23
(1) (2009) 32–44 https://doi.org/10.1016/j.aei.2008.06.005.
[23] M. Stich, H. Friedrich, A. Dietrich, Spatial splits in bounding volume hierarchies,
Proceedings of the 1st ACM Conference on High Performance Graphics - HPG ‘09,
2009, p. 7, , https://doi.org/10.1145/1572769.1572771.
[24] A. Borrmann, S. Schraufstetter, E. Rank, Implementing metric operators of a spatial
query language for 3D building models: octree and B-rep approaches, J. Comput.
Civ. Eng. 23 (1) (2009) 34–46, https://doi.org/10.1061/(ASCE)0887-3801(2009)
23:1(34).
[25] P. Lindemann, The Gilbert-Johnson-Keerthi distance algorithm, Retrieved from,
2009. https://www.medien.ifi.lmu.de/lehre/ss10/ps/Ausarbeitung_Beispiel.pdf.
[26] Y. Saab, A fast and effective algorithm for the feedback arc set problem, J.
Heuristics 7 (3) (2001) 235–250, https://doi.org/10.1023/A:1011315014322.
[27] Wambeke, B. W., Asce, M., Liu, M., Asce, A. M., & Hsiang, S. M. (2012). Using Pajek
and centrality analysis to identify a social network of construction trades. Journal of
Construct, 138(OCTOBER), 1192–1201. https://doi.org/https://doi.org/10.1061/
(ASCE)CO.1943-7862.0000524.
[28] S. Daum, A. Borrmann, Processing of topological BIM queries using boundary re-
presentation based methods, Adv. Eng. Inform. 28 (4) (2014) 272–286 https://doi.
org/10.1016/j.aei.2014.06.001.