Construction Research Congress 2018 470

BIM Interoperability for Structure Analysis

Ran Ren1; Jiansong Zhang2; and Hazar Nicholas Dib3

1
School of Construction Management Technology, Purdue Univ., West Lafayette, IN 47907.
E-mail: ren153@purdue.edu
Downloaded from ascelibrary.org by MISSOURI, UNIV OF/COLUMBIA on 04/15/18. Copyright ASCE. For personal use only; all rights reserved.

2
School of Construction Management Technology, Purdue Univ., West Lafayette, IN 47907.
E-mail: jiansong-zhang@purdue.edu
3
School of Construction Management Technology, Purdue Univ., West Lafayette, IN 47907.
E-mail: hdib@purdue.edu

Abstract
Building information modeling (BIM) is facilitating a procedural change for the
architecture, engineering, and construction (AEC) industry to share information in all the phases
of the life cycle of a building. It possesses great advantages in designing, analyzing, and
documenting all physical and functional information of a building and construction project.
Structural analysis is an integral part of the life cycle phases of building construction projects.
The information needed for structural analysis originates from the architectural model, but the
architectural model can be created without much consideration of structural analysis. Software
tools used by architects and structural engineers are usually different and sustain information
inconsistency and or missing information leading to software interoperability problems. As the
first step towards addressing this issue, in this paper, the authors conducted a preliminary
literature review in order to identify topics and trends on the BIM interoperability problem with a
focus on the structural analysis domain, from both the theoretic perspective and the application
perspective. Structural analysis is performed and discussed in the following sections to
demonstrate interoperability problems and propose possible solutions.

INTRODUCTION
“Interoperability means the ability of information and communication technology (ICT)
systems and of the business processes they support to exchange data and to enable the sharing of
information and knowledge” (EIF 2004). This definition by the European Interoperability
Framework (EIF) is readily applicable in the architecture, engineering, and construction (AEC)
domain (EIF 2004). Traditionally, project information is shared through exchanging files in
different formats, such as .dwg, .dxf, and .pdf, but appropriate levels of information cannot be
transferred from one model to another in a straightforward way through such file exchange
(Howell and Batcheler 2005). In order to better exchange and represent data in the AEC domain,
the International Alliance for Interoperability (IAI) (former name of buildingSMART) developed
a set of building product models including industry foundation classes (IFC). The IFC standard
was first specified in 1996 (BuildingSMART 2007). It was constantly being developed and was
registered as ISO 16739. IFC is currently the most widely used non-proprietary exchangeable
format to represent building information and accelerate information exchange between AEC
software (Volk et al. 2014). IFC-based BIM models are designed to be more interoperable than
traditional CAD; and IFC has been used in information exchange in many scenarios (Volk et al.

© ASCE

Construction Research Congress 2018

 Construction Research Congress 2018 471

2014). This short review paper focuses on existing work and related background using IFC-based
BIM models for information exchange between architectural and structural models, and
identifying research gaps on this topic.
After years of development, the three main stages of which are shown in Table 1, IFC has
helped simplify information flow in the AEC domain.

Table 1. The Three Main Development Stages of IFC

Downloaded from ascelibrary.org by MISSOURI, UNIV OF/COLUMBIA on 04/15/18. Copyright ASCE. For personal use only; all rights reserved.

Stages Time Development

First – 1994- 1994.08 - An open standard (the precursor of IFC) for
Preliminary 1999 information exchange in the AEC industry was published.
Stage 1997.01 - IFC 1.0 was established with limited scope of
information coverage.
1999.04 - IFC 2.0 was published with a focus on building
services, cost estimation, and construction planning
(Kiviniemi 2006).
Second – 2000- 2000 - IFC 2X was published with more focus on underlying
Improved 2005 technical architecture.
Information 2003.05 - IFC2X2 was released with a focus on 2D model
Coverage support for facility management and building codes
of AEC verification (Liebich 2010).
Domain IFC 2X and IFC 2X2 cover 6 AEC subdomains: heating,
ventilation and air-conditioning (HVAC), engineering,
architecture, codes standards, cost estimating, facilities
management, and simulation (Chen et al. 2005).
Third – 2006- 2006 - IFC3 was published (Kiviniemi 2006).
Refinement now 2010 - IFC4 was published and it keeps developing (Liebich
Stage 2010).
IFC3 and onward emphasizes integrated design and
construction process

