Weighted Running Mean not called

Hi All,

I’m doing some scripting for CIBSE TM52 methodology and I think the weighted running mean never gets calculated.

I’m setting the False flag on _avgm_or_runmean in the LB Adaptive Comfort Parameters component, which then gets passed on to LB Adaptive Comfort, on line 140 we have:

comf_result = adaptive_comfort_en15251(prevail_temp, to)

where prevail_temp is the outdoor temperature collection. All makes sense up to here, but taking a look at the source code in ladybug_comfort.adaptive — ladybug comfort documentation

t_comf = neutral_temperature_en15251(t_prevail)

and then at ladybug_comfort.adaptive — ladybug comfort documentation

return 0.33 * t_prevail + 18.8

I can’t seem to find where ladybug_comfort.adaptive.weighted_running_mean_daily gets called. The function is already defined so I figure I’m missing something.

Anyway, all this comes from figuring out how to calculate the maximum acceptable temperature (Tmax): Tmax = 0.33 Trm + 21.8 for TM52 3rd compliance criteria.

Should be fairly simple to add this output to one of the comfort components and would be very useful to us dealing with overheating analysis in the UK. I do realise there’s other things in the docket.

best, M

Glad to see you’re deep in the source code, @Mauricio . This is where GitHub’s “Search” feature comes in handy. If you’re asking where in the process of the LB Adaptive Comfort component that method gets called, I think it usually does not get called. You can see here in the source code this is the place where it could get called:

… but this only happens when you plug in a Daily Data Collection for the prevailing temperature input. More often than not it is the weighted_running_mean_hourly function that is getting called instead.

Also for this:

Have you seen this discussion on the Pollination Forum yet?

Hi Chris,

I hadn’t seen that particular thread but I did stumble onto several others, not quite as detailed though, thanks for sharing.

I took a similar approach but I wanted to do a lot of the modelling leg work automatically in grasshopper. e.g., calculating windows equivalent open area, setting the TM59 programs etc. So my workflow involves modelling and naming in the Rhino plugin and then a bunch of processing in grasshopper.

About the weighted running mean: in my mind it makes sense this function should get called when you toggle on the British standard, as this is required by the standard. But I got around it by a simple python component that calls on LBs library and the created a PrevailingOutdoorTemperature collection that goes into the outdoor temperature input on the adaptive comfort component.

The way you sorted out the ramping up the window opening is clever, man. Fair play! Nonetheless, take a look at Jamie Sullivan’s solution in this thread: EMS for window ramping up.

It requires an AFN network but it’s a very nice representation of how occupants may behave, and it avoids some possible edge cases that may produce misleading results. i.e, you wouldn’t fully open your windows with 30m/s winds outside, even if it’s hot inside.

I simulated the summer bypass on the MVHR with an HB Fan ventilation object, I’m using Ideal Air Loads so recovered heat is not consequential to TM59. However, this solution doesn’t work with AFN, it just doesn’t affect mechanical ventilation loads… not sure why.

I agree with the previous thread about using simple ventilation, I’ve had some significant discrepancies in results when introducing AFN to the simulation (for worse), which shouldn’t be the case.



Hi @Mauricio ,

I really like Jamie Sullivan’s response there. I especially like that he opens with this:

One of the first things you’ll need to accept is that, whatever you do, your modelled ventilation will be “wrong”, whether due to the inaccuracies in the calculations or the uncertainty in occupant behavior.

It’s very true in my experience and, at this point in my career, I have accepted that most of the cooling energy savings that we see in the real world from natural ventilation likely doesn’t even have all that much to do with the things that we’re obsessed with modeling like the mechanics of airflow or the complexities of occupant behavior. I sense that a lot of the savings just comes from a different perception of the thermal environment that occupants get when they’re able to open windows, which we see reflected in the differences between the PMV and Adaptive models. But I probably would not have arrived at this conclusion without spending so much time obsessing over the other parts and realizing that they don’t usually affect the energy use much unless you also change the comfort model and move some thermostat setpoints around to reflect that.

Clarification on the Adaptive Model in Ladybug-Comfort

I realize that my response before might not have been clear that the weighted_running_mean_hourly function does the same exact type of calculation as weighted_running_mean_daily. They both use daily average temperatures to determine the prevailing outdoor temperature. It’s just that one of them works with hourly data and the other one works with daily data. So the reason why you are not seeing the weighted_running_mean_daily method being called is that you’re working with an hourly data collection and not a daily one. I hope that clears things up.

A Note About AFN Modeling with EMS

I know that the post I linked to there is very long and I’m not sure if you checked the Grasshopper definition in this part but, if you jump to my response right here in the thread:

You will find a Grasshopper script where I edit the EMS controls that we export with the AFN from honeybee such that you’ll get gradual window-opening behavior exactly how the TM59 standard describes it. If you’re willing to edit the little “Python postprocessing” component that I wrote there using the OpenStudio SDK, you can probably implement Jamie’s EMS program exactly in a way that it can scale to a Honeybee model of any size.

With all of this said, I think you’re right that people are coming around to recognizing the value of something simpler rather than a complex set of EMS controls with an AFN. Like Jamie said, your airflow and occupant behavior controls are always going to be at least a little wrong and, at least with something simpler, you can wrap your head around all of the assumptions that you’re making.

Hi Chris,

Your sense is probably right, comfort is heavily influenced by occupant agency over their environment. And when we create models we have to accept there is always some deviation from reality. Luckily, I guess, I enjoy modelling even as frustrating as it can be.

Re weighted running mean - That makes sense now.

I did read through the entire post but didn’t get a chance to look at the grasshopper definition you shared. It’s on my neverending list of things to do.

Thanks for everything, Chris.

all the best,


1 Like