Forward modelling and energy usage prediction

Not sure if it has been discussed elsewhere but I would be interested to know how the ‘expected usages’ (green, amber and red bands) are calculated.

For gas I imagine a daily degree day value is used combined with the formula from the regression analysis and some magic… If this is the case then no questions asked here, it makes sense…

What about electricity?

The reason I am asking is because I would like to be able to explain to the building manager why we think the ‘expected usage’ should be within the amber band (at the very least), and why it is bad if the actual usage is within the red band… I am sure his first question would be 'why we set the red band that ‘high’?

@Graeme ?

many thanks

Good questions.

The basic answer is provided in this post:

We actually apply the same method to electricity and to gas. The methodology uses the Bayesian Information Criterion (BIC) to balance improved model fit against increasing the number of variables in the model. We only uses outside air temperature if the BIC registers an improvement, otherwise we use a simple average model. This is applied to every half hour slot, so each building can have a very different overall model structure. This applies to all datasets, electricity, gas, water etc…

In the case of electricity the algorithm often does include temperature as a factor. We are probably picking up pumps and fans in heating systems but also using temperature data as a proxy for daylight availability. This would obviously be a significant factor in half hours which are affected by daylight.

This is something we have been discussing lately in the project. Whether this is useful or not is an open question. It has the benefit of simplicity and usually provides a decent fit to the data. However, the model has limited options to choose from so can introduce problematic predictions sometimes.

I am interested in exposing the model structure in more detail in the user interface. This is a fairly big challenge and requires upgrades to our infrastructure so it is not currently being pursued actively.

However, we are looking at ways to make the temperature correction optional. I am imagining a simple checkbox to force the model to a simple average. This would be part of the virtual meter configuration.