BIM INTEROERABILITY
The Knowledge Industry Survival Strategy (KISS) classification of BIM interoperability
levels is used for modeling language check, information storage and exportation. KISS has five
different levels: file and syntax level, visualization level, semantic level, alternative
representations level, and parametric modeling level (Steel et al. 2012). The file and syntax level
controls the media of exchange between different software tools and checks representations of
model information in the files to ensure the model can run without errors in the different
software tools (Steel et al. 2012). The visualization level is vital in BIM interoperability, given
the multiple dimensions and the high level of complexity of BIM data. Visualization of BIM
models can help identify such missing or inconsistent information, but the large size of a BIM
model causes certain difficulty in its visualization in a comprehensive, detailed, and organized
manner, especially when checking information consistency from model to model is taken into
consideration. The semantic level addresses the exchange of real meanings between models.
Alternative representations level explains that different simulations have different focus areas out

© ASCE

Construction Research Congress 2018

 Construction Research Congress 2018 472

of researrch needs or o applicatio on needs, su uch as enerrgy simulatioon and firee emergencyy exit
simulatioon. Parametrric modeling g level definees parametri c properties of models. A An ultimate BIM
interoperrability need ds to have successful
s a smooth informationn exchange at all thesee five
and
levels.
IFFC interoperrability defiines five lay yers to suppport deployaable results in AEC proojects
(Figure 1), namely,, IFC model specificaation, IFC m model view w definitionns (MVDs), IFC
implemen ntations, excchange requiirements, an nd process mmap. The relaationships beetween thesee five
Downloaded from ascelibrary.org by MISSOURI, UNIV OF/COLUMBIA on 04/15/18. Copyright ASCE. For personal use only; all rights reserved.

layers caan be represeented as a py

yramid shapee, with each layer havingg a direct rellationship wiith its
neighborrs. In additioon, an inform
mation deliveery manual ((IDM) deciddes what infformation neeed to
be deliveered from on ne party to annother at any y given timee for a succeessful commuunication prrocess
and affeccts several laayers (Volk et
e al. 2014).
The
T lower lev vel layers prrovide inform mation requuests to the uupper level llayers. The uupper
level layyers respond d to the reqquests throug gh technologgical innovaations and ddeployment.. The
lower lev vel layers need to be aw ware of the feasibility oof their requuests’ beingg accepted bby the
upper levvel layers to implement. Any noted limitations
l bbased on IFCC data exchannge requirem ments
should beb conveyed d to software developerrs whose deevelopment and implem mentation relly on
informatiion provided d by the uppeer level layeers.

Figure 1. IFC intero

operability llayers (Kiviiniemi 20066)

RESEAR RCH GAP

G ANNALYSIS IN ARCHITE ECTURAL//STRUCTU URAL
INTERO OPERBILIT TY
Innteroperabiliity is the co
ore of BIM informationn exchange in the AEC C domain. Inn this
paper, the authors focus on gap analysis
a of using
u IFC beetween archiitectural desiign and strucctural
analysis, mainly from m the standpo oints of IFC extension aand IFC file iimportation//exportation..
The
T IFC exttension has two main levels: IFC C concepts extension aand IFC doomain
extension n. In IFC cooncepts exten nsion consid derations, cooncepts can be classifiedd into three main
categoriees: concepts in an IFC model, con ncepts not inn an IFC m model, and nnewly introdduced
concepts (Wan et al. a 2004). For example,, in structurral analysis,, boundary conditions (e.g.,
restraintss and releasee of frame elements)
e aree usually maanually addeed to an existing IFC m model,
and theyy must be co ompatible with
w existing g informatioon in this IF FC model. H How to addd new
concepts into an existing IFC model
m withou ut causing c onflicts withh the existinng information in
the IFC model
m is an important
i co
onsideration in such effoorts. Lee andd Kim (2011)) proposed too add
“IfcSpatiialElement” for represeenting spatiaal elements in bridge structures. They addedd the
“IfcSpatiialElement” as a subcon ncept of “IfccElement”. T This additionn allows reppresenting sppatial

