Assigning building and space level construction and schedule sets

Hello everyone,

I am working on a conceptual design and optimization workflow that relies on the link between Honeybee and OpenStudio. I am able to generate and run the EnergyPlus models in both Honeybee and OpenStudio without issue.

However, there are two main issues with output OSM file:

  1. Construction materials are currently assigned to individual zones or surfaces. Is it possible to define building level construction sets so that properties pass onto spaces and ultimately to surfaces?

  2. Schedules and loads are assigned to each individual thermal zone. As a result, in the OpenStudio model, each zone has its own schedule set and load. Is there a way to specify loads and schedules per space type?

Following this hierarchy (building, space, zone, surface) is an important feature of OpenStudio and it can be achieved natively (via SketchUp). It would be great if I could somehow incorporate that logic into Honeybee and Grasshopper as well.

Thank you for the help!


Ali, This is a very good suggestion and possible to implement but will need a lot of changes in the current code-base. We should make sure to keep this in mind for the honeybee[+] libraries. Meanwhile as you probably know OpenStudio has a measure to remove the hard assigned inputs that might help.


You have raised a great point that was also raised by some engineers with whom my architecture office is trying to develop a “shared energy model” workflow.

While I personally have never had the need to use space types, construction sets, etc. because Grasshopper allows the automatic assigning of schedules/loads/constructions to multiple zones at once, I realize that these features are critical for anyone wishing to edit things within the OpenStudio GUI.

This has become a big enough issue within my office work that I will definitely implement something to take care of this before the next stable release of Honeybee. I have just been taking a bit of time to think about the best way to implement it. Ideally, I would like to avoid adding additional components to assign space types or construction sets to zones since Honeybee already has a lot of components, it would be a bit redundant of the current functionality, and I know that both Mostapha and I like the “Grasshopperiness” of the current method for assigning schedules and construction sets to whatever lists of zones we want.

For this reason, I am currently leaning towards adding code to the OpenStudio component that can automatically figure out which zones have the same schedules and assign schedule sets. The same would be done for loads + load definitions. I have added an issue here so that you can track the progress of this:

The only downside to this automation would be that people would not be able to name these schedule sets + loads definitions but I think this could be ok if I generate an automatic name from the first zone that has these things assigned (people can always rename things in the OpenStudio GUI).

I imagine doing something similar for construction sets:

Once we have this initial functionality implemented, it will cut out a lot of the redundancy and we can think about space types. Personally, I’m still questioning what the best workflow for this would be as I think the current assigning of space types based on zone program is nice, allowing you to easily identify the base program of zones exported from Honeybee. If this zone program becomes linked to schedule sets and loads, it could de-couple it from this Honeybee zone program.

Perhaps we add an option on the OpenStudio component to either assign space types based on assigned Honeybee zone program (not linked to schedules or loads) or link it to schedules+loads and auto-generate space types based on how many common schedule sets/loads there are.

Ali and anyone reading this, let me know if you have any thoughts on this proposed implementation.



The idea of checking if the user has assigned the input sounds like the right approach. I know that we have a method for construction to check if it is set by user but not sure about the loads and schedules.

Early on, honeybee was designed not to assign any construction, load or schedule to the zone until the write components because I was thinking to use the space level assignment but then it faded out. The main reason was the confusion of getting None values for unassigned properties. There was no good way to check the inputs before writing them to idf. Admittedly, it was mostly because I didn’t know how to handle this in an elegant way.


@Alilrani .
I just pushed a major overhaul of how Honeybee exports OpenStudio models to our github:

If you sync with the github, you will see that the component now assigns constructions using a default construction set. It will only assign constructions on a surface-by-surface basis if it finds constructions that differ from those of the same surface type in the rest of the model.

Additionally, the component will sense when two zones have the same loads/schedules and will only write a single load definition or schedule set that will be assigned to both zones.

This should give you the vast majority of what you need to produce cleanly-editable OpenStudio models from Honeybee. The only thing that the component is not yet doing is assigning schedules/loads based on space type because I’m still a bit conflicted about the best way to do this. It seems that it would be best to have the component automatically sense when two zones have the same schedules + loads and assign the same space type to each of them (which has the schedules/loads attached to it). I just don’t know if I should generate the name of this common space type from the Honeybee zoenProgram or the names of one of the zones (or both). If you have any suggestions, let me know. Otherwise, give me some time to think about it and I’ll implement it soon.

1 Like

@chris, well done!

I think if you want to introduce the concept of OpenStudio spaces it should be explicit. You can add a new component that inputs HBZones and group them into a space. Similar to what we do for HVAC system assignment. The component should also have an input for space names.