# Case Studies

If you're interested in time series analysis and forecasting, this is the right place to be. The Time Series Lab (TSL) software platform makes time series analysis available to anyone with a basic knowledge of statistics. Future versions will remove the need for a basic knowledge altogether by providing fully automated forecasting systems. The platform is designed and developed in a way such that results can be obtained quickly and verified easily. At the same time, many advanced time series and forecasting operations are available for the experts. In our case studies, we often present screenshots of the program so that you can easily replicate results.

Did you know you can make a screenshot of a TSL program window? Press Ctrl + p to open a window which allows you to save a screenshot of the program. The TSL window should be located on your main monitor.

Click on the buttons below to go to our case studies. At the beginning of each case study, the required TSL package is mentioned. Our first case study, about the Nile data, is meant to illustrate the basic workings of the program and we advise you to start with that one.

# Electricity consumption

Date: July 05, 2022

Software: Time Series Lab - Home Edition

Topics: three seasonal components

#### Electricity consumption

This case study is on hourly electricity consumption in megawatts. The data can be found here or in the TSL data folder under the name hourly elec.csv. The time series starts at 01/01/2005 00:00:00 and ends at 31/12/2017 23:00:00. The time series is challenging in several ways. First, the series is very long with 113,952 observations. Second, the series has multiple seasonal patterns with an intraday hourly pattern with a period of 24, a day-of-the-week pattern with a period of 24 × 7 = 168, and an annual seasonal pattern with a period of 24 × 365.25 = 8766 (taking leap years into account).

We use a training sample consisting of 105,192 observations that ranges from 01/01/2005 00:00:00 to 31/12/2016 23:00:00. The validation sample is the last year of the data set and consists of 8760 observations. With long time series like these, in combination with several dynamic components, estimation times can become relatively long. The goal of this case study is to find a good model and estimate the model parameters. Once these parameters are estimated and the forecasting performance of the model is satisfactory, in general the model parameters do not need to be estimated again for a while and forecasts are obtained quickly. The reason that model parameters do not need to be estimated again is because in most cases, adding data to an already long time series does not change parameter estimates by much.

#### Local level model

To set a benchmark, we model the time series with a Local Level model. Select a time-varying level on the Build your own model page, set the end of the training sample to 105,192 on the Estimation page and Estimate the model. TSL shows us the following estimates for the variances:

```
Variance of disturbances:
Variance type Value q-ratio
Level variance 7641.628 1.0000
Irregular variance 7.548 9.8772e-04
```

We see that the variance of the Level is very high compared to the variance of the Irregular. This means that the specified Level is not informative for the data, something not surprising since we know that several other important dynamics are not yet accounted for. No clear signal is found in the data and the best forecast for the next time period is just the last observation. The result of such a model is that the **Predicted** Level dutifully follows the data but the predictive power of the model is low, something we will see later. Zooming in on the beginning of the training sample we see the Predicted level following the data and lagging by one time point in the following figure.

Start a loss calculation on the Model comparison page to set a forecasting performance benchmark.

#### Path of Local Level model

#### Daily seasonal with a period of 24

Our next task is to model the intraday pattern of the electricity consumption with a seasonal component with a period of 24. Take 6 factors. After TSL is done estimating the model, we find our first seasonal pattern in the top panel of the figure below. After midnight, we see a decrease in electricity consumption which bottoms out around 4 am. From that point on, the day slowly starts and with that electricity consumption increases. It peaks at noon, goes down a bit and increases further to the daily peak around 7pm after which it declines till the next day starts. Interestingly, the differences between daily high and low values is larger during the summer as we can see from the bottom panel of the figure.

Start a loss calculation on the Model comparison page to see the effect on forecasting performance from adding the first seasonal.

#### Intraday seasonal pattern

#### Weekday seasonal with a period of 168

We continue building our model by adding the second seasonal, the day-of-the-week seasonal, with a period of 24 × 7 = 168. Take 6 factors. After TSL is done estimating the model, we find our second seasonal pattern in the figure below. The top panel is the extracted intraday pattern that we saw in the last figure. The mid panel is our extracted day-of-the-week pattern and we see that electricity consumption is on average lower on Saturday and Sunday compared to the weekdays. The bottom panel shows the sum of the two seasonal patterns.

Start a loss calculation on the Model comparison page to see the effect on forecasting performance from adding the second seasonal. The loss calculation becomes a time-consuming process since we have to make many **h-step-ahead** forecasts, see also Section 9.1 of the manual.

#### Intraday, day-of-the-week, and sum of both seasonal pattern

#### Annual seasonal with a period of 8766

The third and last seasonal component, models the annual seasonal pattern to take the differences in electricity consumption per month of the year into account. This seasonal behaves gradually over time since one periods spans 8766 observations. Take 6 factors. To have the third seasonal not interfere with the level, we can adjust the model in several ways. For example, limiting the variance of the level and the 3rd seasonal component by restricting them to a certain value. A probably more elegant way is adding an ARMA(1,0) component to the model which will effectively serve as AR(1) errors. The result is a smooth behaving level and 3rd seasonal component.

Our final text output is:

```
—————————————————————————————— PARAMETER SUMMARY ———————————————————————————————
Variance of disturbances:
Variance type Value q-ratio
Level variance 0.3892 3.6432e-04
Seasonal variance 0.8066 7.5514e-04
Seasonal variance 2 9.2342e-04 8.6447e-07
Seasonal variance 3 0.0000 0.0000
ARMA variance 1068.1885 1.0000
Irregular variance 0.0000 0.0000
Value Prob
Seasonal chi2 test 600.6 8.0100e-121
Value Prob
Seasonal chi2 test 1950.5 0
Value Prob
Seasonal chi2 test 500.1 2.0618e-99
ARMA properties:
Parameter type Value
Unconditional variance 41547.5465
AR1 phi1 0.9871
```

with the three seasonal components all extremely significant with p-values effectively zero. The following figure shows the extracted intraday, day-of-the-week and annual patterns. The bottom right panel is the sum of the three seasonal components. The botom left panel shows the annual seasonal component. it shows that electricity consumption has two peaks during the year. The first one is around february and the second peaks during the summer months.

#### Intraday, day-of-the-week, and sum of both seasonal pattern

It is time to compare the forecasting performance of our models. Start a loss calculation on the Model comparison page to see the effect on forecasting performance from adding the third seasonal. Plotting the losses of the four models in shown in the figure below. We see that in each modelling step, the loss is lower. It shows that taking into account the different seasonal patterns makes a lot of difference in forecasting.