© ASCE

Construction Research Congress 2018

 Construction Research Congress 2018 473

elements in a bridge model with enhanced clarity, while at the same time being compatible with
existing parts of the bridge model. Markova, Dieckmann and Russell (2013) extended the IFC
schema by adding the concepts “simulation and documentation,” and “optimization” into the
material section to enable material reuse feedback in order to reduce waste. Amann et al. (2015)
added “IfcReferenceCurveAlignment2D” element into the IFC schema about a horizontal and a
vertical alignment curve for road design applications.
IFC domain extension requires users’ understanding in: (1) what input information is
Downloaded from ascelibrary.org by MISSOURI, UNIV OF/COLUMBIA on 04/15/18. Copyright ASCE. For personal use only; all rights reserved.

needed in this domain; and (2) how to minimize potential conflicts between the extension and
similar definitions that already existed. How to apply IFC domain extension to AEC subdomains
to better support information exchange between different BIM applications in those subdomains
is an important problem that needs solving (Santos et al. 2017). For example, Sacks and his
colleagues conducted the Rosewood experiment which improved the precasting workflow by
extending IFC support from architectural design to construction applications. They also
developed an Information Delivery Manual for both design and construction domains (Sacks et
al. 2010). Zhang and El-Gohary (2016), on the other hand, extended IFC support from
architectural design to building codes compliance checking through semi-automated IFC
extension methods. For the problem of limited coverage of the IFC schema in supporting BIM
interoperability (Eastman 1992), early work developed customized building models, but they did
not integrate all the domains, e.g., the full interoperability from architectural design to structural
analysis and beyond is yet to be achieved. IFC Extension and data exchange requirement
standardization may solve this problem for BIM interoperability. Well-analyzed IFC files as well
as their needed extensions could help broaden BIM information coverage to improve BIM
interoperability.
From the software point of view, different software have different information coverage
and different usage in the AEC industry. How to import an IFC file and export it for further
analysis successfully is another important consideration for interoperability. Table 2 summarizes
different BIM software and their information coverage related to structural analysis (Zeng et al.
2014).
Table 2. Different BIM Software and Their Information Coverage (Zeng et al. 2014)
Software Tekla Etabs 9 ArchiCAD SAP Revit IFC 4
Sturctures 16 2000 Structure
Properties 18.1 v15 2013
Geometric
Yes Yes Yes Yes Yes Yes
property
Material
Yes No Yes No Yes Yes
property
Structure
analysis No Yes No No No Yes
modeling
Load No No No No No Yes
Reinforcement
Yes No No No No Yes
information
Support
No No No No No Yes
restraint

© ASCE

Construction Research Congress 2018

 Construction Research Congress 2018 474

From Table 2, we can see that different software cover different properties in their
modeling. Therefore, when an IFC model is exported from one software and imported into
another, certain information may miss or become untraceable. Redefining information manually
is time-consuming and human error-prone. But without a full interoperability these manual input
cannot be avoided. In the structural analysis domain, for example, when a shell element is being
analyzed, the following information are needed but may not be successfully transferred using
IFC models: new classes of load setting, combined material definition, different forces and
Downloaded from ascelibrary.org by MISSOURI, UNIV OF/COLUMBIA on 04/15/18. Copyright ASCE. For personal use only; all rights reserved.

