Revision history [back]

The BuildingStory class is unique to OpenStudio. It's indeed very handy for managing spaces in a model (e.g. placeholder for common default construction sets), for GUI visualization (as per your client requirements), etc. Yet it is neither forward translated to an IDF model, nor reverse translated from an IDF model. To the best of my knowledge, there's nothing one can add to an IDF file that will trigger new BuildingStory instances during reverse translation.

How does one figure out which IDF objects get reverse translated (and how)? By exploring OpenStudio's ReverseTranslator.cpp. For instance, you alluded to ZoneList objects (Line 1032). Going over the actual code and comments (Line 40), one understands this is reverse translated as a SpaceType - not what you're after.

You could instead add BuildingStory instances to the reverse translated OSM model/file. Since you appear to be coding a solution (towards generating IDF files), it shouldn't be that challenging to interact with the OSM model using the SDK/API. Here's a Ruby example (Line 44) of reverse translating an IDF, and then accessing the generated OSM model.

An EnergyPlus Zone gets reverse translated (Line 33) as both an OpenStudio ThermalZone and Space. Only the latter can be linked to a BuildingStory. As you already seem to know which zones should be grouped under which building story, it should boil down to:

• adding to the OSM model as many BuildingStory instances as needed
• looping through each OSM space to identify its unique thermal zone
• assigning each space's building story as required (see setBuildingStory)

That should do the trick. There are other ways of doing something similar. This example sorts spaces vs building stories based on the Z-axis values of floor vertices. My 2-cents.

The BuildingStory class is unique to OpenStudio. It's indeed very handy for managing spaces in a model (e.g. placeholder for common default construction sets), for GUI visualization (as per your client requirements), etc. Yet as suggested here and elsewhere, it is neither forward translated to an IDF model, nor reverse translated from an IDF model. To the best of my knowledge, there's nothing one can add to an IDF file that will trigger new BuildingStory instances during reverse translation.

How does one figure out which IDF objects get reverse translated (and how)? By exploring OpenStudio's ReverseTranslator.cpp. For instance, you alluded to ZoneList objects (Line 1032). Going over the actual code and comments (Line 40), one understands this is reverse translated as a SpaceType - not what you're after.

You could instead add BuildingStory instances to the reverse translated OSM model/file. Since you appear to be coding a solution (towards generating IDF files), it shouldn't be that challenging to interact with the OSM model using the SDK/API. Here's a Ruby example (Line 44) of reverse translating an IDF, and then accessing the generated OSM model.

An EnergyPlus Zone gets reverse translated (Line 33) as both an OpenStudio ThermalZone and Space. Only the latter can be linked to a BuildingStory. As you already seem to know which zones should be grouped under which building story, it should boil down to:

• adding to the OSM model as many BuildingStory instances as needed
• looping through each OSM space to identify its unique thermal zone
• assigning each space's building story as required (see setBuildingStory)

That should do the trick. There are other ways of doing something similar. This example sorts spaces vs building stories based on the Z-axis values of floor vertices. My 2-cents.

The BuildingStory class is unique to OpenStudio. It's indeed very handy for managing spaces in a model (e.g. placeholder for common default construction sets), for GUI visualization (as per your client requirements), etc. Yet as suggested here and elsewhere, it is neither forward translated to an IDF model, nor reverse translated from an IDF model. To the best of my knowledge, there's nothing one can add to an IDF file that will trigger new BuildingStory instances during reverse translation.

As suggested here and elsewhere, a limited number of objects get reverse translated. How does one figure out which IDF objects get reverse translated (and how)? By exploring OpenStudio's ReverseTranslator.cpp. For instance, you alluded to ZoneList objects (Line 1032). Going over the actual code and comments (Line 40), one understands this is reverse translated as a SpaceType - not what you're after.

You could instead add BuildingStory instances to the reverse translated OSM model/file. Since you appear to be coding a solution (towards generating IDF files), it shouldn't be that challenging to interact with the OSM model using the SDK/API. Here's a Ruby example (Line 44) of reverse translating an IDF, and then accessing the generated OSM model.

An EnergyPlus Zone gets reverse translated (Line 33) as both an OpenStudio ThermalZone and Space. Only the latter can be linked to a BuildingStory. As you already seem to know which zones should be grouped under which building story, it should boil down to:

• adding to the OSM model as many BuildingStory instances as needed
• looping through each OSM space to identify its unique thermal zone
• assigning each space's building story as required (see setBuildingStory)

That should do the trick. There are other ways of doing something similar. This example sorts spaces vs building stories based on the Z-axis values of floor vertices. My 2-cents.

