Missing Parameters in Rhino+GH plugin

@mingbo @mostapha
I have watched 13 IronBug tutorial videos, and I searched some HB/IB components in GH.

I don’t expect that Rhino and GH plugins cover all of the energy model settings, but I would like to know how much can be set in Rhino+GH and how much needs to be set in osm/idf files.

I quickly listed out parameters that I often use in EnergyPlus but couldn’t find in Rhino+GH plugin. May I know if each parameter can be set in Rhino+GH plugin or not? Just Y or N is fine.
Thank you.

Rhino Plugin

Temperature Difference Between Cutout And Setpoint in ZoneControl:Thermostat

Do HVAC Sizing Simulation for Sizing Period in SimulationControl

1 Like


Thank you for the note but unless there is a good reason not to expose the parameters, or it is too much work to expose them, our goal is to minimize the need to edit OSM/IDF. Even if there is a need to make some of those edits in the OSM/IDF file we should explore the option to use OpenStudio measures. Particularly, if they are repeatable tasks.

@mingbo and @chriswmackey should be able to help you with each item. Hopefully, more than just a Y or N, in particular if the answer is no. I’m also interested in a better understanding of the reasoning.

It might also be helpful for us to understand why do you need these objects in your workflow. At least for the ones that we don’t currently support.

Discourse only lets me assign the topic to one person! Feel free to re-assign the task to Mingbo once you respond to the ones that are not Ironbug related.

Hey @keigonomura ,

I can answer the ones for the Rhino plugin and Honeybee. As @mostapha said, we want every practical thing that you might want to simulate to be assignable from our interfaces. So you can probably hold us to the statement that everything will be supported eventually.

The only major difference in the way that we do things in Pollination/LBT vs. EnergyPlus is that we believe there should be one, and preferably only one, obvious way to model something and EnergyPlus certainly does not follow this philosophy. So, if we’ve decided never to support a certain E+ object, it is probably because we have another recommended way of modeling it. As an example, you will never see us using any of the E+ geometry objects that are not specified from a Detailed list of 3D vertices. Sure, EnergyPlus has 5 other ways to write the geometry but those are not relevant when we have a robust way of editing, validating and translating the detailed 3D geometry.

Maybe one other thing that might cause us to delay exposing certain features is that certain E+ objects are just so easy to apply to your exported models right now using the “additional IDF strings” input that you can find on all of our simulation components and recipes. So we have not felt the pressure to expose them because the people who use them at the moment have been fine with that workflow. But, if you put pressure on us, we can add it as something assignable through a more formal interface. You’ll see these all labeled with a N/Y?* below because saying they’re not exposed is kinda a lie when I have used them through additional strings.

Going down the list and using Y for already-exposed features, P for pending features on our roadmap, which have a good chance of being exposed this year, and N for things that I don’t yet know when they will be exposed or how:

Rhino Plugin
Compliance:Building N (Maybe within the Appendix G recipe if I understand it)
ZoneCrossMixing Y
Exterior:Lights P
Exterior:FuelEquipment P

Site:GroundTemperature:BuildingSurface N/Y? *
Site:GroundTemperature:FCfactorMethod P
Temperature Difference Between Cutout And Setpoint in ZoneControl:Thermostat N
WindowMaterial:Screen P
MaterialProperty:PhaseChange N/Y? *
SurfaceProperty:OtherSideCoefficients Y
SwimmingPool:Indoor P
ZoneVentilation:WindandStackOpenArea Y
DaylightingDevice:Tubular N
CurrencyType N/Y? *
UtilityCost:Tariff N/Y? *
UtilityCost:Charge:Simple N/Y? *
OutputControl:ReportingTolerances Y
Output:Surface:Drawing N
Output:Disgnostics N/Y? *

* It’s just very easy to add it with additional strings so this is what everyone does right now.


Do HVAC Sizing Simulation for Sizing Period in SimulationControl I think Y, but @chriswmackey can confirm.

ZoneAirContaminantBalance P

I am not sure if this should be added to Ironbug or Honeybee. I think it should be better exposed within Honeybee than Ironbug. @chriswmackey what do you think?

ZoneControl:ContaminantController P soon
AirTerminalSingleDuct:Mixer Y: AirTerminalSingleDuctInletSideMixer
HeatExchanger:Desiccant:BalancedFlow P soon
ThermalStorage:Ice:Detailed P soon
FluidProperties:GlycolConcentration N not available in OpenStudioSDK
LoadProfile:Plant P soon
WaterHeater:Stratified P mid-term
AirLoopHVAC:DedicatedOutdoorAirSystem P mid-term
AirLoopHVAC:ExhaustSystem N not available in OpenStudioSDK
SetpointManager:MixedAir P mid-term
Table:Lookup P soon

Prioritize add needed

Thank you, @chriswmackey and @mingbo!

@keigonomura, can you help me to better understand the importance of each of these items in your workflow so we can prioritize them accordingly. It will be helpful if you can group them based on the importance, and workflows.

