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.
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.
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);
@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…
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.