search

openeemeter / eemeter

An open source python package for implementing and developing standard methods for calculating normalized metered energy consumption and avoided energy use.
http://eemeter.openee.io/
Apache License 2.0
220 stars 70 forks source link

Daily Model Overpredictions - eemeter version 4.0 #487

Open khosravym opened 8 months ago

khosravym commented 8 months ago

In this specific zone, the heating system has reached its maximum capacity, resulting in a plateau in energy usage. However, the regression used for prediction has not been split appropriately. It’s important to note that this issue is not about the heating balance point; rather, it pertains to properly handling the regression when HVAC is operating at its maximum capacity.

image

travis-recurve commented 8 months ago

From what I can see this is entirely expected. It's a linear model out here. There is no functionality to decrease the slope. As far as splitting goes, it's done based on season and weekday/weekend. There appears to be no weekday/weekend separation and it has already split on each season.

khosravym commented 8 months ago

As suggested, when the current equipment hits its peak capacity, there’s no further rise in energy usage observed. Therefore, the possibility of a plateau at the end or at extreme temperatures is quite plausible. A potential solution might resemble the TOWT approach, where a bin is used to divide the regressor.

travis-recurve commented 8 months ago

When we were working on the daily model my idea was to have a segmented heating/cooling model. For example in a heating region a breakpoint would be allowed to exist within the current heating linear model, breaking it into 2 lines but the slopes would still be required to be ≤ 0. This could also be smoothed, but this is a nontrivial problem. I was looking at using a circle or ellipse to create the arc to do the smoothing because we cannot use the existing exponential as that converges to the prior slope at infinity as opposed to the set breakpoints.

Overall the idea would look something like the image here.

Picture1

This would be an improvement, but would also require time to ensure that it was fast, accurate, and bugfree.

Proper penalization would also need to be done to ensure that the model is not creating a breakpoint when it is unnecessary to do so. We do not want to get right back where we are with the TOWT model where it is overfit.

khosravym commented 8 months ago

Could we divide the summer or winter into two categories according to the Outside Air Temperature (OAT)? This would mean that instead of classifying by month only, we introduce an additional classification to distinguish between normal and extreme OAT for each month. The shoulder months remain unchanged.

travis-recurve commented 8 months ago

It's possible. I don't think this is nearly as clean of a solution. How do you decide a priori how to further segment the season? Different buildings are going to behave differently. This could require a modeling step that might be thrown away?

Another issue is that each thing you add like this makes the fitting time factorially worse. Originally we had to test for every possible combination of split. We simplify this by checking if clusters of points overlap. This would require that we either go back to fitting all possible splits, but worse, or that we ensure this split reduction method continues to work.

Overall, I am still convinced that the method I explained above is the best because it retains the ability of disaggregating heating and cooling loads. If you keep splitting and splitting then you have to justify those splits and it will eventually impede the ability for the model to give information about heating/cooling load disaggregation.

If you want to try to tackle any of this, feel free. I am personally unable to dedicate significant time to further development of the daily model. If you did want to do this we can further discuss the requirements of any daily model.