Task 2.2.

12 CMU Report 02:

Identification and Analysis of Interoperability Gaps
between Nbims/Open Standards and Building
Performance Simulation Tools

Department of Energy Award # EE0004261

Khee Poh Lam, PhD, RIBA, Professor Of Architecture

Omer T. Karaguzel, PhD Candidate
Rongpeng Zhang, PhD Candidate
Jie Zhao, PhD Student

Center for Building Performance and Diagnostics

Carnegie Mellon University

February 2012
TABLES OF CONTENTS

1. Executive Summary ................................................................................................................. 3

2. Interoperability between Various Performance Domains in Building Industry ...................... 3
3. Prevalent Informational Infrastructures in the Industry: IFC and gbXML ............................. 4
4. Comparison of Informational Infrastructures for Data Exchange in Computational Design
Support Environments .................................................................................................................... 5
5. Pros and Cons of the Technical and Semantic Implementations in IFC and gbXML............. 9
6. Identification and Analysis of Interoperability Issues between Current Dominant Building
Simulation Tools ............................................................................................................................. 9
7. References ............................................................................................................................. 25

LIST OF FIGURES

Fig. 1 UML diagram of the relationship between wall and its dimension in IFC ....................... 7
Fig. 2 Geometry and sensor representations in gbXML .............................................................. 8
Fig. 3 UML diagram of the relationship between sensor and sensed data in IFC ....................... 8
1. Executive Summary

A detailed identification and analysis is conducted on the interoperability gaps between Nbims/Open
standards and building performance simulation tools. As two prevalent Informational Infrastructures in
the architecture, engineering and construction (AEC) industry, IFC and gbXML are investigated and
compared with illustrated examples about geometry and sensor/sensed data. To evaluate the capabilities,
limitations and characteristics of various dominant building modeling and simulation tools,
interoperability issues between these tools are tabulated and analyzed in terms of the distortion of
building model information and the loss of geometric precision. Different types of elements in the
building model are used as illustrations in the comparison of the methods utilized in these tools in
handling the building models imported from other sources. The evaluations of the investigated tools are
summarized in detail for the reference of further study in solving these interoperability issues.

2. Interoperability between Various Performance Domains in Building Industry

The challenges to design complex high performance buildings demand a paradigm shift from the
traditional sequential to an interactive concurrent design environment (Dong, Lam et al. 2007). This
implies the need to adopt new integrative design processes and the associated computer-based design
support tools need to be re-conceptualized and re-engineered within an integrated IT environment. Such a
system must not only be capable of supporting concurrent performance evaluation of building design and
engineering across domains, but be accessible across geographically distributed environments through
both synchronous and asynchronous modes of communication (Lam, Wong et al. 2004).

With the development of information technology, significant progress has been made in the area of
common data exchange in the building industry. The first generation of data exchange models such as
STEP (ISO 1992), COMBINE (Augenbroe 1992), ICADS (Pohi and Rep 1988), ARMILLA (Gauchel,
Hovestadt et al. 1992), and IBOM (Sanvido 1992) focus mainly on building geometry information. It is
necessary but evidently insufficient for any performance-based design support. The second generation
data exchange models expanded to include information that is required for particular domain-specific
performance modeling, such as energy/thermal comfort simulation, HVAC design, lighting design,
building life-cycle analysis and building plan checking. The hierarchical models (Bedell and Kohler 1993)
and KNODES (Rutherford 1993) for energy and life cycle cost modeling are examples. These object-
oriented data models begin to address the larger question of interoperability between various
performance domains in building design. Perhaps more importantly, it offers new opportunities for
integrative concurrent design support (Lam et al., 2004). The current third generation models are able to
potentially encapsulate all information related to a building in a comprehensive data schema and
facilitate the sharing of pertinent information throughout the entire building life-cycle, from design (for
evaluating total building performance) to construction (for evaluating cost and schedules) to operation
(occupancy and environmental sensing and system controls).
3. Prevalent Informational Infrastructures in the Industry: IFC and gbXML

One key factor in the success of any data schema is in the wide-spread adoption by all constituencies in
the architecture, engineering and construction (AEC) industry. Currently, the Industry Foundation Class
(IFC) and Green Building XML (gbXML) are two main and prevalent informational infrastructures in the
industry.

Industry Foundation Classes is a vendor neutral, open data exchange specification. It is an object oriented
file format developed for the building industry and is commonly used in Building Information Modeling
to facilitate interoperability between software platforms. IFC was originally developed in 1995 by a group
of American and European AEC firms and software vendors through the International Alliance for
Interoperability (IAI). Since 2005 it has been maintained by building SMART International (ASHRAE
2005). The goal of IFC is to provide a universal basis for process improvement and information sharing in
the construction and facilities management industries. EXPRESS-G is used to identify classes, the data
attributes of classes and the relationships that exist between classes in IFC (IAI 2006). It is a graphical
modeling notation developed within the ISO-STEP community for representing application interpreted
models. Some major implementations of this schema include CORENET (Singapore), BuildingSMART
(Australia), SARA (Finland), Building Lifecycle Interoperable Cost (BLIS), Simple Access to the
Building Lifecycle Exchange (SABLE) and BSPro (Bazjanac and Maile 2004).

Green Building XML (gbXML) is developed based on the XML format. It uses an XML-based schema to
represent the building information, such as geometry and material properties), for energy simulation
purpose. It was developed by Green Building Studio (formerly GeoPraxis) with the support of the
California Energy Commission Public Interest Energy Research (PIER) Program, and the California
Utilities (Pacific Gas and Electric Company, Southern California EDISON and Sempra Energy Utility), in
order 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.

gbXML has the industry support and wide adoption by the leading CAD vendors and HVAC software
vendors. With the development of export and import capabilities in several major engineering modeling
tools, gbXML has become a defacto industry standard schema. Its use dramatically streamlines the
transfer of building information to and from engineering models, eliminating the need for time consuming
plan take-offs. This removes a significant cost barrier to designing resource efficient buildings and
specifying associated equipment. It enables building design teams to truly collaborate and realize the
potential benefits of Building Information Modeling (Faye C McQuiston 2005). Several popular CAD
software (e.g., Autodesk Revit, Architectural Desktop, and ArchiCAD) and energy analysis applications
(e.g., DOE-2. e-QUEST, HAP) can exchange data using this schema, through the Green Building Studio
web service (DOE-2, 2007).
 4. Comparison of Informational Infrastructures for Data Exchange in Computational