moments (Wan et al. 2004). This requires direct support for IFC files and their processing in
structural analysis software applications.
Even with direct IFC file support, missing information can still be a big problem in the
importation/exportation of IFC files, especially those that are undetected (Kiviniemi 2008). To
address this, developers have to manually check potential information loss before file exchange,
or semi-automatically check it in order to avoid/reduce unknown information missing during the
file exchange. Human-induced errors also need to be considered in such checking. The sizes and
complexities of IFC models affect the importation/exportation process as well. Large models
developed in more powerful platforms may contain information that is not directly interpretable
in smaller platforms. One way to address this problem is to follow strict information
requirements and MVDs to ensure the consistency of models across different platforms.

BIM INTEROPERABILITY WITH STRUCTURAL ENGINEERING APPLICATIONS

To empirically test the interoperability of BIM for structural analysis, the authors
conducted simple experiments using several structural analysis software as described in details
below.
ETABS is a software that conducts linear structural analysis involving both static loads
and dynamic loads (Kalny 2013). AutoCAD drawings can be imported directly into the ETABS
software. Analysis in the ETABS software is based on spatial FEA and focuses on spatial
features of the structure such as different earthquake zones for slabs. Objects are simulated by
targeted geometric representations. Structural models can be transferred from IFC-based BIM to
PKPM or YJK software, and further transferred to the ETABS software (Liu and Zhang 2015).
ABAQUS is a multi-function finite element software, especially suitable for non-linear
analysis. It has a different type of database of material modeling comparing to other tools such as
ETABS (with .e2k file) and SAP2000 (with .s2k file). For example, in ABAQUS, a structural
model can be created directly by selecting material parameters in the GUI. Then processes
affecting the structure such as welding and post weld heat treatment of the structure can be
automatically simulated and analyzed. It supports both modeling and structural analysis. Model
upload from other software (e.g., Pro-Engineer, NX, and Solidworks) is also supported. IFC data
exchange to ABAQUS software is possible by using PKPM or YJK as an intermediary platform
(Liu and Zhang 2015). Input files for ABAQUS can be manually written to do structural analysis.
For example, ABAQUS reads material properties from input files using the following format:
*MATERIAL, NAME=STEEL *ELASTIC 200. E9, 0.3, meaning that this steel element has a
Young’s modulus of 200*109 and a Poisson ration of 0.3.
SAP 2000 is designed by Computer and Structures Inc. in 2011. It is a civil engineering
software used for designing and analyzing structural systems. It has buit-in model templates, and
advanced analysis options, especially for 3D complex space structures. SAP 2000 can also be

© ASCE

Construction Research Congress 2018

 Construction Research Congress 2018 475

used as a solver of other softwaare, such as Tekla Struccture softwaare. Wind, w wave, bridgee and
seismic loads can be automaticallly generated d by integrat ed design coode features (Fu 2015).
Autodesk
A Rev vit is part off the BIM so oftware deveeloped by Auutodesk in 22014. It integgrates
many paarts of diffferent functiions, such as architecttural designn, structurall analysis, MEP
engineeriing analysis, sustainability assessmeent and consstruction maanagement suupport. Autoodesk
Revit Strructure has many
m built-iin architectu
ural and struuctural templlates. Models can be crreated
from existing templaates or by designing
d fro
om scratch. In this papeer, Autodeskk Revit Struucture
Downloaded from ascelibrary.org by MISSOURI, UNIV OF/COLUMBIA on 04/15/18. Copyright ASCE. For personal use only; all rights reserved.

software was used to o create beam m and colum mn models fo for testing. T ws different types
Table 3 show
of files used
u in diffferent softw ware for the preliminaryy interoperaability experriment, and their
results off structural analysis.
a

Table 3. Different Types

T of Filees in Differeent Softwaree Representtation
Enttities 1 Ifc Beamm 1 Ifc Column
C 18 Ifc Slaabs 2 Ifc walls
Origin
nal file in
Autodesk
Reviit 2018

IFC
C file
exp
ported