The BuildingStory class is unique to OpenStudio. It's indeed very handy for managing spaces in a model (e.g. placeholder for common default construction sets), for GUI visualization (as per your client requirements), etc. Yet it is neither forward translated to an IDF model, nor reverse translated from an IDF model. To the best of my knowledge, there's nothing one can add to an IDF file that will trigger new BuildingStory instances during reverse translation.

As suggested here and elsewhere, a limited number of objects get reverse translated. How does one figure out which IDF objects get reverse translated (and how)? By exploring OpenStudio's ReverseTranslator.cpp. For instance, you alluded to ZoneList objects (Line 1032). Going over the actual code and comments (Line 40), one understands this is reverse translated as a SpaceType - not what you're after.

You could instead add BuildingStory instances to the reverse translated OSM model/file. Since you appear to be coding a solution (towards generating IDF files), it shouldn't be that challenging to interact with the OSM model using the SDK/API. Here's a Ruby example (Line 44) of reverse translating an IDF, and then accessing the generated OSM model.

An EnergyPlus Zone gets reverse translated (Line 33) as both an OpenStudio ThermalZone and Space. Only the latter can be linked to a BuildingStory. As you already seem to know which zones should be grouped under which building story, it should boil down to:

• adding to the OSM model as many BuildingStory instances as needed
• looping through each OSM space to identify its unique thermal zone
• assigning each space's building story as required (see setBuildingStory)

That should do the trick. There are other ways of doing something similar. This example sorts spaces vs building stories based on the Z-axis values of floor vertices. My 2-cents.

The BuildingStory class is unique to OpenStudio. It's indeed very handy for managing spaces in a model (e.g. placeholder for common default construction sets), for GUI visualization (as per your client requirements), etc. Yet it is neither forward translated to an IDF model, nor reverse translated from an IDF model. To the best of my knowledge, there's nothing one can add to an IDF file that will trigger new BuildingStory instances during reverse translation.

As suggested here and elsewhere, a limited number of IDF objects get reverse translated. How does one figure out which IDF objects get reverse translated (and how)? By exploring OpenStudio's ReverseTranslator.cpp. (starting from Line 254). For instance, you alluded to ZoneList objects (Line 1032). Going over the actual code and comments (Line 40), one understands this is reverse translated as a SpaceType - not what you're after.

You could instead add BuildingStory instances to the reverse translated OSM model/file. Since you appear to be coding a solution (towards generating IDF files), it shouldn't be that challenging to interact with the OSM model using the SDK/API. Here's a Ruby example (Line 44) of reverse translating an IDF, and then accessing the generated OSM model.

An EnergyPlus Zone gets reverse translated (Line 33) as both an OpenStudio ThermalZone and Space. Only the latter can be linked to a BuildingStory. As you already seem to know which zones should be grouped under which building story, it should boil down to:

• adding to the OSM model as many BuildingStory instances as needed
• looping through each OSM space to identify its unique thermal zone
• assigning each space's building story as required (see setBuildingStory)

That should do the trick. There are other ways of doing something similar. This example sorts spaces vs building stories based on the Z-axis values of floor vertices. My 2-cents.

The BuildingStory class is unique to OpenStudio. It's indeed very handy for managing spaces in a model (e.g. placeholder for common default construction sets), for GUI visualization (as per your client requirements), etc. Yet it is neither forward translated to an IDF model, nor reverse translated from an IDF model. To the best of my knowledge, there's nothing one can add to an IDF file that will trigger new BuildingStory instances during reverse translation.

As suggested here and elsewhere, a limited number of IDF objects get reverse translated. How does one figure out which IDF objects get reverse translated (and how)? By exploring OpenStudio's ReverseTranslator.cpp (starting from Line 254). For instance, you alluded to ZoneList objects (Line 1032). Going over the actual code and comments (Line 40), one understands this is reverse translated as a SpaceType - not what you're after.

You could instead add BuildingStory instances to the reverse translated OSM model/file. Since you appear to be coding a solution (towards generating IDF files), it shouldn't be that challenging to interact with the OSM model using the SDK/API. Here's a Ruby example (Line 44) of reverse translating an IDF, and then accessing the generated OSM model.

An EnergyPlus Zone gets reverse translated (Line 33) as both an OpenStudio ThermalZone and Space. Only the latter can be linked to a BuildingStory. As you already seem to know which zones should be grouped under which building story, it should boil down to:

• adding to the OSM model as many BuildingStory BuildingStory instances as needed
• looping through each OSM space to identify its unique thermal zone
• assigning each space's building story as required (see setBuildingStory)

That should do the trick. There are other ways of doing something similar. This example sorts spaces vs building stories based on the Z-axis values of floor vertices. My 2-cents.A more general solution.

The BuildingStory class is unique to OpenStudio. It's indeed very handy for managing spaces in a model (e.g. placeholder for common default construction sets), for GUI visualization (as per your client requirements), etc. Yet it is neither forward translated to an IDF model, nor reverse translated from an IDF model. To the best of my knowledge, there's nothing one can add to an IDF file that will trigger new BuildingStory instances during reverse translation.

