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.

Hi @chriswmackey, we have been making some progress on the TM59 grasshopper script (with the help of the post processing script you shared previously - thank you for that!) using rhino-pollination and it seems one of the final barriers which is preventing us from aligning the methodology with the TM59/Part O UK standards, is the ability to model a ramping profile for the windows according to the following:

  • Start to open when the internal temperature exceeds 22 C
  • Be fully open when the internal temperature exceeds 26 C

I have searched for what feels like every forum post on the internet to try and achieve this, and the closest lead I found was this example idf on page 86 here: https://energyplus.net/assets/nrel_custom/pdfs/pdfs_v9.5.0/EMSApplicationGuide.pdfEMSAirflowNetworkOpeningControlByHumidity.idf, which suggests the opening can be opened as a function of the indoor conditions. It seems we need to use an AFN in combination with an EMS. I would be extremely grateful if you could you please explain the steps required to achieve this inside of grasshopper?

Inside the HB AFN component, the comment on point 4 says: “4. For each Room with a VentilationControl object to specify setpoints at which
the windows open, an Energy Management System (EMS) program will be written to
dictate when the operable Apertures of the Room open.”

How can we modify this EMS program to be a function of the indoor air temp calculated at each time step and be used to create a fractional schedule for the opening.

1 Like

Hi @milog ,

I remember seeing some research from the UK a decade ago noting how window-opening behavior is often gradual and not all at once when a setpoint is reached. It seems like the way it has been written into the standard isn’t really how the research described it but I can see that their intent is probably to align with this research.

In any event, there are a couple of ways to do this with EnergyPlus, though neither are exposed in Honeybee VentilationControl and both would have to be added via additional IDF strings or a measure right now.

Is there anything in the standard that says you have to model the building air flow using an Airflow Network? Or is it acceptable to use simpler means of modeling the air flow through windows?

I ask because I can put together a sample that gives you the additional IDF strings for a simpler air flow model much more quickly that I can put together something that uses the AFN. For simple air flow, you’ll basically be using a series of ZoneVentilation:WindandStackOpenArea objects that change the Opening Area of each window as different room air temperatures are reached. Maybe you have 4 of them for each window, where each one gives you a different opening area for each degree Celsius rise in temperature.

2 Likes

Chris, thank you for your speedy reply. Ideally we would like to have more control over the natural ventilation modelling by using the AFN approach as this seems too be more desirable when carrying out dynamic simulation modelling (based on the guidance I have read), though I am keen to hear your opinion on this. That being said, the CIBSE guidance does not explicitly state whether it needs to be one or the other, so as a starter perhaps we could try and solve the simpler method first as you describe above as to have this in our current script would be one step closer from where we are now.

For reference here is a link which describes how IES models bulk air flow using MacroFlo: Applications MacroFlo

Some key highlights being:
MacroFlo incorporates models of:

  • Problems involving any combination of infiltration, natural ventilation and mechanical ventilation.
  • External wind pressure based on empirical data derived from wind tunnel experiments
  • Warmer air rising through building via stack effect (buoyancy)
  • Flow characteristics of infiltration via ‘cracks’
  • Flow characteristics of a variety of window types
  • Flow characteristics of large openings
  • Two-way flow through any openings internally or to outside
  • Resistance due to grilles and wall friction rayleigh instability modelling how cool air ‘falls’ as it interacts with rising warmer air

For each opening MacroFlo calculates:

  • Volume flows in and out
  • Mass flows in and out
  • Effective free area for air flow
  • Aggregated air flows for each room

Opening properties:

  • Wind exposure
  • Crack dimensions and flow characteristics
  • Free opening area
  • Timing and degree of opening
  • Opening controls, expressed as functions of weather variables and conditions recorded at any time in any room
  • Hourly wind speed, wind direction and external air density from weather file
  • Data from ApacheSim and ApacheHVAC building simulation and system thermal parameters can be used

I am interested to know what the capabilities of Energy Plus are and how much information we would be able to get from an EnergyPlus simiulation, vs IES in regards to how air flow is modelled for natural ventilation studies.

1 Like

To throw in - airflow networks are pretty important to us as a capability. We might get away without them for Residential buildings but for more complex buildings such as offices or schools (where we are likely to utilise cross ventilation or stack driven ventilation into an atrium, for example), it would be essential.

Hi @chriswmackey, just wondering if you had any further thoughts on this? :slight_smile:

Hi @milog and @chriss ,

Sorry for the radio silence here and I have not forgotten about this. It’s just that, because you asked to have a sample that works with the AFN instead of the simpler air flow objects, I have needed some time to think of the best way to put together a sample for you. If you can give me a day or two, I think I’ll give you something that post-processes the AFN EMS in object in the OpenStudio model using the OpenStudio SDK inside of a Grasshopper component. It will basically change the EMS control to just stagger the opening based on indoor temperature instead of opening the windows all of the way at a certain setpoint. If this sample does what you want it to, then the OpenStudio SDK code can be translated into an OpenStudio measure that can be run as part of any Pollination/LBT simulation (instead of needing to postprocess the OSM).

My personal opinion is that either the approach with the AFN or the simpler air flow objects can work well as long as you do diligence in checking all of the inputs and coordinating them with the expected airflow. The calculation that the AFN runs is truer to real fluid dynamics but it has a lot more inputs to check so I tend to only use it when I have enough time to verify all of these inputs and when the air flow pattern is complex (meaning that the AFN will save me some manual calculations that I might need to do to get the simpler airflow objects correct).

I would also be skeptical of lists of airflow capabilities without the formulas being used, the inputs that you need to supply, or the sensitivity of the results to these inputs. Practically all of the MacroFlo capabilities that you list there can be done with the E+ AFN and I would be willing to bet that you can get more outputs out of E+ than you can from any other energy simulation engine. I say this because E+ already has thousands of built-in outputs and because E+ is open source with a Python API. The Python API means you can get even more information out of the simulation if you wanted it. But a significant fraction of the air flow capabilities in that list are really only practical for researchers since I find that most people working on real buildings do not have the correct inputs that are needed to make use of them.

Just to give a really basic example, I know of a lot of people who have told me they want to run a full AFN yet they have no idea what the discharge coefficient will be for the windows on their building or even whether or not there will be insect screens. Trying to run an AFN without knowing precise things like that is like trying to repair a car when your only tool is a sledge hammer. If you’re going to run the AFN in a way that is meaningful, you really need a full set of tools, which often includes a bunch of manufacturer specifications for the window products and/or maybe some blower door tests/CFD studies of the components being used in the real building.

If you’re at the stage of design where you don’t know these things yet, you may just be better off running a bunch of shorter simulations with simple airflow objects so that you understand the sensitivity of certain parameters and how decisions like whether or not there are insect screens will affect the results. Those are just my thoughts on this and I think there is a time and a place for all of those capabilities of the AFN. It’s just that the time and place is pretty clearly not “all of the time” and “everywhere.”