I understand your desire here but this goes against the reusability of ProgramType objects since they’re meant to be abstract enough to be applied to Rooms of any size and fixing an absolute load to a program essentially breaks this. Granted, I am all for implementing anything else that makes your life easier here to apply a fixed load to multiple rooms at once but I feel strongly that Programs need to retain their current level of abstraction and specification in terms of per-unit values if we want to keep using them in all of the ways they are currently used across the plugins.
I don’t plan to implement anything natively in the Honeybee schema for this since the default supply temps of each HVAC system template are different and trying to expose them in Honeybee will make these HVAC templates fragile, harder to maintain over time, and easier for beginners to create bogus sets of controls. However, editing the OSM to tweak the setpoints only requires a few lines of code with the OpenStudio SDK and you can see here for an example of how I helped another user do just this:
This is currently supported natively in the Honeybee schema and the Rhino plugin. Occupant activity levels in EnergyPlus/OpenStudio are assigned via an “Activity Schedule,” which you can see is under the Room energy properties dialog:
So, if you want to change this, you have to create a new schedule with a ScheduleTypeLimit of ActivityLevel and schedule values in Watts. You can see a sample with the “Seated Adult Activity” schedule that comes by default with Pollination/Honeybee:
Yes- I get that it seems an odd request in this respect. For most applications, once at detail design stage we would tend to do room specific Watts figures based on the amount of equipment present, so we would override the standard template on a room by room basis. However, it is a feature of CIBSE TM59 (and also soon to be Building Regulations Part O) to use fixed heat gain (W) figures for types of rooms such as living rooms, kitchens, bedrooms. The sizes of these rooms could vary between houses/flats, but the Wattage is fixed (i.e., 1 TV, 1 Fridge, 1 Oven etc). I guess this is a specific application, but if we can get a Honeybee TM59 workflow going, it’s going to be potentially huge in the UK, where currently the only game in town for this is closed-source (and expensive) software.
Yes I understand there is a balance here. I think this opens up a wider question of what kind of analysis, and what kind of users you anticipate using the platform. We are coming from a detailed engineering analysis perspective, where we need maximum flexibility. We’ve so far only been looking at resi modelling, but things get a lot more complex with non-res and we would want to have control over quite a few things such as demand control ventilation (based on air quality and/or temp), multi-layered window opening control, and potentially HVAC systems too.
Will check out the OpenStudio SDK- got a few baby steps to take first to get some results!
How easy would it be to write a grasshopper script to calculate the W/m2 figure for each room and override the program value? ie
For each room
Get the programme type (e.g., kitchen)
Get the floor area
Calculate the W/m2 (a kitchen should have 150W, so do 150/floor area
Push this into the room equipment load
You may want to also check Ironbug. It takes advantage of the OpenStudio API to expose most of the functionalities that you’re looking for and works smoothly with the Ladybug Tools Grasshopper plugin.
This is what the HB Apply Absolute Load Values component already does. So you can just import the Pollination Model, use this component and then bake the model back to Rhino.
Here’s the list of ways that you can do detailed customization on the HVAC:
Both IronBug and the use of the OpenStudio SDK inside GHPython components use the .NET bindings of OpenStudio SDK. This is done primarily because Rhino is .NET-based but there are also cPython bindings for the OpenStudio SDK if you would rather use those to customize your OSM files exported from Pollination/Ladybug Tools.
Thanks for this Chris. So what I want to do next is group the rooms by the programme type, then apply different fixed Watts for equipment, etc, depending on the programme type. I’m trying to use the HB Rooms by Attribute component for this, how do I get this to work? See below.
You are on the right track. Just don’t flatten the _rooms input into the apply “Apply Absolut Load Values” component and then you should also graft your corresponding list of loads that are coordinated with each of those programs.
Is there a smarter way I can coordinate the heat gain values to the program name? I.e., program “TM59 4 bed: kitchen” automatically gets 150W applied to it? Perhaps what I’d like to do is filter the rooms by each program name, then apply the heat gain, then bring them back together?
I’ve come up with the below, which is successfully filtering the rooms, allowing me to apply heat gains according to the Program name. Does it look right? Can I reassemble the HB model as I’ve shown? What happens if I have shading objects?
If you have shade objects, just connect the shades output of the “HB Deconstruct Model” component to the shades_ input of the “HB Model” component at the end.
It’s been on my to do list for a couple of years now and I’ve finally built a script with the TM59 profiles that at a glance seems to give roughly the right ballpark of results. Need to do some serious checking over the next few days and validate against IES.
I also had the same issue as you with the window opening, would be great to be able to set this to Part O 22-26 opening, atm I’ve compromised and set it at 23.
I’m doing this purely through LBT atm, not using the Pollination Rhino Plugin.
Hi @charliebrooker, I’ve been a bit distracted recently by other things but check out this where @chriswmackey has written a sample TM59 workflow!
I’ve created the TM59 profiles in the Rhino PO plugin, which has a nice GUI for such things. Happy to share with you if helpful? (actually- how do I do this, presumably just share the Rhino file?)
I’m planning to spend some time pulling this all together in the next month or so, but my workflow will be something like:
Build geometry using Rhino Pollination Plugin
Pull model into Grasshopper
Simulate using Grasshopper PO plugin
Post process in Grasshopper with visualisations in Rhino
Like you I need to do some comparison with IES, although I wouldn’t say “validation” as I’m not sure I believe IES is any more accurate than EnergyPlus (and possibly less).
Unfortunately I’m not able to work in the Rhino PO plugin atm so can’t take you up on that generous offer!
I need to spend more time looking at the benefits of it to get a business case together.
I’m mainly using Rhino layers to manage geometry in a way that I can then quickly apply TM59 profiles etc. to the geometry.
I’m planning to run some comparisons with IES this week - will try and remember to feedback here to keep sharing the learning.
Totally agree with you on the “validation” point - I guess what I really mean is some kind of calibration, to ensure that the models are set up comparably in terms of their settings for natural ventilation, constructions, etc.
HB is orange,
IES is blue
Min comfort temp is purple
Neutral temp is green
Max comfort temp is red
Max adaptive temp is brown
I’m still getting my head around python, and need to do some digging into the differences between IES and HB (I’ve got some ideas in mind). But it’s nice to see proof of concept wise that the trends are pretty consistent between the two.
I just wanted to respond to this and say that it’s the right way to do this for now, though we realize that this only allows you to pass your standards between users of the Pollination Rhino Plugin.
We eventually want to add a command that will let you write all of these constructions, schedules etc. to your user standards that live at:
This will allow you to share the standards that you plan to reuse across multiple pollination models and between Pollination + Ladybug Tools (they all get loaded up from that folder and placed in your user library whenever you start the Pollination Rhino plugin or the Ladybug Tools Grasshopper plugin).
If you really wanted to make use of this workflow right now, you can import your ConstructionSets or ProgramTypes into Grasshopper from your Rhino model and write them into your user standards using the HB Dump Objects component. Then, you can zip up your standards library and share it.