Stru
uctural
anaalysis
resuults in
ETABS
Stru
uctural
anaalysis
resuults in
SAP P2000
Stru
uctural
anaalysis
resuults in
Autodesk
Roobot

In
n this experiiment, Revitt files were imported innto Autodeskk Revit, andd exported ass IFC
files. Th
he IFC files were imported into different softw ware, such as ETABS, SAP 2000, and
Autodesk k Robot to conduct
c strucctural analyssis. Four typpes of objeccts were usedd, namely, bbeam,
column, slab, and wall.
w Beam and
a column models weere created iin Autodeskk Revit Struucture
software directly, whhereas slabs and walls models
m were downloadedd from onlinne sources. T Table
4 shows the property
y representattions of the models in d
different sofftware for st ructural ana
alysis,

© ASCE

Construction Research Congress 2018

 Construction Research Congress 2018 476

including material properties, section properties, degree of freedom, and load description.
IFC file was used as the standard file to test the interoperability between architectural
design and structural analysis. During this import/export process, a few problems occurred that
caused unsuccessful import/export results. For example, when IFC files were created in the
Autodesk Revit Structure and imported into Autodesk Robot for structural analysis, material
property was missing and loads information could not be loaded. Autodesk Revit Structure is
good for processing large building models, but for simple models, such as a beam or column,
Downloaded from ascelibrary.org by MISSOURI, UNIV OF/COLUMBIA on 04/15/18. Copyright ASCE. For personal use only; all rights reserved.

boundary conditions such as a pin on certain point/node/element cannot be directly loaded.

Secondly, when IFC files were imported, Autodesk Robot could not read material information
from the IFC files. It caused information missing when IFC files were imported into Autodesk
Robot. That was the reason why we had no structural analysis results for slabs and walls (Table 3)
when using Autodesk Robot. If Autodesk Robot can read IFC input files directly like ABAQUS
as we explained above, the problem in loading forces information for the created models could
be solved.

Table 4. Properties Representations in Different Software

Softwa Entities Material properties Section properties Degree Load
re of
freedo
m
ETABS 1Ifcbeam Steel ASTM A992 Frame W12*26 UX Trapezoid
UY al
RX RY
1Ifccolu Steel ASTM A992 Frame W10*49 UZ RZ Trapezoid
mn al
18Ifcslab nbl_DeckBeamAndBloc Slab UZ RZ Uniform
s k150 nbl_DeckBeamAndBloc 2kN/mm2
k150
2Ifcwalls nbl_concept Wall UY UZ Uniform
nbl_concept150.000 RY RZ 2kN/mm2
SAP20 1Ifcbeam Steel ASTM A992 Frame W12*26 UX Trapezoid
00 UY al
RX RY
1Ifccolu Steel ASTM A992 Frame W10*49 UZ RZ Trapezoid
mn al
18Ifcslab nbl_DeckBeamAndBloc Slab UZ RZ Uniform
s k150 nbl_DeckBeamAndBloc 2kN/mm2
k150
2Ifcwalls nbl_concept Wall UY UZ Uniform
nbl_concept150.000 RY RZ 2kN/mm2
1Ifcbeam Steel ASTM A992 Frame W12*26 UX Trapezoid
Autode UY al
sk RX RY
Robot 1Ifcolum Steel ASTM A992 Frame W10*49 UZ RZ Trapezoid
n al

© ASCE

Construction Research Congress 2018

 Construction Research Congress 2018 477

Table 5 compares different software from a user’s perspective through a small

comparative experiment. ETABS and SAP 2000 turned out to be easier to learn and use, whereas
Autodesk Robot is more complex but more powerful.

Table 5. Advantages and Disadvantages of Different Software

Software IFC Import Time Feasibility Common
Consumed
Downloaded from ascelibrary.org by MISSOURI, UNIV OF/COLUMBIA on 04/15/18. Copyright ASCE. For personal use only; all rights reserved.

ETABS Yes 10 minutes Properties need Autodesk Robot