Design Support Environments
In this section, a comparative study of the IFC and gbXML informational infrastructures for data
exchange in computational design support environments is conducted with illustrated examples about
geometry and sensor/sensed data.
IFC
Geometry information
Fig.1 shows how the IFC schema represents the
coordinates and dimensions of an IfcWall object.
IfcWall is a subtype of IfcBuildingElement.
IfcBuildingElement is a subtype of IfcElement, which
generalize all components that make up an AEC product
such as walls, windows or doors.
IfcElement is a subtype of IfcProduct. IfcProduct has
two attributes named ObjectPlacement and
Representation. ObjectPlacement defines the starting
point of IfcWall. It can be given by (1) absolute value
relative to the world coordinate system by
IfcGridPlacement; (2) relative, value relative to the
object placement of another product by
IfcLocalPlacement; (3) by grid reference i.e., by the
virtual intersection and reference direction given by two
axes of a design grid through IfcGridPlacement.
The followings give an example of how IfcWall is
represented as IfcProductRepresentation to elaborate the
relational and organized data representation of IFC.
The IfcProductRepresentation defines a representation
of a product, including its eometric or topological
representation. It has two attributes:
IfcProductDefinitionShape, and
IfcMaterialDefinitionRepresentation. The
IfcProductDefinitionShape defines all shape relevant
information about an IfcProduct. It allows for multiple
geometric shape representations of the same product.
The IfcRepresentation defines the general concept of
representing product properties. (IAI, 2006).
IfcPlacement locates a geometric item with respect to
the coordinate system of its geometric context. It has
two attributes called Location and Dim, where Location
refers to the geometric position of a reference point such
as the center of a circle, of the item to be located, Dim
refers to the space dimensionality of this class and is a
gbXML
In order to compare with IFC approach, the same
examples are given in gbXML approach.
gbXML is developed based on XML, which captures
data information representation but not the
relationships among them.
Fig.2 shows gbXML schema of geometry information
representation. All the geometry information imported
from CAD tools are represented by the "Campus"
element. The global child element "Surface" represent
all the surfaces in the geometry. There are several
attributes defined in "Surface" such as "id and
"surfaceType". Every "Surface" element has two
representations of geometry, "PlanarGeometry" and
"RectangularGeometry". They both carry the same
geometry information. The purpose of this is to
double-check whether the translation of geometry
from the CAD software is correct or not.
Every "RectangularGeometry" has four
"CartesianPoint" elements which represent a surface.
Every "CartesianPoint" has a three dimensional
representation, three coordinates (x,y,z).
Below is an example of a partial XML file generated
by gbXML with surface type "Exterior Wall".
"RectangularGeometry" defines the starting point of
this surface. "PlanarGeometry" defines all the
coordinates. Again, there are only fives levels to
transverse to get the all the coordinates of an "Exterior
Wall" location. It is also easy to add up other surfaces
according to the schema defined in Fig.2. In addition,
every polyloop, which contains a list of coordinates
that makes up a polygon in three-dimensional space,
follows a right-hand rule defining the outward normal
of a surface (Mazzeo 2011).
IfcDimensionCount object, derived from the
dimensionality of the location. IfcPlacement has three
subtypes: IfcAxis1Placement, which defines the
direction and location in three dimensional space of a
single axis. IfcAxis2Placement2D is used to locate and
originate an object in two dimensional spaces and to
define a placement coordinate system.
IfcAxis2Placement3D is used to locate and originate an
object in three dimensional spaces and to define a
placement coordinate system.

Hence, a wall gains its geometric position and

orientation by virtue of a reference to
axis2_placement (IfcAxis2Placement) that in turn
references a cartesian_point (IfcCartesianPoint), several
directions (IfcDirection) and its starting point
(IfcVirtualGridIntersection). IfcCartesianPoint has an
attribute called Coordinates, which is a list of 1 to 3
IfcLengthMeasure objects. This is where the
coordinates are represented (Mazzeo 2011).

Sensor information

Fig.3 shows the UML diagram of the IFC schema
representations of sensors and sensed data using
temperature and CO2 parameters as examples. An
IfcSensorType defines a particular type of sensor which
is used for detection in a control system such as a
building automation control. Parameters of the sensors
are specified through property sets that are enumerated
in the IfcSensorTypeEnum data type. IfcSensorType has
an attribute called PreDefinedType, which is an object
of IfcSensorTypeEnum. IfcSensorTypeEnum defines the
range of different types of sensor that can be specified.
A temperature sensor and CO2 sensor type are instances
of IfcSensorTypeEnum. The usage of IfcSensorType
defines the parameters for one or more occurrences of
IfcDistributionControlElementType, which inherited
from the IfcDistributionElementType This is how
sensors are connected with the equipment.
Here is an example of how the sensor values are
represented. IfcPropertySingleValue is one of the
subtypes of IfcSimpleProperty. It has two attributes:
NorminalValue and Unit. The NorminalValue is an
object of IfcValue, while Unit is an IfcUnit object,
where "parts per million (ppm)" is stored. IfcValue is a
SELECT type for selecting between more specialized
As shown in Fig.2, gbXML has an element named
Meter which is a description of a resource
measurement. Any measured data can be defined in
this element. It has children elements: Name,
Description, UtilityRate and others."Name" defines a
name of sensor, while"other" could contain the value
and unit of this sensor and it has any occurrences.
Using the same temperature and CO2 parameters, the
generated XML file could be as follows:
There are only three levels from root element
"gbXML" to data element"value". In addition, there is
no need to contain"UtilityRate" element in "Meter"
element if there was no UtilityRate information.
Furthermore, a simple XML stylesheet can extract the
information from the above XML file. Hence, to store
and obtain the sensor data using gbXML is relatively
simple and straightforward (Mazzeo 2011).
types IfcSimpleValue, IfcMeasureValue and
IfcDerivedMeasureValue. Attributes of
IfcMeasureValue include
IfcThermodynamicTemperatureMeasure and
IfcRatioMeasure which are REAL types.
IfcThermodynamicTemperatureMeasure is where the
sensed temperature value is stored, while
IfcRatioMeasure is where the sensed CO2 value is
stored (IAI, 2006).

Fig. 1 UML diagram of the relationship between wall and its dimension in IFC
 Fig. 2 Geometry and sensor representations in gbXML

Fig. 3 UML diagram of the relationship between sensor and sensed data in IFC
5. Pros and Cons of the Technical and Semantic Implementations in IFC and gbXML