As suggested here and elsewhere, a limited number of IDF objects get reverse translated. How does one figure out which IDF objects get reverse translated (and how)? By exploring OpenStudio's ReverseTranslator.cpp (starting from Line 254). For instance, you alluded to ZoneList objects (Line 1032). Going over the actual code and comments (Line 40), one understands this is reverse translated as a SpaceType - not what you're after.

You could instead add BuildingStory instances to the reverse translated OSM model/file. Since you appear to be coding a solution (towards generating IDF files), it shouldn't be that challenging to interact with the OSM model using the SDK/API. Here's a Ruby example (Line 44) of reverse translating an IDF, and then accessing the generated OSM model.

An EnergyPlus Zone gets reverse translated (Line 33) as both an OpenStudio ThermalZone and Space. Only the latter can be linked to a BuildingStory. As you already seem to know which zones should be grouped under which building story, it should boil down to:

• adding to the OSM model as many BuildingStory instances as needed
• looping through each OSM space to identify its unique thermal zone
• assigning each space's building story as required (see setBuildingStory)

That should do the trick. There are other ways of doing something similar. This neat example sorts spaces vs building stories based on the Z-axis values of floor vertices. A vertices - a more general solution.solution, IMO.

The BuildingStory class is unique to OpenStudio. It's indeed very handy for managing spaces in a model (e.g. placeholder for common default construction sets), for GUI visualization (as per your client requirements), etc. Yet it is neither forward translated to an IDF model, nor reverse translated from an IDF model. To the best of my knowledge, there's nothing one can add to an IDF file that will trigger new BuildingStory instances during reverse translation.

As suggested here and elsewhere, a limited number of IDF objects get reverse translated. How does one figure out which IDF objects get reverse translated (and how)? By exploring OpenStudio's ReverseTranslator.cpp (starting from Line 254). For instance, you alluded to ZoneList objects (Line 1032). Going over the actual code and comments (Line 40), one understands this is reverse translated as a SpaceType - not what you're after.after (so IMO, forget zone lists).

You could instead add BuildingStory instances to the reverse translated OSM model/file. Since you appear to be coding a solution (towards generating IDF files), it shouldn't be that challenging to interact with the OSM model using the SDK/API. Here's a Ruby example (Line 44) of reverse translating an IDF, and then accessing the generated OSM model.

An EnergyPlus Zone gets reverse translated (Line 33) as both an OpenStudio ThermalZone and Space. Only the latter can be linked to a BuildingStory. As you already seem to know which zones should be grouped under which building story, it should boil down to:

• adding to the OSM model as many BuildingStory instances as needed
• looping through each OSM space to identify its unique thermal zone
• assigning each space's building story as required (see setBuildingStory)

That should do the trick. There are other ways of doing something similar. This neat example sorts spaces vs building stories based on the Z-axis values of floor vertices - a more general solution, IMO.

The BuildingStory class is unique to OpenStudio. It's indeed very handy for managing spaces in a model (e.g. placeholder for common default construction sets), for GUI visualization (as per your client requirements), etc. Yet it is neither forward translated to an IDF model, nor reverse translated from an IDF model. To the best of my knowledge, there's nothing one can add to an IDF file that will trigger new BuildingStory instances during reverse translation.

As suggested here and elsewhere, a limited number of IDF objects get reverse translated. How does one figure out which IDF objects get reverse translated (and how)? By exploring OpenStudio's ReverseTranslator.cpp (starting from Line 254). For instance, you alluded to ZoneList objects (Line 1032). Going over the actual code and comments (Line 40), one understands this is reverse translated as a SpaceType - not what you're after (so IMO, forget zone lists).

You could instead add BuildingStory instances to the reverse translated OSM model/file. Since you appear to be coding a solution (towards generating IDF files), it shouldn't be that challenging to interact with the OSM model using the SDK/API. Here's a Ruby example (Line 44) of reverse translating an IDF, and then accessing the generated OSM model.

An EnergyPlus Zone gets reverse translated (Line 33) as both an OpenStudio ThermalZone and Space. Only the latter can be linked to a BuildingStory. As you already seem to know which zones should be grouped under which building story, it should boil down to:

• adding to the OSM model as many BuildingStory instances as needed
• looping through each OSM space to identify its unique thermal zone
• assigning each space's building story as required (see setBuildingStory)

That should do the trick. There are other ways of doing something similar. This neat example (Line 62) sorts spaces vs building stories based on the Z-axis values of floor vertices - a more general solution, IMO.IMO.

