Using Rhino plugin for CIBSE TM59 overheating assessment

@mostapha is this possible? Eg bring in Pollination rooms from Rhino to grasshopper, alter the fixed hear gains, push back to Rhino?

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.

1 Like

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.

1 Like

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.

Something like this?

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?

1 Like

It looks good to me!

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.

Hey @chriss,

How are you getting on with this?

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.

Cheers,
Charlie

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).

Chris

2 Likes

Thanks @chriss!

Unfortunately I’m not able to work in the Rhino PO plugin atm so can’t take you up on that generous offer! :slight_smile:
I need to spend more time looking at the benefits of it to get a business case together.

For reference this is the very early workflow I’ve got set up at the moment, mainly working in grasshopper:
220728_Resi_Box_Model_4Dwellings.3dm (47.7 KB)
220728_Resi_Box_Model_4Dwellings.gh (694.5 KB)

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.

Cheers,
Charlie

Hey @chriss,

Thought you might like to see this.


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.

2 Likes

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:

C:\Users\[USERNAME]\AppData\Roaming\ladybug_tools\standards

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.