Using Rhino plugin for CIBSE TM59 overheating assessment

[chriswmackey]

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.

[milog]

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.

[chriss]

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.

[milog]

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

[chriswmackey]

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

[chriswmackey]

@milog and @chriss ,

It ended up being faster than expected to put together a sample that changes the AFN output by honeybee to gradually open the windows.
afn_with_gradually_opening_windows.gh (116.9 KB)

In the sample, you’ll find a small component that I wrote, which post-processes the OSM with the AirflowNetwork in it:

It essentially goes through all of the EMS program objects that tell the AFN when to open the windows and changes them from this simple logic with one setpoint:

… to this more complex logic that gradually opens the windows with each degree rise in room temperature (between 22C and 26C):

The resulting OSM can be simulated with the HB Run OSM component as you see in the sample file.

Let me know if this gives you what you need. As I said earlier, this custom postprocessing component can also be converted into an OpenStudio measure if you want to run it as part of the simulation process in any Pollination recipe.

[milog]

Hi @chriswmackey , this is amazing! Thank you so much for your help on this… I have managed to succesfully integrate this component into the current TM59 script I have set up on my PC.

One last thing I would like to hear your thoughts on, currently I am applying this ventilation control during the hours 8AM - 11PM using a ConstantSchedule On/Off component. This ensures the EMS program is applied only during this time period and as a result, does not capture nighttime ventilation. This leads me onto the final adjustment I need to make according to Part O, which is the allowance of windows to be fully opened if the internal temperature exceeds 23 degrees C at 11PM, during the hours (11PM - 8AM). Is there a way to peice together two seperate EMS programs? So that, between 8AM - 11PM we use a ramping profile EMS system, and between 11PM - 8AM we apply a simple ventilation control to be fully open if the indoor temperature recorded at 11PM >= 23C, otherwise keep closed.

I tried to achieve this by using two VentControl components in series but they seemed to conflict/overrride one another, which might be due to the way the python component you wrote is applying the EMS?

Thanks again for your help on this so far Chris, much appreciated.

[chriswmackey]

Hey @milog ,

The EnergyPlus EMS lets you write practically any logic that you want so I’m sure that it’s doable. I have written EMS programs that use schedule values in the logic but I have never written an EMS program that depends on something that happens several hours earlier in the E+ simulation, which is what you are after with the night time operation. So I will have to check examples for this. Give me a few days and I’ll hopefully have a sample.

[milog]

Hi @chriswmackey thanks for the speedy response. I’m not sure if I am overcomplicating it but it sounds as though the check would need to be a single check on the hour (11PM), if the internal temp > 23degC then open windows fully for the duration of the time period (11PM - 8AM), otherwise, keep the window closed. At least that is how I have interpretted this statement from the Part O document:

"b. At night (11pm to 8am), openings should be modelled as fully open if both of the following apply.
i. The opening is on the first floor or above and not easily accessible.
ii. The internal temperature exceeds 23°C at 11pm. "

The floor level criteria is not a concern right now as that can be dealt with seperately.

Just wanted to clarify this.

Thanks!

[chriswmackey]

Hi @milog ,

Sorry that it took so long for me to get to get back to you here and I hope that you have had a happy new years. I have put together a solution that gets the EMS to behave exactly as you have described it and here is the sample Grasshopper file with an updated component that edits the EMS:

afn_with_gradually_opening_windows_and_night.gh (117.9 KB)

The way that I have gotten it all to work is by using a special schedule value for 11 PM, which you can see that I assign here in the Grasshopper script:

And I have changed the edits of the EMS program to recognize this special schedule value like so:

Basically, when the EMS senses this special schedule value, it will override everything else with the logic of open the windows fully when the temperature is >= 23 or close them fully if the temperature is < 23.

What follows from this is the typical controls that gradually open the windows more as the temperature increases. However, you’ll notice that these “gradual opening” controls only happen when the schedule values are >0, which you can see is only from 8AM-11PM in the schedule values.

Because there is no statement to set the opening values when the schedule value is zero, the windows should remain exactly as they were when they were last set in this condition. This should mean that the opening status remains constantly closed or open until 8AM given the value that last happened at 11PM.

