Overheating TM59

@chris

Hi,

I have been applying the TM59 script you had previously posted. (CIBSE TM59 - Grasshopper Workflow - #2 by mostapha - Grasshopper Plugin - Pollination Discourse)
Its really helpful (thanks!) and works well with single zone models but recently I noticed some things when working with more zones:

  1. Using your TM59 script for multi zone models causes the results to double up and also the first zone always has a results that is “fractional”. This does not happen when I input just one zone from the exact same model. I noticed the data only doubles after the “LB apply conditional statement”, so possible its the true/false results and I need to remove the falses?

  2. Whenever I test multiple zones using the TM59 script, the flip component gets an error saying “1. All paths in the input tree must have the same length” but no error when testing one zone.

GH.zip (239.0 KB)

I recommend watching some tutorials on Grasshopper Data Trees since it seems that this is what you’re struggling with here.

Your script is running fine for me:


GH_CWM.gh (119.6 KB)

That’s interesting, the same script works on one computer but not on another? But thanks I will look into the data tree outputs that should help narrow the issue down :grin:

Hi wtrmln,

Just to add to this - the data trees of the results need to match in structure in order for the occupancy schedule to apply to the air temperature & radiant temperature results which are getting collected.

The graft component in the example Chris helpfully supplied (Thank you!) fixes this issue for when you have multiple sets of results from rooms in your model. It’s just kind of hidden within the component rather than using the “Graft Tree” component which I find to be more explicit as per explanation in LB Adaptive Comfort for occupied hours only.

++++

As a follow up for anyone using this workflow, there is a chance that the example script Chris supplied is not culling unnocupied hours after applying the “LB Apply Conditional Statement” and this will produce an incorrect final % uncomfortable result which you may not notice at first (i didn’t!)

I found in my testing that the schedule/occupancy data was the 3rd data collection feeding into the “LB Apply Conditional Statement” component and so needed to change the statement from “a >” to “c >” to fix this. I added a “Merge” component which I believe orders the data collections which again i feel is more explicit to show which data collection the statement is being applied.