to be set is more
manually, it may complicated to
cause human use than ETABS
error and SAP 2000,
SAP 2000 Yes 10 minutes Properties need it is not an
to be set analysis solver,
manually, it may but it has good
cause human compatibility
error with design
Autodesk Robot Yes 20 minutes Material software to
properties may import model
be missing when structure quickly
importing IFC
models

In addition, further gaps were identified in using IFC to support BIM interoperability
with structural analysis. One such gap is reflected in the use of a “top-down” approach in
representing model elements and tracking semantic changes of elements between different
models. This “top-down” approach yields complex data representations and large file sizes,
which is hard to program and implement in a software. IFC uses the “top-down” and relational
approach to track all the semantic changes when one parameter in the schema changed. This
keeps data integrity automatically but can become an obstacle to processing large data file (Lam
et al. 2012). In comparison, gbXML uses the “bottom-up” approach, which is more flexible and
less complex. A second gap identified is the lack of tools and methods in addressing model
information distortion and geometric precision lost problems (Lam et al. 2012). Future research
is needed to address these research gaps to improve IFC-based BIM interoperability for
structural analysis, through efforts in, for instance, reducing misinterpretation of modeling
information passed to structural analysis by establishing data exchange criteria, interfaces, and
standard tools.

© ASCE

Construction Research Congress 2018

 Construction Research Congress 2018 478

CONCLUSION
Interoperable data exchange is important in the architecture, engineering, and
construction (AEC) domain because of: (1) the collaborative nature of the domain; and (2) the
many differences in the tools and data formats used by different stakeholders. In this paper, the
authors conducted a preliminary literature review about BIM interoperability trying to identify
topics and trends on the BIM interoperability problem with a focus on the structural analysis
domain, from both the theoretic perspective and the application perspective. Based on the review
Downloaded from ascelibrary.org by MISSOURI, UNIV OF/COLUMBIA on 04/15/18. Copyright ASCE. For personal use only; all rights reserved.

and preliminary experimental analysis, research gaps were identified in the BIM interoperability
with structural analysis area where future researches are recommended: (1) the need of better
information coverage in the IFC schema; (2) the need of stronger IFC importation/exportation
support in structural analysis software; (3) the lack of methods other than the “top-down”
approach in representing model elements and tracking semantic changes of elements between
different models; and (4) the lack of tools and methods in addressing model information
distortion and geometric precision lost problems. Addressing these research gaps can improve
interoperability of IFC-based BIM, and therefore facilitate information flow between different
parties in the AEC domain with a central model/database, resulting in a simpler information flow
pattern and less interoperability problems.

ACKNOWLEDGMENTS
The author would like to thank the National Science Foundation (NSF). This material is
based on work supported by the NSF under Grant No. 1745374. Any opinions, findings, and
conclusions or recommendations expressed in this material are those of the author and do not
necessarily reflect the views of the NSF.

REFERENCES
Amann, J., Singer, D., and Borrmann, A. (2015). “Extension of the upcoming IFC alignment
standard with cross sections for road design.” ICCBEI, 2015. <cms.bgu.tum.de> (Aug.
15, 2017).
BuildingSMART. (2007). “IFC 2 × edition 3 technical corrigendum 1.” <
http://www.buildingsmart-tech.org/ifc/IFC2x3/TC1/html/> (Aug. 28, 2017).
Chen, P., Cui, L., Wan, C., Yang, Q., Ting, S. K., and Tiong, R. L. K. (2005). “Implementation
of IFC-based web server for collaborative building design between architects and
structural engineers.” Automation in Construction, 14(2005), 115-128.
Eastman, C. M. (1992). “Modeling of buildings: evolution and concepts.” Automation in
Construction, 1(1992), p 99-109.
European Iteroperability Framwork (EIF). (2004). “European interoperability framework for
pan-European egovernment services.” Publ., the European Communities, European
Communities, Belgium.
Fu, Feng. (2015). Advanced Modelling Techniques in Structural Design. First Edition. John
Wiley and Sons, Ltd. Chapter 2. P 12.
Howell, I., and Batcheler, B. (2005). “Building information modeling two years later – huge
potential, some success and several limitations.” The Laiserin Letter, 24.
<http://www.laiserin.com/features/bim/newforma_bim.pdf> (Aug. 28, 2017).

