Charging for peak demand - Pyosch/powertac-server GitHub Wiki

up

In the real world, the cost of delivered energy has two main components: the cost of generating it, and the cost of delivering it. Generation cost is dominated by fuel prices, while delivery cost consists of capital and O&M cost for the overall capacity to deliver it, including generation capacity and grid capacity. Of course, the capacity to deliver energy must be sufficient to support the maximum demand for power that might be anticipated over some future horizon.

In an environment where the bulk of energy is generated by fossil fuels, the fixed (capacity) and variable (fuel) costs of delivered energy are of the same order of magnitude. In rural distribution cooperatives in Wisconsin, where over 70% of energy is generated by burning coal, they are nearly equal. However, wind, solar, and hydro supplies have zero fuel cost, making capacity costs the dominant factor in delivered energy cost from these sources.

Much of the cost of capacity in modern grids is in the transmission infrastructure, which in the Power TAC scenario is behind the wholesale market. Since the need for capacity is driven by peak demand rather than mean demand, it makes sense that brokers should pay for their (customers') contribution to demand peaks. But demand peaks are only discernible in retrospect. For example, Wisconsin rural distribution cooperatives pay in year n for their contributions to demand peaks during year (n - 1). They generally have only two tools to manage demand peaks: curtailment, and demand charges in tariffs for large customers. Both of these are very blunt instruments.

Power TAC has two features that complicate the application of capacity costs to individual brokers. One is the short duration of the scenario, the other is the rapid churn of customer portfolios. What we need is a mechanism that fairly allocates capacity costs to the brokers who are using capacity during demand peaks, and avoids motivation for unproductive strategic behaviors. Here are some potential principles:

• Brokers should be charged based on their individual contributions to measured demand peaks.
• Demand peaks should be measured over time horizons that make sense in the context of the Power TAC scenario, even if they are not global peaks. For example, the horizon should be an integer multiple of a week, because demand is typically lower over weekends. It should be shorter than a month, because that is half the length of a tournament game.
• Start-of-game and end-of-game effects should be carefully considered. For example, we have a 2-week bootstrap period that can be used at the start of a game; costs for peaks during the bootstrap period might be allocated based on an assumption of equal market shares. Alternatively, an end-of-game capacity payment could be assessed.
• Since short-horizon demand peaks are in general smaller than the global peaks that actually drive capacity costs, it might make sense to pro-rate peak-demand charges based on the ratio of measured peaks to an assumed global peak, which could be a game parameter.

Data

To get a better idea of how we might make peak-demand a clearer concept, we have studied demand peaks in the 230 games of the Power TAC 2015 finals. Assuming the most of the capacity costs come from the transmission system and large-scale power providers (the other side of the wholesale market from the brokers), we'll consider "net demand", the demand satisfied through the wholesale market whether it was purchased by brokers directly, or provided by the Balancing Market through the wholesale market. Here is what the net demand looks like on weekdays and weekends. The contours are percentiles. The big spread in the middle of the day is caused by the variable output of the Solar Leasing customer. Note that there are occasions on weekends when net demand drops below zero.

Another way of looking at this is as a histogram. Here is the distribution of overall demand in the 2015 final round.

So if we say that the lowest net demand that qualifies as a 'peak' is one std dev above the mean, that would be about 61.5 MW. The highest observed demand across the 230 games was about 138 MW. One might argue that the demand distribution is skewed by the high solar production, which is true - it reduces the mean, and increases the std dev. So for comparison, here's the histogram for the 2014 final round, which was 72 games and nearly the same customer population except for the solar production. One std dev above the mean for this set is about 66 MW.

Let's look at "peak demand" over some horizon. If at every timeslot we look at the highest demand over the last 7 days, we get the distribution on the left below. If we look over a 21-day horizon, we get the distribution on the right. This one has more density at higher values, and is "choppier" because fewer peak events are observed a larger number of times. The highest peaks are observed in every timeslot for 21 days, around 500 times.

Identifying and evaluating peak demand events

There are several ways we might identify peak-demand events in order to assess capacity charges. Here are some examples:

1. In each timeslot, look at net demand. If it's above a threshold (perhaps 65 MW), then a fee is computed as (peak - minPeak) * capacityCharge, and allocated to brokers according to their relative contributions to the peak.
2. In each timeslot, look back at the past n timeslots (perhaps n = 336, or two weeks), the highest peak over that period is identified, and a charge is applied, perhaps computed the same way as in the previous case. By this means, smaller peaks are masked by larger peaks, and the largest peaks are observed and assessed multiple times. This is what is plotted above.
3. Every n timeslots (perhaps every two weeks, for example), the highest peak (or perhaps the highest m peaks) over the last n timeslots is identified and assessed. This has the advantage of #1 in which each peak is observed and assessed just once, and of #2 in which larger peaks mask lower nearby peaks.

To get an idea of what the capacity charges might be for peak-demand events, we need to know how many there are per game and how big they are. If we want to scale the charges to the wholesale cost of energy, we also need to know what brokers are spending for energy. Here is a histogram showing the total cost of cleared trades in the wholesale market over the 230 games of the 2015 final round:

Next, we look at the weighted sum of peak events over 70 MW, observed by method 3 above. The histogram shows how the weighted sum is distributed across the games of the 2015 final round. Note that there about 8.5 weeks in each game, and the mean weighted sum across the games is 120.6, so there are about 14.2 weight points (difference between observed peak and minimum threshold) per week to be assessed.

If we want the total capacity charges per game to be the same order of magnitude as the wholesale energy costs, we would have to allocate something over 1E6 Euro over 120.6 weight points per game, or about 8300 Euro per point.

Proposal

With this background, here is a specific proposal:

1. Brokers should pay for both capacity and for the capital and O&M costs of the distribution grid.
2. Capacity charges will be computed periodically by finding the highest n peaks that exceed a threshold over an assessmentInterval. The threshold would be computed as (mean + thresholdCoefficient * stdev) where the mean and std deviation are computed from the start of the bootstrap period through the assessment timeslot. For each identified peak, the total fee across all brokers would be (peak - threshold) * feePerPoint, allocated to individual brokers in proportion to the relative net consumption values among their customer portfolios in that timeslot. As a result, a broker whose customers use less energy or produce more during a peak timeslot would pay a lower capacity fee.
3. Distribution charges would be assessed in each timeslot in the form of "meter fees" -- for each individual customer, a fixed amount would be assessed in each timeslot. Customers would be divided into (at least) two categories for this purpose: small customers and large customers.

Given this structure, how should the values of the various parameters be set? Ideally, they should be large enough to motivate brokers to manage the overall demand profile, preventing peaks from exceeding the thresholds computed in each assessment intervals. In addition, it has become clear that the cost of balancing services has not been high enough to motivate broker developers to take advantage of customer-side balancing resources. Therefore, one possible goal would be that the costs of capacity and balancing be at least within an order of magnitude of the cost of energy. Here is the bank balance for an example game, with a single sample-broker, using the customer population and wholesale market setup from the 2015 competition. This broker makes no attempt to control peak demand, and its balancing performance is very primitive, especially in the presence of significant solar production in its customer portfolio.

Note the impact of the weekly peak-demand assessments. Cost distribution in this game is as follows:

Energy cost	balancing cost	distribution fees	capacity fees	bank interest
-5,682,973	-3,781,872	-1,213,458	-3,415,098	5760

Parameters used to produce this result are as follows:

regulation premium	small-meter fee	large-meter fee	assessment interval	threshold coefficient	fee per point
1.8	0.015	0.05	168	1.2	-180

where the regulation premium is the base cost of balancing energy as a proportion of the "spot" price on the wholesale market. The spot price is the highest price paid for the given timeslot, which is typically, but not always, seen in the 1-hour-ahead closing.