The pons and cons of the technical and semantic implementations in IFC and gbXML can be analyzed
from the following two aspects:

Firstly, IFC adopts a comprehensive and generic approach to represent an entire building project. From
IAI online information website, it shows a holistic approach of IFC representation, covering domains
from building construction to building operation. IFC representation was also extended in the building
commission domain and implemented in several cases studies. The application of gbXML deployed by
Green Building Studio Inc. is currently only on the energy simulation domain. Users can upload a well-
formatted gbXML file to get a quick summary of simulation results from DOE-2 based on contextually
related assumptions. It is also possible to get input files for EnergyPlus and eQuest from GBS after the
simulation runs. However, gbXML has the ability to carry building environmental sensing information.
gbXML schema can be extended for certain purposes such as conducting lighting simulation. In terms of
geometry, the generic approach of IFC has the ability to represent any shape of building geometry, while
gbXML only accepts rectangular shape, which is enough for energy simulation.

Secondly, IFC uses a "top-down" and relational approach, which yields in a relative complex data
representation schema and a large data file size. gbXML adopts a "bottom-up" approach, which is flexible,
open source, and a relatively straight-forward data schema. The "top-down" approach can trace back all
the semantic changes when one value of the element in the schema changed. Ideally, it has the ability to
maintain semantic integrity automatically. However, it is very complex to program and be implemented in
software. The "bottom-up" approach has less layer of complexity. This approach has proven successful in
offering web-based simulation service (notably Green Building Studio) for the industry.

6. Identification and Analysis of Interoperability Issues between Current Dominant

Building Simulation Tools

In this section, the interoperability issues between various dominant building modeling and simulation
tools are analyzed in terms of the distortion of building model information (e.g., definition of thermal
zones, building materials and HVAC system) and the loss of geometric precision.

All the tools investigated in the study are current dominant tools in the building modeling and simulation
field, including DesignBuilder, Energyplus, eQUEST, Autodesk Revit, Autodesk CAD, Google Sketchup
and Autodesk Ecotect. Different types of elements in the building model, such as building openings,
adiabatic component blocks, external louvres and air walls, are used as illustrations to compare the
methods utilized in different tools in handling the building models imported from other sources, which is
useful to analyze the capabilities, limitations and characteristics of these tools.

The evaluations of the investigated tools are summarized and tabulated in detail for the reference of
further study in solving these interoperability issues.

DESIGN BUILDER (DB) V2.3
Design Builder 3D GUI
View from Building Level
(Openings on the building surfaces)
(Holes, doors, windows, vents)
GOOGLE SKETCH UP (OPEN STUDIO
ENERGYPLUS V6.0 [DXF Output] Problem EXPLANATION
PLUG IN)
Generation of sub-surfaces and
EnergyPlus model exported from Design
Google Sketch up model exported from associated model elements for
Builder
EnergyPlus building openings of non-
(3D DXF output after a simulation run is
(3D view with X-RAY surfaces) rectangular geometry developed in
shown)
DB and exported to EnergyPlus

Maximum number of vertices

accepted by EnergyPlus for
building openings in the form of
holes, doors, windows, and vents
is limited to 4 only. Since these
Plenum zone objects (created in Design Builder)
are exported as
FenestrationSurface:Detailed.
Such a limitation results in
triangulation of surfaces with more
than four vertices (such a polygons
and circles). Polygonal surfaces
are sub-divided into multiple
Office module surfaces with vertices of three.
Each subsurface is exported as an
individual object (with discrete
attributes) inside EnergyPlus
simulation model. Loss of
geometric precision is also
observed for circular geometries
(as seen in current example). The
user will experience increased
number of object entries (than
originally created in Design
Builder) after exporting the
simulation model from Design
Total of 14 Total of 14 Builder environment to
different building different building EnergyPlus. Detailed geometric
opening surfaces opening surfaces analysis of building openings can
Total of 3different be done after running an
building opening EnergyPlus simulation with
surfaces Output:surfaces:Drawing class
including DXF report type.
Similar analysis can be carried out
by exporting EnergyPlus
DB 3D GUI: Openings inserted into ceiling EnergyPlus 3D DXF Output: Rectangular Google Sketch-up X-ray view of building geometric model to Google
surface elements openings (same geometry), polygonal openings surfaces. EnergyPlus model has building Sketch-up environment via Open
Rectangular (4 vertices), polygonal (finite (triangulated into multiple elements of 3 openings of different geometries with polygonal Studio plug-in. Hidden surfaces
number of vertices) and circular (infinite number vertices), circular openings (triangulated into and circular surfaces divided into multiple sub- can be viewed by choosing X-ray
of vertices). multiple surfaces if 3 vertices + loss of surfaces with 3 vertices (triangulation process). surface view option.
geometric precision)

DESIGN BUILDER (DB) V2.3
Design Builder 3D GUI
View from Building Level
(Adiabatic component blocks)
Adiabatic blocks with complete
geometry attached to building
external surfaces
DB 3D GUI: Adiabatic component blocks
attached to external building envelope surfaces
to simulate adiabatic relationship in terms of
heat flows through the related surface.
ENERGYPLUS V6.0 [DXF Output]
EnergyPlus model exported from DB. 3D DXF
output after a simulation run is shown
Missing lateral surfaces of
rectangular prisms (defined for
adiabatic component blocks)
EnergyPlus 3D DXF Output: Rectangular prisms
adjacent to building envelope are missing a
number of lateral surfaces (which are not in touch
with the actual building surfaces).
GOOGLE SKETCH UP (OPEN STUDIO
PLUG IN)
Google Sketch up model exported from
EnergyPlus
(3D view with X-RAY surfaces)
Lateral surfaces of adiabatic blocks that are
attached to external building surfaces are
always exported correctly.
Google Sketch-up X-ray view of building
surfaces. Adiabatic blocks are not exported in
their full geometry, missing lateral surfaces can
be seen from the overall building model view.
Problem EXPLANATION
Missing lateral surfaces of
adiabatic blocks after export to
EnergyPlus
Rectangular adiabatic blocks
created in Design Builder lack
some lateral surfaces after
being exported to EnergyPlus.
Total number of surfaces
generated inside DB is not the
same as the model exported to
EnergyPlus. However, lateral
surfaces adjacent to external
building envelope are always
exported successfully and
adiabatic adjacencies are
always preserved. Solar
shading and solar heat gain
processes are not affected by
missing adiabatic block
surfaces due to intrinsic
functionality of these surfaces:
blocking all sorts of heat flux
through the related surfaces.
One option to avoid such
geometric inconsistencies is to
manually assign adjacency
properties to each related
building surface inside DB by
selecting Adjacency as 4-
Adiabatic at surface level.
 DESIGN BUILDER V2.3
