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.