Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Consider adding non-elec demand driven additions in capacity #106

Closed
robbieorvis opened this issue Oct 28, 2020 · 14 comments
Closed

Consider adding non-elec demand driven additions in capacity #106

robbieorvis opened this issue Oct 28, 2020 · 14 comments
Assignees
@jrissman @robbieorvis @mkmahajan
Labels
3.5 high priority

Comments

@robbieorvis
Copy link
Contributor

Right now the EPS will only build power plants to meet electricity demand, peak demand, or comply with an RPS. But under certain circumstances, new power plants will be deployed based purely on costs. For example, in a system that is oversupplied but with a huge carbon tax, the model would currently change the dispatch order but not choose to build new, zero carbon resources.

We should think about how we might add a mechanism by which the model would choose to build new resources based on cost as well as demand instead of only based on cost.

One thought is to change the cost based retirement mechanism to encourage retirement of power plants when they are uneconomic not just against the existing fleet but also against new power plants (have to think more about what this would look like). This would induce retirements and push the model to build more. It's a little backwards (instead of having new deployment drive this we would have retirements drive it) but it's one option.
@jrissman
Copy link
Contributor

The early retirement mechanism was designed to handle this case. It retires things early when the difference in cost between that plant type and the average plant is wider (more expensive) in the policy case than the BAU case. A huge carbon tax will cause the fossil resources to retire like crazy, which should rapidly deal with the oversupply issue. Then the model will build wind and solar as soon as the retirements start cutting in below energy need.

If the system is sufficiently oversupplied, maybe it will take a year or two for the plant retirements to catch up and get rid of all the excess supply, but in the real world, utilities can't retire an entire coal fleet in a day, and stretching it out over a few years probably adds realism.

So I'm not sure why the current early retirement system can't handle the case you describe. Maybe you just need to tune the input data that adjusts the sensitivity of early retirements to price increases, so the retirements happen faster?

@robbieorvis
Copy link
Contributor Author

robbieorvis commented Oct 28, 2020 via email

@jrissman
Copy link
Contributor