@mostapha, I picked up high priority parameters below. Please find my comments in italics.

Rhino Plugin
Exterior:Lights P Most projects have exterior lighting.
Exterior:FuelEquipment P Process loads such as Lift/Escalator electricity are often modelled with this when we don’t want to add the load to specific zone.

Site:GroundTemperature:FCfactorMethod P Necessary for ASHRAE 90.1 compliance for both the Baseline case and the Proposed case.
Temperature Difference Between Cutout And Setpoint in ZoneControl:Thermostat N Normally, HVAC systems has Thermostat Throttling Range, and this is one of the options to model the range.

ZoneControl:ContaminantController P soon Necessary to model DCV with CO2 sensors. Most of my models have DCV with CO2 sensors.
AirLoopHVAC:DedicatedOutdoorAirSystem P mid-term I often have projects with a PAU which is connected to multiple AHUs. This object is necessary to model such equipment connection.
SetpointManager:MixedAir P mid-term Necessary to take into account downstream supply fan heat and adjust the setpoint temperature.

Output:Disgnostics N/Y? * To DisplayAllWarnings and fix models. By default, not all warnings are shown in the err file.
SwimmingPool:Indoor P I often model buildings with swimming pools.
Output:Surface:Drawing N Just to visualize the geometries in the idf file and double-check if they are modelled as intended.

The others are more project-specific and lower priority.

Btw @mingbo, I didn’t know that AirLoopHVAC:DedicatedOutdoorAirSystem is available in OpenStudio SDK. Could you please tell me how to model it with OpenStudio?

Thanks, @keigonomura .

I’ll prioritize the two things that are difficult to apply with additional strings, which are the Site:GroundTemperature:FCfactorMethod and maybe the ZoneControl:Thermostat. Can you give me a sample of how ZoneControl:Thermostat is supposed to be used? Some of the inputs seem redundant from the ThermostatSetpoint:DualSetpoint that we use for all thermostats exported from Pollination/Honeybee right now. Do we have to replace the thermostat with something else?

After those two items, I can work on Exterior:Lights, Exterior:FuelEquipment, and SwimmingPool:Indoor, which are all easy to expose but also really easy to add right now with additional strings since they are just additions to the IDF and they don’t require any edits to the objects that are exported currently.

Output:Disgnostics is so specific to advanced EnergyPlus users that I think this might remain an additional strings item for a while but I will keep your request in mind. And Output:Surface:Drawing is one of those things where we have recommended workflows that do effectively the same thing but much better (eg. Open IDF in the Pollination Rhino plugin or open the OSM or IDF in the OpenStudio Application). So I would really like to leave this as an additional strings item such that people don’t get the impression that that we recommend using it. If you use either of the two methods above and can tell me what they lack, which the DXF written by E+ has, then I’ll know if we can make some useful edits to the software here.

Yes, all of SimulationControl is already exposed on SimulationParameter.

I’ll have to see an example of what @keigonomura specifically wants here. If he just wants us to expose the “Carbon Dioxide Generation Rate” property on the People objects that we are already exporting from Honeybee, then yea, it belongs in Honeybee. Anything else like controllers based on CO2 probably belong in Ironbug.

Hi @keigonomura, this is one of the new objects that I noticed OpenStudio team added. I haven’t really used it, but I did a quick test, and you can start with the following sample code (no promises, don’t count me one this:> ).

            var model = new OpenStudio.Model();
            var airloop = new OpenStudio.AirLoopHVAC(model);

            var oaControler = new OpenStudio.ControllerOutdoorAir(model);
            var oa = new OpenStudio.AirLoopHVACOutdoorAirSystem(model, oaControler);
            var doas = new OpenStudio.AirLoopHVACDedicatedOutdoorAirSystem(oa);

@mingbo Do you think we can visualise AirLoopHVAC:DedicatedOutdoorAirSystem in OpenStudio Application? I installed the latest version (v1.7.0). The HVAC Systems tab looks the same as the earlier versions. I don’t see the object for AirLoopHVAC:DedicatedOutdoorAirSystem in the Library…

No, I don’t think it is available in the OpenStudio Application.

1 Like


ThermostatSetpoint:DualSetpoint is for cooling and heating. It’s not for modelling Throttling Range.
The image below (from this website) is good to understand Throttling Range.

In reality, HVAC systems have cooling/heating setpoints with Throttling Range. Without Throttling Range, cooling/heating fluctuates ON/OFF frequently, which leads to equipment failure. It also affects energy consumption. Energy models with Throttling Range has a little larger cooling/heating energy than models without it.
Actually, Temperature Difference Between Cutout And Setpoint in ZoneControl:Thermostat does not model both upper and lower throttling ranges like the image above. It’s very tricky to model Throttling Range same as the image (Please refer to my post on UnmetHours if you have time). Temperature Difference Between Cutout And Setpoint may not be perfect but is good to take into account Throttling Range to some extent.

Make sense. Output:Surface:Drawing is not necessary.