Content uploaded by Timur Dogan
Author content
All content in this area was uploaded by Timur Dogan on Aug 30, 2015
Content may be subject to copyright.
Autozoner: An algorithm for automatic thermal zoning of build-
ings with unknown interior space definitions
Timur Dogan1, Christoph Reinhart1, and Panagiotis Michalatos2
1 Massachusetts Institute of Technology, Cambridge, USA
2 Harvard Graduate School of Design, Cambridge, USA
Abstract
In this paper we present a general algorithm to automatically convert
arbitrary building massing models into multi-zone building energy
models (BEM). The algorithm follows current guidelines for thermal
zone discretization of BEMs when actual interior space boundaries are
yet undefined. Envisioned applications are for rapid model generation
during schematic building design as well as for urban massing studies.
We present an argument that current recommendations for separating
core from perimeter zones effectively follow a straight-skeleton sub-
division. Following a step-by-step explanation of the procedure, a
number of example building shapes of varying complexity are shown
to demonstrate the algorithm’s robustness and suitability for automat-
ed multi-zone BEM generation. Going forward, it is recommended
that the algorithm is adopted by software developers to ensure more
consistent thermal model production within the building simulation
community.
Keywords: multi-zone energy modeling, automatic thermal zoning,
urban and schematic design.
1. Introduction
For decades modelers have implemented multi-zone thermal models to simulate ener-
gy use of buildings to inform construction and design processes. It is widely acknowledged
that the earlier such simulations are being used during design, the greater their impact on im-
portant design decisions can be [Schlueter and Thesseling, 2009]. It is therefore surprising,
that there exists very limited advice on how early design variants should actually be broken
up into discrete thermal zones. According to the literature [Bobenhausen, 1994] [Hirsch,
2010][BEMBOOK, 2014], a thermal zone should roughly correlate with the spatial subdivi-
sion of a building into rooms and spaces. To simplify the simulation and also the HVAC
(Heating ventilation and air conditioning) system layout, multiple rooms may be joined to-
gether into one zone if they share similar load profiles resulting from space use and solar
gains. However, the room layout that would provide the basis for such a subdivision is usually
unknown during the schematic design stage. ASHRAE 90.1 Appendix G hence provides a
brief guideline for this case, stating that a floor should be divided into a core and perimeter
region. The perimeter is defined as the space along the facade with a depth of five meters.
Further, perimeter spaces with more than one orientation should be subdivided proportionally.
The leftover region in the center of the floor forms the core [ANSI/ASHRAE/IESNA, 2013].
The motivation for dividing a building into thermal zones is that simulation programs
treat all zones as nodes within a thermal network with perfectly mixed air volumes attached to
them. If one falsely models a larger building as a single thermal zone, a localized heat surplus
that may occur during the winter near a south-facing façade may be absorbed by a space to
the north that is underserved by solar gains. As a consequence, the predicted energy demand
DRAFT
according to the one-zone thermal model will be dampened compared to a multi-zone model
of the same building since loads, solar gains and thermal mass effects may cancel each other
out. This can lead to significant load under-predictions [Smith et al. 2011], revealing the rele-
vance of a consistent zoning methodology in early design studies. Consistency also ensures
that the influence of generic thermal zoning on the simulation results remains the same when
multiple geometric variants are being explored. This consistency is especially desirable if a
building energy model is used for massing studies when interior space boundaries are neither
known nor under evaluation.
Figure 1 shows a series of increasingly complex floor plans that are divided according
to Appendix G using an algorithm that will be described in the following paragraphs. Figures
1 (a) and (b) show that complying with Appendix G is unambiguous and straightforward for
simple building shapes. These two floor plans correspond to the EnergyPlus Example File
Generator models [EERE, 2013] as well as the DOE reference buildings [DOE, 2013]. How-
ever, for more complex shapes such as (c) and (d), following Appendix G zoning rules quick-
ly evolves into a tedious and somewhat ambiguous process. Figure 1 (c') shows that subdivid-
ing perimeter spaces proportionally by façade orientation can get tricky in some regions due
to the asymmetric position of the courtyard. Finding the subdivision in a floor plan such as
(d), ceases to be practical by hand because of the number of zones one would have to draw as
shown in (d').
Figure 1: Floor plans zoned according to ASHRAE 90.1 Appendix G
To reduce the BEM setup time several researchers have implemented automatic zon-
ing algorithms into existing design tools. EQuest [Hirsch, 2010] and Bentley AECOsim
[Bentley, 2013] both come with a wizard for core-perimeter subdivision for simple geometric
shapes. Autodesk Vasari [Autodesk, 2013], a schematic design tool for architects, can auto-
matically split up a building massing into perimeter and core zones. Details of the zoning al-
gorithm and its implementation have not been publicly released. Reinhart et al. [2013] intro-
duced software with similar functionality. The software is, however, limited to simple and
strictly orthogonal shapes with a minimum floor plan depth, comparable to Figures 1(a).
Given the absence of a published, general and automatic zoning methodology, this
manuscript introduces a zoning algorithm, called the Autozoner. We propose that the propor-
tional space subdivision suggested by the Appendix G zoning guidelines can be related to a
topological skeleton of a polygon and that it is therefore possible to formulate a general and
DRAFT
robust algorithm to obtain Appendix G compliant space partitioning automatically. We de-
scribe a proof of concept implementation that is designed to convert an arbitrarily shaped ar-
chitectural massing model, represented by a closed poly-surface, into a multi-zone thermal
model that can be used by whole building energy modeling programs such as EnergyPlus,
TRNSYS and others [Crawley et al., 2000] [Klein, 1979] [ESRU, 2005]. After a detailed de-
scription of the algorithm, we test it on different shapes with varying complexity and examine
the automatically generated zoning subdivision. Finally, we show a proof of concept of how
the Autozoner can be integrated in current workflows.
2. Methodology
The following section is divided into three parts: Following a step by step de-
scription of the Autozoner algorithm, a testing procedure is described along with a
proof of concept implementation and simulation workflow.
Automated zoning:
Input: Based on the authors’experience in architectural practice and education, urban
and schematic design processes mainly produce three types of input geometry. During the ear-
liest stages, the buildings are modeled as a single volume (Figure 2(a)). This form of repre-
sentation helps the designer to understand basic morphologic features such as the massing and
the proportions of a design. It usually originates from a 2D drawing that is extruded. Another
very common representation involves ‘stacking’ floor-volumes. This adds a notion of ‘scale’
since it immediately allows one to read floor-to-floor heights from the model and it facilitates
the distribution of densities during the design process (Figure 2(b)). In a later stage the
stacked volumes can be further subdivided and differentiated by program/function such as
shown in Figure 2(c). Here, more complex spatial arrangements within a building can be de-
picted. Prominent examples might be split-levels or atria spanning over multiple floors. The
Autozoner algorithm supports all three input geometries. In the case of a single volume model
like shown in Figure 2(a), the input must be given as a list of closed poly-surfaces with one
volume per building. Then the algorithm begins with a floor-to-floor subdivision of the enve-
lope based on a floor height that is specified by the user. The floor-to-floor distance can be
given as array to consider varying floor heights. For the models that already have a floor- or
programmatic subdivision (Figure 2(b) and (c)), the user must be able to group the volumes
accordingly. This can be done with a tree data structure where each branch represents a user-
defined group (Figure 3). Figure 3(c) shows a data tree representation of the geometry shown
in Figure 2(c). The entire scene is grouped into buildings where each building has sub-groups
that reflect the different programs within it. The volumes representing the floors are stored
inside of these sub-groups. The organization (the structure and depth of the branches) of such
a tree is arbitrary and thus allows the user to pick any grouping schema. The algorithm stores
the given tree structure and reflects it in the outputs. Starting point for all following steps is
hence a data tree of arbitrary depth containing closed poly surfaces representing floor vol-
umes. For convenience and clarity it makes sense to convert this purely geometric data into
objects that allow us to attach further information to them and that facilitate querying the data
later. We therefore introduce two constructs called ‘unit’and ‘face’. A unit contains a floor
volume and its position in the input data tree. It further holds a list of all surfaces of the floor
volume in form of our ‘face’construct. Since we will produce essential steps of our zone sub-
division based on a 2D floor plan we must be able to distinguish between the faces that define
the floor volume. This can be done by simply checking their normal orientation. If the face-
normal points downwards we found a floor plate, if it points up we found a ceiling or roof.
All other normal orientations must then be walls or facades. We store this information in form
of a type label in each face. To correctly handle sloped surfaces we allow the user to specify a
maximum tilt angle to distinguish floors and ceilings from possibly tilted facades. For each
unit we then compute the 2D floor plan by collecting its faces labeled as floor plate, project-
ing them onto the XY-Plane (to eliminate slopes) and merge them with a boolean addition.
Figure 2: Typical modeling styles of massing models.
Figure 3: Data tree structure for the three possible input cases
2D Zoning: The next step is to subdivide each unit into thermal zones. We begin with
the perimeter and core zone subdivision of the 2D floor plan, as described by the previously
mentioned ASHRAE 90.1 Appendix G guideline. In the simplest case the core region can be
found by offsetting the outer edge of the floor plan. Then a search for the closest point from
the outer polygon vertices to the inner ones can yield the desired subdivision. This is shown in
Figure 4(a). For more complicated cases, the above-mentioned approach fails. Figure 4(b)
shows a convex floor plan with a core region that retreated completely from the left part of
the polygon due to a series of collapsing edges during the offset. It subdivides parts that have
good ‘core visibility’ as intended but leaves the entire left half undivided. However, with a
certain thickness of the remaining polygon-tip it might be desirable to split the tip into single
sided zones instead of a lumped region with access to multiple cardinal directions. This would
require a partition somewhere along the medial axis [Preparata, 1977] of the polygon. A me-
dial axis approximation is shown in Figure 4(c). However, the medial axis does not consist of
straight-line segments and can instead involve parabolic curves. This is not desirable since the
final output of the algorithm is a set of 3D thermal zones that should ideally consist of as few
planar surfaces as possible. Very similar to the medial axis, but involving just straight lines, is
the ‘straight skeleton’ that was first described by Aichholzer et al. [1996; Aichholzer and Au-
renhammer, 1996; Barequet et al., 2003]. The straight skeleton of a polygon, as shown in Fig-
ure 4(d), divides the polygon into one cell per outer edge and is thus fulfilling the requirement
of proportionally splitting the perimeter region by orientation. In order to obtain a core and a
valid thermal zone subdivision, a couple of simple steps have to be added. After the skeleton-
ization (Figure 5(a)), the algorithm produces the core region by performing an offset of the
outer and hole polygons (see Figure 5(b)). In step (c) the core overlap is removed from each
DRAFT
skeleton cell by a 2D boolean difference operation. If the thermal zones have to be strictly
convex, such as required by the ‘detailed’ radiation distribution algorithms of EnergyPlus and
TRNSYS, the resulting perimeter and core zones have to be further subdivided if they are
concave. Various polygon-partitioning techniques exist for this task and have been described
in detail [O’Rourke, 1998]. Since the resulting perimeter regions are guaranteed to be hole-
free, a simple split at each concave vertex to the closest point on the exterior edge of the pol-
ygon delivers the desired result (Figure 5(d)). The core regions, however, can consist of poly-
gons with holes. One simple example is a donut-shape floor plate with a circular core region.
Here, a triangulation and a subsequent diagonal-removal procedure is used to obtain strictly
convex zones [Hertel & Mehlhorn, 1983]. Enforcing convexity as described before can yield
perimeter regions without facade access or zones that are unrealistically small and narrow. It
is therefore important to split non-convex spaces only virtually by placing a partition that is
permeable for air and radiation. The result of the previous steps is a set of 2D regions for the
perimeter and the core of each floor plate. As underlying data structure we use a doubly con-
nected edge list (DCEL), a planar graph that allows efficient topological manipulation of our
core and perimeter cells [De Berg et al., 2000]
Figure 4:From a simple and limited to a general cell finding method based on Straight
Skeleton
Figure 5: Step by step visualization of the 2D zoning procedure
From 2D to 3D zones: The 2D core and perimeter cells resulting from the previous
steps have to be further processed to obtain the final 3D volumes that represent a thermal
zone. The simplest and fastest approach is to extrude the cells by the floor height. This how-
ever, is only possible, without significantly altering the building shape, if the facades of the
initial envelope are strictly vertical. In order to overcome this limitation, the algorithm can use
the floor volumes stored in each unit as a basis to cut out a zone volume with the correct fa-
çade geometry. In addition to the floor volume we need to construct a cutting volume. The
required procedure is shown in Figure 6(e) whereas Figure 6(a) to (d) depict the initial Auto-
zoner steps discussed above. In Figure 6(e) we query our DCEL data structure from the 2D
zoning step for all edges of each perimeter cell that have a congruent neighboring edge in an
adjacent cell. This yields only the interior edges of the perimeter zones. We then extract them
in form of a poly-line and extend the endpoints outwards. If the extensions intersect, we close
the polygon at the intersection point (This may happen in the case of two following convex
corners in our floor plan shape) otherwise we draw a line between the two endpoints. The ex-
tension is necessary to span beyond any outward tapering of the facade. Then we begin to ex-
trude our cutting volume to match the height of the bounding box of our currently processed
floor volume (Figure 6(f)). A boolean intersection of the floor volume and the cutting volume
follows as shown in Figure 6(g). Since the cutting volume might intersect in multiple regions,
e.g. in convex corner regions where another facade is in close proximity, we check the foot
print of each volume that is returned by the intersection and only add it to our list of zone vol-
umes if it corresponds to the perimeter cell region that we are currently processing. This
method, unfortunately does not guarantee convex volumes as a result. An example where this
method would yield a concave space is a floor volume with a facade that zig-zags up multiple
times. For our implementation we consider this an exception and rely on the user to prevent
such a case when zone convexity is a requirement.
Figure 6: Graphic representation of the main algorithmic steps
Adjacency: In urban scenes it is quite common that buildings touch each other and
not every face with horizontal orientation is a facade. Similarly, the programmatically subdi-
vided volumes (Figure 2(c)) have interior partition walls. A simple 2D example is shown in
Figure 7(a) where adjacent regions with interior walls are represented by a thick stroke. In
such a case the algorithm presented thus far would build perimeter cells at each inter-building
and program-separating partition such as shown in Figure 7(b). In 2D, a simple trick to avoid
this is to join all neighboring floor plans into a single one before the cellular subdivisions are
computed. Following the subdivision, we can use the original floor plans to crop the comput-
ed results to obtain core and perimeter cells corresponding to the original floor plans. The
cropping operation can produce perimeter cells without any exterior edge. However, by keep-
ing track of the type of cell and it's parent floor plan in our DCEL data-structure we can detect
these cells and merge them with neighboring perimeter cells (if there is no neighboring pe-
rimeter cell we merge with the core). The result is a 2D cellular subdivision as shown in Fig-
ure 7(c). The dotted lines indicate edges that have been removed during the merging.
DRAFT
Figure 7: Zoning for adjacent regions.
In 3D the adjacency problem is far more complex. We must be able to detect horizon-
tal adjacencies of our units in order to selectively join only neighboring floor plans. Thus, we
have to test for a potential overlap of all unit faces with all other unit faces labeled as
wall/facade. We first check if the face pair resides in the same plane and has opposite face
orientation. If both tests are positive we compute a 2D polygon intersection. If we encounter
an intersection and the two faces overlap both parent units are adjacent. Then, we loop over
each unit, join its floor plan with all floor plans in adjacent units, compute the 2D zoning and
then crop the result back as described for the simple case in Figure 7. Figure 8 visualizes the-
se steps. For the input shown in (a) the final result (c) is computed. The core volumes are
shown separately for clarity in (b). The process is highlighted for the face f1 in (d) and its par-
ent unit u1 shown in (a). The adjacent floor plans are merged into the polygon set p1 in (e).
Figure 8(e) also shows the result of the cropped zoning as shaded surfaces. Figure 8(f) shows
the resulting 3D zones.
The user can further specify a minimum overlap area and a maximum floor plan dis-
tance in order to cull small overlaps and overly distant floor plans in the adjacency test. The
importance of both parameters is highlighted in (g)(h) and (i) where we deliberately set both
parameters so that all adjacencies are found. The face f2 has a clearly visible neighbor but its
parent unit u2 is slightly higher and thus overlaps with other unit faces from higher and lower
floors. Thus, faces f3-6 are also detected as adjacent. If the geometry is tapering (f3) or chang-
ing drastically from floor to floor (f5) the geometry of such floor plans should not be added to
the floor plan union (p2) since it widens or alters the core region at the adjacent edge and
would thus produce unexpected zoning (Figure 8 (h) and (i)).
Figure 8: 3D adjacency detection and adjacency aware zoning.
Modeling of windows: After the zone geometry is modeled, we have to further ar-
ticulate the facades. In our implementation the user can specify orientation dependent win-
dow-to-wall-ratios that are then used to model the windows. As a basis to construct the win-
dow geometry we retrieve all unit faces that are outward facing facades (labeled wall/facade
and no overlaps with other faces). We then sort them by face normal orientation and then
copy and scale its geometry by the specified window-to-wall-ratio around its center of mass
to obtain the window geometry (facade faces must be convex). We do not model shades at
this point, however, others can easily override our simple function with a custom implementa-
tion of window and shading surface modeling to accommodate for more elaborate designs
such as punched hole facades, horizontal window stripes or orientation dependent shading
devices. Manual intervention is also possible after the 3D geometry is output and before the
energy model is written out.
Testing the algorithm:
In order to test the algorithm’s capability, we computed subdivisions for various floor
plan outlines of varying complexity (Figure 9). Starting with a simple rectangle (a) we con-
tinued by adding convex (c) and non-convex holes (d) and increasing the overall edge count
of the polygons (g). The time required to compute the Zones was recorded (measured on 15"
MBP Early 2011 laptop). In a next step we wanted to understand how and when the results
from our automated procedure could be different to potential manual zoning. Therefore, we
also zoned each shape in Figure 9 by hand according to how we believe a typical energy
modeler would subdivide the shapes into core and perimeter cells. There is certainly a high
degree of subjectivity associated with this approach. To quantify the geometric difference be-
tween the automatically and the manually zoned versions we compare both based on the zone
DRAFT
floor area Ai normalized by the zone facade length lfi given as ωi in Formula 1a. We then
computed an area weighted Root Mean Square Error AW-RMSE as given in Formula 1b and
1c where ωAi is the normalized area for the automated zoning and ωMi is the normalized area
for the manual zoning. To understand the implications of the possible geometric difference on
a thermal simulation we then compare three different annual load calculations for the shapes
in Table 1. First we use the same material and internal gain settings as given in the DOE
Commercial Reference Buildings ‘Small Office - New Construction’ case [DOE, 2013]. For
the second case we change the materiality to a heavy weight construction without insulation
and single glazing. For the third case we add insulation and triple glazing. Results are given
as percentage error labeled E%DOE, E%LOW and E%HIGH respectively. All simulations were
simulated in the Boston climate.
Further, we monitor the runtimes of our algorithm to compute the zone subdivision of
the shapes in Figure 9 and the runtimes of Energy Plus to run an annual energy simulation for
each zoned model.
Figure 9: Test shapes of varying complexity
Formula 1 a,b,c:
a) Facade area weight ωb) Percentage error E% c) Area weighted RMSE
Proof of concept implementation and workflow integration:
The algorithm presented in the previous sections was implemented as a proof of con-
cept plug-in for McNeel’s Rhinoceros [McNeel, 2012] and Grasshopper [McNeel, 2012] us-
ing the C# programming language. McNeel’s Rhinoceros is a CAD modeling software that
can create, edit, analyze, and translate curves, surfaces, and solids. Grasshopper is a graphical
editor for generative algorithms within the Rhinoceros ecosystem. Both where primarily cho-
sen due to their popularity among architects and urban planners and the extensive support for
plug-in development provided through the RhinoCommon SDK [McNeel, 2013]. However,
the Autozoner algorithm can be implemented in any modeling environment if the following
three geometric algorithms are available:
1. Offsetting and 2D boolean addition, subtraction and intersection are used
throughout the 2D zoning procedures. Our implementation uses the publicly available
polygon-clipping library called ‘Clipper’ by Johnson [2012], which provides this func-
tionality.
2. For the cellular subdivision a straight skeleton algorithm is needed. The imple-
mentation of a robust straight skeleton algorithm that can handle complex polygons is not
a trivial task. Our algorithm uses a ported and slightly modified version of an implemen-
tation provided by Petr Felkel and has been extensively described by Felkel & Obdrzalek
[1998]. An alternative by Cacciola [2004] ships with CGAL [CGAL, 2014] an extensive
computational geometry library.
3. For the 3D zoning (Figure 7 (e-h)) 3D boolean operations are required. Our im-
plementation uses the boolean operations provided by Rhinoceros. However, CGAL of-
fers similar functionality.
For a fully automated massing model to BEM conversion the model geometry pro-
duced by the Autozoner has to be paired with further non geometric simulation inputs and
zone properties such as materiality, loads, schedules and HVAC settings, in order to obtain a
fully functional energy model. Automated pairing of geometry and non-geometric simulation
properties can be done with a tool-set published by Dogan [2013]. The tool-set provides a us-
er and programming interface for energy modeling within Grasshopper featuring a thermal
model class library containing abstract definitions for zones, faces, materials, etc. that can be
translated into a simulation engine specific syntax such as the EnergyPlus [EERE, 2013] IDF
format and the TRNSYS [Klein, 1979] BUI format. This allows us to launch a simulation and
visualize the simulation results spatially in the Rhino CAD modeling viewport. Once the ge-
ometric and non-geometric data streams are set up correctly, iterating through various geo-
metric design versions and getting simulation based feedback is only a matter of a few clicks.
The proposed workflow is depicted in Figure 10.
Figure 10: Energy modeling workflow integration
3. Results
This section shows the results of our automated zoning and compares the outcome
with manual zoning. Further, algorithm runtimes are presented.
Figure 11 shows the automatically zoned test floor plans of Figure 9. Simpler shapes
such as Figure 11(a) result in a subdivision with a zone count of 5. More complex shape out-
lines yield a higher zone count. An example is Figure 10(g) with 58 zones.
While comparing the automatic subdivision shown in Figure 11 with a manually gen-
erated subdivision we encountered significant differences is some regions of the shapes. The
most prominent cases are highlighted in Figure 12. Region 1 shows a detail from shape (c) of
Figure 11. A manual subdivision would very likely connect both exterior corner points with a
straight line with α=30°. The straight skeleton approach in our algorithm strictly follows the
bisectors of the exterior edges with α’=45°. This leads to a difference in normalized area for f1
to f1’ of 18%. A similar case shown in Region 3 leads to a local disagreement of 43% between
f2 to f2’. We also observe higher disagreement in regions where the polygon offset that in-
scribes the core region vanished and many facade edges are in close proximity (Region 2 and
4). The geometric differences for the entire shapes are far less pronounced. The computed
AW-RMSEs range form 0%-7% and are given in Table 1.
These differences are also reflected in the load simulation comparison. Table 1 lists
the differences in the results for manually and automatically zoned shapes with the labels
E%DOE, E%LOW and E%HIGH. While, the disagreement does not exceed 1.65% for cases with
facade insulation and better glazing (E%DOE, E%HIGH), the deviation can jump up to 8% for
the E%LOW scenario. Here, the difference in floor area, where we assign all internal gains, to
facade length, where mayor losses occur, has a much bigger impact on the simulation out-
come. Due to the different orientations of zones it is also possible that the deviation levels
out, as it happened for shape d) were the geometric deviation is at 4% and the simulation
based deviation for all three scenarios is near zero. Table 1 also shows the measured runtimes
of our automated zoning algorithm and each EnergyPlus simulation. For small models the ge-
ometry is computed within milliseconds. Larger models with e.g. 184 zones require 15.5 se-
conds to compute. EnergyPlus simulation time ranges from 20 seconds to 5 minutes for the
largest model.
Figure 11: Automatic zoning results
Figure 12: Complex massing: Input, floor subdivision, inner subdivision and facade.
Shape
Zones
AW-RMSE
E% DOE
E% LOW
E% HIGH
Autozoning [s]
E+ runtime [s]
a
5
0%
0%
0%
0%
0.29
20
b
8
0%
0%
0%
0%
0.327
23
c
9
4%
-0.78%
-2.19%
0.15%
0.49
24
d
22
4%
0.1%
0%
0.06%
1.4
38
e
26
3%
-1.18%
-4.95%
0.09%
2.8
72
f
28
2%
-1.65%
-8.0%
0.34%
2.1
180
g
58
7%
-0.88%
-6.34%
1.13%
7.7
331
Table 1: Algorithm runtime and difference compared to manual zoning
4. Discussion
The foregoing section demonstrated that the Autozoner algorithm provides a fast, ro-
bust and unambiguous method for automatic zoning of a building according to ASHRAE 90.1
Appendix G. The algorithm is based on standard computational geometry procedures such as
offsetting, straight skeleton and 2D/3D boolean operations and can thus easily be implement-
ed in a variety of energy modeling environments. Arguments for doing so are presented next
followed by the algorithm’s limitations as well as some thoughts about the usefulness of the
Appendix G guidelines themselves.
As mentioned before, the two main arguments for using the algorithm are speed and
reproducibility. If professional organizations such as the American Institute of Architecture
and ASHRAE along with green building rating systems such as LEED [UGBC, 2008], DGNB
[UGBC, 2014] BRREAM [BRREAM, 2004] want to promote early design phase rapid BEM
generation, then having an unambiguous procedure in place that does not provide a burden on
the design team is useful and facilitates compliance procedures.
It has further been shown that, comparing manually and automatically zoned BEMs
can yield differences in simulated EUI of up to 8%. Here, it is not the point to claim that one
or the other solution is more correct, both are only preliminary assumptions and do not repre-
sent actual floor plan subdivisions. It is more important to note that in a comparative study
with multiple variants, a deviation of 8% in the results solely due to inconsistency in the sub-
division, can dilute the analysis and thus complicate making the right design decisions. Thus,
it is desirable to employ a zoning method that can compute unvarying and reproducible zone
subdivisions for any shape.
It is further worth pointing out that having an algorithm that can reliably perform an
otherwise time consuming and inconsistent process has the potential to significantly increase
the adoption rate and quality of early stage BEMs. According to a recent survey by Samuel-
son et al. [2012], 30% of the participating AEC firms (Architecture, Engineering, and Con-
struction) who employ in-house energy modelers reported that simulation based feedback has
only ‘rarely’ or ‘occasionally’ an impact on design decisions, a fact that has been traced back
to time and resource intensive workflows that prohibit the early use of BPS tools [De Wilde,
1999][Mahdavi et al., 2003][Ianni et al., 2013]. Apart from individual building design, the
Autozoner can also be applied to urban projects that involve dozens of buildings that practi-
cally could not be modeled in a reasonable time frame [Besserud & Hussey, 2011][Dogan &
Reinhart, 2013][Dogan et al., 2012]. For very large urban models with hundreds of buildings
and thousands of zones the model setup may still require only seconds or minutes. However,
the simulation time and the amount of data may impose limits. The algorithm that we de-
scribed has not been optimized for efficiency in that regard. Many of the zones that the algo-
rithm creates could be merged since they have similar orientations (ASHRAE 90.1 recom-
mends merging if the difference in orientation is less than 45°) and many floors could be rep-
resented by multipliers to simplify and thus speed up the simulations. Despite all the previ-
ously mentioned improvements the presented algorithm has limitations in applicability that
modelers should be aware of:
To this point, a question that remains open is how the boundary conditions between
touching zones should be modeled by an algorithm such as the Autozoner. ASHRAE 90.1
Appendix G does not provide any binding guidance regarding this question. The DOE Refer-
ence Buildings as well as the Energy Plus Example Files model the zone subdivision with an
opaque surface without airflow between zones. What are the consequences of this decision?
Figure 13 compares annual heating and cooling loads for the same zoning of a square office
building but various heat and mass transfer effects at the interior zone boundaries. Beginning
with an adiabatic space boundary, conduction, solar radiation and different levels of air mix-
ing are added step by step. As one would expect, adding these different modes of inter-zone
heat flows successively, the ASHRAE solution is brought closer to the single zone solution.
Annual heating and cooling loads vary by up to 41% and 10%, respectively, compared to the
building modeled as a single zone. This suggests that an energy modeler and the design team
should be conscious of the likely building layout even during the earliest massing studies us-
ing the boundary conditions for the individual or open office scenarios form Figure 13 as they
may apply.
Ultimately, this observation leads to the larger questions which is how meaningful the
conceptual division of a floor plan into core and perimeter spaces is at any point in the design
process. An experienced architect working with a massing model necessarily has (or should
have) an intuition how the interior of this model could be divided. This knowledge should
hence be part of the thermal zoning considerations as early as possible. As an example, Figure
14 shows the same building as from Figure 13 divided into a conditioned workspace plus an
unconditioned circulation area (in gray). The different layouts change the annual conditioning
loads by up to 21%. Going forward, this suggests that it might be useful to go beyond Appen-
dix G and consider thermal zoning in a more architectural sense. In the meantime, it seems
that a version of the Autozoner algorithm along with an input parameter for the interior
boundary conditions that toggles between individual rooms or open plan provides a meaning-
ful step towards consistent BEM during schematic design.
Figure 13: Comparison of a perimeter and core subdivision with different inter-zonal
heat and mass transfer scenarios versus a single zone simulation and their correlation
with architectural floor plan typologies.
Figure 14: Comparison of different positions of an unheated circulation space
5. Conclusion
A general algorithm for creating multi-zone energy models for complex building
shapes with unknown interior space subdivision is introduced. The algorithm is compliant
with ASHRAE 90.1 Appendix G thermal zoning requirements and can easily be implemented
in any thermal modeling environment to alleviate time-consuming thermal model preparation
and to avoid modeling inconsistencies between different design variants. In practice the algo-
rithm should be combined with meaningful assumptions regarding the heat transfer through
interior boundaries in order to differentiate between single and open plan scenarios. It is im-
portant to note, that the algorithm should only be used during early massing studies when in-
terior space divisions are still undefined.
6. Acknowledgements
We would like to thank Transsolar Energietechnik GmbH Munich for productive discussions
and partial funding of the research project.
7. References
Aichholzer, O., Aurenhammer, F., Alberts, D., & Gärtner, B. (1996). A novel type of skeleton
for polygons (pp. 752-761). Springer Berlin Heidelberg.
Aichholzer, O., & Aurenhammer, F. (1996). Straight skeletons for general polygonal figures
in the plane (pp. 117-126). Springer Berlin Heidelberg.
ANSI/ASHRAE/IESNA Standard 90.1-2013 Appendix G
Autodesk. (2013). Autodesk Vasari. Retrieved November 1, 2013, from
http://autodeskvasari.com/
Barequet, G., Goodrich, M. T., Levi-Steiner, A., & Steiner, D. (2003, January). Straight-
skeleton based contour interpolation. In Proceedings of the fourteenth annual ACM-
SIAM symposium on Discrete algorithms (pp. 119-127). Society for Industrial and
Applied Mathematics.
BEMBOOK (2013). Thermal Zoning Determination, Retrieved Jan 20 2014, from
http://bembook.ibpsa.us/index.php?title=Thermal_Zoning_Determination
Bentley (2013) AECOsim, Retrieved November 1, 2013,
http://docs.bentley.com/en/AECOsimEnergySimulator/benshelp89.html
Besserud, K., & Hussey, T. (2011). Urban design, urban simulation, and the need for compu-
tational tools. IBM Journal of Research and Development, 55(1.2), 2-1.
Bobenhausen, W. (1994). Simplified design of HVAC systems. New York: Wiley.
BRREAM 2004. Building research establishment environmental assessment method. Re-
trieved April 21, 2014, http://www.breeam.org/index.htm
Cacciola, F. (2004). A CGAL implementation of the Straight Skeleton of a Simple 2D Poly-
gon with Holes. In 2nd CGAL User Workshop, Polytechnic Univ., Brooklyn, New
York, USA.
CGAL (2014), Computational Geometry Algorithms Library, Retrieved April 21, 2014,
http://www.cgal.org
Crawley, D. B., Lawrie, L. K., Pedersen, C. O., & Winkelmann, F. C. (2000). Energy plus:
energy simulation program. ASHRAE journal, 42(4), 49-56.
De Berg, M., Van Kreveld, M., Overmars, M., & Schwarzkopf, O. C. (2000). Computational
geometry (pp. 29-33). Springer Berlin Heidelberg.
De Wilde, P., Augenbroe, G., & Van Der Voorden, M. (1999, September). Invocation of
building simulation tools in building design practice. In Proceedings of IBPSA ‘99
Buildings Simulation Conference (pp. 1211-1218).
DGNB, (2014). DGNB Zertifizierungssystem. Retrieved April 21, 2014, http://www.dgnb-
system.de/de/system/zertifizierungssystem/
DOE. (2013). U.S. Department of Energy Commercial Reference Building Models. Retrieved
November 1, 2013, from http://energy.gov/eere/buildings/commercial-reference-
buildings
Dogan, T. (2013). Energy Modeling Tools for Grasshopper. Retrieved November 1 2013,
from http://www.timurdogan.de/
Dogan, T., Reinhart, C. (2013). Automated conversion of architectural massing models into
thermal ‘shoebox’models. Proceedings of BS2013.
Dogan, T., Reinhart, C., & Michalatos, P. (2012). Urban Daylight Simulation Calculating the
Daylit Area of Urban Designs. SimBuild 2012.
EERE. (2013). EnergyPlus Energy Simulation Software. EERE U.S. Department of Energy.
Retrieved November 1, 2013, from http://apps1.eere.energy.gov/buildings/energyplus/
EERE. (2013). EnergyPlus Example File Generator. Retrieved November 1, 2013, from
http://apps1.eere.energy.gov/buildings/energyplus/cfm/inputs/index.cfm
ESRU, ESP-r, http://www.esru.strath.ac.uk, 2005.
Felkel, P., & Obdrzalek, S. (1998). Straight skeleton implementation. In Proceedings of
spring conference on computer graphics.
Hirsch, J. (2010). eQuest Introductory Tutorial, version 3.64. http://www.doe2.com/equest/
Ianni, M., & de León, M. S. (2013). Applying Energy Performance-Based Design in Early
Design Stages.
Johnson, A. (2012). Clipper 6.0 -an open source freeware polygon clipping library.
http://www.angusj.com/delphi/clipper.php
Klein, S. A.(1979). TRNSYS, a transient system simulation program. Solar Energy Laborato-
ry, University of Wisconsin—Madison.
Mahdavi, A., Feurer, S., Redlein, A., & Suter, G. (2003, August). An inquiry into the building
performance simulation tools usage by architects in Austria. In Eighth International
IBPSA Conference.
McNeel, R. (2012). Grasshopper - Generative Modeling with Rhino, McNeel North America,
Seattle, USA. (http://www.grasshopper3d.com/).
McNeel, R. (2012). Rhinoceros - NURBS Modeling for Windows (version 5.0), McNeel
North America, Seattle, WA, USA. (www.rhino3d.com/).
McNeel, R. (2013). RhinoCommon Plug-in SDK. Retrieved November 1, 2013, from
http://wiki.mcneel.com/developer/rhinocommon/
Morbitzer, C., Strachan, P. A., Webster, J., Spires, B., & Cafferty, D. (2001). Integration of
building simulation into the design process of an architectural practice. Chicago
Preparata, F. P. (1977). The medial axis of a simple polygon. In Mathematical Foundations of
Computer Science 1977 (pp. 443-450). Springer Berlin Heidelberg.
Reinhart, C. F., Dogan, T., Jakubiec, J. A., Rakha, T., & Sang, A. (2013). UMI-An Urban
Simulation Environment for Building Energy Use, Daylighting and Walkability. In
Proceedings of BS2013
Samuelson, H. W., Lantz, A., & Reinhart, C. F. (2012). Non-technical barriers to energy
model sharing and reuse. Building and Environment, 54, 71-76.
Schlueter, A., & Thesseling, F. (2009). Building information model based energy/exergy per-
formance assessment in early design stages. Automation in Construction, 18(2), 153-
163.
Smith, L., Bernhardt, K., & Jezyk, M. (2011). Automated energy model creation for concep-
tual design. In Proceedings of the 2011 Symposium on Simulation for Architecture
and Urban Design (pp. 13-20). Society for Computer Simulation International.
