I am trying to develop a workflow which enables me to conduct adaptive thermal comfort assessments for the UK’s CIBSE TM59 thermal comfort standard. This is similar to EN15251, but sets some specific modelling parameters for internal gains, and window openings. This is creating a few challenges in the Rhino plugin for me:
1) Internal gains from equipment
TM59 stipulates specific equipment internal gains figures - in Watts - for particular room types, e.g., a living room has 150W of equipment. This is then modulated using a schedule (which I have created in the plugin).
However, the plugin only appears to allow entry of a W/m2 value. This means I’d have to manually calculate this for each room size (possible but very fiddly for larger buildings).
Can you advise if there is another way around this?
2) Occupants
Similar to the above- TM59 specifies the number of occupants for each space (e.g., 2 people in a bedroom), the plugin is in people/m2.
It also specifies the heat gain (latent and sensible) per person- how is this changed in the plugin?
3) Window openings
It is about to become part of building code in the UK to use TM59 for residential buildings, but with some modifications. A key one is that windows should be modelled as opening on a “ramp function”, rather than a single temperature threshold. The idea is that this is a more realistic model of occupant behaviour- windows are not suddenly opened when the temperature reaches a threshold, rather they are increasingly opened as occupants get hotter.
As far as I can tell this isn’t possible within the current Rhino plugin, or the Grasshopper window control component. Is there a way you can think of to achieve this?
Thanks for your comments and they are all reasonable. Unfortunately, they are currently unavailable to do within any Pollination or LBT plugins as they require the Honeybee Schema to be updated to support such inputs.
I personally support these updates, @chriswmackey what do you think about this?
The first two issues that @chriss brought up were things I was thinking you might actually be able to add in the Rhino plugin UI. I still feel pretty strongly that there should be “one and only one obvious way” to check each of the loads assigned to a Room in a Honeybee model. I just know from experience that having to check multiple properties often means people assume that there’s “zero load” when it’s actually assigned by absolute quantity instead of per-unit area.
However, in the LBT Grasshopper plugin, we have a component called HB Apply Absolute Load Values, which will do the math for you, converting the “number of people” or “watts of equipment” into a per-unit floor area for each room so that it can be assigned to the honeybee model. Do you think we could add some similar functionality into the Rhino plugin?
Another feature that might be particularly helpful for the case of equipment is that the Honeybee schema supports Process Load definitions, which are always defined in terms of absolute load and you can apply as many as you want of them to a given Honeybee Room. It’s very helpful for modeling things like kitchen stoves and other large pieces of equipment and you might consider using this here, @chriss .
For item 3. that you brought up, @chriss , this is definitely model-able in OpenStudio/EnergyPlus but we don’t have native support for it in honeybee-schema since we effectively have all windows open when you hit the specified window-opening setpoint. This assumption has always worked pretty well for me and my understanding from a lot of the experts was that these “ramp functions” were an area that needed more research since there wasn’t strong evidence that they were any more accurate than just opening windows at a setpoint. Maybe this is changing now but I might still advocate for doing this via an OpenStudio measure or editing the OSM with the OpenStudio SDK with a workflow like what you see here.
Also, just to be sure I understand, this “ramp function” changes the window opening according to the INDOOR temperature, right? Not the OUTDOOR temperature? I ask because, if it’s the latter, you can simply set up this control using a ventilation schedule instead of needing to edit the OSM/IDF.
It would be interesting to see the research on this- I’d always assumed it would be a more accurate approach. Will check out the link- although might be a bit beyond me and the moment. FYI- from next month it will be a requirement in the UK to assess overheating in new dwellings with a methodology which includes a ramp function on the windows!
I’m just going off of Michael Humphrey’s and Susan Roaf’s “Adaptive Comfort” books. They’re at least 5 years old now so it’s very possible the research has progressed. But it’s also possible that some people thought that they knew better and put together a standard that makes it unnecessarily difficult for everyone else (as any daylight expert would tell you, it certainly would not be the first time that something like this has happened).
If you end up taking a stab at using the OpenStudio SDK to edit the Honeybee AFN EMS program for this “ramp function”, I would be happy to look it over ad check your work.
Hi @mingbo , I have found the “Process load” in the individual rooms, but it’s not available in the “Program Manager” - it would be great if it could be added in here too. This would enable fixed power values in W to be added to program types.
Hi @mingbo , thanks a lot for this- really great. Would it be possible to include this in the loads within the program manager? You see I’m trying to set up templates for various types of room (such as a living room) with a standard load (heat gain).
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.