Design Builder 3D GUI
Rendered and Shaded View from Building
Level (Local shading devices - external louvres)
External louvres parametrically
defined in DB (without material
thickness)
DB 3D GUI: Local shading devices defined
through parametric design data entries regarding
number of louvre blades, vertical spacing, blade
angle, distance from the window, blade depth,
vertical offset from window top frame, and
horizontal window overlap.
ENERGYPLUS V6.0 [DXF Output]
EnergyPlus model exported from DB. 3D DXF
output after a simulation run is shown 3D
rendered view
External louvre geometry is
correctly exported to EnergyPlus
without loss of precision
EnergyPlus 3D DXF Output: Rectangular
external louvres are exported as 2D surfaces.
No practical restriction (number of allowed
vertices is 120) is seen on the total number of
vertices to define element geometry.
ENERGYPLUS V6.0 [IDF Editor]
EnergyPlus IDF Editor
(Text-input view)
External louvres exported to
Shading:Building:Detailed class which
restricts parametric modifications
EnergyPlus IDF Editor Text-input: External
louvre elements are exported as
Shading:Building:Detailed objects in
EnergyPlus environment. No thermal
calculations are possible for such objects.
Parametric design data entries are lost and not
available for parametric simulation studies.
Problem EXPLANATION
External louvres elements lacks
parametric data entries
External louvres parametrically
defined in DB are exported
correctly to EnergyPlus in terms
of element geometry (with
maximum number vertices up to
120 practically no limit).
However, external louvre
elements have no thickness and
treated as 2D surfaces only. Such
elements are also exported to
Shading:Building:Detailed
class of EnergyPlus which
restricts parametric variations (on
overall geometry as well as tilt
angle) as in the case of
Shading:Overhang class. This
situation indicates the loss of
parametric data entry options
from DB to EnergyPlus.
Shading:Building:Detailed class
only allows variations of absolute
coordinate points (locations) of
an object in addition to
transmittance of the surface.
Additional geometric calculations
are needed to parametrically
modify overall surface geometry
(and tilt angle of louvre blinds)
and run iterative simulations for
shading analyses.

AUTODESK REVIT Architecture 2011
AutoDesk REVIT
Plan View + Section View
Plan View
Room Separation line between
office space and the meeting
room
Section View
Room objects defined to represent thermal
zones/blocks as the basic units of energy simulations in
Design Builder and EnergyPlus programs. Room 7 is
created by the use of a Room Separation Line between
Office Space and Meeting Room. This line should
represent air wall in E+ and virtual partition in
Design Builder environment.
AUTODESK REVIT Architecture 2011
(gbXML)
AutoDesk REVIT gbXML Export View
(gbXML Rooms & Analytical Surfaces 3D
Views)
Room 7 is successfully
differentiated from the
surrounding room objects
3D View Rooms Separation surface is also
in place as seen from
analytical surfaces
analysis
3D View Analytical Surfaces
AutoDesk REVIT gbXML Export Analysis:
Room 7 is successfully differentiated from the
immediate surrounding room objects by the
use of a separation surface (defined by
drawing a separation line). It can be seen that
building model includes Room 7 as well as
analytical surfaces include the separation
surface.
DESIGN BUILDER V2.3
Design Builder 3D GUI
View from Block Level
Room separation surface is
missing. Thermal zone defined by
Room 7 is ignored and merged
with the adjacent meeting room
(Room 6)
3D Block View from DB
Exported gbXML model to Design Builder
v2.3 does not include room separation
surface. Room 7 is not a discrete object but
unified/combined with meeting room. Total
number of thermal zones decreases from 3
to 2 where Room 7 (office space) is
ignored.
Problem EXPLANATION
Room surfaces (created by
separation lines) are ignored
causing merging of adjacent
thermal zones
Room objects identified by
room separation lines (and
surfaces) which are also used
to separate two adjacent zones
by air surfaces (without a
thermal mass) in Design
Builder (virtual partitions) and
EnergyPlus (air walls)
environments cannot be
successfully exported to
Design Builder v2.3 through
the use of REVIT generated
gbXML models.
Although analysis of gbXML
building model shows
existence of such room
surfaces, it is seen that Design
Builder gbXML import
functions cannot differentiate
separation surfaces causing
merging/combination of the
two thermal zones that are
supposed to be divided by a
separation surface. Loss of
model detail is observed by
missing thermal zones.
Building model exported from
Design Builder to EnergyPlus
also includes merged thermal
zones (or lacks air walls).

AUTODESK REVIT Architecture 2011 DESIGN BUILDER V2.3
Design Builder 3D GUI
AutoDesk REVIT 3D Rendered + Section View
View from Building Level
Axonometric View from SE
3D Rendered Exterior View from SE External face of the roof object is
exported as a detached shading
element to Design Builder
Room object bounded by inner
surfaces of flat roof and roof
objects in REVIT modeling
environment
Section View
South Elevation detail
Room object (equivalent of a thermal zone) is bounded Room object geometry is exported
by regular REVIT objects of an external wall, floor slab successfully to Design Builder environment.
(ground), and a roof having certain thicknesses. Room volume is preserved. Internal surfaces
According to room object creation conventions, object of floor slab and flat roof are defining the
boundaries (of floor and roof) are specified from the thermal zone geometry. The thickness of the
internal face (faces in touch with interior volumes) of the flat roof (external to room object/thermal
related REVIT objects. Therefore, thermal zone defined zone) is ignored or missing. Exterior face of
by a room object is the air volume enclosed by inward- the flat roof object is exported as a 2D stand-
facing surfaces of floor slab and flat roof objects (as in alone (detached) shading element (w/o a
the case shown above). thickness). 2D roof element is elevated from
the exterior face of the thermal zone
(generating an air gap between these two
objects).
GOOGLE SKETCH UP (Open Studio
Plug-In)
Google Sketch up model exported from
EnergyPlus
(3D shaded view and Elevation with X-Ray
surfaces)
3D View (Shaded)
Air gap between the detached
roof surface (defined as a stand-
alone external shading element in
EnergyPlus) and actual thermal
zone
Elevation (w/ X-Ray Surfaces)
Geometry of the EnergyPlus model after
being exported to Google Sketch Up.
External roof surface is also seen as a
detached shading element floating above the
actual roof surface (defining external
boundary of the thermal zone defined).
Problem EXPLANATION
Roof objects of REVIT Model
lacks thickness (lateral
surfaces)
Flat roof elements (of REVIT
Model) that are used to define
room objects lacks thickness
(or 2D lateral surfaces) after
being exported to Design
Builder environment. Internal
faces (inward-facing) of such
elements are correctly used as
room bounding surface (or
roof of thermal zones).
However, external faces
(outward-facing) are exported
as detached, stand-alone
shading surfaces that are also
elevated from the actual
thermal zone with a distance
from the external roof face.
In other words, thickness of
REVIT roof elements is
ignored, lateral faces are
missing, one of the remaining
roof surface (inward face)
forms the thermal zone
boundary, and the other
(outward face) is floating
above the thermal zone.
Floating 2D shading element
can be deleted. Under such a
condition, roof eaves will also
be deleted and should be re-
drawn inside Design Builder
so as to simulate their shading
effects. Keeping the entire
floating roof surface will not
be reasonable due to the air-
gap between the thermal zone
beneath.
 AUTODESK REVIT Architecture 2011
