The BX Tab

MetrixND provides several options for determining whether a variable is useful. Typically, a model builder reviews the variable coefficients, standard error, t-statistic and p-values. These statistics are located on the “Coef” tab as shown below.

bxtab1

 

 

 

 

An evaluation of the variable coefficients shows that each variable is significant and behaves as expected. For instance, the CDD70 variable has a t-statistic of 11.563 (statistically significant) and indicates that when cooling degree days (CDD70) increase, sales increase by 1.896 units.

While these numerical results are useful, a graphical depiction of the variable aids the understanding of the variable’s contribution to the model. In the regression model object, the BX tab provides the picture of each explanatory variable’s contribution to the predicted value.

In the figure below, the contribution of CDD70 (red line) is compared to the model’s predicted value (blue line). Formally, the CDD70 line is calculated from the CDD70 variable value and the CDD70 coefficient (BCDD70 x XCDD70).

bxtab2

 

 

 

 

 

 

 

 

 

 

The power of the graphic is visual clue about what each variable is doing to generate the predicted value. In this example, the CDD70 variable is responsible for the summer cooling shape.

A closer inspection of the graphic (zooming into 2014 in the figure below), shows how CDD70 only contributes to the predicated values in May through October. So while the predicted value decreases from April to May, the graphic tells us the decrease is not caused by the CDD70 variable because CDD70 does not contribute to the April predicted value.

bxtab3

 

 

 

 

 

 

 

 

 

 

Coupled with the traditional variable statistics, the BX view enhances the model builder’s understanding of variable’s contribution and power. Begin using the BX tab and add it to your box of model building tools.


Who is Forecasting Long-Term Solar Generation?

In this last forecasting brown bag presentation on solar load forecasting, we asked participants who had developed a long-term solar load forecast before 2013 and after 2015. As expected, very few had done a forecast before 2013 and majority put together something after 2015. During the last Vermont state forecast we did in 2014, solar wasn’t even a major topic until, of course, the month before the forecast was due. But what is a reasonable approach?

We started by collecting monthly data on installed systems and number of customers for each state starting in 2010. Then we compared saturation rates – what we found is that those states with the highest return on investment had the highest level of saturation. People make rational economic decisions after all! Well, at least some people do. Armed with this information, we estimated a regression model for Vermont that relates system saturation to system economics using a simple payback to capture system economics. And guess what? It worked. We were pleasantly surprised; when we used a cubic specification the model fit was awesome. We have used this model in several service areas – some with high saturation-levels (Nevada) and some with very low saturation (Indiana) and it seems to work, most of the time. This model approach was laid out in the brown bag presentation.

If you google “Forecasting New Technologies” you will find dozens of approaches. Most of these entail fitting an S-shaped curve to your own or like technology data set. If you have tried a Bass Diffusion model or Fisher-Pry logistic curve fit model or something else, we would love to hear about it. We all need to forecast solar generation – let’s share approaches!


Developing the Peak Day Dataset Using MetrixLT

I think of MetrixLT as a fancy load shape manipulator and calculator. While the software was originally designed to calibrate load shapes to monthly energy forecasts, newer features of MetrixLT allow users to calculate normal weather (including Rank and Average methods), add and subtract load shapes, and perform top-down calibrations of hourly loads. Within the myriad of features, I’ve found a hidden gem that helps me forecast peak loads. MetrixLT builds my monthly peak database.

The foundation for the monthly peak model is historic monthly peaks and the weather associated with those peaks. Monthly peaks are obtained from historic hourly temperatures. Once the peaks are identified, the dates of the peaks must be used to obtain the associated weather. Instead of culling through complex Excel formulas, MetrixLT creates this database from daily peak data in a single transformation.

An example of the results is shown below. In this figure, the January 2005 peak is 900 MW. The temperature that produced the 900 MW peak is 16.42 degrees. Likewise, the temperature on the day before peak is 33.13 degrees.

forecasting1

 

 

 

 

 

 

 

 

While this figure shows the temperature and prior day temperatures associated with the monthly peak, MetrixLT can provide any daily condition associated with the peak, such as dew point, wind speed or demand response estimates.

To create a monthly peak database, use the Frequency Transformation in MetrixLT. This transformation converts data of a different periodicity into monthly data. Begin by creating the Frequency Transformation and setting the frequency to “Monthly” as shown below.

forecasting2

 

 

 

 

 

 

 

 

 

Within this Transformation, insert variables you want shown in the peak database. In this example, three variables are included.

1. Monthly Peak. The monthly peak value is obtained by creating the variable and placing the daily peak series in the “Source” box. Assign the method “Maximum” and Transform will return the monthly peak value.

