Close
About
FAQ
Home
Collections
Login
USC Login
Register
0
Selected
Invert selection
Deselect all
Deselect all
Click here to refresh results
Click here to refresh results
USC
/
Digital Library
/
University of Southern California Dissertations and Theses
/
Building bridges: filling gaps between BIM and other tools in mechanical design
(USC Thesis Other)
Building bridges: filling gaps between BIM and other tools in mechanical design
PDF
Download
Share
Open document
Flip pages
Contact Us
Contact Us
Copy asset link
Request this asset
Transcript (if available)
Content
1
Building Bridges:
Filling Gaps between BIM and other Tools in Mechanical Design
By
Kai Yin
Presented to the
FACULTY OF THE
SCHOOL OF ARCHITECTURE
UNIVERSITY OF SOUTHERN CALIFORNIA
In partial fulfillment of the
Requirements of degree
MASTER OF BUILDING SCIENCE
AUGUST 2016
2
Committee
Karen Kensek
Assistant Professor
USC School of Architecture
kensek@usc.edu
Joon Ho Choi
Assistant Professor
USC School of Architecture
Marc Schiler
Professor
USC School of Architecture
3
TABLE OF CONTENT
Committee ..................................................................................................................................................................... 2
Abstract.......................................................................................................................................................................... 6
Hypothesis ..................................................................................................................................................................... 6
List of figures ................................................................................................................................................................ 7
List of tables .................................................................................................................................................................. 9
Acknowledgement ....................................................................................................................................................... 10
Chapter 1 Introduction ................................................................................................................................................. 11
1.1 Overview ........................................................................................................................................................... 11
1.1.1 A problem that provoked thought ............................................................................................................... 11
1.1.2 The gap between the software tools ............................................................................................................ 12
1.1.3 Reasons for some of the gaps ..................................................................................................................... 12
1.2 Terminology ...................................................................................................................................................... 13
1.3 The Design Process............................................................................................................................................ 14
1.4 Current Problems ............................................................................................................................................... 14
1.5 Inefficiency came of the BIM gaps .................................................................................................................... 16
1.6 Current Approaches ........................................................................................................................................... 16
1.6.1 Interoperability Approach ........................................................................................................................... 16
1.6.2 Macro Approach ......................................................................................................................................... 17
1.7 Purposed Approach ............................................................................................................................................ 18
1.7.1 Applicability ............................................................................................................................................... 18
1.7.2 Transferability ............................................................................................................................................ 19
1.8 Scope of Thesis and Application ....................................................................................................................... 19
1.9 Summary ............................................................................................................................................................ 19
Chapter 2 Background ................................................................................................................................................. 20
2.1 Introduction ....................................................................................................................................................... 20
2.2 IFC vs gbXML ................................................................................................................................................... 20
2.3 Approaches to the issue ..................................................................................................................................... 21
2.3.1 Data transferring visualization .................................................................................................................... 21
2.3.2 Creating a template in Revit ....................................................................................................................... 22
2.3.3 Creating tool ............................................................................................................................................... 22
2.3.4 Using a Cloud Based Database ................................................................................................................... 23
2.3.5 Providing Guidelines .................................................................................................................................. 23
2.3.6 Third party gbXML editor .......................................................................................................................... 24
2.4 Summary ............................................................................................................................................................ 24
Chapter 3 Methodology ............................................................................................................................................... 25
3.1 Overview of the proposed tool........................................................................................................................... 25
4
3.2 Method and Process ........................................................................................................................................... 26
3.2.1 gbXML modifying tool (GMT) .................................................................................................................. 26
3.2.2 Validator ..................................................................................................................................................... 28
3.2.3 Translator .................................................................................................................................................... 28
3.2.4 Modifier ...................................................................................................................................................... 29
3.2.5 Recorder...................................................................................................................................................... 29
3.2.6 Direct approach ........................................................................................................................................... 29
3.2.7 Indirect approach ........................................................................................................................................ 29
3.3 Tools and techniques used to develop the gbXML modifier ............................................................................. 30
3.3.1 gbXML Schema .......................................................................................................................................... 30
3.3.2 Python ......................................................................................................................................................... 30
3.3.3 Excel Spreadsheet ....................................................................................................................................... 31
3.4 Creating the Revit-Trace GMT .......................................................................................................................... 31
3.4.1 Trace object hierarchy ................................................................................................................................ 31
3.4.2 Trace objects and Associated Errors ........................................................................................................... 32
3.4.3 Implementing the rules into GMT .............................................................................................................. 34
3.5 Summary ............................................................................................................................................................ 34
Chapter 4 The Development of GMT .......................................................................................................................... 35
4.1 Overview of Revit-Trace GMT ......................................................................................................................... 35
4.2 Development of the GMT .................................................................................................................................. 36
4.2.1 gbXML Parsing Tooling ............................................................................................................................. 40
4.2.2 Excel Interface ............................................................................................................................................ 41
4.2.3 gbXML Generating Tool ............................................................................................................................ 45
4.3 Summarize ......................................................................................................................................................... 46
Chapter 5 Presenting the GMT .................................................................................................................................... 47
5.1 Overview ........................................................................................................................................................... 47
5.2 Conventional Approach (Test 1) ........................................................................................................................ 48
5.3 GMT approach (Test 2) ..................................................................................................................................... 51
5.3.1 Overview Sheet ........................................................................................................................................... 51
5.3.2 Space Sheet ................................................................................................................................................. 54
5.3.3 Surface Sheet .............................................................................................................................................. 54
5.3.4 Opening Sheet ............................................................................................................................................. 55
5.3.5 Imports ........................................................................................................................................................ 55
5.4 Test 1 and Test 2 comparison ............................................................................................................................ 56
5.5 Other applications .............................................................................................................................................. 57
5.6 Summary ............................................................................................................................................................ 59
Chapter 6 Conclusion .................................................................................................................................................. 60
5
Chapter 7 Future Work ................................................................................................................................................ 62
7.1 The universal GMT............................................................................................................................................ 62
7.2 Building an interface.......................................................................................................................................... 62
7.3 Enrich the validation rule ................................................................................................................................... 62
7.4 Summary ............................................................................................................................................................ 62
Reference ..................................................................................................................................................................... 63
Appendix A: Survey .................................................................................................................................................... 64
Appendix B: Python Code ........................................................................................................................................... 66
Appendix C: Complete Trace Object and Associated Potential Errors ....................................................................... 76
6
Abstract
Software were being utilized to assist the job creation, coordination and delivery during mechanical design process
as more and more information were evolved to be managed electronically. Data transferring between software
became essential as to save time and effort in inputting the information in different software. BIM gaps existed that
prohibited data from transferring successfully between BIM software and other analytical software.
Current approaches utilized existing data schema such as gbXML and IFC, as media of storing information to
interoperate between software. Nevertheless, the data transferring are not always successful due to human error,
mismatching data structure, different adoption of schema, and limited features.
Possible erroneous data transferring between software reduced the efficiency in the design process. Money and time
were being wasted to correct and check for the missing data as a result of the gap. To improve the data quality and
design experience, a GMT (gbXML Modifying Tool) approach was proposed. GMT was designed to catch errors
(both human error and computer error), and correct errors.
The gbXML modifier is a point-to-point specific customized tool between two software that increases data
transferring efficiency through augmenting the gbXML schema. A Revit-Trace GMT was developed to support the
validity of the approach.
To make up for the erroneous data information, the GMT shows what is in the data, validates the data, patches the
missing data, or modifies the data. The purposed tool (GMT) and method takes the directly exported gbXML file
from the Revit model and modifies the file to account for the problems. Then the tool makes a new gbXML file to
be imported to the analysis software such that less error were generated, improving the efficiency of the data
transferring process.
A case study was done to compare approaching a typical design process using the conventional method and GMT
method. GMT caught both simulated human error and computer error.
It takes time to familiarize users to use GMT. In small size project, the time spent detecting error using conventional
approach is same as GMT. Nevertheless, GMT could save significant time in large complex project.
Hypothesis
GMT can facilitate data transferring between software, saving time and effort for error detection and modification.
7
List of figures
Figure 1.1 Zoning Diagram ......................................................................................................................................... 11
Figure 1.2 Design processes and typical software used ............................................................................................... 12
Figure 1.3 Data sharing between the software (solid arrow indicates direct, dotted arrow indicates indirect) ............ 13
Figure 1.4 Software and data flow in design process .................................................................................................. 14
Figure 1.5 BIM utilization ........................................................................................................................................... 15
Figure 1.6 Data Sharing Method between Revit and other Tools ................................................................................ 15
Figure 1.7 BIM Automatically Generated Data (ASHRAE Journal 2010) .................................................................. 17
Figure 1.8 Macro Script Example (Gates Blog 2015) ................................................................................................. 18
Figure 1.9 GMT overview ........................................................................................................................................... 18
Figure 2.1 BIM gaps and solutions .............................................................................................................................. 20
Figure 2.2 DTT framework (Hijazi 2015) .................................................................................................................. 21
Figure 2.3 gbXML to INP converter (Guzmán and Zhu 2016) ................................................................................... 22
Figure 3.1 GMT overview ........................................................................................................................................... 25
Figure 3.2 gbXML structure ........................................................................................................................................ 25
Figure 3.3 gbXML hierarchical structure .................................................................................................................... 26
Figure 3.4 Wall representation in gbXML ................................................................................................................... 26
Figure 3.5 R-T-GMT diagram ..................................................................................................................................... 27
Figure 3.6 Different adoption of gbXML schema by different software programs ..................................................... 27
Figure 3.7 Revit-Trace GMT conceptual flow ............................................................................................................ 28
Figure 3.8 Floor constructed in Revit, represented in gbXML .................................................................................... 28
Figure 3.9 GMT validates inputs ................................................................................................................................. 28
Figure 3.10 Direct approach ........................................................................................................................................ 29
Figure 3.11 Indirect approach ...................................................................................................................................... 30
Figure 3.12 Tool developing process and tools involved ............................................................................................ 31
Figure 3.13 Trace Object Hierarchy Map (Red: required cells; yellow, Revit data not supported by Trace).............. 32
Figure 3.14 Detailed Element Breakdown and associated error (1) ............................................................................ 33
Figure 3.15 Detailed Element Breakdown and associated error (2) ............................................................................ 33
Figure 3.16 Detailed Element Breakdown and associated error (3) ............................................................................ 34
Figure 3.17 Detailed Element Breakdown and associated error (4) ............................................................................ 34
Figure 4.1 Conventional gbXML flow ........................................................................................................................ 35
Figure 4.2 GMT gbXML flow ..................................................................................................................................... 35
Figure 4.3 GMT components and detail ...................................................................................................................... 36
Figure 4.4 gbXML hierarchical tree ............................................................................................................................ 37
Figure 4.5 Sample gbXML as text ............................................................................................................................... 37
Figure 4.6 GMT data flow ........................................................................................................................................... 39
Figure 4.7 Partial GPT example .................................................................................................................................. 40
Figure 4.8 GPT flow chart ........................................................................................................................................... 40
Figure 4.9 Excel Interface tabs .................................................................................................................................... 41
Figure 4.10 Excel Interface hierarchy .......................................................................................................................... 41
Figure 4.11 General Information ................................................................................................................................. 42
Figure 4.12 Space Matrix ............................................................................................................................................ 42
Figure 4.13 Zone matrix .............................................................................................................................................. 43
Figure 4.14 Space sheet ............................................................................................................................................... 43
Figure 4.15 Surface sheet showing missing data ......................................................................................................... 44
Figure 4.16 Opening sheet ........................................................................................................................................... 45
Figure 4.17 GGT script ................................................................................................................................................ 45
Figure 4.18 GGT flowchart ......................................................................................................................................... 46
Figure 5.1 Test Overview ............................................................................................................................................ 47
Figure 5.2 3D view of the model ................................................................................................................................. 47
Figure 5.3 room view in Revit ..................................................................................................................................... 47
Figure 5.4 gbXML export continued ........................................................................................................................... 48
8
Figure 5.5 gbXML export ............................................................................................................................................ 48
Figure 5.6 Trace model main page .............................................................................................................................. 49
Figure 5.7 Trace model template creation ................................................................................................................... 49
Figure 5.8 gbXML import ........................................................................................................................................... 49
Figure 5.9 import detail ............................................................................................................................................... 49
Figure 5.10 main page after import ............................................................................................................................. 49
Figure 5.11 Missing occupancy for rooms .................................................................................................................. 50
Figure 5.12 Missing floor ............................................................................................................................................ 50
Figure 5.13 Unassigned space ..................................................................................................................................... 51
Figure 5.14 General information ................................................................................................................................. 51
Figure 5.15 Space matrix for the model ...................................................................................................................... 52
Figure 5.16 Conditional formatting ............................................................................................................................. 52
Figure 5.17 Conditional formatting result ................................................................................................................... 52
Figure 5.18 Modified space matrix .............................................................................................................................. 53
Figure 5.19 Zone space ................................................................................................................................................ 53
Figure 5.20 Space sheet info ........................................................................................................................................ 54
Figure 5.21 Surface sheet ............................................................................................................................................ 54
Figure 5.22 Opening sheet ........................................................................................................................................... 55
Figure 5.23 fixed occupancy ........................................................................................................................................ 55
Figure 5.24 fixed floor ................................................................................................................................................. 56
Figure 5.25 fixed zone assignment .............................................................................................................................. 56
Figure 5.26 Test 1 and Test 2 comparison ................................................................................................................... 57
Figure 5.27 Space matrix modification ........................................................................................................................ 57
Figure 5.28 Zone matrix modification ......................................................................................................................... 58
Figure 5.29 New zone list in Trace model ................................................................................................................... 58
Figure 5.30 New room page in Trace model ............................................................................................................... 59
Figure 5.31 New design temperature ........................................................................................................................... 59
Figure 6.1 Comparison result ...................................................................................................................................... 60
9
List of tables
Table 1 Time Spent in Data Inputting ......................................................................................................................... 16
Table 2 Issue encountered when data transferring ....................................................................................................... 16
10
Acknowledgement
I am using this opportunity to express my sincere appreciation to the support throughout the course of this thesis
work.
From generating and refining the ideas in the beginning period, throughout completion of the thesis, my committee
members, Professor Marc Schiler, Professor Joon-Ho Choi, especially committee chair Professor Karen Kensek
have been providing me constant support, without which I could not possibly finish this.
During the process of writing the thesis, interviews have been conducted to collect opinions and information related
to the work. The engineers and managers from Southland Industry, Arup, Burohappold Engineering, Kohler Co,
WSP have been incredibly nice and informative. A special thanks to Mr. Richard Holzer from Southland Industry,
who offered a company staff meeting to discuss the potential of the thesis and applications, which made the scope of
the thesis work much clearer.
I would also like to thank my whole MBS family. Everybody has been supporting each other from day one, not only
on the school work, but also in life.
11
Chapter 1 Introduction
With the development of technology and science, the method of approaching problems keeps changing. In the field
of building mechanical engineering, due to education and level of preference of the engineers, the approaches vary
widely. This chapter discusses the current approaches that the mechanical engineers are using in the designing
process for load calculation and energy simulation, gaps in data transfer and reasons why they exist, possible
solutions to the existing gaps, and the importance of filling the gaps. With the proposed new approaches to the
problems, the collaboration of mechanical engineers themselves and between other discipline and parties will be
easier.
1.1 Overview
A normal task done by a mechanical engineer raised the thought of solving it in a new way. Gaps between the
mechanical designing processes were investigated, reasons were researched, and solutions provided to bridge the
gaps.
1.1.1 A problem that provoked thought
Currently, in most of the building engineering consulting firms, software programs are incorporated in the design
process to assist in doing calculations, modeling, and coordination. The role of software is critical in the designing
process. During a recent project, Kai Yin (mechanical engineer intern) was assisting the mechanical design team. He
was looking at the Revit three dimensional model that he got from the architect that contained the room information,
construction information, and geometry information. He started creating a zoning diagram by doing markups on a
PDF editing software. The job was to create a semitransparent shape that matches each zone on top of the floor plan,
so it would be clear the zoning of the whole area (Figure 1.1). He stretched the polygon to match the shape of each
zone and input the names for each room/zone, which he read from the Revit model – note that the data already exists
in a digital form, but in a different format and software program. After he finished the diagramming job, he started
generating his own load calculation by inputting the information to the calculation software manually, specifically,
room dimensions, orientations which already exists in the Revit model he got. The job kept going, with one
question repeating in his mind. Is there a better way to do this?
Figure 1.1 Zoning Diagram
12
1.1.2 The gap between the software tools
There are different software programs used in different steps during the mechanical design process during building
design (Figure 1.2). When using each of the software programs, the engineers would have to input the building
information into the program for it run calculations and analysis, which could take long due to the complexity of the
project. For instance, hospital projects are complicated because there are thousands of rooms, zones, and hundreds
of different categories of rooms. The engineers use different software during different phases of the design’ they
have to input the same data again in a different software, in addition to the time just spent on the last software,
which just double the effort and time spent on data inputting. When engineers move to the next step, depending on
the program they use, a third time of data input is expected, and comes the fifth, sixth, and etc., to the end of the
project. When changes and modification are made, it is hard to track back and change everything once again.
Software can talk to each other generally through common file formats, but not enough to pass all the useful
information, which is one of the reason causing redundant work.
Figure 1.2 Design processes and typical software used
Standard file formats like IFC and gbXML were developed to facilitate data transferring between different software.
Nevertheless, errors and gaps still exist when data is transferred according to the interviewed engineers, which cause
extra time for the engineers to resolve the problems manually (Yin, 2015).
1.1.3 Reasons for some of the gaps
Data in the model can be shared and used in a different software directly and indirectly, if already existed in another
one (Figure 1.3). A direct data exchange supported by a software allows it to export the information directly into the
other software with no external assistance. For example, a three dimensional building model in Revit (rvt format)
can be exported as an AutoCAD file (dwg format) that can be opened directly in AutoCAD. The building data gets
carried over to another software, so that time is saved for not having to reconstruct the model. While the direct
transferring of data saves significant time with high efficiency and low error, it requires the developers to custom
data transferring channel for each specific software. As more and more analytical software are created to assist the
designing process, the third party data storing schema was developed, for instance, gbXML and IFC. As long as the
data import and output follows the agreed format, the information can flow from one software from one to another.
Indirect data flow is utilizing predesigned schema, such as gbXML or IFC, to facilitate data transferring between
software.
13
Figure 1.3 Data sharing between the software (solid arrow indicates direct, dotted arrow indicates indirect)
Yet despite common file formats, the transition of data between the software did not perform perfectly. Ten out of
ten mechanical engineers interviewed claimed that data sometimes got missing during transferring by using gbXML
(Yin, 2015). The gap in transferring data between the different phase-specific models interrupts the flow of the data
(Hijazi 2015).
It became apparent when looking at the different software programs and the process in which that they were used,
that there were several reasons that gaps may exist:
different data structures
minor formatting difference in data files
unfriendly user interface
limited features
user preferences
1.2 Terminology
Building Information Technology (BIM): “Building Information Modeling (BIM) is a digital representation of
physical and functional characteristics of a facility. A BIM is a shared knowledge resource for information about a
facility forming a reliable basis for decisions during its life-cycle; defined as existing from earliest conception to
demolition (US National Building Information Model Standard Project Committee 2014).” Revit from Autodesk is
an example of a BIM software program.
gbXML: “The Green Building XML schema, referred to as gbXML, was developed to facilitate the transfer of
building information stored in CAD building information models, enabling integrated interoperability between
building design models and a wide variety of engineering analysis tools and models available today ” (National
Renewable Energy Laboratory 2016).
Excel: Spreadsheet application designed for analyzing data, generating graphs, storing information.
IFC: IFC is a standard format developed by buildingSMART to describe BIM information.
14
Interoperability: “Interoperability refers to the ability of two separate systems or software programs to
communicate and exchange data with each other” (American Institute of Steel Construction 2014).
Python: Object Oriented Programming language designed for general purposes.
Trace 700: Load calculation software developed by Trane Company. The building geometry information, weather
condition, design requirement are needed. The software would calculate the load condition based the data inputted.
1.3 The Design Process
Many software programs are used to facilitate the engineering design process. Through different stages of design
process, building modeling software, analytical software and markup software are used to assist the design in
different aspects. Data and information needed in each tool are related. Depending on the feasibility, data are put
into the software through direct transferring, indirect transferring (Figure 1.3), or manually. For example, in a typical
mid-size commercial building mechanical system design, Revit was used as building three dimensional model draft
tool, AutoCAD was used as two dimension drawing draft tool, BlueBeam was used as markup tool, Trace 700 was
used as load calculation tool, and IES VE was used as building energy simulation tool. Throughout different process
in the design, the level of detail involved in each stage got higher. Iteration of design and calculation required
information from different software (geometry, design criteria, calculation results, etc.) (Figure 1.4). Due to
preference and applicability, zoning diagrams were created in BlueBeam manually (manually); building geometry
information was imported to Trace 700 partially (indirect); building heat load information was transferred to Excel
directly from Trace 700 (direct). As the media containing most building information (geometry, location, design
criteria, construction and etc.), Revit (the BIM tool) have the data that are needed by other analytical software to
perform calculations. The data transferring between Revit and other software is of special concern.
Figure 1.4 Software and data flow in design process
1.4 Current Problems
An informal survey was conducted to interview the designers in mechanical field in regarding to the utilization of
BIM software and issues about the designing process:
Do you use BIM in the mechanical design?
How do you pass data between BIM software and other tools?
Is it successful sharing data among software?
15
How long do you spend inputting data into software?
Out of 10 firms, 9 claimed that BIM tools (Revit, Naviswork, SketchUp) was utilized in some kind of form (Figure
1.5).
Figure 1.5 BIM utilization
Depending on the size and complexity of the project, time, and resources are invested in constructing a Revit model.
A well-constructed 3D model has the data capable for other analytical tools to use from. With Revit getting more
and more accepted and preferred in the industry, focuses have been placed in data transitioning to other tools.
Results from the informal survey showed that fair percentage of indirect method and even manual data input were
used for data sharing (Figure 1.6).
Figure 1.6 Data Sharing Method between Revit and other Tools
Since direct import/export might not be available for all the software so far, other methods were used to do the
transferring. Depending on the complexity and size of the projects, the approximate time spent in inputting the data
using different methods might varies substantially (Table 1).
9, 90%
1, 10%
BIM UTILIZATION
Using BIM
Not Using BIM
Revit - Excel
Revit - Trace
700
Revt - IESVE
Revit -
AutoCAD
Revt -
BlueBeam
Not Applicable 3 4 2 1 6
Indirect 1 10 9 0 0
Direct 0 0 2 10 0
Manual 12 2 3 5 10
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Data Sharing Method between Revit and other Tool
Not Applicable
Indirect
Direct
Manual
16
Table 1 Time Spent in Data Inputting
Time Spent in Data Inputting
Small Size Mid Size Large Size
Manual Couple Hr Several Days Weeks
Indirect Couple Hr Several Days Few Days
Direct Couple Hr Couple Hr Couple Hr
Among the mechanical designers who used third party data schema as transferring media, gbXML schema were
mostly accepted. Although gbXML schema was utilized during data transferring, a lot time were spent to check the
correctness. Sometimes the data was “lost” during the transferring using gbXML. It is because of the possible
missing data that the users have to check and correct the errors, causing extra time and effort. Results showed that
although gbXML imports saved time, all the interviewed engineers who used gbXML schema had experience of
errors using the schema, along with other issues (Table 2).
Table 2 Issue encountered when data transferring
Issues Encountered
Errors in using gbXML 10
Not familiar with gbXML 6
Prefers the conventional method 2
Don't know 1
According to another survey, BIM is getting more and more popularity because of the ability to improve
communication, money saving and effort saving. Owners, engineers and architects all concern about increasing the
efficiency of the work, in which the BIM gaps appear as an obstacle (Young et al., 2007).
1.5 Inefficiency came of the BIM gaps
because of lack of confidence in the correctness of data transferring, users spent extra time checking details (Hijazi
2015). Repetitive data entry and effort among BIM and other software programs are taking place in the mechanical
designing process. As mechanical designing fees accounts for 1 to 2 percent of the total cost. (ICE 2011), time and
resources are wasted for the inefficient work process.
1.6 Current Approaches
Currently, there are many approaches to fill the gaps between BIM and analytical software tools. Each approach has
its own advantages and advantages. There is no clear regulation and mandatory ways of approaching the problem.
Specific project requirement, condition, and personal preferences account substantially for decision making. For the
case where direct approach is not available, indirect approach and manual approach are used. Issues in indirect
approaches also exist.
1.6.1 Interoperability Approach
Recall that interoperability refers to the ability of a system or a product to work with other systems or products
without special effort on the part of the customer (TechTarget, 2016). It is used in mechanical design. For example,
after all of the rooms in a building have been defined by an architect in the BIM, an HVAC engineer creates
conditioned spaces or zones in the analytical model from those rooms to facilitate HVAC analysis. The space
defined in the HVAC analytical model retains all the room information from Revit and has additional information
needed for HVAC analysis (Figure 1.7)). One of the problems is that there is no R value associated with the room
(Turner 2010). “Although the process is not yet automatic, the engineer can quickly assign common U-values to
most objects in the BIM for use in HVAC analysis either within the BIM or when using standalone HVAC analysis
software” (Turner 2010), which agrees which the interview conducted.
17
Figure 1.7 BIM Automatically Generated Data (ASHRAE Journal 2010)
Once spaces are defined in the model, HVAC loads can be generated from within the BIM software or exported to
an IFC or gbXML file that can be used with another software package (ASHRAE Journal 2010).
The approach certainly saves time. According to Trane, “around 75% of the time to generate a file in TRACE 700 is
typically spent in Create Rooms. A gbXML import can reduce this time by more than 2/3” (Mayra Reyes 2014). On
the other hand, the major flaw of the procedure is its limited type in transferable data. As in the example, only space
geometry, name are capable to carried over to the Trace 700 template model, with manual wall construction input in
the Trace model itself. Construction material is not able to be transferred due to lack of library. “Fortunately, many
manufacturers and third-party vendors are beginning to provide BIM object libraries populated with many of the
physical and analytical characteristics needed to perform HVAC analysis” (ASHRAE Journal 2010). While so, the
developing period could be long. For a small project where only ten or twenty numbers of R value are needed to be
input to Trace model, there might not be huge difference. Nevertheless, the repetitive R value input could cause long
time if in huge development design project. . Furthermore, the accuracy of the data transferred is uncertain. The
level of uncertainty in data quality could cause time and effort checking the work.
1.6.2 Macro Approach
“Macros are programs that are designed to help you save time by automating repetitive tasks. Each macro performs
a series of pre-defined steps to accomplish a particular task. The steps should be repeatable and the actions
predictable” (Autodesk Inc. 2015).
A blog kept by Troy Gates, dedicated to write and post macro solutions to reduce the repetitive work in Revit, shows
examples for filling gaps using customized scripts and macros that are specific to a software program. For example,
the purpose of this specific macro converts the view names on sheets from lower case to upper case (Figure 1.8).
The single dedicated function of the script reduces the repetitive work converting lower case to upper case, reducing
the waste, increasing the efficiency of the design.
18
Figure 1.8 Macro Script Example (Gates Blog 2015)
Each macro solution provides an alternative approach to the traditional approach that requires repetitive work,
reducing the amount of work needed due to gaps. The flaw of the approach is its transferability to other projects.
The approach might work in certain project, solving only one specific task.
1.7 Purposed Approach
Due to the BIM gaps discussed in section 1.4, the importance of filling the gaps in section 1.5, the flaws of the
current approaches in section 1.6, a new approach was proposed (Figure 1.9).
Figure 1.9 GMT overview
A GMT (gbXML Modify Tool) approach was proposed. The GMT approached the data transferring problem
through the utilization of gbXML schema. One of the gaps of gbXML data transferring is data quality. The GMT
takes the gbXML file, shows what is in the data, validates the data, patches the missing data, or modifies the data. A
new updated gbXML file can be generated by the GMT that can be imported to the analysis software with less
errors.
1.7.1 Applicability
Because all the software writes/reads gbXML differently, the GMT was designed as a point-to-point tool. For
example, a Revit-Trace GMT only assists data transferring between Revit and Trace 700. It does not work for data
transferring between other different software. In a Revit-Trace GMT, the tool takes the gbXML file generated from
19
the building model in Revit. The GMT reads through the file and validates the information. The missing data or
erroneous data are shown to the user for correction. In addition, all the information what is going to be imported to
the Trace model are shown to the user. The data can be modified to generate different gbXML files to be used to
import to Trace model for different design options.
1.7.2 Transferability
Although the GMT is a point-to-point tool that assists data transferring between two specific software, it can be used
in all the projects that use the same software. Result from the interviewed mechanical engineers showed that out of 9
firms that uses BIM, all of them uses Revit as the BIM software (see Appendix A for more details). Furthermore, the
software that most mechanical consulting firms use converges to the same ones. Since there are limited number of
software, developing GMT for precise and fast data transferring makes the process easier.
1.8 Scope of Thesis and Application
The reasons behind the development of a GMT (gbXML Modify Tool) was given. The logic and principal of the
GMT was discussed. A working tool of Revit-Trace GMT was developed to support the proposed approach. A case
study was conducted using Revit-Trace GMT. The comparison of creating a Trace model using conventional direct
gbXML import and using GMT was conducted.
The Revit-Trace GMT can be used to facilitate data transferring between Revit model and Trace model. As the
traditional gbXML import method is still widely used, the errors contained in the model (human error, or computer
error) are hard to be detected. Time and effort have to be invested in check the data in the Trace model one by one to
insure the data quality. The GMT shows the error contained in the gbXML before it goes to the Trace model and
updates a new gbXML file.
The GMT shows the data before it goes into the Trace model. Changing the information in the original gbXML file,
such as set point for different zones, the user can generates multiple gbXML based on different design options. The
updated gbXML files can be imported to Trace models to compare and evaluate different designs. As this process is
iterative, time can be saved for each design iteration.
Names and design parameters can be modified in the GMT. A new gbXML file, along with the associated
calculation can be generated. For every set of gbXML, GMT generated Excel, and calculation results, it can be
grouped and documented. Instead of going back to the Revit model, the GMT handles data in gbXML file and
generates different gbXML for different design options, so that it can be documented and categorized more easily.
1.9 Summary
This chapter discussed the existence of gaps in terms of data sharing between BIM software and other analytical
software. The reasons for the inefficiency in the mechanical design was discussed. Current problems and issues in
the data transferring was discussed. A new approach was proposed. GMT was a point-to-point tool that facilitate
data sharing between two specific software, using gbXML schema. In the following chapter, research investigating
approaches to use interoperability for data sharing will be discussed.
20
Chapter 2 Background
This chapter introduces the approaches to solve the current BIM gap and inefficiency. The advantages and
limitations of each approaches are discussed.
2.1 Introduction
As discussed in chapter 1, the reasons for the inefficiency during data transferring includes schema mismatch, low
user familiarity to the schema, and limitations due to schema data structure. Approaches to decrease the inefficiency
introduced during the data transferring have been investigated to solve each individual gap (Figure 2.1).
Figure 2.1 BIM gaps and solutions
2.2 IFC vs gbXML
Schema and standards have been developed to facilitate building information exchange in the architecture,
engineering, and construction (AEC) industry, among which IFC and gbXML are the most prevalent.
Industry Foundation Classes (IFC) is an object based file format developed by buidingSMART to facilitate
interoperability in the AEC industry between software. It is described as a standard whose goal is to provide a
universal basis for process improvement and information sharing in the construction and facility management
industries (Dong et al. 2007).
gbXML is an open schema developed by Green Building Studio, to facilitate data exchange between BIM software
and building analysis tools, based on Extensible Markup Language (XML) schema. gbXML has a hierarchical data
structure that stores the building information (building, wall, window, etc.) in a straight forward belonging manner.
As Dong discussed in the paper on the comparison between IFC and gbXML that IFC has a more complex and
comprehensive data structure that allows it to carry more information of the building, while gbXML has fewer
layers of complexity, which restricted its ability of storing data (Dong et al. 2007). With the intention and goal of
IFC, its data structure and representation tries to include more accurate information of the building, causing the IFC
file to be larger size and hard to track. On the other hand, gbXML schema represents the building in a less
complicated hierarchy, resulting in a smaller file size with restrictions of describing the information.
With different applications in the AEC process, for instance, at the beginning of the design work, where the level of
detail is low, Trace 700 load calculated is needed to give a general sense of the load size for preliminary design. In
the case, the tentative building shapes, geometries, purposes, openings are needed for the simulation. gbXML
structure carries theses data in a simple hierarchy (campus, building, surface, geometry), with a smaller size and
more readable file than IFC representation. For more complicated applications where the shape of wall is unique and
21
irregular, the zone relation to the surfaces is convoluted, the accuracy of element is essential is required, using IFC
would be a better choice. For energy analysis and simulation applications, gbXML is preferred for its simplicity.
2.3 Approaches to the issue
Different methods were attempted to resolve the BIM gap. Creating tools in third party software for data
visualization, developing a template in Revit, creating a language translator, utilizing cloud based data, providing a
guide line have all been tried with their own respective strengthes and weaknesses.
2.3.1 Data transferring visualization
Although standards and schemas have been developed to help facilitate the data transferring, it is not easy for
inexperienced users to utilize in the real project work without guidance and training. Missing data or errors during
the process due to various reasons including misoperation, modeling error in BIM software, or internal schema
interoperability mismatch. The users transferred building information to the analysis tool using gbXML or IFC
without knowing where it went wrong, causing extra time rechecking and modifying. Hijazi partially solved the
issue by developing a Data Transparent Tool (DTT) in Excel to show the data that is actually carried over from the
source to the target (Figure 2.2) (Hijazi 2015).
Figure 2.2: DTT framework (Hijazi 2015)
According to Hijazi, “DTT is developed for the users to verify the data in the gbXML files and then correct
inaccuracies by applying a transparent layer upon the gbXML data model so users can easily understand what is
being transferred” (Hijazi 2015). The principal of the tool is taking the gbXML file generated from the source
software, map, in another word, interpret it to the spreadsheet in four main categories, namely, program, form,
fabric, and equipment. The spreadsheet contains the interpreted elements carried over from the gbXML file, with
values associated. For inexperienced users of gbXML schema, the DTT is useful tool that it shows all the data from
the source gbXML file in a categorized readable way in spreadsheet. The user could tell what is in the gbXML file
right away. The DTT is a gbXML interpreter that tells the user what is in the file.
Nevertheless, the data structure in different software might not be the same. Extraction technique of the data from
different software through gbXML might not be the same. For example, the gbXML export function in Trane Trace
700 only exports the building heat load results in the gbXML file, without any building envelope information. Since
there is no data in the gbXML, using DTT would not show if the data has been transferred to the software correctly.
Furthermore, although the users now know what is inside the box of gbXML file, they still might not solve the error
if they are not familiar with gbXML schema. Modification in the BIM or energy software is needed to resolve the
missing data transfer.
22
2.3.2 Creating a template in Revit
Kumar from University of Southern California tested the interoperability between Revit MEP and the analysis
software IES VE in her paper in 2008, proposed a solution to the gap by implementing a template file to Revit MEP
making the model in Revit more accurate and more informative (Kumar 2008).
The principle of the template is that, Revit MEP has materials, constructions that are different than the ones IES VE,
so that the proposed solution is to enrich the Revit library by extracting the database from IES and storing in the
Revit MEP template. The template can be saved and imported to any Revit project to use that it would have less
interoperability issue with IES software. “The major role of the template file and families is an informative one, the
major role of the template file and families is an informative one. Also, it was established in the last section that
using the template improves upon the accuracy of the model, even if only slightly so. The building material being
modeled is more consistent and closer to the real life building” (Kumar 2008).
The template patch approach is good that it enriches the Revit library that the user can choose family from the Revit
MEP software directly without knowing anything in IES. This approach could reduce some of the rework changing
construction types in IES after importing the model. However, the approach has its own limitations. The template
might not be applicable to any project. It also could not change certain protected types in the Revit MEP. The users
might get confused when the certain element could be transferred correctly and if there is going to be an error when
transferring, which could cause time and effort to do the recheck work.
2.3.3 Creating tool
Because gbXML file can generate an error while data transferring, causing inefficiency, missing information, and
misinterpretations, one solution is to change gbXML into other file format to avoid its error prone nature. Guzman
and Zhu from Concordia University proposed a tool to convert gbXML to INP file (Figure 2.3) (Guzmán and Zhu
2016).
Figure 2.3 gbXML to INP converter (Guzmán and Zhu 2016)
The principle of the theory is creating a plug-in in Autodesk Revit 2013 that converts the exported gbXML schema
into INP schema, instead of exporting INP file directly from the software. The results showed that the newly
converted INP file correctly transferred the missing roof that the directly exported INP file could not transfer.
Using this technique, the tool could solve the issues related to the misinterpretation of gbXML file from the
targeting software, theoretically. However, for the information and data that is not in the gbXML itself will not be in
the converted INP for sure. Adding another layer into the data structure certainly adds the complexity to the process,
23
as well as the associated potential mistakes. The other limitation includes the interoperability issue there already
exists between INP and the supporting software and the user’s confidence level on the accuracy of the transferring.
If the user is not sure if the data has been transferred correctly, the rechecking work could take a long period of time.
2.3.4 Using a Cloud Based Database
“Data exchanges are generally classified in one of three formats: direct links, proprietary file exchange, and public
product data model exchange (Redmond et al. 2012).” One of the proposed solution is to design an integrated
platform that harnesses the public product data model, namely IFC, XML, instead of introducing new schema in
data exchanging (Redmond et al. 2012).
The logic of the approach is to create a shared station in the cloud that utilizes the current data schema. Data is
transferred to the cloud service using the existing schema and stored. The station serves as a schema neutral storage
center that facilitate data transferring for each terminal device. The advantage of the proposal is that no new schema
is introduced, which means there would not be new bugs introduced. The resources could be focused on solving the
current schema errors. The down side of the approach is similar to the translator approach that it could not modify
the data during transferring, that if there are mistakes in the original data (human error or machine error), the
transferred data would not be correct neither.
2.3.5 Providing Guidelines
A data gap can be due to unfamiliarity with the gbXML schema. One solution is to provide guidelines on using
gbXML as means of transferring data in step by step instruction. According to Ali, gbXML drastically increased the
productivity in generating energy analysis model. R-G-T workflow has been presented as in R (Revit MEP 2010), G
(gbXML), and (Trace 700) (Ali 2010).
A 12 step workflow was presented:
1. Revit Model Creation – Use Rooms
2. Revit Model Creation – Adjust Rooms
3. Revit Model Creation – Create Space
4. Revit Model Creation – Make Ceiling Non-Room Bounding
5. Revit Model Creation – Rename and Renumber Space
6. Revit Model Creation – Occupancy
7. Revit Model Creation – Create Zones
8. Revit Model Creation – Export gbXML
9. Trace Analysis Creation – Template Trace File
10. Trace Analysis Creation – Importing a gbXML Model
11. Trace Analysis Creation – Reimporting a gbXML Model
12. Trace Analysis Creation – Exporting Results to the Revit Model
The workflow gave a clear instruction on the key steps in geometry model generation in Revit and importing
gbXML step between Revit MEP and Trace 700. The workflow provided the basic steps in data transferring.
Nevertheless, it did not discuss the interoperability issue between the software:
Why does the wall disappear?
Why does the zone have different area?
What happens to the missing floors?
The common errors above and more are not addressed in the guideline, which confuses the user of gbXML when the
errors are generated while data transferring.
24
2.3.6 Third party gbXML editor
Cunningham suggested in his presentation in the Autodesk University that third party gbXML data handling can be
used for creative data transferring (Cunningham, 2009). By using the XML editor tool, building information is
written in the Excel file. Cunningham manually construct a new gbXML file using Excel VBA. It is suggested that
the fact that Trace 700 can use partial data import make it possible that a new gbXML file can be creatively created
externally to solve the BIM gaps.
The approach is efficient and direct. It does solve the problem of data modification during the transferring process.
This requires significant familiarity of the user to the original architectural model and expert excel skill. In addition,
errors are not easily to be detected in the process.
2.4 Summary
This chapter introduced some approaches to solve the current BIM interoperability gap. The advantages and
limitations of each approaches were discussed. The next chapter would introduce and explain the theory and logic of
the new proposed approach, gbXML modifying tool (GMT). A point-to-point tool Revit-Trace GMT would be
introduced. Methods, techniques, and tools used would be discussed. Data structure and new schema rule would be
investigated. The process of making the GMT will be presented.
25
Chapter 3 Methodology
This chapter introduces and explains the theory and logic of the gbXML modifying tool (GMT). A point-to-point
tool Revit-Trace GMT is introduced. Methods, techniques, and tools used are discussed. Data structure and new
schema rule are investigated. The process of making the GMT is presented.
3.1 Overview of the proposed tool
With the BIM gap reasons discussed in chapter 1, and the weaknesses in the approaches done in other searches
discussed in chapter 2, the proposed tool was developed with the following intentions (Figure 3.1):
To validate the data transferred in gbXML file from the source file
To patch the missing data from gbXML file
To be able to change information in the gbXML file and track changes
To familiarize users of the information in the gbXML file
Figure 3.1 GMT overview
The media of data exchange is through gbXML schema. The information in the BIM software model is stored in the
respective objects. When the data is exported in the gbXML format, the information is stored in a hierarchical
structure (Figure 3.2).
Figure 3.2 gbXML structure
26
GbXML file is a hierarchical file format (Figure 3.3). Sub information, such as name, latitude, and longitude are
stored under the parent category, namely location. A more comprehensive data structure is discussed in chapter
3.4.1.
Figure 3.3 gbXML hierarchical structure
The analytical software such as Trane Trace 700 accepts gbXML file and extract the target information using the
predefined rules. For example, for a wall’s surface in the gbXML file, directly exported from the Revit model of a
simple house, the components are the id, type of surface, and type of construction (Figure 3.4).
Figure 3.4 Wall representation in gbXML
Trane Trace 700 is widely accepted in the AEC industry as heat load calculation and mechanical equipment sizing
tool. Trace 700 does support direct gbXML import from the BIM model. When it is trying to construct walls in the
trace model, the software goes into the gbXML file and search for “surface” and translate the associated information
under the certain wall object.
As recalled back from chapter 1, some of BIM gaps and missing information are due to following reasons:
Missing information in directly exported gbXML file
Human mistakes in the original building model
Target software does not support certain inputs
Information mismatch during transferring
The purposed tool (GMT) and method takes the directly exported gbXML file from the Revit model and modifies
the file to account for the problems. Then the tool makes a new gbXML file to be imported to the analysis software
such that less error were generated, improving the efficiency of the data transferring process.
3.2 Method and Process
This section introduced the logics of the GMT, the functions of the GMT, and the data flow of the proposed
methodology.
3.2.1 gbXML modifying tool (GMT)
The gbXML modifier is a point-to-point specific customized tool between two software that increases data
transferring efficiency through augmenting the gbXML schema. For example, a Revit-Trace 700 GMT works only
between Revit and Trace 700 (Figure 3.5). The reason for the point-to-point design is that each different software
might have its own understanding of the standard schema, even if all of them are using gbXML.
27
Figure 3.5 R-T-GMT diagram
The gbXML schema allows for a large number of data to be encoded, but each software program developer chooses
what parts to use (Figure 3.6).
Figure 3.6 Different adoption of gbXML schema by different software programs
Assume the black circle includes all the gbXML schema dictionary (all the rules, languages, and requirements)
(Figure 3.6). Each software adopts only certain part of the all schema depending on the purpose of the tool. For
example, Revit adopts a large portion of the gbXML schema, because it is intended to facilitate comprehensive
multi-disciplinary AEC designs and coordination, whereas, Trace adopts only small part of the schema, because
Trace 700 is intended to be used as building heat load calculation and simulation, in which only the related
information is needed. Other software all have their own set of adoption of the schema. If the two sets of schema
from two software are not identical or inclusive, it is highly possible that they are different, there would exist gap
between the data transferring using gbXML option. So the GMT was designed to offset the adoption difference
between two software. The point-to-point design is necessary so far because each software is different.
To test the feasibility of the method and the point-to-point approach. Autodesk Revit 2015 and Trane Trace 700
were selected as the source and target points. Revit has been used widely in the AEC industry as 3D modeling tool.
Trace 700 is one of the most popular load calculation tool in mechanical design. The connection between Trace and
Revit is important. The standard procedure, method, and guidelines introduced by Ali is common in practice for
transferring data from Revit to Trace through gbXML (Ali 2010). At the same time, unpredictable errors pop-up and
hide in the model generated in the Trace file after the gbXML file was imported, causing fair amount of time
checking and refining the model. To test the validity of theory and approach, a Revit-Trace GMT was developed.
28
The new approach was compared with the old approach in terms of time spent in transferring, reworking, accuracy,
and ability to be applied to all general projects.
The Revit-Trace GMT uses four function in two approaches (Figure 3.7). The four functions are validation,
translation, modification, and recording (Validator, Translator, Modifier, and Recorder). The two approaches are
direct and indirect.
Figure 3.7 Revit-Trace GMT conceptual flow
3.2.2 Validator
The GMT serves as a validator, validating the information contained in the direct exported gbXML file. For
example, in the Revit model, wall, floors and ceilings are constructed and stored in the “surface” object (Figure 3.8).
Figure 3.8 Floor constructed in Revit, represented in gbXML
The floor is constructed in Revit and exported in the gbXML file. The floor is constructed under “surface” object
with its attribute “surfaceType” being ExteriorFloor. Other information such as floor dimension, tilt angle, and
construction are all under the hierarchy of this object. After the gbXML file is transferred to the Trace model, the
floor is missing. The gbXML mismatch as shown clearly in Figure 3.8. In Trace, the surface type object is
interpreted as follows:
Type “ExteriorWall” becomes a wall
Type “InteriorWall” becomes a partition
Type “Roof” becomes a roof
Type “SlabOnGrade” becomes an exposed floor
Notice that the type “InteriorFloor” is not supported in the Trace gbXML schema, thus, causing the missing floor.
The validator in GMT takes in the type “ExteriorFloor” and changes it to type “SlabOnGrade.”
Figure 3.9 GMT validates inputs
Figure 3.9 shows the line after the GMT validated the gbXML file, which successfully import the interior floor into
the Trace model. As a validator, the Revit-Trace GMT validates the obvious schema offsets and change the types
automatically into the corresponding, assuming the original model is error free. The purpose of the validator is to
eliminate the basic error and mismatching.
3.2.3 Translator
One of the reasons for inefficiency in using gbXML schema as data transferring language is user’s lack of
familiarity to the schema itself. As discussed in chapter 2, Hijazi introduced a data transparent tool (DTT) that
29
projects the information contained in the gbXML file onto Excel spreadsheets (Hijazi 2015). The DTT increases
user’s confidence level of the content in the gbXML file significantly. However the user still can’t do much about
the file unless they go back to the original model.
Revit adopts a much larger set of gbXML schema than Trace 700. The gbXML file exported from Revit contains
much more information than needed. Projecting all the information onto the spreadsheet might confuses the user. So
the GMT is designed to project only the common set onto the spreadsheet making it more concise and clear.
Moreover, if the user changes anything in the spreadsheet, the GMT translates the changes back into the gbXML
file, updating the modification.
3.2.4 Modifier
The GMT is able to modify the directly exported gbXML file from the Revit model. For example, if the user wants
to change one of the room names, he or she has the option of changing the room name directly in the interface. The
modifier updates the corresponding gbXML accordingly without having to make the user go back to the original
model.
3.2.5 Recorder
One of the most popular demands from the interviews with the mechanical engineers is the ability to keep a record
of changes. It is common in the AEC industry that the model keeps being changed and the requirements and options
varies as project progresses. With the ability to modify the spreadsheet and update the gbXML file, the GMT
provides the user ability to document the changes. For example, the original model has a gbXML file and
spreadsheet associated with it. The engineer changed 200 room names and cooling strategy, adjusted the set point
for the ones got changed in the spreadsheet. The GMT made a new gbXML file (called gbXML
+
) associated with
the modified spreadsheet (spreadsheet
+
). The spreadsheet-gbXML set as a whole can be documented with
comments. So the model can go forward or backward based on different needs in different stages.
GMT implements the data transferring by using different combinations of the functions based on user’s need in two
approaches: direct approach and indirect approach (Figure 3.7).
3.2.6 Direct approach
The direct approach can also be considered as automated approach. Using this approach, the user does not have to
know what goes under the hood of the GMT. The functions used in this approach are validator and modifier. The
Revit-Trace GMT takes the directly exported gbXML file from the Revit model, processed (validated) in the GMT
automatically, and makes a new modified gbXML+ file. Than the gbXML+ file can be used to import to the Trace
file (
Figure 3.10).
Figure 3.10 Direct approach
30
The direct approach is fast and easy. The user does not have to know too much information about the model or
gbXML schema. The direct approach is designed to be used on the fly, eliminating the basic error without user’s
involvement in the gbXML file itself.
3.2.7 Indirect approach
While using the direct approach is easy, it has limitations. The approach only correct the schema mismatch error
between the software. The direct approach does not provide ability to patch the missing information, users’ ability to
change the data, documentation.
The other approach is the indirect approach, which can also be considered as manual approach (Figure 3.11). The
gbXML file is generated using direct export from Revit, the Revit-Trace GMT projects the selected information onto
spreadsheet. Users can change information in the Excel spreadsheet for various reasons (adding missing
information, comparing options, change room names, etc.). The GMT take the new spreadsheet and make a new
gbXML file accordingly. The new gbXML file can be used to import to the Trace model.
Figure 3.11 Indirect approach
The indirect approach was designed to let the users have more operability and controls over the transferring process.
The user invests some time and effort in operating the spreadsheet in order to control the flow of the data. For
example, the user wants to change 300 room names. It might be time consuming to accomplish the task in Revit.
Nevertheless, it would be much easier to do the task in the spreadsheet. The user could load the newly generated
gbXML file back to Revit to make all the changes.
3.3 Tools and techniques used to develop the gbXML modifier
gbXML schema, Python, and Excel were used to develop the tool.
3.3.1 gbXML Schema
The gbXML schema was chosen as the communication schema over IFC and other schema for several reasons.
gbXML has more concise data representation structure than IFC. The limitation of such data structure constrains the
BIM model’s ability to precisely represent complex geometry of the buildings. The special non-rectangular shaped
surfaces might be interpreted differently depending on the target software. For standard heat load calculation and
mechanical equipment sizing, in which the buildings are mostly under standard condition (rectangular walls,
windows, doors), the limitation of gbXML format has a small impact on data sharing. On the other side, with the
more clearly hierarchical data structure of gbXML, the information contained in the file is easier to be tracked and
modified. With the characters of gbXML, the file has smaller size, in which it takes less time and space to store and
analyze.
31
3.3.2 Python
In order to make modification and validation of the gbXML file, Python was selected as the scripting language for
developing the tool. Python is a high level object oriented programming language. Tool itself and the interface were
developed using Python 2.7, with its developing environment IDLE. The tasks that need to be accomplished by
using Python are
Extract information from original gbXML file
Translate the information
Project the information onto spreadsheet
Detect changes in the spreadsheet
Translate the information back into gbXML file
Extracting information from gbXML was done using Beautiful Soup library (a Python XML parsing library) and
regular expression (a data searching technique) in Python, targeting the keywords, such as “surface”. Translation
was done using Trace gbXML manual (Trace 2015). Projection of data onto spreadsheet in done by Python
spreadsheet access and editing. Detecting and updating the gbXML file are done by comparing the new spreadsheet
with the old one. Appendix B contains all the Python code used.
3.3.3 Excel Spreadsheet
Results from the interviews with the mechanical engineers shows that Excel spreadsheet is still their favorite tool for
manipulating and quick analyzing the information, due to its flexibility. Excel is chosen to present the information
translated from gbXML file (Yin 2016). The user would have more familiarity to the interface and control over the
information. The entire process starts with the gbXML file and ends with the updated gbXML file (Figure 3.12).
Figure 3.12 Tool developing process and tools involved
3.4 Creating the Revit-Trace GMT
In order to develop the tool, Trace data structure and detail have been studied, the errors have been identified with
associated reasons. The solutions to the errors were implemented into the tool to automate the error correction.
3.4.1 Trace object hierarchy
The complete Trace object hierarchy structure is shown where objects marked in red represent the required field
where it cannot be blank (Figure 3.13). The yellow cells show the object and data from Revit model that is not
supported in the Trace model. For example, CADObject represent the certain object from CAD library, with which
Revit use to refer to the specific family, such as wall type. With the CADObject object, the Revit model would be
able to extract wall properties associated with the number. However, on the other side, the Trace model would not
be able to interpret the object and construct wall, causing missing wall construction error. The Trace object map
setup a skeleton work for the GMT and the necessary information to look for and validate.
32
Figure 3.13 Trace Object Hierarchy Map (Red: required cells; yellow, Revit data not supported by Trace)
3.4.2 Trace objects and Associated Errors
As discussed in 3.2, a wall was missing in the Trace model due to different type name in the Revit model. A
complete analysis for the rules and errors associated with each object elements from the Trace object map was
conducted and tabulated (Figure 3.14~Figure 3.17).
33
Figure 3.14 Detailed Element Breakdown and associated error (1)
Figure 3.15 Detailed Element Breakdown and associated error (2)
34
Figure 3.16 Detailed Element Breakdown and associated error (3)
Figure 3.17 Detailed Element Breakdown and associated error (4)
3.4.3 Implementing the rules into GMT
As all the objects and validation rules were defined (Figure 3.14~Figure 3.17), the new Revit-Trace was
implemented into GMT using Python. The Revit-Trace GMT was built and ready for the test and comparison with
the conventional approach.
3.5 Summary
This chapter introduced and explained the theory and logic of the gbXML modifying tool (GMT). A point-to-point
tool Revit-Trace GMT was introduced. Methods, techniques, and tools used were discussed. Data structure and new
schema rule were investigated. The process of making the GMT were presented. In the next chapter, the actual tool
development will be presented.
35
Chapter 4 The Development of GMT
As described in chapter 3, the gap between the BIM software and analytical software in terms of interoperability
exists due to different adoption of the gbXML subset. A gbXML Modifying Tool (GMT) has been developed to
provide alternative approach for data sharing and modifying between different software.
4.1 Overview of Revit-Trace GMT
The GMT is a software specific approach, which means each tailored tool can only be used between two specific
software programs. The Revit to Trace GMT has been developed to show the validity and effectiveness of the
approach. There are different data flow types with the conventional method and the GMT approach (Figure
4.1,Figure 4.2). The building was constructed in the Revit, with all the rooms, zones defined in the model. A
gbXML file containing all the building information was exported. The gbXML file, which might or might not
contain erroneous information, was imported to the Trace software directly (Figure 4.1,Figure 4.2). The exported
gbXML was load in the gbXML Parsing Tool (Figure 4.2). The Parsing Tool generates an Excel sheet containing
the useful information contained in the gbXML and puts it on the Excel sheet in an organized manner. The Excel
sheet shows the information from the source gbXML file and how it would be imported to the Trace model. In
addition, the Excel file is interactive, the room/zone names, parameter can be modified to meet various design needs.
This was the step where the error could be detected and corrected manually or automatically. For the next step, the
gbXML Generating Tool reads the updated Excel file and the original gbXML, then generated a new updated
gbXML file that could be used to be imported to the Trace model with all the correct and new information. The
dotted box, comprising of gbXML Parsing Tool, Excel Interface, and gbXML Generating Tool, are all the
components of the GMT (Figure 4.2).
A detailed diagram of three components of the GMT with different tasks and functionality at each stage was created
(Figure 4.3).
Figure 4.1 Conventional gbXML flow
Figure 4.2 GMT gbXML flow
36
Figure 4.3 GMT components and detail
4.2 Development of the GMT
GMT consists of GPT, Excel Interface, and GGT.
Data Flow through GPT
Data stored in gbXML file is in hierarchical order. The relationship and hierarchy between the elements in the
building information model can be represented as a hierarchy tree (Figure 4.4). A text based gbXML is shown
(Figure 4.5). By knowing the location of all the data information, scripts were developed using Python (gbXML
Parsing Tool). The gbXML Parsing Tool (GPT) finds useful information from the source gbXML file and writes
them to the Excel interface in organized structure. The useful information defined in Revit-Trace GMT are the
following:
General information (Temperature unit, length unit, volume unit, SI/IP unit)
Campus id, name
Building id, name
Space id, name, internal load (people, lighting, and equipment)
Zone id, name, set point, related space
Surface (wall, floor, roof)
Opening (window, door)
37
Figure 4.4 gbXML hierarchical tree
Figure 4.5 Sample gbXML as text
Data Flow through Excel Interface
The Excel interface has five sheets:
1. Cover sheet
2. Overview
3. Space
4. Surface
5. Opening
The cover sheet gives general information about how to use the Excel sheets and instructions on how to modify the
data using the sheets.
38
The overview sheet is the interactive sheet where the user can read or change the information. All the information
are grouped into space matrix and zone matrix, where all the pieces of information were tabulated for easy access
and readable. The suspicious data (“0 entries,” “unassigned zones”) in the matrix would be highlighted so that the
user can determine if the data is correct and modify it if it is not.
Data Flow through GGT
The corrected or updated information are then extracted by the gbXML Generating Tool (GGT) to make the new
gbXML file. The GGT script was also developed using Python.
The Overall Data Flow
To summarize the data flow in all three components (Figure 4.6):
useful information is extracted from the gbXML file
the extracted data is organized and written in corresponding location in Excel sheet
the data in Excel sheets got updated
the updated Excel sheets makes a new gbXML file
39
Figure 4.6 GMT data flow
40
4.2.1 gbXML Parsing Tooling
The development of the tool was conducted in the Python scripting environment (Figure 4.7). The complete script of
GPT is attached in Appendix B
Figure 4.7 Partial GPT example
The development of GPT followed the designed process and tasks (Figure 4.8). The GPT is a standalone Python
script that reads a gbXML file (input) and generates an Excel file (output).
Figure 4.8 GPT flow chart
41
4.2.2 Excel Interface
The Excel interface has the five tabs (Figure 4.9).
Figure 4.9 Excel Interface tabs
For each of the tab, the corresponding data information were stored. The overall data stored location of the Excel
sheet followed the four main categories, namely, overview, space, surface, and opening (Figure 4.10).
Figure 4.10 Excel Interface hierarchy
42
4.2.2.1 Interactive Overview Sheet
In the Overview tab, there are three components:
General information table shows the temperature unit, length unit, volume unit, SI/IP (metric/imperial) unit that the
building is using (Figure 4.11).
Figure 4.11 General Information
The space matrix summarizes the space information into a tabulated matrix. This is the main interface where the
user can modify and view the space data information (Figure 4.12).
Figure 4.12 Space Matrix
The ID column shows the Space ID; it can be changed to their names that the user wanted. The space ID will
become space description in the Trace model after the gbXML file is imported.
The building column shows the building that the space belongs to, if there are multiple buildings.
The Name column shows the name of the space that the user specified in the Revit model. It can be changed in the
matrix for user convenience, but it will not be imported into the Trace model.
The zone ID column shows the zone that the space belongs to. The space that has not been assigned to any space
would be highlighted. The zone can be changed and reassigned in the matrix directly.
The area column shows the area of each space, which cannot be changed.
The # people column shows the occupancy in each space. It can be changed in the matrix directly.
The three columns of people load (latent, sensible and total) shows the internal load generated by people. It can be
changed in the matrix directly.
43
The lighting and equipment column show the internal load generated by lighting and equipment. They can all be
changed in the matrix directly.
The zone matrix summarizes the zone information. This is the main interface where the user could modify and
change the controls of the zones (Figure 4.13).
Figure 4.13 Zone matrix
The zone ID corresponds to the zone ID in the space matrix. The user could change the zone ID in the matrix and
have an updated gbXML file. Zone ID is used to connect spaces to zones.
The zone names are the description of zones, which will be import to the Trace model and become zone description.
It can be change in the zone matrix directly.
Design heating and cooling temperature can be changed in the matrix directly.
4.2.2.2 Space info sheet
The space sheet shows the space information in a hierarchical order (Figure 4.14). It is not for interactive use or
modifications by the users. It is for user to see what is going to be imported to the Trace model in in terms of space
by space.
Figure 4.14 Space sheet
44
4.2.2.3 Surface info sheet
All the surfaces are pulled out from the gbXML file, including walls, floors, roofs, and air surfaces.
All the surfaces with types that it is created in Revit model are listed in the column named Surface Type in Revit
(Figure 4.15). The corresponding type it is going to be imported in Trace are listed in the column next to it.
According to the Trace Manual (Trane, 2015), Trace takes surfaces in the following manner:
Interior walls become partitions
Exterior walls become walls
Roofs become roofs
Slabs on grade become exposed floors
So any other representation of the surfaces would not be recognized in the Trace model. The missing surface would
be highlighted so the user would detect the suspicious entry easily.
Figure 4.15 Surface sheet showing missing data
45
4.2.2.4 Opening info sheet
All the openings are imported from the gbXML file including door and windows (Figure 4.16). The opening type,
on which wall it belongs to, and the zone that the wall is in would be shown in the sheet. This sheet is not
interactive; the purpose of the sheet is only to inform the user, so that if there is anything missing or suspicious, the
user could go back to the location in the Revit model to see the problem.
Figure 4.16 Opening sheet
4.2.3 gbXML Generating Tool
The GGT script was developed using Python scripting environment. Part of the script were shown with the complete
script attach in Appendix B (Fig. 16).
Figure 4.17 GGT script
46
The GGT development followed its main purpose of comparing and updating the new gbXML file based on the
modified Excel file (Figure 4.18). The GGT is a standalone Python strip that reads the original gbXML file and the
modified Excel file, generate a new updated gbXML file.
Figure 4.18 GGT flowchart
4.3 Summarize
gbXML Modifying Tool consists of three parts: gbXML Parsing Tool, Excel Interface, and gbXML Generating
Tool.
The gbXML Parsing Tool takes the source gbXML file, organizes the data, pulls out useful information and writes
to the Excel Interface. gbXML Parsing Tool was developed in Python scripting environment.
The Excel Interface shows the building information in five tabs: cover sheet, overview, space, surface, and opening.
The purpose of the Excel sheet is to detect erroneous and suspicious data. The Excel Interface is interactive, that the
user could change error directly in the sheet. The Excel file is auto generated after using GPT.
The gbXML Generating Tool takes the modified Excel sheet, and makes a new updated gbXML file. The GGT was
developed in the Python scripting environment.
47
Chapter 5 Presenting the GMT
The previous chapter discussed the development of the tool. This chapter presents the tool with a case study of a
typical building that demonstrates the process of using the tool.
5.1 Overview
A Revit model was created. The model was built with some intentional wrong settings to test the effectiveness of the
case study. A gbXML file was exported from the Revit model. The exported gbXML was considered the source
gbXML file to be used for both Test 1 and Test 2 (Figure 5.1). Test 1 was conducted using the conventional direct
import approach. Test 2 was conducted using the GMT approach, as described in chapter 4 (Figure 4.1Figure 4.2).
Figure 5.1 Test Overview
Creation of Revit Model and Source gbXML
A Revit model was developed in Revit 2014, with room, zone, wall, internal load, window, and door (Figure
5.3,Figure 5.2). Some of the elements were falsely defined to simulate human error. Some of the spaces were
intentional left out from the zone. Internal load were inputted as zeros and very large numbers. The floor was
selected as “exterior floors .
Figure 5.3 room view in Revit
Figure 5.2 3D view of the model
48
A standard gbXML file was exported using the complex option (Error! Reference source not found.,Error!
Reference source not found.).
5.2 Conventional Approach (Test 1)
The source gbXML file created in section 5.1 was imported directly to the Trane Trace Software.
A standard Trace load model was created (Figure 5.7).
The template was empty (Figure 5.6).
A gbXML file was imported (Figure 5.9).
Figure 5.5 gbXML export
Figure 5.4 gbXML export continued
49
Internal load and design temperature were selected (Figure 5.8).
After gbXML file was imported to the Trace model, 17 rooms and 1 system were created as they were stored in the
Revit model (Figure 5.10).
Figure 5.10 main page after import
Figure 5.7 Trace model template creation
Figure 5.6 Trace model main page
Figure 5.9 import detail
Figure 5.8 gbXML import
50
The Trace model contained erroneous information:
simulated human typing error for occupancy were introduced to the model (Figure 5.11)
floors were missing (Figure 5.12)
unassigned zone stayed in default group (Figure 5.13)
Figure 5.11 Missing occupancy for rooms
Figure 5.12 Missing floor
51
Figure 5.13 Unassigned space
These errors could cause substantial inefficiency and inaccuracies during the design process. For the unassigned
zone error, it is easy to catch because all the unassigned spaces were group together in the default group (Figure
5.13). The user could just reassign the zones directly in the Trace software in the window. Nevertheless, for other
errors like occupancy, internal load, floors, it is much more difficult to catch the error. The user would have to go
through each room one by one to make sure the accuracy of the data entry.
5.3 GMT approach (Test 2)
The source gbXML file was read by gbXML Parsing Tool (GPT) and an Excel file was auto generated.
5.3.1 Overview Sheet
The general information table showed the units that the model was using (Figure 5.14).
Figure 5.14 General information
The space matrix summarized the entries from the building model (Figure 5.15). There were three unsigned rooms,
marked in read as “Missing”. Space 2 had 0 occupancy and internal load entry, also highlighted in red. Space 15 had
0 light power.
52
Figure 5.15 Space matrix for the model
Notice that space 4 had a latent load of 1200, which is much higher than the other entries. Although it was not
highlighted in the sheet, it can be easily spotted by using the Excel internal function. By applying conditional
formatting to column Latent Load, setting the constraint to 600 as suspicious number (Figure 5.16). All the number
that is higher than 600 will be highlighted (Figure 5.17). The erroneous numbers in the model that were hard to be
detected in Trace, now would be easy to be spotted in Excel sheet directly, or through Excel functions.
Figure 5.16 Conditional formatting
Figure 5.17 Conditional formatting result
53
By knowing the errors contained in the model, the user can change the data directly in the space matrix. After
modification of the data entries directly in the space matrix, the new space matrix was updated (Figure 5.18).
Figure 5.18 Modified space matrix
The zone matrix was shown right next to the space matrix, with all the parameters tabulated (Figure 5.19).
Whenever there is a zone-Default row shown in the zone matrix, it indicates that there are unassigned spaces. Since
the zones have already been fixed above, everything was left the same in the zone matrix.
Figure 5.19 Zone space
54
5.3.2 Space Sheet
The space sheet showed the parameter for each space as a whole; the user can view the data in different perspective
here (Figure 5.20).
Figure 5.20 Space sheet info
5.3.3 Surface Sheet
All the surfaces were shown in the surface sheet (Figure 5.21).
Figure 5.21 Surface sheet
The exterior floors would be missing in Trace model. The user can replace all the exterior floors with slab on grade
to fix this error.
55
5.3.4 Opening Sheet
The opening sheet showed the doors and windows that were going to be imported to Trace model, it cannot be
modified here (Figure 5.22).
Figure 5.22 Opening sheet
5.3.5 Imports
The modified Excel file was saved. A new gbXML file was generated by running the gbXML Generating Tool
(GGT). The updated gbXML file was imported to the Trace Software (Fig 5.23 ~ Fig 5.25).
All the spaces were assigned to the new zone with no space left out.
The missing floor was fixed.
The occupancy number was fixed.
The internal loads was fixed.
Figure 5.23 fixed occupancy
56
Figure 5.24 fixed floor
Figure 5.25 fixed zone assignment
5.4 Test 1 and Test 2 comparison
A comparison between solving the errors using conventional approach and GMT approach was tabulated (Figure
5.26). In small scale project, the two approaches might take the same time. In large scale project, the conventional
approach of checking each entry could take long time, and the GMT tool would allow for more accurate data entry
into Trace.
57
Figure 5.26 Test 1 and Test 2 comparison
The advantage of using the conventional approach is that the users are already familiar with the software and no
training is needed. The disadvantage of using the conventional approach is that it is very time consuming and errors
could be overlooked in Trace.
The advantage of using GMT approach is that it significantly cuts down the design time. All the error correction and
modification can be achieved in Excel interface. The disadvantage of using the approach is that it is that it adds a
little to the complexity of the design process.
5.5 Other applications
In addition to the error detection and correction, the GMT has other applications.
For example, in the case where multiple runs of calculation is needed in the Trace model, the GMT can be used to
assist the design.
This can be shown in the case of the previous case study. For the next simulation, each room might be named
differently and zoned differently due to some client request. Instead of going back to the Revit model and change the
settings, data in the space matrix can be modified directly due to the request. The space ID has been renamed. The
rooms has also been assigned to the different zones to compare different simulation results (Figure 5.27).
Figure 5.27 Space matrix modification
The Zone ID could be changed. As long as the zone ID in zone matrix has the same name as that in the space matrix,
the zone ID can be changed to anything. The settings for the zones can also be changed for different runs of
simulation. Notice that only three zones in the zone matrix were used in the space matrix. Zone-6 to zone-10 were
58
left same from the source gbXML (Figure 5.28). It is not necessary to delete zone-6 to zone-10. As long as it is not
referred to in space matrix, it would not be imported to the Trace model.
Figure 5.28 Zone matrix modification
The updated gbXML file was then imported to the Trace template.
Zone assignments got updated (Figure 5.29).
Room names got updated (Figure 5.30).
Zone set points got updated (Figure 5.31).
Figure 5.29 New zone list in Trace model
59
Figure 5.30 New room page in Trace model
Figure 5.31 New design temperature
5.6 Summary
A case study was conducted to compare the effectiveness difference between conventional approach and the GMT
approach. GMT approach can save design time in large complex scale project and increase accuracy in the Trace
model, but it adds a bit complexity to the design process.
In addition to the error detection function, the GMT can also be used to facilitate data modification in the Revit
model with respect to different Trace simulation.
60
Chapter 6 Conclusion
With the technology being utilized to assist the mechanical design, various software are becoming indispensable in
the design process. There exist gaps between software in terms of data sharing, which reduces the efficiency of the
work. It became apparent when looking at the different software programs and the process in which that they were
used, that there were several reasons that gaps may exist:
different data structures
minor formatting difference in data files,
unfriendly user interface
limited features
user preferences
The current approaches to data transferring have pros and cons of their own. A new approach was proposed to try to
solve the issue. A GMT (gbXML Modify Tool) approach was proposed. The GMT approached the data transferring
problem through the utilization of gbXML schema. Some of BIM gaps and missing information are due to following
reasons:
Missing information in directly exported gbXML file
Human mistakes in the original building model
Target software does not support certain inputs
Information mismatch during transferring
To make up for the erroneous data information, the GMT shows what is in the data, validates the data, patches the
missing data, or modifies the data. The purposed tool (GMT) and method takes the directly exported gbXML file
from the Revit model and modifies the file to account for the problems. Then the tool makes a new gbXML file to
be imported to the analysis software such that less error were generated, improving the efficiency of the data
transferring process.
The gbXML modifier is a point-to-point specific customized tool between two software that increases data
transferring efficiency through augmenting the gbXML schema. A Revit-Trace GMT was developed to support the
validity of the approach.
A comparison between approaching a standard mechanical load calculation process using conventional process and
GMT process was conducted (Figure 6.1).
Figure 6.1 Comparison result
The advantage of using the conventional approach is that the users are already familiar with the software and no
training is needed. The disadvantage of using the conventional approach is that it is very time consuming and errors
could be overlooked in Trace.
61
The advantage of using GMT approach is that it significantly cuts down the design time. All the error correction and
modification can be achieved in Excel interface. The disadvantage of using the approach is that it is that it adds a
little to the complexity of the design process.
62
Chapter 7 Future Work
There are limitations to the GMT approach. Since GMT is a point-to-point tool, it requires tailored programming
between two specific software. A Revit-Trace GMT was developed. This chapter suggested a few possible
improvements to the approach that can be done in the future.
7.1 The universal GMT
Currently, the GMT was designed to be point-to-point due to the reason that every software uses different set of
gbXML set. For the future study and development, the GMT database can be built, in addition to Revit-Trace. For
example, IESVE-Revit, Revit-BlueBeam. As the database gets more and more comprehensive, a universal GMT can
be integrated. The universal GMT can take any two software and facilitate the data transferring in-between.
7.2 Building an interface
Currently, the three parts of GMT are GPT, Excel interface, and GGT. The GPT and GGT are two separate Python
file that does their own tasks. For the future study and development, an integrated software combing all the
components can be developed so that it would be easier to operate the tool.
7.3 Enrich the validation rule
The validation rule used in Revit-Trace GMT is based on the available data in the gbXML file exported from the
Revit model. Only the information that will be accepted by the Trace software is extracted by the GMT. All the
other information that is specific to Revit will be ignored. For the future study, the Revit object that is not accepted
by Trace can be pulled out for analysis. For example, for a wall in Revit model, the wall construction type is stored
under ‘CADObjectId’, which Trace does not under. All the wall construction information, namely, R value,
transmittance, will be stored in CADObjectId. By enriching the validation rule, the GMT can go into the
CADObjectId and extract the information associated with it, which can be used to be transferred to specific location
in Trace.
7.4 Summary
The GMT is a point-to-point tool to facilitate data transferring between two software. The future work can be done
to enrich the validation rule to make the data transferring range larger for the current Revit-Trace GMT. Interface
can be built for better user experience to the tool. Database can be developed to collectively integrate different
software so that GMT can be used for all the software data transferring.
63
Reference
Ali, Shariq. 2010. “ANALYSIS OF PROCEDURES AND WORKFLOW FOR CONDUCTING ENERGY
ANALYSIS USING AUTODESK REVIT, GBXML AND TRACE 700.”
American Institute of Architects. 2009. The American Institute of Architects Official Guide to the 2007 AIA Contract
Documents. John Wiley & Sons.
American Institute of Steel Construction. 2014. “Interoperability.” 2014.
Autodesk Inc. 2015. “About Macros.” http://help.autodesk.com/view/RVT/2016/ENU/?guid=GUID-EFF4E5A3-
16EB-4CB4-AD6A-5EEE823CCE76.
Dong, B, K Lam, Y Huang, and Dobbs. 2007. “A Comparative Study of the IFC and gbXML Informational
Infrastructures for Data Exchange in Computational Design Support Environment.”
Grilo, António, and Ricardo Jardim-Goncalves. 2010. “Value Proposition on Interoperability of BIM and
Collaborative Working Environments.” Automation in Construction, Building Information Modeling and
Collaborative Working Environments, 19 (5): 522–30. doi:10.1016/j.autcon.2009.11.003.
Guzmán, Elizabeth, and Zhenhua Zhu. 2016. “Interoperability between Building Design and Building Energy
Analysis.” In Computing in Civil and Building Engineering (2014), 17–24. American Society of Civil
Engineers. Accessed January 22. http://ascelibrary.org/doi/abs/10.1061/9780784413616.003.
Hijazi, Mohammed Omar. 2015. “Bridging the Gap: A Tool to Support Bim Data Transparency for Interoperability
with Building Energy Performance Software.” M.B.S., United States -- California: University of Southern
California. http://search.proquest.com.libproxy2.usc.edu/docview/1686798497/abstract.
Kensek, Karen. 2014. Building Information Modeling: BIM in Current and Future Practice. 1 edition. Hoboken,
New Jersey: Wiley.
Kumar, Sumedha. 2008. “Interoperability between Building Information Models (BIM) and Energy Analysis
Programs :: University of Southern California Dissertations and Theses.”
http://digitallibrary.usc.edu/cdm/ref/collection/p15799coll127/id/64743.
Laurent, Simon, and Michael Fitzgerald. 2016. XML Pocket Reference. Accessed January 14.
http://shop.oreilly.com/product/9780596100506.do.
Mayra Reyes. 2014. “Trane C.D.S. eLearning Series.”
https://www.trane.com/content/dam/Trane/Commercial/global/products-systems/design-analysis-tools/cds-
software-news/CDSNews2015/Trane_gbXMLandTRACE700.pdf.
National Renewable Energy Laboratory. 2016. “gbXML.”
http://www.gbxml.org/About_GreenBuildingXML_gbXML.
Phillip Cunningham. 2009. “Heating and Cooling Load Calculations and Energy Model Development From an
Autodesk Revit MEP Model Utilizing gbXML.”
Redmond, Alan, Alan Hore, Mustafa Alshawi, and Roger West. 2012. “Exploring How Information Exchanges Can
Be Enhanced through Cloud BIM.” Automation in Construction 24 (July): 175–83.
doi:10.1016/j.autcon.2012.02.003.
Turner, Fred. 2005. ASHRAE Journal: Vol. 47, No. 4, April 2005. American Society of Heating, Refrigeration and
Air-Conditioning Engineers, Inc.
———. 2010. ASHRAE Journal 2010. American Society of Heating, Refrigeration and Air-Conditioning Engineers,
Inc.
University of Cambridge. 2016. “IES Virtual Environment — Energy Modelling and Building Physics Resource
Base.” Page. Accessed January 14. http://www-embp.eng.cam.ac.uk/software/iesve.
US National Building Information Model Standard Project Committee. 2014. “BIM.”
Welle, Benjamin, John Haymaker, and Zack Rogers. 2011. “ThermalOpt: A Methodology for Automated BIM-
Based Multidisciplinary Thermal Simulation for Use in Optimization Environments.” Building Simulation
4 (4): 293–313. doi:10.1007/s12273-011-0052-5.
64
Appendix A: Survey
Survey was conducted in person or through phone calls with 10 firms related to mechanical design. The firm was
elected from the lesser proactive ones like corporate facility group, to the more proactive ones like the famous
consulting firm. Multiple employees were interview from each firm to collect more comprehensive information.
Four prepared questions were ask during the interview. Conversations were extended to collect potential scope and
application of the tool.
Do you use BIM in the mechanical design?
Using BIM : 9
Not Using BIM : 1
How do you pass data between BIM software and other tools?
Manual Direct Indirect Not Applicable
Revit - Excel 3 10 0 3
Revit - Trace 700 2 0 10 4
Revt - IESVE 3 2 9 2
Revit - AutoCAD 5 10 0 1
Revt - BlueBeam 10 0 0 6
65
Is it successful sharing data among software?
How long do you spend inputting data into software?
Errors in using gbXML 10
Not familiar with gbXML 6
Prefers the conventional method 2
Don't know 1
Issues Encountered
Small Size Mid Size Large Size
Manual Couple Hr Several Day Weeks
Indirect Couple Hr Several Day Few Days
Direct Couple Hr Couple Hr Couple Hr
Time Spended in Data Inputing
66
Appendix B: Python Code
Code for GGT:
# this file generate new gbxml based on the change
import xml.etree.ElementTree as ET
from openpyxl import Workbook
from openpyxl import load_workbook
tree = ET.parse('CaseStudy.xml')
rt = tree.getroot()
# load excel and sheet
data = load_workbook('ExcelInterface.xlsx')
sheet = data['Overview']
#get the space numbers
Space = rt[0][1].findall('Space')
n = len(Space)
row = 13
#get info from space matrix
space_matrix = []
while n > 0:
space_info=[]
space_info.append(sheet['A'+str(row)].value)
space_info.append(sheet['C'+str(row)].value)
space_info.append(sheet['D'+str(row)].value)
space_info.append(sheet['E'+str(row)].value)
space_info.append(sheet['F'+str(row)].value)
space_info.append(sheet['G'+str(row)].value)
space_info.append(sheet['H'+str(row)].value)
space_info.append(sheet['I'+str(row)].value)
space_info.append(sheet['J'+str(row)].value)
space_info.append(sheet['K'+str(row)].value)
space_matrix.append(space_info)
n -= 1
row += 1
# goe info from original data
space_matrix_o = []
for i in Space:
sp_info = []
sp_info.append(i.get('id'))
sp_info.append(i.find('Name').text)
sp_info.append(i.get('zoneIdRef'))
sp_info.append(i.find('Area').text)
sp_info.append(i.find('PeopleNumber').text)
heat_gain = i.findall('PeopleHeatGain')
sp_info.append(heat_gain[0].text)
67
sp_info.append(heat_gain[1].text)
sp_info.append(heat_gain[2].text)
sp_info.append(i.find('LightPowerPerArea').text)
sp_info.append(i.find('EquipPowerPerArea').text)
space_matrix_o.append(sp_info)
## updating.......
n = len(Space)
c = 0
for i in Space:
i.set('id',str(space_matrix[c][0]))
for j in tree.iter('AdjacentSpaceId'):
if j.get('spaceIdRef') == space_matrix_o[c][0]:
j.set('spaceIdRef',str(space_matrix[c][0]))
i.find('Name').text = str(space_matrix[c][1])
i.set('zoneIdRef',str(space_matrix[c][2]))
i.find('PeopleNumber').text = str(space_matrix[c][4])
a = i.findall('PeopleHeatGain')
a[0].text = str(space_matrix[c][5])
a[1].text = str(space_matrix[c][6])
a[2].text = str(space_matrix[c][7])
i.find('LightPowerPerArea').text = str(space_matrix[c][8])
i.find('EquipPowerPerArea').text = str(space_matrix[c][9])
c+=1
Zone = rt.findall('Zone')
n = len(Zone)
## read from excel, zone
row = 13
zone_matrix = []
while n > 0:
zone_info=[]
zone_info.append(sheet['N'+str(row)].value)
zone_info.append(sheet['O'+str(row)].value)
zone_info.append(sheet['P'+str(row)].value)
zone_info.append(sheet['Q'+str(row)].value)
zone_matrix.append(zone_info)
n -= 1
row += 1
## read original data
zone_matrix_o = []
for i in Zone:
zn_info = []
zn_info.append(i.get('id'))
zn_info.append(i.find('Name').text)
zn_info.append(i.find('DesignHeatT').text)
zn_info.append(i.find('DesignCoolT').text)
zone_matrix_o.append(zn_info)
## updating zone.....
n = len(Zone)
68
c = 0
for i in Zone:
i.set('id',str(zone_matrix[c][0]))
i.find('Name').text = str(zone_matrix[c][1])
i.find('DesignHeatT').text = str(zone_matrix[c][2])
i.find('DesignCoolT').text = str(zone_matrix[c][3])
c+=1
tree.write('updated.xml')
69
Code for GPT:
import xml.etree.ElementTree as ET
from openpyxl import Workbook
from openpyxl.styles import Font
from openpyxl.styles import colors
from openpyxl.styles import PatternFill
##project gbXML Parsing Tool
##this scripe read information from source gbXML file
##and organize the useful information, write to excel
## get the gbxml and store it in root
tree = ET.parse('CaseStudy.xml')
rt = tree.getroot()
hFont = Font(color = colors.RED)
blackFill = PatternFill(start_color=colors.BLACK,
end_color=colors.BLACK,
fill_type='solid')
bold = Font(bold = True)
yellowFont = Font(color = colors.YELLOW)
def makeCoverSheet():
for i in range(5,31,1):
sheet_0['C'+str(i)].fill = blackFill
sheet_0['L'+str(i)].fill = blackFill
a = ['D','E','F','G','H','I','J','K']
for i in a:
sheet_0[i+str(5)].fill = blackFill
sheet_0[i+str(30)].fill = blackFill
# eyes
sheet_0['E10'].fill = blackFill
sheet_0['J10'].fill = blackFill
# mouth
sheet_0['E21'].fill = blackFill
sheet_0['J21'].fill = blackFill
a = ['F','G','H','I']
for i in a:
sheet_0[i+str(22)].fill = blackFill
sheet_0['E3'] = "Welcome to the gbXML external modifier!"
sheet_0['E3'].font = Font(size = 18,bold=True)
def printSpace2excel(root,startingR):
row = startingR
##--------------------------------------------------------
## now we assmue there is only one campus. modify here if there is more campus
campus = root[0]
70
sheet_1['A'+str(row)] = "Campus ID:"
sheet_1['A'+str(row)].font = bold
sheet_1['B'+str(row)]= campus.get('id')
row += 1
## get the building
buildings = campus.findall('Building')
for i in buildings:
## building id
sheet_1['B'+str(row)] = "Building ID:"
sheet_1['B'+str(row)].font = bold
sheet_1['C'+str(row)] = i.get('id')
row += 1
## get the spaces
spaces = i.findall('Space')
for j in spaces:
sheet_1['D'+str(row)] = "Space ID:"
sheet_1['D'+str(row)].font = bold
sheet_1['E'+str(row)] = j.get('id')
## now print all the information associated with the room
row += 1
sheet_1['E'+str(row)] = "Name"
sheet_1['E'+str(row)].font = bold
sheet_1['F'+str(row)] = j.find('Name').text
row += 1
sheet_1['E'+str(row)] = "Zone"
sheet_1['E'+str(row)].font = bold
try:
sheet_1['F'+str(row)] = j.get('zoneIdRef')
except:
sheet_1['F'+str(row)] = "No Value"
sheet_1['F'+str(row)].font = hFont
row += 1
sheet_1['E'+str(row)] = "Area"
sheet_1['E'+str(row)].font = bold
sheet_1['F'+str(row)] = float(j.find('Area').text)
row += 1
## modify later for other units
sheet_1['E'+str(row)] = "Number of People"
sheet_1['E'+str(row)].font = bold
try:
sheet_1['F'+str(row)] = float(j.find('PeopleNumber').text)
except:
sheet_1['F'+str(row)] = "No Value"
sheet_1['F'+str(row)].font = hFont
row +=1
PHG = j.findall('PeopleHeatGain')
for k in PHG:
try:
sheet_1['E'+str(row)] = "Btu Per Person - " + k.get('heatGainType')
sheet_1['F'+str(row)] = float(k.text)
except:
sheet_1['F'+str(row)] = "No Value"
sheet_1['F'+str(row)].font = hFont
71
row +=1
sheet_1['E'+str(row)] = "Lighting Power"
sheet_1['E'+str(row)].font = bold
try:
sheet_1['F'+str(row)] = float(j.find('LightPowerPerArea').text)
except:
sheet_1['F'+str(row)] = "No Value"
sheet_1['F'+str(row)].font = hFont
row += 1
sheet_1['E'+str(row)] = "Equipment Power"
sheet_1['E'+str(row)].font = bold
try:
sheet_1['F'+str(row)] = float(j.find('EquipPowerPerArea').text)
except:
sheet_1['F'+str(row)] = "No Value"
sheet_1['F'+str(row)].font = hFont
##-------------------------------------rooms over
row += 2
def spaceMatrix(rt,row):
root = rt
## print the general informations on the sheet
sheet_2['A'+str(row)] = "General Information:"
sheet_2['A'+str(row)].font = bold
row +=2
sheet_2['B'+str(row)] = 'Temperarue Unit:'
sheet_2['B'+str(row)].font = bold
sheet_2['C'+str(row)] = root.get("temperatureUnit")
row +=1
sheet_2['B'+str(row)] = 'Length Unit:'
sheet_2['B'+str(row)].font = bold
sheet_2['C'+str(row)] = root.get("lengthUnit")
row +=1
sheet_2['B'+str(row)] = 'Volume Unit:'
sheet_2['B'+str(row)].font = bold
sheet_2['C'+str(row)] = root.get("volumeUnit")
row +=1
sheet_2['B'+str(row)] = 'Use SI for Results:'
sheet_2['B'+str(row)].font = bold
sheet_2['C'+str(row)] = root.get("useSIUnitsForResults")
row += 3
# put all the informaiton into the space matrix
sheet_2['A'+str(row)] = "Space Super Matrix"
sheet_2['A'+str(row)].font = bold
row += 1
sheet_2['A'+str(row)] = "ID"
sheet_2['B'+str(row)] = "Building"
72
sheet_2['C'+str(row)] = "Name"
sheet_2['D'+str(row)] = "Zone Id"
sheet_2['E'+str(row)] = "Area"
sheet_2['F'+str(row)] = "# People"
sheet_2['G'+str(row)] = "Total Heat/Person"
sheet_2['H'+str(row)] = "Sensible/Person"
sheet_2['I'+str(row)] = "Latent/Person"
sheet_2['J'+str(row)] = "Lighting"
sheet_2['K'+str(row)] = "Equipent"
#font change
a = ['A','B','C','D','E','F','G','H','I','J','K']
for i in a :
sheet_2[i+str(row)].font = bold
row += 1
#ploting information
buildings = rt[0].findall('Building')
for i in buildings:
spaces = i.findall('Space')
for j in spaces:
sheet_2['A'+str(row)] = j.get('id')
sheet_2['B'+str(row)] = i.get('id')
sheet_2['C'+str(row)] = j.find('Name').text
try:
if j.get('zoneIdRef')!= "zone-Default":
sheet_2['D'+str(row)] = j.get('zoneIdRef')
else:
sheet_2['D'+str(row)] = 'Missing'
sheet_2['D'+str(row)].font = hFont
except:
sheet_2['D'+str(row)] = "No Value"
sheet_2['D'+str(row)].font = hFont
sheet_2['E'+str(row)] = float(j.find('Area').text)
try:
sheet_2['F'+str(row)] = float(j.find('PeopleNumber').text)
except:
sheet_2['F'+str(row)] = "No Value"
sheet_2['F'+str(row)].font = hFont
PHG = j.findall('PeopleHeatGain')
try:
sheet_2['G'+str(row)] = float(PHG[0].text)
except:
sheet_2['G'+str(row)] = "No Value"
sheet_2['G'+str(row)].font = hFont
try:
sheet_2['H'+str(row)] = float(PHG[1].text)
except:
sheet_2['H'+str(row)] = "No Value"
sheet_2['H'+str(row)].font = hFont
try:
sheet_2['I'+str(row)] = float(PHG[2].text)
except:
sheet_2['I'+str(row)] = "No Value"
sheet_2['I'+str(row)].font = hFont
73
try:
sheet_2['J'+str(row)] = float(j.find('LightPowerPerArea').text)
except:
sheet_2['J'+str(row)] = "No Value"
sheet_2['J'+str(row)].font = hFont
try:
sheet_2['K'+str(row)] = float(j.find('EquipPowerPerArea').text)
except:
sheet_2['K'+str(row)] = "No Value"
sheet_2['K'+str(row)].font = hFont
row += 1
##check for zeros
a = ['A','B','C','D','E','F','G','H','I','J','K']
for i in a:
for j in range(13,row,1):
try:
if float(sheet_2[i+str(j)].value) == 0:
sheet_2[i+str(j)].font = hFont
except:
pass
# zone matrix
row = 11
sheet_2['N'+str(row)] = "Zone Matrix"
sheet_2['N'+str(row)].font = bold
row += 1
sheet_2['N'+str(row)] = "Zone Id"
sheet_2['N'+str(row)].font = bold
sheet_2['O'+str(row)] = "Zone Name"
sheet_2['O'+str(row)].font = bold
sheet_2['P'+str(row)] = "Design Heating Temperature"
sheet_2['P'+str(row)].font = bold
sheet_2['Q'+str(row)] = "Design Cooling Temperature"
sheet_2['Q'+str(row)].font = bold
row += 1
zones = rt.findall('Zone')
for i in zones:
sheet_2['N'+str(row)] = i.get('id')
if sheet_2['N'+str(row)].value == 'zone-Default':
sheet_2['N'+str(row)].font = hFont
sheet_2['O'+str(row)] = i.find('Name').text
sheet_2['P'+str(row)] = float(i.find('DesignHeatT').text)
sheet_2['Q'+str(row)] = float(i.find('DesignCoolT').text)
row += 1
row += 1
sheet_2['N'+str(row)] = "*if 'zone-Default' shows up in the matrix, there might be unassigned spaces"
def print_surface(rt,row):
surfaces = rt[0].findall('Surface')
74
sheet_3['A'+str(row)] = "Wall ID"
sheet_3['A'+str(row)].font = bold
sheet_3['B'+str(row)] = "Surface Type in Revit"
sheet_3['B'+str(row)].font = bold
sheet_3['C'+str(row)] = "Corresponding Type in Trace"
sheet_3['C'+str(row)].font = bold
sheet_3['D'+str(row)] = "Recommended Change"
sheet_3['D'+str(row)].font = bold
row += 1
for i in surfaces:
sheet_3['A'+str(row)] = i.get('id')
sheet_3['B'+str(row)] = i.get('surfaceType')
if i.get('surfaceType')== "ExteriorWall":
sheet_3['C'+str(row)] = "Exterior Wall"
elif i.get('surfaceType')== "InteriorWall":
sheet_3['C'+str(row)] = "Partition"
elif i.get('surfaceType')== "Roof":
sheet_3['C'+str(row)] = "Roof"
elif i.get('surfaceType')== "SlabOnGrade":
sheet_3['C'+str(row)] = "Floor"
elif i.get('surfaceType')== "InteriorFloor":
sheet_3['C'+str(row)] = "Missing"
sheet_3['D'+str(row)] = "InteriorWall"
sheet_3['C'+str(row)].font = hFont
row += 1
def print_opening(rt,row):
sheet_4['A'+str(row)] ='Opening ID'
sheet_4['A'+str(row)].font = bold
sheet_4['B'+str(row)] ='Wall ID'
sheet_4['B'+str(row)].font = bold
sheet_4['C'+str(row)] ='Space ID'
sheet_4['C'+str(row)].font = bold
sheet_4['D'+str(row)] ='Space Name'
sheet_4['D'+str(row)].font = bold
sheet_4['E'+str(row)] ='Opening Type'
sheet_4['E'+str(row)].font = bold
row += 1
space = rt[0].iter('Space')
nameDict ={}
for i in space:
nameDict[i.get('id')] = i.find('Name').text
surface = rt[0].findall('Surface')
for i in surface:
opening = i.findall('Opening')
if opening != []:
for j in opening:
sheet_4['A'+str(row)] = j.get('id')
sheet_4['B'+str(row)] = i.get('id')
sheet_4['C'+str(row)] = i.find('AdjacentSpaceId').get('spaceIdRef')
a= sheet_4['C'+str(row)].value
try:
75
sheet_4['D'+str(row)] = nameDict[sheet_4['C'+str(row)].value]
except:
pass
sheet_4['E'+str(row)] = j.get('openingType')
row += 1
#------------------starts here
# creat a doc and sheet
doc = Workbook()
sheet_0 = doc.active
sheet_0.title = "CoverSheet"
makeCoverSheet()
sheet_2 = doc.create_sheet(title = 'Overview')
spaceMatrix(rt,3)
sheet_1 = doc.create_sheet(title = 'Space')
printSpace2excel(rt,3)
sheet_3 = doc.create_sheet(title = 'Surface')
print_surface(rt,3)
sheet_4 = doc.create_sheet(title = 'Opening')
print_opening(rt,3)
doc.save('ExcelInterface.xlsx')
76
Appendix C: Complete Trace Object and Associated Potential Errors
77
78
79
Abstract (if available)
Abstract
Software were being utilized to assist the job creation, coordination and delivery during mechanical design process as more and more information were evolved to be managed electronically. Data transferring between software became essential as to save time and effort in inputting the information in different software. BIM gaps existed that prohibited data from transferring successfully between BIM software and other analytical software. ❧ Current approaches utilized existing data schema such as gbXML and IFC, as media of storing information to interoperate between software. Nevertheless, the data transferring are not always successful due to human error, mismatching data structure, different adoption of schema, and limited features. ❧ Possible erroneous data transferring between software reduced the efficiency in the design process. Money and time were being wasted to correct and check for the missing data as a result of the gap. To improve the data quality and design experience, a GMT (gbXML Modifying Tool) approach was proposed. GMT was designed to catch errors (both human error and computer error), and correct errors. ❧ The gbXML modifier is a point-to-point specific customized tool between two software that increases data transferring efficiency through augmenting the gbXML schema. A Revit-Trace GMT was developed to support the validity of the approach. ❧ To make up for the erroneous data information, the GMT shows what is in the data, validates the data, patches the missing data, or modifies the data. The purposed tool (GMT) and method takes the directly exported gbXML file from the Revit model and modifies the file to account for the problems. Then the tool makes a new gbXML file to be imported to the analysis software such that less error were generated, improving the efficiency of the data transferring process. ❧ A case study was done to compare approaching a typical design process using the conventional method and GMT method. GMT caught both simulated human error and computer error. ❧ It takes time to familiarize users to use GMT. In small size project, the time spent detecting error using conventional approach is same as GMT. Nevertheless, GMT could save significant time in large complex project.
Linked assets
University of Southern California Dissertations and Theses
Conceptually similar
PDF
Streamlining sustainable design in building information modeling: BIM-based PV design and analysis tools
PDF
Bridging the gap: a tool to support bim data transparency for interoperability with building energy performance software
PDF
Visualizing thermal data in a building information model
PDF
A BIM-based visualization tool for facilities management: fault detection through integrating real-time sensor data into BIM
PDF
BIM+AR in architecture: a building maintenance application for a smart phone
PDF
Using building information modeling with augmented reality: visualizing and editing MEP systems with a mobile augmented reality application
PDF
MM Electrical Tool: a tool for generating electrical single line diagrams in BIM
PDF
Building information modeling based design review and facility management: Virtual reality workflows and augmented reality experiment for healthcare project
PDF
Multi-domain assessment of a kinetic facade: determining the control strategy of a kinetic façade using BIM based on energy performance, daylighting, and occupants’ preferences; Multi-domain asse...
PDF
Automating fire code compliance using BIM and Revit plug-ins
PDF
Visualizing architectural lighting: creating and reviewing workflows based on virtual reality platforms
PDF
Office floor plans generation based on Generative Adversarial Network
PDF
A simplified building energy simulation tool: material and environmental properties effects on HVAC performance
PDF
Building information modeling: guidelines for project execution plan (PxP) for India
PDF
Quantify human experience: integrating virtual reality, biometric sensors, and machine learning
PDF
Data visualization in VR/AR: static data analysis in buildings
PDF
Landscape and building solar loads: development of a computer-based tool to aid in the design of landscape to reduce solar gain and energy consumption in low-rise residential buildings
PDF
Daylight and health: exploring the relationship between established daylighting metrics for green building compliance and new metrics for human health
PDF
Guidelines to airport design: accounting for glare from buildings during takeoff and landing – an LAX case study
PDF
A BIM-based tool for accessible design standard plan check: an automated plan review plug-in for Revit focusing on accessible design
Asset Metadata
Creator
Yin, Kai
(author)
Core Title
Building bridges: filling gaps between BIM and other tools in mechanical design
School
School of Architecture
Degree
Master of Building Science
Degree Program
Building Science
Publication Date
08/03/2016
Defense Date
04/27/2016
Publisher
University of Southern California
(original),
University of Southern California. Libraries
(digital)
Tag
BIM,data exchange,data transfer,gap,mechanical design,OAI-PMH Harvest,python,software
Format
application/pdf
(imt)
Language
English
Contributor
Electronically uploaded by the author
(provenance)
Advisor
Kensek, Karen (
committee chair
), Choi, Joon Ho (
committee member
), Schiler, Marc (
committee member
)
Creator Email
yinkcareer@gmail.com,ykai@usc.edu
Permanent Link (DOI)
https://doi.org/10.25549/usctheses-c40-293498
Unique identifier
UC11281468
Identifier
etd-YinKai-4718.pdf (filename),usctheses-c40-293498 (legacy record id)
Legacy Identifier
etd-YinKai-4718.pdf
Dmrecord
293498
Document Type
Thesis
Format
application/pdf (imt)
Rights
Yin, Kai
Type
texts
Source
University of Southern California
(contributing entity),
University of Southern California Dissertations and Theses
(collection)
Access Conditions
The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the a...
Repository Name
University of Southern California Digital Library
Repository Location
USC Digital Library, University of Southern California, University Park Campus MC 2810, 3434 South Grand Avenue, 2nd Floor, Los Angeles, California 90089-2810, USA
Tags
BIM
data exchange
data transfer
gap
mechanical design
python