(gbXML)
AutoDesk REVIT gbXML Export View
(Analytical Surfaces Elevation and 3D View)
Elevation View
Inner face of the floor slab
element is projecting out to touch
the outer face of the ext. wall
3D View
AutoDesk REVIT gbXML Export Analysis: Visual
analysis of the analytical surfaces exported from
REVIT Model as gbXML file indicates that internal
surface (inward-facing) of the floor slab (tagged as
an external element) projects to the outer surface of
the ext. walls. However, room object geometry is
bounded by the inside surface of the ext. walls. This
situation denotes a possible discrepancy in the
exported floor slab geometry.
DESIGN BUILDER V2.3
Design Builder 3D GUI
View from Building Level
3D View (zooming to SE corner)
Unused shading element
(inherited from Revit floor slab
element) attached to ground
surface
3D View (SE corner seen from the bottom)
Parts of the floor slab projecting out from
the internal geometry is identified as
external, detached shading surfaces (and
attached to the ground, z=0 elevation) by
Design Builder. A continuous strip of a
shading element is seen at the ground level.
Such an element has no functionality to the
building model analyzed with Design
Builder.
GOOGLE SKETCH UP (Open Studio
Plug-In)
Google Sketch up model exported from
EnergyPlus
(3D shaded view)
3D View (Shaded)
Ring of unused floor surfaces
(identified as shading surfaces
attached to ground all around the
building model)
Geometry of the EnergyPlus model after being
exported to Google Sketch Up. Same external
shading surface attached to the ground is
exported to EnergyPlus model. The unused
surface here is seen as ring encircling the
building perimeter. The distance between the
strip of unused shading element and external
wall surface of the thermal zone is equal to
ext. wall thickness (if room objects are defined
from interior face) of half of it (if room objects
are defined from wall centroid).
Problem EXPLANATION
External floor objects of REVIT
Model generates redundant
geometry (unused shading
elements)
Parts of the external floor slabs
that are outside the room
boundary definition surfaces (such
as internal surfaces of walls) are
exported as redundant ground
attached shading surfaces. These
surfaces have no use in the
simulation model. Their existence
increase models geometric
complexity. They can be safely
removed from the model.
However, such a post-processing
requires time and extra effort to
complete geometric modeling
phase of the entire simulation
activity.
Outward-facing surface of the
external floor slabs is totally
ignored and thermal zone is
assumed to be in contact with the
ground surface through internal
surface of the floor slab. Slab
thickness is not subtracted from
the zone volume. Thickness of
floor slab construction assembly is
not effective to geometric model
and only used for heat balance
equations (taking floor surface
area as a geometric input data).

AUTODESK REVIT Architecture 2011
AutoDesk REVIT 3D Rendered + Plan View
3D Rendered View Room object encircled by another
room object in REVIT model
Plan View
In this REVIT model, Room 11 is placed inside of
another room object (Room 10). Therefore, Room
11 has no surface facing exterior environment. All
bounding surfaces are internal (partition walls).
Room 11 is totally encircled by Room 10 which has
continuous floor and roof surfaces around Room 11.
AUTODESK REVIT Architecture 2011
(gbXML)
AutoDesk REVIT gbXML Export View
(gbXML Rooms 3D & Analytical Surfaces
roof plan)
3D View Rooms
Encircling Room 10 is present in gbXML
model. Room 10 floor & roof surfaces are
fragmented into multiple triangular and
trapezoidal sub-surfaces
Plan View Analytical Surfaces
REVIT generates a gbXML model of the
building with equal number of room objects
(thermal zones). Horizontal bounding
surfaces for all rooms except Room 10 are
rectangular. However, surfaces of Room 11
are a combination of triangles and
trapezoids so as to cope with the non-
homogenous nature of such surfaces.
DESIGN BUILDER V2.3
Views from Building Level
(Axonometric + Rendered Perspective)
Axonometric Model View
Missing thermal zone in Design Builder.
Remaining zones are assumed to be
exposed to outside conditions
Rendered Perspective View (w/ shadows)
Design Builder import functions cannot create
the whole geometry of Room 10 (enclosing
Room 11). Therefore, building simulation
model misses the entire Room 10 after being
exported to Design Builder environment.
Furthermore, with the omission of Room 10
internal surfaces of remaining zones are
assumed to have external adjacencies.
Problem EXPLANATION
Room objects enclosing other
room objects are missing in after
Design Builder export
Room objects
enclosing/encircling other room
objects cannot be successfully
exported from REVIT medium to
Design Builder through the use of
gbXML export schema. Although
enclosed room objects are
exported without lack of
geometric detail, geometry of
enclosing room objects cannot be
identified. This situation results
in entire omission of enclosing
room objects.
Furthermore, with the omission
of such room objects/thermal
zones, remaining thermal zones
are assumed to have all surfaces
adjacent to outside/exterior. The
structure of the entire simulation
model is altered drastically.
Room objects are not transferred
as thermal zones of a single
building block conversely they
are considered as distinct building
blocks.
Although both concave and
convex room geometries are
successfully exported to Design
Builder environment, torus-like
room geometries (having non-
homogenous floor and roof
surfaces enclosing internal
objects) which requires extensive
triangulation cannot be identified
as thermal zones.
 AUTODESK REVIT Architecture 2011 AUTODESK REVIT Architecture 2011
