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.
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.
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:BuildingN (Maybe within the Appendix G recipe if I understand it) ZoneCrossMixingY Exterior:LightsP Exterior:FuelEquipmentP
HoneyBee Site:GroundTemperature:BuildingSurfaceN/Y? * Site:GroundTemperature:FCfactorMethodP Temperature Difference Between Cutout And Setpoint in ZoneControl:ThermostatN WindowMaterial:ScreenP MaterialProperty:PhaseChangeN/Y? * SurfaceProperty:OtherSideCoefficientsY SwimmingPool:IndoorP ZoneVentilation:WindandStackOpenAreaY DaylightingDevice:TubularN CurrencyTypeN/Y? * UtilityCost:TariffN/Y? * UtilityCost:Charge:SimpleN/Y? * OutputControl:ReportingTolerancesY Output:Surface:DrawingN Output:DisgnosticsN/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.
ZoneAirContaminantBalanceP
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:ContaminantControllerP soon AirTerminalSingleDuct:MixerY: AirTerminalSingleDuctInletSideMixer HeatExchanger:Desiccant:BalancedFlowP soon ThermalStorage:Ice:DetailedP soon FluidProperties:GlycolConcentrationN not available in OpenStudioSDK LoadProfile:PlantP soon WaterHeater:StratifiedP mid-term AirLoopHVAC:DedicatedOutdoorAirSystemP mid-term AirLoopHVAC:ExhaustSystemN not available in OpenStudioSDK SetpointManager:MixedAirP mid-term Table:LookupP soon
@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:LightsPMost projects have exterior lighting. Exterior:FuelEquipmentPProcess loads such as Lift/Escalator electricity are often modelled with this when we don’t want to add the load to specific zone.
HoneyBee Site:GroundTemperature:FCfactorMethodPNecessary for ASHRAE 90.1 compliance for both the Baseline case and the Proposed case. Temperature Difference Between Cutout And Setpoint in ZoneControl:ThermostatNNormally, HVAC systems has Thermostat Throttling Range, and this is one of the options to model the range.
IronBug ZoneControl:ContaminantControllerP soon Necessary to model DCV with CO2 sensors. Most of my models have DCV with CO2 sensors. AirLoopHVAC:DedicatedOutdoorAirSystemP 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:MixedAirP mid-term Necessary to take into account downstream supply fan heat and adjust the setpoint temperature.
HoneyBee Output:DisgnosticsN/Y? * To DisplayAllWarnings and fix models. By default, not all warnings are shown in the err file. SwimmingPool:IndoorPI often model buildings with swimming pools. Output:Surface:DrawingNJust 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?
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);
doas.addAirLoop(airloop);
@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…
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.
Sorry for such a late response. We just got finished with a series of workshops where and we’re planning to get back to some key development tasks now. Upgrading to the latest version of EnergyPlus/OpenStudio is one of the first things on our list now and I think we’ll use the opportunity to add support for some of the EnergyPlus features that you requested here.
In particular, I took a closer read through your description of the Temperature Difference Between Cutout And Setpoint and I read your UnmetHours post. What you said makes a lot of sense and I didn’t realize how easy it is to expose given that we’re already writing the ZoneControl:Thermostat object. In fact, I think I’ll start adding support for it now since it’s so straightforward and won’t take me more than half a day. It may be a while before you see it exposed on the Rhino interface but you can expect this one to be ready soon.
Hi @chriswmackey, I feel this ZoneControl:ContaminantController object probably should be added in Honeybee while you are adding the ZoneControl:Thermostat, because this object doesn’t need to connect to any HVAC system/loops, it is more a room setting as the same as thermostat.
I added SwimmingPoolIndoor object into Ironbug as it need to be added a plant loop’s demand side and it makes sense to be included in Ironbug with more controls with other systems.
Hi @keigonomura, I also added SetpointManager:MixedAir to Ironbug and it should be ready in the next release.
That’s a big help that you added the SwimmingPoolIndoor object to Ironbug. Looking it over, I think you are right that it’s more like a HVAC system object than it is like an internal load, which is how I was originally thinking about it. The fact that you need an inlet and outlet for the water definitely puts it in the HVAC category.
I agree that the ZoneControl:ContaminantController object belongs in the core Python/Honeybee side rather than the Ironbug side. It has more in common with the criteria that govern how the Room is used than it does with the HVAC system that might be designed to meet that criteria. I opened an issue for it here:
@keigonomura , can you confirm that the only CO2 sources that you’ll be modelling are from people and maybe some gas equipment? If so, can you confirm that the default E+ value of CO2 generation from people is suitable. This seems to be 0.0000000382 m3/s-W of human activity (or 0.0084 cfm/met/person as ASHRAE 62.1 defines it). Also, do you have a suggestion for the CO2 generation rate of gas equipment (typically gas stoves) per Watt of gas consumed? If so, I’ll make sure that this makes it into the IDFs exported from our end.
