Skip to content

1.3 Relationship to Honeybee schema

Chris Mackey edited this page Sep 4, 2020 · 7 revisions

The Dragonfly Model schema has a direct relationship with the Honeybee Model schema and each Dragonfly Model can be translated into one or more Honeybee Models using the dragonfly-core Python package. The reverse is not true as Honeybee Models have much more detail than Dragonfly Models and this detail would be lost in the conversion from Honeybee to Dragonfly.

Object Mappings

Dragonfly Room2Ds map directly to Honeybee Rooms and these two objects share many of the same properties. Where the Room is the coarsest/most abstract object in the Honeybee Model schema, the Room2D is the finest/ most detailed object in the Dragonfly Model schema. This means that the Dragonfly schema has objects above Room2Ds(Stories and Buildings) that make it easier to organize and manage Building-scale models. If one were to work purely with Honeybee, one would have to manage lists of lists of lists of Rooms to be able to represent the same hierarchy of the Dragonfly Model schema. Such list management is feasible but, because Dragonfly represents this hierarchy through objects instead of arrays, these hierarchical groups can have properties that simple arrays lack. For example, Dragonfly Stories have a property for multiplier that makes it easy to specify when a given Story is repeated over the height of a Building. This also means that extension properties like energy ConstructionSets can be assigned on the level of Buildings rather than specifying such a property for every single room.

Altogether, the relationship between Dragonfly and Honeybee objects can be represented as follows:

Dragonfly to Honeybee Schema Relationship

Strengths of Dragonfly's Abstraction

Aside from the ease of model management noted above, there are several other advantages to representing building geometry as 2D extrusions grouped into Stories and Buildings. The first is that the size of the schema files can be dramatically smaller, making it possible to store large portions of the built environment in a model a fraction of the size. A typical urban district represented as a Dragonfly model can have a file size that is less than 1/10th the size of equivalent the Honeybee model, making Dragonfly models much more portable and share-able. Another advantage is that Dragonfly Models can be easily exported to 2D formats that are common in the building industry. For example, Dragonfly models can be exported to geoJSON format with ease since all of the geometry is already in a 2D format (see below). It's also easier to produce visualizations of floor plans (eg. grids of daylight results) when the starting geometry is in 2D. Equivalent operations for Honeybee models would involve a lot more work and would likely be more prone to errors.

A Dragonfly Model and it's geoJSON Export Dragonfly Model Results Dragonfly Model geoJSON

Dragonfly Models can also be easily built from a variety of 2D sources, making use of the 2D constraint to automate much of the process. For example, straight skeleton operations can be performed in 2D space to quickly yield geometry with core + perimeter zoning: Dragonfly Model core + perimeter zoning

Operations like the generation of plenum spaces can also be easily automated as a result of the 2D constraint: Dragonfly Model plenum spaces

Yet another advantage is that such abstracted Dragonfly models can be easier to edit, enabling large changes like the deletion, replacement or addition of entire Stories or Buildings. Operations like changing the window ratio of a Dragonfly Model are also much easier to perform than an equivalent operation in Honeybee. In this sense, Dragonfly Models evade some of the negative effects of "The Law of Design Inertia" where "the more detail that is put into the model, the more [human] energy is needed to edit it." By keeping the information needed to describe the model to a minimum, it can more easily accommodate changes in design and the testing of new design strategies.

Limitations of Dragonfly's Abstraction

However, all of this can come with significant limitations that are perhaps best summarized with the following depiction of a detailed BIM model in Dragonfly and Honeybee formats:

Sample Model in Dragonfly and Honeybee

While the Dragonfly representation of this model might be suitable for simple annual energy analysis or the sizing of HVAC systems (assuming the total amount of glazing and the room volumes match), there are many types of studies where such a representation would not be appropriate. For example, an annual daylight study or a detailed thermal comfort mapping study would require the explicit representation of the gabled roof and individual windows in order to be accurate.

In this respect, Dragonfly models are not intended to be used for all types of buildings and types of studies. Instead, they aim to make use of the most common features of contemporary buildings (eg. extruded floor plates, repeating window patterns, etc.) to make the majority of cases easier to model and edit.