AutoDesk REVIT Plan Views 01 AutoDesk REVIT Plan Views 02
Plan Views Plan Views
Room external wall type: Basic Wall 6
Room volume computation at wall finish
Room volume computation at wall center line Room external wall type: Basic Wall 12
In REVIT modeling, volume of room objects In REVIT modeling, external wall types can
(representative of thermal zone air volumes) can be be selected to be at any thickness. For
computed either by accepting an external geometric instance, in the above case, modeled room
boundary lying at the wall finish (inner face of external wall types are 6 thick basic wall and
external walls) or at wall center (half wall thickness). 12 thick basic wall. Such a selection will
naturally affect external footprint of the
building without any change in internal
useable floor area.
DESIGN BUILDER V2.3
Views from Block and Zone Level
(Plan View + Axonometric View)
External Dimension = 15.02 m
Plan View (Block Level)
Internal Dimension = 15.00 m
Block wall thickness = 0.1 m
Axonometric View (Zone Level)
Irrespective of room area computation method
(wall finish/wall center line) or ext. wall type
(6/12 basic wall), Design Builder only
assume room geometry to be defined by internal
face of the ext. walls ignoring the wall
thicknesses. Internal dimensions and associated
volumes are used for calculation. Block wall
thickness is set to a standard of 0.1m.
Problem EXPLANATION
Room volume computation
method and wall thickness
information are not exported
from REVIT to DB
There exists no relationship
between room area
computation method and
selection of external wall type
(thickness of the walls) with
exported room object
attributes in terms of zone
geometry. Irrespective of such
selections, Design Builder
always accepts room object
external boundary lying at the
wall finish and computes
thermal zone volumes without
external wall thickness
information.
Therefore, the only effective
parameter is the length and
width of the room object when
measured from inside wall
finish/surface. Design builder
ignores wall thicknesses and
such information is not
visualized at zone level. For
block level visualization,
Design Builder assumes a
constant wall thickness of
0.1m no matter what type of
wall is selected during REVIT
modeling phase. Block level
wall thickness is only
functional for visual analyses
and has no effect on thermal
calculations.
On the other hand, wall
thicknesses due to assumed
construction assembly is not
visualized but taken into
account during thermal
calculations.
 AUTODESK REVIT Architecture 2011 &
