1.3 Relationship to Honeybee schema
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.
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:
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 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:
Operations like the generation of plenum spaces can also be easily automated as a result of the 2D constraint:
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.
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:
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.