Calculation of electricity output subsidies needs to be differentiated by power plant quality

[robbieorvis]

Currently, the policy lever for electricity subsidies per unit output is applied to all power plant quality levels: preexisting retiring, preexisting nonretiring, and newly built. We need to differentiate this policy and its implementation in the model by power plant quality.

There are multiple types of subsidies for electricity output we want to model. The most common is something like the production tax credit, which only applies to newly built resources.

However, a newer type of policy is an incentive for existing generation, in particular nuclear power plants. US policymakers are already considering and at the state level have already passed incentives for existing nuclear power plants to keep them from retiring.

Seems like a relatively easy fix would be to further subscript this policy lever by power plant quality in addition to power plant type.

We will also need the ability to set customized policy schedules for each subscripted element, so need to add that.

This is a fairly high importance fix as we need it to properly do the US modeling we are working on. I am thinking it can be wrapped into 3.3.1 or 3.4

[jrissman]

Okay, I can do this one today. I'll increment the EPS version number to 3.3.1 in case you want a quick release, and we can change the version number to 3.4 if we end up adding enough stuff to justify that before the next release.

Do you want only the policy lever subscripted by power plant quality level, or also the variable BS BAU Subsidy per Unit Electricity Output? You didn't mention the BAU value, but if real-world subsidies can differ by quality level, it seems like this could happen whether the subsidies in question are part of the BAU case or part of the policy case.

Remember that each subscripted element of a policy lever has its own individual implementation schedule. This was added in issue #16 a little less than a year ago.

[robbieorvis]

I think the variable needs to be subscripted as well.

Megan also correctly pointed out to me that there will be an issue if a policy has a strange policy schedule. For instance, if a newly built subsidy only comes on in 2030, it would apply to all newly built capacity for the power plant type throughout the model run starting in 2030. SO a plant built in 2022 would starting getting the subsidy in 2030. That doesn’t seem right either.

I think what we essentially want is something like a sumproduct where the subsidy in a given year only applies to some share (or a weighted average value) corresponding with how the policy schedule is implemented. I know this probably complicates issues.

---

Robbie Orvis Senior Director of Energy Policy Design +1 415-799-2171 1225 Eye Street, N.W. Suite 904 Washington, D.C. 20005 www.energyinnovation.orghttp://www.energyinnovation.org/ @.***