forecasting3

 

 

 

 

 

 

 

 

 

 

 

 2. Temperature on the day of the Peak. The temperature on the peak day is obtained by creating another variable and placing the daily temperature series in the “Source” box. Assign the “Coincident Max” method and insert the daily peak series in the Coincident Max box as shown below. This transformation will return the daily temperature coincident with the monthly peak value.

forecasting4

 

 

 

 

 

 

 

 

 

 

 

3. Temperature on the day before the Peak. The temperature on the day before the peak is obtained with another variable. In this variable, assign the daily temperature series as the “Source”, select the “Coincident Max” method, and assign the daily peak series in the “Coincident Max” box. For this variable, assign “Coin Lag” the value of “1”. This transformation returns the daily temperature coincident with the monthly peak value, lagged one day.

forecasting5

 

 

 

 

 

 

 

 

 

 

 

While the three variables in this example result in the database shown at the top, the example is easily extended to obtain temperatures two days before the peak or daily wind speed on the peak day by defining more variables. Once all the desired variables are included in the monthly peak database, simply export the data, import the values into MetrixND, and build the monthly peak model.


Creating a Nonlinear Growth Variable

I love straight lines. After all, the fastest route between any two points is a straight line. But in forecasting, going from point A to point B isn’t always as straightforward as we imagine.

There are two ways to capture long-term growth in electric sales. The best way is to correlate growth with a macroeconomic driver. The process involves endless iterations of testing alterative series until you find one that works and makes sense. For those of us with less patience, a linear trend is used, which captures the average growth over the historic period and apply it to the forecast. While this is easier, we understand that past growth won’t always happen in the future (thus the need for a macroeconomic driver).

Another option is to create a growth variable which captures growth based on a percent increase in each year. But, how do you create this growth variable in MetrixND? In Excel, creating a growth rate variable is as simple as creating the following formulas assuming that X is the growth rate.

C4=C3*(1+x)
C5=C4*(1+x).

For example, a one percent growth rate beginning with a base value of 1.0 will yield a value of 1.01 in the second period. In six periods, the value grows to 1.0510. These first six values are shown below.

Period

Index Value

1

1.0000

2

1.0100

3

1.0201

4

1.0303

5

1.0406

6

1.0510

In MetrixND, the same index can be created using four transform variables in a transformation tables. First, create two variables that serve as the base index value and the growth rate. Second, create a period index. Finally, create the growth index using the first three variables as shown below.

forecasting3

The transformation table result as well as a graph of the Growth index is shown in the final two pictures.

forecasting2

forecasting1

Keep the growth rate index in your toolbox of modeling techniques. You never know which technique will work best when developing your models and long-term forecasts.

 


Using In-Line Transformation in the Report Object

 

I’m developing a forecast that requires base, high, and low scenarios.  After building the base scenario, the high and low scenarios are created by duplicating the base scenario process, changing the tables names from “Base” to “High” or “Low” and updating the equations.  The result is a structure where the variable names are identical, but the table names indicated the scenario as shown below.

 

Using this structure, I build a Report Object that exports the Residential Sales variables for comparison in a summary MetrixND file.  I create the Report object by dragging and dropping the variables into a single Report.  The comparison Report of the Residential sales is shown below.

 

I like to import the Report into a second MetrixND project file so I can develop comparison graphs and objects.  Using a second MetrixND project file helps me reduce the clutter of my project files pushing diagnostic and summary information away from my primary forecast models and variable development.

 
The problem is that the Report cannot be imported into a second MetrixND project file.  When I attempt to import the table, I get the following error because the three variables are named “Residential”.  The import process does not recognize that the variables come from different tables.

 

 

To solve the problem, I use the “In-Line” transformation in the Report Object.  In the Report Object, “right-mouse-click” to bring up the “Insert Inline Transform” option.

 

Selecting this option initiates the “Edit Transform” dialogue box.  To obtain the same results as before, I define a unique name (e.g. High) and set the formula to equal the High Residential sales variable.

 

Replicating the process three time (i.e. for High, Base, and Low), I construct the same Report Object as before, but I now have unique names for the Residential forecast values.

 

This Report can now be imported into a second MetrixND project file or the new Forecast Manager system.  The In-line transform feature of the Report Object is a useful to rename variables, create equations, or summarize results prior to exporting the data.  The ability to create new names makes the report a powerful tool for connecting a MetrixND project file to MetrixLT or Forecast Manager.

 

 


DON'T MISS A POST!
I agree to have my personal information transfered to AWeber ( more information )
Opt in to receive notifications when a blog post is published. Don't miss the thought leadership, insight and news from Itron.
We hate spam. Your email address will not be sold or shared with anyone else.