Let me know if you get the chance to test this and confirm whether this addresses your case.

[milog]

Hi @chriswmackey , apologies for the radio silence here, and happy late new year to you too! I have found some time to look at this again and I was able to successfully integrate the night time ventilation into my current grasshopper script, so thank you very much for this!

We are using Rhino 8 now so I have re installed pollination for Rhino 8, so far so good.

Our next step of development which could be fairly complex is the inclusion of MVHR in the model. For residential Passivhaus dwellings with MVHR units, we need to be able to include this in the TM59 modelling, how do you recommend we go about doing this? Ironbug seems like the most appropriate, but potentialy more complex solution, do you have any experience with this, as I couldnt find much guidance on the LBT forum.

For reference this is the type of unit we would look to model: Compact P - Nilan | England & Wales Distributor

I have also attached our latest grasshopper TM59 script, if you have any time it would be great to get some feedback on the approach we have arrived at. One thing that I have noticed to be potentially a little awkward is appling different opening areas to different windows/rooms easily in Pollination-rhino. In vanilla honeybee-grasshopper this would be fairly straight forwards by referencing surfaces, grouping in grasshopper and applying free area that way, but I couldnt find a straight forwards way of doing this in Rhino Pollination… any thoughts?

One final comment, after the upgrade from Rhino 7 to 8, some of my python components have the ‘old’ tag, I have been able to migrate most of these except this one which contains the following code:

import honeybee_energy

data = honeybee_energy.result.match.match_rooms_to_data(data_collections, rooms, invert_multiplier=False)

a=
b=
for i in data:
a.append(i[1])
b.append(i[0])
result = a
room_name = b

when I transfer over to python3 component I get the following error shown in the screenshot below. Any ideas as to why this is the case, and how I could fix this?

231107 TM59 Workflow_Pollination_MG_V4.gh (411.8 KB)

[chriswmackey]

Hi @milog ,

Sorry for the late response here. For MVHR, I recommend opening a separate topic because we are starting to get away from the evaluation of natural ventilation for the TM59 standard and we’re more into specifics about passivhaus. There are a few ways to model heat recovery in Pollination/Ladybug Tools but it would be good to have a summary of what exactly you want to be simulated in order to be able to recommend the right one to you. For example, is am I correct that you are trying to run this heat recovery without any heating/cooling system.

@milog

One thing that I have noticed to be potentially a little awkward is appling different opening areas to different windows/rooms easily in Pollination-rhino.

I personally find applying different operable fractions to different apertures to be MUCH easier in the Rhino plugin compared to Grasshopper. You just select all of the apertures in the Rhino document that you want to set a certain operable fraction on, then you use the PO_EditApertureProperties command to pull up an interface where you can specify the operable area of all the Apertures at once:

Note that, to have the most control over the Aperture selection you may want to turn the Room selection off first:

With this approach, you can easily specify different operable fractions for different windows of the same room, which is much harder to do in Grasshopper.

@milog

One final comment, after the upgrade from Rhino 7 to 8, some of my python components have the ‘old’ tag

Yea, I would not worry too much about the OLD tag as your GHPython components are all still fully functional in Rhino 8. It’s just that McNeel added a new script editing interface, which they are trying to get everyone to use so they label the original one as OLD. If it bothers you, you can call this method inside the component to turn the OLD tag off:

ladybug-tools/ladybug-rhino/blob/master/ladybug_rhino/grasshopper.py#L93

@milog

when I transfer over to python3 component I get the following error shown in the screenshot below. Any ideas as to why this is the case, and how I could fix this?

As I said above, I would not worry about upgrading to the new Python components yet. You can either keep using the old component (optionally turning off the old tag) or, if you really want to use the new components, you should use IronPython instead of the cPython3 one (unless you have watched all of Ehsan’s tutorials and you set up your Ladybug Tools dependencies correctly). But we are not planning to upgrade our own Python components any time soon since it will be a long time until the whole community is using Rhino 8 and, even though McNeel labels the component as OLD, they have told us it will be a very long time before the deprecate them.

[milog]