EDIT: Here's a hack that offers what you're after, strictly using the OpenStudio Application. The following screenshots are based on an imported IDF of the US Warehouse Prototype. An OSM version of the model holds a single BuildingStory (i.e. 1-story building) and 3 instances of SpaceType. Once the IDF is imported however, all instances of BuildingStory and SpaceType have been dropped (i.e. they have not been reverse translated).

Go the Facility tab, under the Stories sub-tab. Add as many new BuildingStory instances as needed. Here, I added 3 for the heck of it. No need to set any attributes.

Go to the Space tab, and drag-and-drop (from right-to-left) newly created BuildingStory instances to the suitable Spaces. In this case, I'm assigning a unique BuildingStory to each Space. In your case, I imagine 10-20 Spaces per BuildingStory.

Go back to the Geometry tab, and select which BuildingStory to visualize.

This is a banal example (3x spaces, 3x zones). It may be cumbersome (and error prone) to carry this out with 200 zones. Yet it may be easier than the coding solution I initially suggested. Whatever works for you and your clients ...

The BuildingStory class is unique to OpenStudio. It's indeed very handy for managing spaces in a model (e.g. placeholder for common default construction sets), for GUI visualization (as per your client requirements), etc. Yet it is neither forward translated to an IDF model, nor reverse translated from an IDF model. To the best of my knowledge, there's nothing one can add to an IDF file that will trigger new BuildingStory instances during reverse translation.

As suggested here and elsewhere, a limited number of IDF objects get reverse translated. How does one figure out which IDF objects get reverse translated (and how)? By exploring OpenStudio's ReverseTranslator.cpp (starting from Line 254). For instance, you alluded to ZoneList objects (Line 1032). Going over the actual code and comments (Line 40), one understands this is reverse translated as a SpaceType - not . Not what you're (initially) after (so IMO, forget zone lists).... (see EDIT below).

You could instead add BuildingStory instances to the reverse translated OSM model/file. Since you appear to be coding a solution (towards generating IDF files), it shouldn't be that challenging to interact with the generated OSM model using the SDK/API. Here's a Ruby example (Line 44) of reverse translating an IDF, and then accessing the generated OSM model.

An EnergyPlus Zone gets reverse translated (Line 33) as both an OpenStudio ThermalZone and Space. Only the latter can be linked to a BuildingStory. As you already seem to know which zones should be grouped under which building story, it should boil down to:

• adding to the generated OSM model as many BuildingStory instances as needed
• looping through each OSM space to identify its unique thermal zone
• assigning each space's building story as required (see setBuildingStory)

That should do the trick. There are other ways of doing something similar. This neat example (Line 62) sorts spaces vs building stories based on the Z-axis values of floor vertices - a more general solution, IMO.

EDIT: As you seem quite comfortable with ZoneLists, here's a Ruby script example that populates an OSM with BuildingStory instances from newly-created SpaceType instances (resulting from reverse translating an IDF holding ZoneList objects). Adapt the files/directories as needed.

file = File.join(__dir__, "files/idfs/test.idf")
path = OpenStudio::Path.new(file)
workspace = OpenStudio::Workspace.load(path)
raise("Empty Workspace?") if workspace.empty?
workspace = workspace.get

rt = OpenStudio::EnergyPlus::ReverseTranslator.new
model = rt.translateWorkspace(workspace)

raise("Existing Building Stories?") unless model.getBuildingStorys.empty?

model.getSpaceTypes.each do |type|
  name  = type.nameString
  story = OpenStudio::Model::BuildingStory.new(model)
  story.setName("#{name} STORY")

  type.spaces.each { |space| space.setBuildingStory(story) }
end

file2 = File.join(__dir__, "files/osms/test.osm")
model.save(file2, true)

Tested it on IDFs. Works on my end. If this works for you, great!

EDIT 2: Here's a hack that offers what you're after, strictly using the OpenStudio Application. The following screenshots are based on an imported IDF of the US Warehouse Prototype. An OSM version of the model holds a single BuildingStory (i.e. 1-story building) and 3 instances of SpaceType. Once the IDF is imported however, all instances of BuildingStory and SpaceType have been dropped (i.e. they have not been reverse translated).

Go the Facility tab, under the Stories sub-tab. Add as many new BuildingStory instances as needed. Here, I added 3 for the heck of it. No need to set any attributes.

Go to the Space tab, and drag-and-drop (from right-to-left) newly created BuildingStory instances to the suitable Spaces. In this case, I'm assigning a unique BuildingStory to each Space. In your case, I imagine 10-20 Spaces per BuildingStory.

Go back to the Geometry tab, and select which BuildingStory to visualize.

This is a banal example (3x spaces, 3x zones). It may be cumbersome (and error prone) to carry this out with 200 zones. Yet it may be easier than the coding solution I initially suggested. Whatever works for you and your clients ...