Give industrial producers foresight of carbon price

[dobrien13]

Carbon pricing schemes are typically crafted with progressively increasing prices or tightening caps. Industry considers multiple future years' costs when making investment decisions and should be able to take future carbon price increases into account when making decisions. Now that we have endogenous technology choice for industrial equipment, we should incorporate future knowledge of carbon pricing, else we will underestimate the impact of carbon pricing schemes on decarbonization.

We could structure this similarly to the Five Year Forward Electricity Taxes read from BFPaT but would need to map to future years from an endogenously calculated variable, rather than an input file. Is this possible?

[jrissman]

The RPS policy lever in the electricity sector already has a mechanism that lets electricity suppliers intelligently account for future RPS values when deciding what to build. This structure was carefully refined through many EPS iterations. The five-year-forward approach is much newer and I'm not familiar with it. Whoever works on this issue should review and understand the RPS policy's mechanism for letting entities account for future values, in addition to reviewing the five-year-ahead approach, to decide which one would be more robust in terms of software architecture and handling edge cases. The RPS's approach isn't limited to five years but examines all future values and tries to smooth out the compliance pathway to the most-difficult year to minimize sharp disruptions.

[dobrien13]

Thank you, Jeff! Megan had the same advice. I'll spend some time looking at the implementation of that lever in 4.0 to make sure we take the right approach in this issue.

[robbieorvis]

The mechanism for the RPS mechanism no longer works. It broke when we built the new code and we did not update it. We could consider looking into fixing that in 4.1 and carrying the fix over to the industry sector. The other way of doing this, which is probably a long term fix but would require significant new structure and possibly web app updates, is to convert FOPITY from a time series to a constant, along the lines of what we do for BFPaT now. That would let you map future year values directly in a given year. This would be particularly relevant for the carbon price and it would affect multiple sectors. To do this, you would just have to convert FoPITY like BFPaT and put in the relevant Future Year to Year mapping structure as needed. But I'm not sure what would be required on the WebApp side. FWIW, this would allow foresight for all policies, which has a lot of advantages over the current approach, so it might be a good thing to consider after consulting with Todd... From: dobrien13 ***@***.***> Sent: Thursday, January 16, 2025 4:19 PM To: EnergyInnovation/eps-us ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [EnergyInnovation/eps-us] Give industrial producers foresight of carbon price (Issue #355) Thank you, Jeff! Megan had the same advice. I'll spend some time looking at the implementation of that lever in 4.0 to make sure we take the right approach in this issue. - Reply to this email directly, view it on GitHub<#355 (comment)>, or unsubscribe</~https://github.com/notifications/unsubscribe-auth/AK5N6SLVGFHDRWM73IF5BK32LAO4VAVCNFSM6AAAAABVKBIDJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOJWHEYDONZVHA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>

[jrissman]

I did not know that the RPS foresight mechanism was broken at some point between when I last worked on it during the development of 4.0 and currently in 4.0.3. Was it broken in the official (final) 4.0 release?

The idea you propose about making the whole FoPITY schedule accessible for all policies in all timesteps an interesting idea. I don't think you would have to involve Todd or make any changes to the web app if you can leave the variable FoPITY Fraction of Policy Implemented This Year alone and simply adjust the equation in Selected Policy Implementation Schedule to include the FutureYear subscript (plus update variables that use Selected Policy Implementation Schedule, most of which should just reference the current year because for most of them, we would not wish to grant foresight). FoPITY Fraction of Policy Implemented This Year is a lookup variable, which already should not restrict you from referencing all future years anyway, so I don't see why you would necessarily need Todd to do anything. You might just need to use an equation that looks up each future year from the existing lookup variable and stores it as an element in the FutureYear subscript in Selected Policy Implementation Schedule. (For code readability, I'd actually split this step and the step of selecting one of the nine implementation schedules into two variables.)

That said, this change alone isn't an alternative to what the RPS foresight mechanism does. Changing Selected Policy Implementation Schedule and the variables that use it would mostly be a different way of reading in the numbers that allows for foresight because the numbers are stored in a non-Time subscript, all elements of which are accessible in every simulated year. You still need to program any relevant variables in the sectors to make us of that information, which could involve a mechanism equivalent to the one the RPS uses.

Also note that this can block people's ability to use the policy schedules freely and see the model strictly follow the schedules they enter. If the model always approaches targets with foresight, for instance, then if you want to simulate the policy remaining weak for a number of years and then starting to increase, you can't really do it because the model will see the future increases and start working to meet them sooner. In other words, it's taking some decision-making power out of the hands of whomever is designing the scenario, and they might not necessarily want that. They might be trying to simulate a scenario where no action is taken until 2030, for instance. You could give them a bunch of control levers that let them toggle foresight on or off for every policy individually, but that's more work and complexity, both for the model developer and the user.

If you expect to use foresight widely, it would make sense to put the work upstream (on the "Policy Implementation Schedule" sheet or in a new sheet) to calculates the "target" values the model aims to hit for each policy, and then feed the "target" policy settings (rather than "this year" policy settings) into the various sectors. This would prevent repetitive messy code for managing foresight in appearing multiple places in every sector. The foresight mechanism would be subscripted by Policy (we already have a "Policy" subscript range, which is mostly disused now, but would be useful for building model-wide foresight).

As far as the real world goes, foresight might apply best to policies with built-in long-run targets like the RPS and the EU cap-and-trade mechanism. In the U.S., tax and subsidy rates seem to vary wildly and unpredictably with changes in administration and priorities. For instance, I would struggle to predict what changes will be made to energy-relevant taxes and subsidies even one year from now, let alone 10+ years from now.