© ASCE

Construction Research Congress 2018

 Construction Research Congress 2018 479

IAI. (2003). “IFC implementation: Ifc 2X2- final.” <

http://jira.buildingsmart.org/browse/ISG/fixforversion/10045/?selectedTab=com.atlassian
.jira.jira-projects-plugin:version-summary-panel > (Aug. 1, 2017).
Kiviniemi, A. (2006). “Ten years of IFC-development – why are we not yet there?” Proc., 2006
Joint Int. Conf. Compt. and Desi. Making in Civil and Bldg. Eng., VTT Building
Technology, Espoo, Finland.
Kiviniemi, A. (2008). “IFC certification process and data exchange process.” in: A. Zarli, R.
Downloaded from ascelibrary.org by MISSOURI, UNIV OF/COLUMBIA on 04/15/18. Copyright ASCE. For personal use only; all rights reserved.

Scherer (Eds.), ECCPM 2008, Taylor & Francis Group, Sophia Antipolis, France, 2008,
p. 8.
Kalny, O. (2013). “CSI knowledge base.” <https://wiki.csiamerica.com/display/etabs/Home >
(Aug. 28, 2017).
Liebich, T. (2010). “Unveiling IFC2x4 - the next generation of OPENBIM.” AEC3 Deutschland
GmbH, Germany.
Lee, S. H., and Kim, B. G. (2011). “IFC extension for road structure and digital modeling.”
Procedia Enginering, 14(2011), 1037-1042.
Lam, K. P., Karaguzel, O. T., Zhang, R. P., and Zhao, J. (2012). “Identification and analysis of
interoperability gaps between Nbims/Open standards and building performance
simulation tools.” <
https://www.andrew.cmu.edu/user/okaraguz/TechnicalWritingSamples/Interoperability_I
dentification.pdf > (Aug. 28, 2017).
Liu, Z. Q., and Zhang, J. (2015). “BIM-based structural analysis model and data conversion
application.” Industrial Construction, 45(2), 4-5.
Markova, S., Dieckmann, A., and Russell, P. (2013). “Custom IFC material extension.” Proc.,
18th Int. Conf. on Compt.-Aided Archi. Desi. Research in Asia, Hong Kong. p13-22.
Sacks, R., Kaner, I., Eastman, C. M., and Jeong, Y. S. (2010). “The Rosewood experiment-
building information modeling and interoperability for architectural precast facades.”
Automation in Construction, 19(4) p 419-432.
Steel, J., Drogemuller, R., and Toth, B. (2012). “Model interoperability in building information
modelling.” Software System Model, 11(1), 99–109.
Santos, R., Costa, A. A, and Grilo, A. (2017). “Bibliometric analysis and review of building
information modelling literature published between 2005 to 2015.” Automation in
Construction, 80(2017), p 118-136.
Volk, R., Stengel, J., and Schultmann, F. (2014). “Building information modeling (BIM) for
existing buildings — literature review and future needs.” Automation in Construction,
38(2014), 109–127.
Wan, C., Chen, P., and Tiong, R. L. K. (2004). “Assessment of IFCs for structural analysis
domain.” J., Information Technology in Construction, 9 (2004), 75-75,88-88.
Zeng, X., Lu, X., and Xu, Z. (2014). “Modeling technology for building aseismic elasto-plastic
analysis based on BIM data.” Computer Aided Engineering, 23(4), 3-3.
Zhang, J., and El-Gohary, N. (2016). “Extending building information models semi-
automatically using natural language processing techniques.” J. Comput. in Civ. Eng.,
30(5), C4016004.

© ASCE

Construction Research Congress 2018