Thanks @chriswmackey that is super helpful! Is it possible to do this aperture opening application via rhino layers in some way? For example if I had different window geometries drawn on separate layers (grouped by aperture opening for example). This would be handy if the aperture opening areas changed for a particular window aperture group at a later design stage, or if you wanted to test different aperture opening areas for different window groups when simulating.

The only way I can imagine doing this is to then reselect all apertures you want to change manually in rhino, and then batch changing the opening areas using the command you describe above. Could you please clarify, apologies this is probably more due to my lack of understanding of the plug in rather than the limitations of pollination itself!

And yes I’ll post the MVHR question on a separate thread with more details on the type of system we are looking at

[chriswmackey]

Hey @milog ,

@milog

Is it possible to do this aperture opening application via rhino layers in some way?

Yea, this is do-able by just right-clicking on the layer with the apertures and hitting “Select Objects”. Then you use the PO_EditProperties command to set the opening area like I said above. Granted, this won’t try to change the properties of any objects just because you move some new geometry onto this layer. But just reselecting the Apertures by layer and editing their properties should be pretty fast.

[milog]

Hi Chris, just an update as to where we are at with this TM59 testing… I have spent my time recently testing the grasshopper script on a test geometry file from one of our internal projects. We have existing TM59 results from an IES model/simulation so I converted this GEM into a HBJSON file using the honeybee-ies methods and converted into a full pollination model which seemed to work great!

One of the issues I noticed with our current TM59 script is how long the simulation takes to run! For reference there are about 200 rooms in the model and the simulation took about 2-3 hours to run (locally). I then tested without using the AFN, and instead ran via the pollination cloud which took 10 minutes, which is roughly the amount it time it took to run the model in IES for reference.

In light of practical usage of this TM59 script moving forwards I am keen to move away from the use of the AFN and instead use the simple ventilation controls which we had been using previously, and I think this agrees with your intial concern in using the AFN anyways, nevertheless I think it was necessary to test in this scenario.

This leads on to my actual question, without using the AFN is it possible to configure the ventilation control objects in such a way so as to capture the ramping profile? I think you mentioned this would be possible using multiple ventilation control objects connected in parallel in some way? In addition would the night time ventilation opening (conditional) be possible without using the AFN? Ie - if temp > 23C at 11pm then open windows for the duration of the night.

It’s a shame the AFN increases simulation time by so much as the previous snippets you provided helped us produce a fully working script TM59 simulation (at least for small models), hence my inclination to return back to a simplified set up which does not use an AFN. Apologies for all the messages on this platform the past couple of days, hopefully they are useful to us both, and I’m not just taking up your valuable time!

Milo.

[chriswmackey]

Hi @milog ,

I’m glad you are coming around to seeing the value of the simpler ventilation objects and maybe appreciating the fact that we designed things so you can switch between the AFN and the simpler method right before simulation. This way, you don’t have to re-do the whole assignment of ventilation properties when you see how time-consuming the AFN can be.

To answer your question here:

@milog

This leads on to my actual question, without using the AFN is it possible to configure the ventilation control objects in such a way so as to capture the ramping profile? I think you mentioned this would be possible using multiple ventilation control objects connected in parallel in some way?

Yes, you can definitely set up the gradual opening controls by just using several ZoneVentilation:WindandStackOpenArea objects for each window. Since each of these objects includes controls for the zone temperatures at which the windows open and close, you basically set them up so that, as the zone temperature rises, another object with a higher opening area gets activated as the previous one with the lower opening area gets deactivated.

This part is more complex if you want it to match exactly what I wrote for you with the AFN:

@milog

In addition would the night time ventilation opening (conditional) be possible without using the AFN? Ie - if temp > 23C at 11pm then open windows for the duration of the night.

I think you are probably going to need the EMS to do this. I think you should be able to use the EMS to activate and deactivate the ZoneVentilation:WindandStackOpenArea objects just like you used it to activate parts of the AFN. To know for sure, I would have to request an EDD file from EnergyPlus using the Output:EnergyManagementSystem object. The EDD would say for sure if you can use the EMS to just override the simple ventilation objects.

[milog]

Hi @chriswmackey, thanks for this. Can you just verify the approach below is correct?