Using Rhino plugin for CIBSE TM59 overheating assessment

chriswmackey · November 28, 2023, 11:34pm

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 · December 11, 2023, 4:13pm

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 · December 11, 2023, 9:51pm

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 · December 11, 2023, 11:15pm

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 · January 5, 2024, 12:06am

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 · January 29, 2024, 3:54pm

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 · March 2, 2024, 8:49pm

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.

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.

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:

github.com

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


      
          
          
          def turn_off_old_tag(component):
              """Turn off the old tag that displays on GHPython components.
          
              Args:
                  component: The grasshopper component object, which can be accessed through
                      the ghenv.Component call within Grasshopper API.
              """
              try:  # try to turn off the OLD tag on the component
                  component.ToggleObsolete(False)
              except Exception:
                  pass  # older version of Rhino that does not have the Obsolete method
          
          
          def all_required_inputs(component):
              """Check that all required inputs on a component are present.
          
              Note that this method needs required inputs to be written in the correct
              format on the component in order to work (required inputs have a
              single _ at the start and no _ at the end).

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 · March 3, 2024, 10:53pm

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 · March 7, 2024, 8:49pm

Hey @milog ,

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 · April 8, 2024, 7:22pm

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 · April 10, 2024, 8:18pm

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:

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:

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 · April 16, 2024, 1:30pm

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

milog · April 17, 2024, 8:54am

Note - I just tried the above as a test and all bedrooms rooms in my model appear to fail the night time sleeping condition by a very significant margin so dont think the approach I have used is correct… For reference all rooms pass the night time sleeping condition when windows are set as fully open at T = 22C

chriswmackey · April 17, 2024, 10:03pm

Hey @milog ,

That approach with the Grasshopper components is not going to work as each component is overwriting the controls of the one that came before it. To create the “chain of controls” you’ll have to do some post-processing of the OSM (like I did for the AFN) or you can use additional IDF strings.

But just doing the chain of controls is not going to get you any special nighttime behavior. I looked at the EnergyPlus EDD and it looks like the EMS only allows you to control the total airflow rate (in m3/s) from outside to inside when you use the simple ventilation objects:

So it’s really simple and there’s no control of opening factors or anything like what you get with the AFN. Does the TM59 standard say anything about whether it’s ok to assume a constant flow rate through windows for the entire night time (regardless of wind speed or indoor/outdoor temperature difference)? If it’s not prescriptive there, then maybe there’s a way that you can still use the simple ventilation objects to check your compliance box.

milog · April 18, 2024, 10:38am

Hi Chris, the overarching methodology for compliance is dictated by Part O which states the following:

It sounds like meeting this to the letter is going to be difficult with the simple openings, but as a minimum I would feel a lot more comfortable with a system which uses a gradual opening for both the day and night time condition as this would put us in a reasonable degree of accuracy in terms of what Part O is asking for, and from what you have described this sounds possible using the simple openings.

This would allow us to run parametric studies relatively quickly, and IF a full model is required at a later stage we can always fall back on the AFN method to ensure we are following TM59/Part O exactly, at the expense of significantly longer run times…

The constant flow rate seems like a viable alternative but I’m not sure how we would correlate a m3/s flow rate at night to what a window opening would provide, given that window sizes vary between rooms?

chriswmackey · April 18, 2024, 6:21pm

Thanks for clarifying, @milog .

It’s a little odd that the standard is so specific about how exactly they want occupant behavior to be modeled yet they seem to be providing little to no information about how they want the airflow through the windows to be modeled. It just kinda opens up the potential for a lot of loopholes in the standard. Or it puts people in the position that we are in now where we are considering using a less realistic air flow rate just to say that the controls match the standard.

In any event, putting together something that does the gradual opening during the day is very straightforward with the simple ventilation objects. I’ll try to put together a sample for you at some point in the next few days.

And, at the least, I can use the schedules of the simple ventilation objects to set up a different set of controls at night. It may not be exactly as you have interpreted it, @milog , but I can set controls to just make the windows fully open when the internal temperature is above 23C and fully closed if the temperature is below this. Granted, when the internal temperature drops below 23C at night, the windows will close. But this is at least a little closer to how the standard is worded compared to just continuing the gradual opening at night.

We’ll start there and, if we later decide that we want to sacrifice the more accurate modeling of stack and wind ventilation at night for a constant air flow rate that follows your interpretation of the night time controls, we can always switch to that.

How does this sound?

milog · April 18, 2024, 9:12pm

This sounds great @chriswmackey, I really appreciate you taking the time to help us develop this process.

We are definitely on the same page here… the TM59/Part O guidance is overly specific in certain regards whilst also lacking the technical rigor in terms of specifying which software/engines us modellers are able to use for this type of comfort analysis, particularly in regards to how air flow should be modelled. All I could find is a few statements which state that ‘software with dynamic thermal modelling capabilities should be used’.

In summary, we are aiming to set up a workflow which we can clearly show that we have followed the framework to a reasonable degree of accuracy, ensuring we are ticking the boxes particularly in terms of Part O. I wonder if this work could eventually be packaged into a default set of standards into the Pollination software which would allow other users to run TM59 simulations, given that we have already set up all the profiles on our end, I think there would certainly be a high interest for UK based projects… food for thought!