I guess it depends on the magnitude of the oversupply. In your example, the system is so oversupplied that it could retire all of the coal and still meet the energy need with the gas it already has. In that case, you are right, it would not retire the gas, because the gas is not more expensive relative to the mean. (In an exclusively coal/gas system, a carbon tax actually makes gas cheaper relative to the mean, since gas's carbon intensity, and hence effective tax rate, is half that of coal. So the carbon tax increases the mean cost more than it increases the gas cost. Then as coal retires, gas becomes closer to, and eventually equal to, the mean. Gas never becomes more expensive than the mean.)

But imagine the oversupply isn't so large as in your example. Let's use your example, except electricity demand is for 150 GW, not 100 GW. Now when all the 100 GW of coal retire, the remaining 100 GW of gas can't meet the demand. So the model builds 50 GW of renewables. That pulls down the mean cost of power, which will in fact make gas more expensive than the mean once enough coal retires. So as RE gets larger and coal goes away, the carbon tax will gradually start causing early gas retirements, too. This graceful hand-off in response to changing market conditions is one of the nice properties of our current early retirement system.

We also wouldn't see an issue in a system that already had 1/3 RE, 1/3 gas, and 1/3 coal (even if the coal were entirely extraneous) because the RE holds down the mean, and will cause gas retirements once enough coal is gone, similar to the example above.

So it seems like your example only demonstrates a problem because (1) there is no existing RE, and (2) the coal is entirely extraneous, so they are able to retire all of it and still meet energy demand, so no RE gets built. That is a combination of factors we never thought about when designing this part of the model, probably because we deemed it unlikely to arise in real-world practice.

Have you encountered this issue using real-world data in one of our EPS regions, which could be used for testing/debugging? There are many cases throughout the EPS where it cannot produce realistic results unless given realistic input data.

@robbieorvis
Copy link
Contributor Author

robbieorvis commented Oct 28, 2020 via email

@jrissman
Copy link
Contributor

Okay, when it's time, just point me to the EPS deployment (repo and branch) that is showing this issue, and I'll look into it and work on a fix. I don't think the following should be happening:

a model with 100 GWh renewables, 100 GWh coal, and 100 GWh of gas but with 200 GWh of demand could retire all the coal and then do nothing, because the natural gas plants become the marginal resource driving cost changes

because I thought the early retirements are based on differences in cost of each source relative to the mean (in policy case vs. BAU), and retiring half the fossil plants should pull down the mean tremendously, which should make the gas vulnerable to early retirement. If it's not happening that way, it might just be a bug or something odd about the input data, and I'd like to investigate the behavior and see what's going on, using real data. I want to make sure the existing EPS model components are working as intended before we consider whether to introduce new conditions under which plants are built.

@robbieorvis
Copy link
Contributor Author

robbieorvis commented Oct 29, 2020 via email

@robbieorvis
Copy link
Contributor Author

Hi @jrissman, not sure if you've had a chancel to follow up on this, but another example would be with the Nevada model. A strong carbon tax in the power sector eliminates coal, but then with overcapacity the model continues to dispatch gas.

Happy to think through ways we might improve this.

@jrissman
Copy link
Contributor

I was avoiding working on this because it will probably change model outputs, which means we cannot include it in 3.1, due to the cutoff triggered by EPS Texas. Therefore, I was assuming that I would wait to look into this until we were doing features for 3.1.1 or 3.2.

@jrissman
Copy link
Contributor

I could look into it to see if it's specific to the input data for these states, but if you've seen the issue in both VA and NV, that makes it less likely to be data-only. If it's data-only, then it is fine to go in 3.1 because it doesn't affect Texas.

@robbieorvis
Copy link
Contributor Author

robbieorvis commented Nov 20, 2020 via email

@robbieorvis
Copy link
Contributor Author

robbieorvis commented Nov 20, 2020 via email

@robbieorvis
Copy link
Contributor Author

Following up on this as it is coming up again in Virginia and I had a chance to dig in a bit more.

The current economic retirement mechanism calculates differences in the cost to dispatch of a power plant type and the market average, but it also computes this in a single versus the previous year. The result is that if you have, for example, a very high carbon price that maxes out in 2030, and you have little or no growth in demand, the carbon price can stop driving retirements of resources once it's maxed out, because the year over year change in a resources dispatch price versus the market price is unchanged.

In the VA model, you can see this if you set a $300/ton electricity carbon tax, maxing out in 2030. The tax will effectively retire all coal, then retire some gas through 2030 because the tax is growing, so the year over year change in dispatch price versus market price grows. But once the carbon price maxes out and because the market is adequately supplied at that point, even a very high carbon price does not drive additional retirement.

I think I in part understand why we designed it this way: we must have seen a situation where not using year over year changes resulted in too many retirements.

For me there are two questions here:

  1. Is the methodology correct, but are we missing the other side of the equation in which power plants enter the market not just for demand but because it is economic to do so?
  2. If the methodology is incorrect, what would we change (and why did we design it that way)?

On the first question, you could see the addition of a new mechanism that would add power plants to the market if they are cost effective, kind of like the inverse of the economic retirement calculation. In other words: if a power plant's operating costs are below the market price, then it might induce additional power plants into the market. It's basically the same thing in reverse. In both cases though there is reason to wonder if the year-over-year piece of the methodology is flawed. For example, say I have a technology with a -$100/MWh cost (from subsidies). It would always be profitable to add that to the market but if there's no year over year change in the market price, it wouldn't be added. Similarly, as soon as you add more power plants to the market, it would drive down the market price, shrinking the gap, so in year t+1 it would probably eliminate adding new plants, even if they are very economic, because the gap would shrink instead of grow.

@robbieorvis
Copy link
Contributor Author

Moving our email thread with a sample model over to GitHub.

I made the attached simplified hourly dispatch and economic capacity expansion model in Vensim using ALLOCATE AVAILABLE. It runs every hour of every year 2020-2050 by adding a Day (1-365) subscript and an hour (1-24) subscript. It takes a fraction of second to run. It’s obviously much simpler than the EPS in total, and there are fewer power plant types in my model than in the EPS, but this is pretty hopeful if we wanted to add an hourly dispatch module.

It is hard to visualize results in Vensim and I couldn’t get the output graphs right, in part because the x-axis I want is a subscript, but you can pull the result into Excel.

Next, I wanted to compute the marginal clearing price in any hour in order to figure our potential revenue for capacity expansion.

Had to be a bit crafty here:

ALLOCATE AVAILABLE converts everything to a normal distribution, and the mean and standard deviations are two inputs.
The share of actual output from any power plant type relative to its potential output from any power plant type is the equivalent of the cumulative probability for each power plant type.
I read in a z-score table from some input data, which converts cumulative probabilities to z-scores for a normal distribution. The Z-score is equal to the number of standard deviations away from the mean the observed value is at the cumulative probability.
So, we can look up the Z-score value (standard deviations away from the mean) using the cumulative probability, then multiply the standard deviations for each power plant type to get the marginal price in each hour.
This produced results that were almost identical across power plants types, (confirming it was working correctly to identify the marginal price in any hour), with tiny differences (<0.1), just from internal calculations in Vensim.
I used VMAX to take the max value across the vector of power plant types in any given hour.
Voila, we have the marginal electricity price in any given hour of the year.
With this data, we can calculate generation costs (paid by customers), profitability of existing power plants, and profitability of new power plants entering the market.

I also added in the necessary data (hard coded for now for the most part) estimate LCOEs for building new power plant types. This uses the calculated capacity factors in the model with a one year time delay.

I then estimated the potential revenue from a new MW of each power plant type, by looking at the output from the previous year and market prices, which gives an estimated annual $/MWh built. Subtracting the LCOE from this value gives estimated profitability for a new power plant of given type in $/MWh. For now, I tried something simple by adding a new variable for the elasticity of new power plant construction, which uses a MW/($/MWh) value to estimate how much new capacity is built when it is profitable to do so, and set up the model to calculated power sector capacity.

This approach seems to work pretty nicely and you can see that even with fixed demand, the more profitable a power plant type (which is tied to its hourly output and clearing prices in a given hour), the more gets built. I also added a little policy lever so you can test adding $/MWh subsidies to see how that works. The idea would be to calibrate the values in the elasticity using ReEDS or another model. There are of course a lot of simplifications here, for example we assume a static going forward market price to see if new power plants are profitable and we don't optimize but rather use elasticities. However, I think to pass the "laugh" test, this is fine.

It's possible we could do more on battery storage on this framework to by using a one year time delay to determine how batteries charge/discharge, subject to some constraints, but that's a topic for another time.

I'm uploading a copy of the model here in case anyone wants to play with it. I think that this could serve as a nice basis for adding hourly electricity dispatch to the EPS, calculating generating costs (which is the best way to compute changes in electricity prices and rates), and potentially to add economic capacity expansion to the model, in addition to the other capacity expansion approaches.
Dispatch model test.zip

@robbieorvis robbieorvis mentioned this issue Apr 28, 2022
Closed
@robbieorvis robbieorvis mentioned this issue May 25, 2022
Closed
@jrissman
Copy link
Contributor

This is handled as part of #232 (and is working), so I'm closing this issue as duplicative.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jrissman jrissman

@robbieorvis robbieorvis

@mkmahajan mkmahajan

Labels
3.5 high priority
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jrissman @robbieorvis @mkmahajan