From: Jeff Rissman @.> Sent: Friday, September 10, 2021 3:09 PM To: Energy-Innovation/eps-us @.> Cc: Robbie Orvis @.>; Author @.> Subject: Re: [Energy-Innovation/eps-us] Calculation of electricity output subsidies needs to be differentiated by power plant quality (#186)

Okay, I can do this one today. I'll increment the EPS version number to 3.3.1 in case you want a quick release, and we can change the version number to 3.4 if we end up adding enough stuff to justify that before the next release.

Do you want only the policy lever subscripted by power plant quality level, or also the variable BS BAU Subsidy per Unit Electricity Output? You didn't mention the BAU value, but if real-world subsidies can differ by quality level, it seems like this could happen whether the subsidies in question are part of the BAU case or part of the policy case.

Remember that each subscripted element of a policy lever has its own individual implementation schedule. This was added in issue #16https://github.com/Energy-Innovation/eps-us/issues/16 a little less than a year ago.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/Energy-Innovation/eps-us/issues/186#issuecomment-917144465, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AK5N6SJCZLEP2VNYWSUZY63UBJJTPANCNFSM5DZ3ZWAQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[jrissman]

Yeah, the thing Megan points out is true, and difficult. The quality tiers are being used to separate plants into three buckets. They aren't really intended to track which plants are built in which year, which would require a proper vintaging system, like we're going to add for vehicles.

A faster solution might be to track how much capacity was added to the model each previous year of the run by applying a DELAY function like DELAY FIXED to the variable New Generation Capacity and checking each year (each delay amount) between the start of the model run and the previous year. That could give you a share of the capacity that exists in the currently-simulated year (say, 2038) that was built on or after a particular prior year (say, 2030).

Suppose the policy implementation schedule says (2029, 0%), (2030, 25%), (2031, 50%), (2032, 75%), (2033, 100%). The current year is 2038.

I guess we have to check every year and apply the schedule setting to the share in that year. So it would be something like:

As of 2038, 40% of newly built plants existed in 2029, and they get a zero subsidy. 45% of newly built plants existed in 2030, so (40% - 45%) = 5% of plants get 25% of the lever's subsidy value. 50% of newly built plants existed in 2031, so (50% - 45%) = 5% of plants get 50% of the subsidy. 55% of newly built plants existed in 2032, so (55% - 50%) = 5% get 75% of the subsidy value. Etc.

We'd also have to account for the fact that some of the plants may have retired, and we'd need to somehow determine which year the plants that retired were built in. We're starting to get into territory that really needs the proper vintaging system, not the DELAY hack.

It makes it a larger and more challenging feature request. Perhaps for now we simply subscript the lever by power plant quality, which is simple from a code perspective and lets you exclude all the plants in the other quality tiers, which should make up probably the vast majority of plants you would want to exclude, especially in the early years of a model run.

[jrissman]

I made some edits/corrections to the previous comment, visible on Github, not in emailed notifications from GitHub.

[jrissman]

I think I could track vintage by year more simply than with DELAY FIXED. I think I could add a vintage subscript without too much difficulty, if I can make a reasonable assumption about retirements, such as: When power plants of a given quality tier retire, it is always the oldest plants within that quality tier that retire first.

[jrissman]

Note however that this would actually remove functionality. If I link the implementation schedule percentages to the year the plant was built, there is no time-series way to specify the policy's behavior for plants of that age! So we can't really do it that way. We'd need to control this with a separate input data variable.

[jrissman]

The main implementation is completed in b2aae05, 3cb22e0, and efb6770. In my testing, I've found that you now get very different behavior if you apply the subsidy to preexisting plants vs. new plants. It's pretty flexible, and I'm hoping it can get you essentially what you need. It certainly should be fine for nuclear, and for other plant types, hopefully the exclusion of preexisting plants will be good enough. Plus you can now alter BAU subsidy rates for preexisting vs. new plants. (I haven't changed the data, so they get the same subsidy rates as each other currently.) Please test it carefully and see if it can work for you.

If not, and you really need to exclude (say) the plants built from 2020-2029 from receiving subsidies, while offering subsidies to plants built in 2030 and later, open a new ticket for that. It will probably be lower-priority than this ticket and require more detailed work. I imagine this shouldn't come up much, since generally the idea behind subsidies is that they are for new technologies and decline over time, not that they suddenly kick in for wind or solar projects built in 2030 while punishing the early adopters who built wind or solar plants in the 2020s. So I am hopeful that odd scenario isn't very important and what we have here now might be sufficient for most purposes.

[robbieorvis]

Hi Jeff,

Thanks for this. I will go ahead an open another ticket. I thought of a much common/likely way in which this will come up, which is actually through the phase out of subsidies (I suppose this goes for EVs too in fact).

Let's take the US production tax credit as an example. Going forward, based on what is being proposed right now. The subsidy would be about $30/MWh for any solar plant built between 2022 and 2030, and then would phase down over the following three years. The subsidy also lasts for 10 years. So anything built between 2022 and 2030 gets $30/MWh for ten years, then in 2031 gets $20/MWh for ten years, then $10/MWh, then no subsidy. Right now, the problem is that in 2031, the subsidy for all the stuff built between 2021 and 2030 would drop, then drop again, and again. We would be dramatically underestimated the cost of the subsidy to the government and associated cash flows.

I agree this is a much trickier implementation and requires vintaging most likely to be accurate. The specific implementation I mentioned here is even more challenging in that the subsidy only lasts for a certain amount of time, which introduces a different wrinkle.

If we were to compare instead to the US investment tax credit, I think the current implementation is probably fine, since it's a one time payment.

[jrissman]

Your PTC example is a good one.