(gbXML)
AutoDesk REVIT Plan View &
AutoDesk REVIT gbXML Export 3D View
Plan View
REVIT separation lines are exported as
separation surfaces to gbXML building model
gbXML model view
shows 4 different
3D View Rooms
thermal zones
successfully separated
Room 6, 7, and 9 are separated from each other
by the use of separation lines. There exist 4
different room objects defined in Revit Model.
DESIGN BUILDER V2.3
Views from Block and Surface Level
(Axonometric)
Axonometric Block View
Axonometric Floor Surface View
Separation lines cannot be successfully
exported to Design Builder. Instead rooms 6,
7, and 9 are combined into a single thermal
zone. Internal partitions create undefined floor
areas.
GOOGLE SKETCH UP (Open Studio Plug-In)
ENERGYPLUS V6.0 [IDF Editor] &
Google Sketch up model exported from EnergyPlus
EnergyPlus IDF Editor (Text-input view)
3D shaded View
IDF Text Input for lateral partition surfaces
IDF Text Input for frontal partition surfaces
Analysis of EnergyPlus model indicates that some
surfaces (frontal) of partitions are assumed to be
facing outdoors and regarded as ext. walls whereas
others are counted as indoor partitions (lateral
surfaces).
Problem EXPLANATION
Unsuccessful export of
separation lines causes model
inconsistencies in area
calculations outdoor adjacency
Room objects created by the
use of room separation lines
cannot be successfully
exported from REVIT model to
Design Builder and EnergyPlus
environment (as analyzed
before). Consequently, each
and every room object cannot
be transformed to a
corresponding thermal zone in
energy simulation programs.
However, partition walls
connecting separation lines to
the nearest internal/external
walls are exported (these are
referred as remaining
partitions. The remaining
partitions are not treated as
hanging partitions by DB,
instead their footprints are
subtracted from roof and floor
surfaces causing mismatch in
floor area calculations.
Furthermore, slots created by
such partitions are treated as
narrow external environments.
However, exposing to such
external conditions is also
partial. Such that frontal
surfaces of partitions are
counted as external walls
facing outdoors whereas lateral
surfaces of the same partitions
are counted as internal to the
zones with no exposure to
outdoors. Such partial exposure
assignments are unreasonable,
and increase model complexity
 AUTODESK CAD 2011 AUTODESK ECOTECT ANALYSIS 2011 AUTODESK ECOTECT ANALYSIS 2011 Problem EXPLANATION
Lack of layer information and
AutoDesk CAD DXF Views AutoDesk Ecotect Analysis Views 1 AutoDesk Ecotect Analysis Views 2
curve line process in Ecotect

Ecotect should include layer

information in the importing
process, users should be
allowed to decide which layer
is useful and should be
imported. In this way, some
layers in DXF can be ignored
when importing to Ecotect,
such as construction line
layers. Of course, it also
requires users to draw the
model in CAD carefully and
systematically to separate
layers by different objects and
functions.
Perspective views Perspective views
Different lines and surfaces may represent only one When the model is imported into Ecotect, Ecotect should develop a
object. although there is a function called remove method to process arc or
duplicated surfaces, it fails to remove spline to be curve line or
duplicated lines, which can be the construction polyline that composed with
line of the DXF model. short straight lines instead of
Perspective views
decompose the originally arc
to numerous separated short
When importing the DXF model to Ecotect, the
straight lines.
arc (construction line) in CAD is decomposed
into short straight lines. On the contrary, the
Overall, the DXF import
rectangle surfaces are imported correctly.
function in Ecotect is useful
when you try to import
Red line represents the construction line; furniture, plants, landscape or
Blue line represents the upper surface boundary; any other object model that
Green rectangles represent the curve surface of the does not affect the indoor
object. thermal performance; or the
objects that has relatively
consistent surface properties
which can be set as
homogeneous material that has
limited influence on thermal or
In CAD modeling, people get used to draw additional When importing the DXF model to Ecotect, duplicated and overlapped lines can be produced. First lighting performance analysis.
lines in different layers for convenience. It may cause because the construction line that should have been deleted from the model is imported as an object into For building zones, it is better
the problem that several lines or surfaces represent Ecotect; second because the curve line (such as arc or spline) is decomposed and processed as multiple to draw it in Ecotect using
one single object. This problem will not cause trouble short straight lines in Ecotect. floor plans, elevations and
for visualization purpose, but may cause trouble when Although lines do not affect built environment analysis in Ecotect, it makes the model redundancy and sections based on zone
it is imported into object-oriented programs, such as the import process can be slow and even do not response. concepts.
Ecotect.
 AUTODESK REVIT Architecture 2011 &
(gbXML)
AutoDesk REVIT 3D Model View &
AutoDesk REVIT gbXML Export 3D View
3D View Revit Model (continuous single surface
for the intermediate floor)
3D View Rooms (floor surface can be seen within
gbXML model view)
Intermediate floor slab/object between 1st and 2nd
floors is defined as a single continuous surface
having adjacency conditions for both interior-
interior and exterior-interior. Floor object type is
defined as interior within Revit modeling since
only single type definition can be made here.
eQUEST v3.64
AutoDesk Revit Model in gbXML format
exported to eQUEST v3.64(through Green
Building Studio desktop client)
3D View from eQUEST graphical modeling
interface
After exporting the gbXML model to
eQUEST, its seen that part of the intermediate
floor having exterior boundary conditions is
totally missing from the building model.
Whereas, detailed analysis showed that
internal floor parts are successfully exported.
ENERGYPLUS V6.0 [DXF Output]
EnergyPlus model exported from DB. 3D DXF
output after a simulation run is shown 3D
rendered view
3D View from AutoCAD DXF output from
EnergyPlus simulations
After a simulation run, EnergyPlus warns the user
with specific error logs indicating that no-floor
object exists for the related thermal zones of the
model (e.g., Zone SP-6-Room input doesnt
appear to have any floor surfaces).
The same model exported to Design Builder v2.0
(as gbXML) and then to EnergyPlus (with IDF
conversions). DXF output analyzed after a
simulation run (with EnergyPlus) indicates that
external floor surfaces are also missing from the
building model.
Problem EXPLANATION
Unsuccessful export of external
floor surfaces from REVIT to
energy simulation tool with
gbXML format
The special floor slabs that have
both interior-interior and interior-
exterior boundary/adjacency
conditions can be defined with
multiple but jointed surfaces
separately created for interior and
exterior parts. Alternatively, such
floor slabs can be defined with a
single continuous surface (which is
the most common and efficient
method of floor object creation
within Revit modeling
environment). However, when
floor slabs are defined with a single
surface, only single Revit object
function type assignment can be
made (it should be interior or
exterior but not both at the same
time). Under such conditions,
exporting Revit models to eQUEST
or EnergyPlus results in missing
external floor surfaces from the
building model if floor object
function type is defined as interior
in Revit modeling. On the contrary,
defining such floors as exterior
results in missing internal floor
surfaces from the building energy
models.
BIM to BEM data structure should
automatically detect different
adjacency conditions observed on a
single surface and should
automatically partition the single
surface into multiple sections
compatible with different boundary
conditions. Otherwise BIM users
can end up with malfunctioning
building energy models exported
from Revit Modeling environment.
 AutoDesk Ecotect Model Exported From Design Builder v2.0 AutoDesk Ecotect Model Exported From Design Builder v2.0
Problem EXPLANATION
in DXF Format in RADIANCE Format
Effects of model import format
Ecotect 3D Model Views
Ecotect 3D Model Views (DXF vs. RADIANCE) in the
(Wireframe and rendered with cut-out perspective)
(Wireframe and rendered with cut-out perspective) Ecotect model quality

Comparisons regarding surface

geometry, vertex redundancies,
excessive triangulations, surface
material assignments, and thermal
zone information are given on the
left hand side. As a continuation of
this comparison, its also observed
that for both data formats imported
to Ecotect environment, all
different/distinct thermal zones are
combined into a single zone
covering the whole building.

With import with DXF format,

window and wall objects are
overlapping each other.
Furthermore, object relationship
between wall and window is not
that of a parent and child type
(there is no affiliation between
windows and walls). However,
with import in RAD format,
windows and walls do not overlap
each other by dividing the walls
into small pieces. Similar to DXF
format, there is no parent-child
3D Views from Ecotect model editing interface (wireframe above and rendered 3D Views from Ecotect model editing interface (wireframe above and relationship between wall and
with a cut-out perspective below) rendered with a cut-out perspective below) window object.
..

When, Ecotect model is imported from Design Builder v2.0 in the form of a
simple DXF format, there exist many redundant tangling surfaces. Many surfaces
are triangulated increasing the modeling complexity. Some surfaces for detailed
fenestration geometry are missing from the model. With DXF import, all surfaces
are assigned with a brick material (whether transparent or opaque). Thermal zone
distinctions and related information are missed in the imported model.
When Ecotect model is imported from Design Builder v2.0 in the form
of detailed RADIANCE format (*.RAD files), it is seen that fewer
redundant surfaces exists. With RAD import, window surfaces are
assigned with glazing materials (but still not the same specification
originally given in Design Builder program). Thermal zone distinctions
are also missed in the imported model.
 Design Builder v3.0.0.091
Glazing Data Input View - Main
Glass Pane Modeling Dialog Box Type 1
Model Inputs for Glass Pane: Broadband Type
Locked Library Data (User Modification
Prohibited) Model Data (User Modification
Allowed)
Glass Pane Definition with broadband values
(where transmission and reflection data is
averaged across solar spectrum (all wavelengths)
Thermal
+ to 0.40 microns)
Solar (Averaged)
Visible (Averaged)
Infra-Red (Averaged)
During glazing data input, Design Builder
normally does not allow users to modify default
libraries (locked library data). However, users
can create their own libraries and new objects by
starting from scratch or duplicating an existing
object (model library data)
Design Builder v3.0.0.091
Glazing Data Input View - Main
Glass Pane Modeling Dialog Box Type 2
Model Inputs for Glass Pane: Spectral Type
Locked Library Data (User Modification
Prohibited) Model Data (User Modification
Still Prohibited)
Glass Pane Definition with full spectral values
(where solar transmission and reflectance are
defined for a range of solar spectrum between 0.1
Thermal
+
Spectral Data (over 0.05micron intervals)
Model libraries can be updated by the users for
glazing data type of broadband (as explained
above). However, with spectral type data
modifications, updates, and adding new data to
the library are still prohibited even though data is
in model library (which should be customizable).
Design Builder v3.0.0.091
Glazing Data Input View Sub-Category
Glass Pane Modeling Spectral Input Dialog
Box
Model Inputs for Spectral Type
Data Type: Model Data
by only entering overall
performance parameters (such as
Duplicating existing object and converting
library type from locked to model have no effect
on the restrictions. Any modification is restored
to the original after refreshing the current screen.
Problem EXPLANATION
Customized glass pane definitions
for spectral data type are not
allowed for user defined material
libraries
Design Builder v3.0.0.091 program
doesnt allow users to create
customized glass material libraries
in which glass panes are defined
with spectral entries instead of
broadband (averaged) type.
Customization of default program
library is already prohibited,
however, when user creates a new
object from scratch or duplicates an
existing object then any
modification is allowed. Due to
current structure of design Builder
program such functionality is not
working properly for glass panes to
be defined with spectral data
entries.
This problem is not observed for
glass panes defined with broadband
data entries at the material level.
Users can also create new window
assemblies with simplified method
U-factor, SHGC, and Visible
Transmittance).
 Design Builder v3.0.0.091 Problem EXPLANATION
Limitations of assignment
different thermal zones into
HVAC template library and modeling input and assignment views
separate air loop of the same
HVAC type

Two HVAC templates for the same type When users select, Compact
HVAC design detail within
(Constant Volume DX Unitary Multi-zone) are
Design Builder (which is the
created (by duplication method) and current most common and easy to use
HVAC template library is updated. To create two type where template HVAC
different air-loop in the same building model, systems can be assigned to
different thermal zones are assigned to different thermal zones and later
HVAC templates (of the same type). However, exported in full detail to
analysis of simulation models to EnergyPlus EnergyPlus program),
developing multiple air-loops
revealed that only one of the assigned systems is
of the same type of system is
assumed for the whole building and all thermal not possible. Such as, users
zones are grouped in the same air-loop of this cannot create two different air-
single HVAC system. loops of constant volume DX
system, by grouping different
Design Builder HVAC Template Library thermal zones and assigning
them to different HVAC
objects of the same type.

However, different air-loops

can be developed for different
HVAC systems used in the
same building (such as
Constant Volume DX vs. VAV
terminal reheat).

Some other observations about

HVAC template assignments
are:
- If unitary single zone type is
assigned at the building level, it
will not be possible to defined
unitary multi-zone type for a
group if thermal zones selected.
- If unitary multi-zone is
assigned at the building level,
and unitary single zone for a
group of thermal zones, it is
also seen that building model is
Design Builder HVAC modeling input dialog boxes exported as all zones grouped
under unitary multi zone
HVAC topology.
Multiple air-loops of the same type of HVAC system cannot be created by thermal zone assignments when HVAC system design detail type is Compact
 AUTODESK REVIT Architecture 2012 eQUEST v3.64 Problem EXPLANATION
Geometrically irregular/floating
AutoDesk REVIT 3D Model View AutoDesk Revit Model in gbXML format exported to eQUEST
shading type surfaces
v3.64(through Green Building Studio desktop client)

Roof assemblies defined as

continuous objects with continuous
surfaces covering both actual roof
(over the thermal zones) and
shading (in the form of eaves)
functions generate problems when
exported to eQUEST through
gbXML data structure. Eave
sections of the roof are broken into
multiple surfaces with irregular
azimuth angles. eQUEST users
need to identify each irregular
shading type surface and correct
azimuth angle one-by-one in
eQUEST.

However, roof assemblies defined

3D Model View with roof assembly defined with a single, continuous surface 3D Model View with roof assembly exported with multiple irregular with multiple surfaces (for actual
surfaces for eave sections (defined as shading type surfaces) roof and the eave section) do not
experience such as a data export
problem. Second method is not a
usual modeling approach for
architects/designers working within
Revit environment compared to
continuous roof definitions which
create geometric problems on the
contrary.

3D Model View with roof assembly composed of multiple surfaces (for eave 3D Model View with roof assembly exported with correct geometry for
sections) eave sections (defined as shading type surfaces)

In Revit modeling environment, building roof assembly can be defined as a
continuous surface covering thermal zones underneath and extending outwards to
form eaves on the sides. Alternatively, same roof assembly can be defined as
separate/distinct multiple surfaces covering thermal zones, and forming eave
sections on different sides of the building.
Different roof assembly definition methods have different results when
exported to eQUEST environment (through gbXML format).
Continuous roof assembly is broken into multiple surfaces and the ones
assigned as shading type (for eave sections) are distorted and have
irregular geometry (irregular azimuth angles).
7. References

ASHRAE (2005). ASHRAE Handbook, Fundamentals Volume. Atlanta, GA.

Augenbroe, G. (1992). "Integrated building performance evaluation in early design stages." Building and
Environment 27(2).

Bazjanac, V. and T. Maile (2004). "IFC HVAC Interface to EnergyPlus - A Case of Expanded
Interoperability for Energy Simulation." Proceedings of the SimBuild 2004 Conference in Boulder, CO.

Bedell, J. and N. Kohler (1993). "CAAD Future." 423-435.

Dong, B., K. P. Lam, et al. (2007). "A comparative study of the IFC and gbXML informational
infrastructures for data exchange in computational design support environments." Proceedings: Building
Simulation 2007.

Faye C McQuiston, Jerald D Parker, Jeffery D Spitler (2005). "Heating, Ventilating and Air Conditioning
Analysis and Design." John Wiley & Sons, Inc.

Gauchel, J., S. Hovestadt, et al. (1992). "Building modeling based on concepts of autonomy." Proceedings
of AID 1992, Pittsburgh, PA.

ISO (1992). Product data representation and exchange part 1: Overview and Fundamental Principles

Lam, K., N. Wong, et al. (2004). "SEMPER-II: an internet-based multi-domain building performance
simulation environment for early design support." Automation in Construction 13(15).

Mazzeo, N. (2011). Chemistry, Emission Control, Radioactive Pollution and Indoor Air Quality InTech

Pohi, J. and I. Rep (1988). "An integrated intelligent CAD environment. Proceedings." 4th International
Conference on Systems Research, Informatics and Cybernetics, Baden-Baden, Germany.

Rutherford, J. (1993). " KNODES: knowledged-based design decision support. ." CADD Future.

Sanvido, V. (1992). "Linking levels of abstraction of a building design." Building and Environment 27(2).