Yes, I think it would require vintaging all power plants, which includes not just tracking when they are built, but having a way to decide which age plants retire when plants retire. We'd also need to assign vintages to the preexisting plants too. For example, some of them were built in 2018 and still have some years left during which they would receive a 10-year subsidy. Essentially, all capacity would need a vintage, so all plants could be treated consistently, which increases input data requirements.

Then, once we have vintaging in place, we need a policy lever to control the subsidy separately for every vintage. That's because you want to schedule the behavior of the policy to be different for every vintage. For example, for the 2025 plants, you want the policy to last from 2025-2035, while for the 2026 plants, you want 2026-2036. And for plants built after 2030, you want no subsidy at all, so it's not just a consistent 10 years of support. So we'd be subscripting the policy lever by plant vintage and by plant type. (That would replace the current subscripting by quality tier, which would become extraneous if we were subscripting the lever by vintage, since all plants of a given vintage are in the same quality tier as each other.)

Those two changes should do it. I agree that work deserves its own GitHub issue.

[robbieorvis]

In that regard, it would look very much like the new transportation sector I worked on:

-Input data file with plant capacity by power plant type and historical year built -Survival function for power plants (I’ve actually previously calculated this using EIA data and the curves fit quite well -Detailed year-by-year vintaging and retirement data.

Then your edits on top of the vintaging for the policies.

One nice thing about this: if we move to this approach for electricity and transportation (and eventually buildings, which is how Olivia has been building things) the model will neatly and uniformly track vintages of equipment in each of the different sectors and give us a ton of policy flexibility.

---

Robbie Orvis Senior Director of Energy Policy Design +1 415-799-2171 1225 Eye Street, N.W. Suite 904 Washington, D.C. 20005 www.energyinnovation.orghttp://www.energyinnovation.org/ @.***

From: Jeff Rissman @.> Sent: Monday, September 13, 2021 1:06 PM To: Energy-Innovation/eps-us @.> Cc: Robbie Orvis @.>; Author @.> Subject: Re: [Energy-Innovation/eps-us] Calculation of electricity output subsidies needs to be differentiated by power plant quality (#186)

Your PTC example is a good one.

Yes, I think it would require vintaging all power plants, which includes not just tracking when they are built, but having a way to decide which age plants retire when plants retire. We'd also need to assign vintages to the preexisting plants too. For example, some of them were built in 2018 and still have some years left during which they would receive a 10-year subsidy. Essentially, all capacity would need a vintage, so all plants could be treated consistently, which increases input data requirements.

Then, once we have vintaging in place, we need a policy lever to control the subsidy separately for every vintage. That's because you want to schedule the behavior of the policy to be different for every vintage. For example, for the 2025 plants, you want the policy to last from 2025-2035, while for the 2026 plants, you want 2026-2036. And for plants built after 2030, you want no subsidy at all, so it's not just a consistent 10 years of support. So we'd be subscripting the policy lever by plant vintage and by plant type. (That would replace the current subscripting by quality tier, which would become extraneous if we were subscripting the lever by vintage, since all plants of a given vintage are in the same quality tier as each other.)

Those two changes should do it. I agree that work deserves its own GitHub issue.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/Energy-Innovation/eps-us/issues/186#issuecomment-918393867, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AK5N6SNFRDIOUTNEZQAVCMTUBYVO7ANCNFSM5DZ3ZWAQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[mkmahajan]

While testing the new levers, I'm having trouble implementing a custom implementation schedule for new onshore wind. I've loaded in an implementation schedule that strengthens the PTC for new wind in 2022 and then starts to phase it out in the 2030s, and I can verify that the 'Selected Policy Implementation Schedule for elec generation subsidy X onshore wind es X newly built' variable is what I set in my custom FoPITY file. However, when I check the 'Subsidy for Elec Production by Fuel This Year' variable, it is a constant value from 2021-2050 (the default implementation). I'm not familiar with the VECTOR ELM MAP function to pull implementation schedules, so it's hard for me to spot if something is wrong with the formula here.

[jrissman]

Looking into it now

[jrissman]

Fixed in 2016b6d. In the FoPITY files (and in WebAppData), I had varies elements of the first subscript before varying elements of the second subscript, and it needed to be the other way around. No changes in Vensim.