Add CCS-equipped power plant types

[jrissman]

The current way of handling CCS in the power sector makes it difficult to consider economically-driven deployment of plants with CCS (or retrofits with CCS, per issue #279) because the CCS is added on downstream in the calculation flow and doesn't affect initial plant construction and retirement decisions. CCS is not economically-driven (per issue #11).

For the electricity sector, it would likely be better to handle CCS-equipped plants as their own distinct plant types that run through the same mechanisms to compete with other plant types, could be flagged as RPS-qualifying or not, etc.

Structurally, this could be done either by expanding the "Electricity Source" subscript, or by adding a new "CCS Equipped" subscript. There are upsides and downsides to each of these approaches:

• A new CCS-equipped subscript is conceptually neater for a human and is almost certainly how it would be done if we were using a fast, typical programming language like Python. On the downside, it may have greater runspeed impacts (because we have to simulate a bunch of zeroes for CCS-equipped solar, CCS-equipped wind, CCS-equipped hydro, etc.), and it would require Todd to adjust the web app to handle policy levers with three subscripts. FoPITY is already formatted to handle policy levers with three subscripts, but WebAppData.xlsx is not, so it would need a new column added there. It also may cause us to need to add more .csv input files, since those files are limited to two dimensions.

• Expanding the "Electricity Source" subscript to include the new plant types should run faster, involves adding rows to existing input .csv files rather than adding new .csv files (which is cleaner), and avoids the need for web app updates to support policy levers with three subscripts. The main downside here is that it's less elegant and clean from a human perspective, as it's working around Vensim and web app limitations.

On the whole, I think it would be better to expand the existing "Electricity Source" subscript rather than adding a new "CCS Equipped" subscript. In some sense, it may be less elegant, but I think the benefits in terms of higher runspeed, fewer .csv input files, no updates needed to the web app, and fewer adjustments to equations throughout the electricity sector are worth it.

Completing this issue will resolve half of issue #11 (pertaining to the power sector). The remaining half of issue #11 pertains to the Industry sector.

Note that a large expansion of the power plant types will have runspeed impacts. We should not worry about that while implementing it, but after we get it working, we may need to consider reducing the number of peak days in the electricity timeslices (we might not need five summer peak and five winter peak days). And we should definitely get a profiler working and profile the C code generated by SDEverywhere to help us identify where to focus our efforts to improve runspeed, as the model is now too complicated to be able to do this by hand, without the help of a profiler tool.

[robbieorvis]

Agree with this discussion and suggested approach.

From: Jeff Rissman @.> Sent: Tuesday, June 13, 2023 2:52 PM To: EnergyInnovation/eps-us @.> Cc: Subscribed @.***> Subject: [EnergyInnovation/eps-us] Add CCS-equipped power plant types (Issue #280)

The current way of handling CCS in the power sector makes it difficult to consider economically-driven deployment of plants with CCS (or retrofits with CCS, per issue #279https://github.com/EnergyInnovation/eps-us/issues/279) because the CCS is added on downstream in the calculation flow and doesn't affect initial plant construction and retirement decisions. CCS is not economically-driven (per issue #11https://github.com/EnergyInnovation/eps-us/issues/11).

For the electricity sector, it would likely be better to handle CCS-equipped plants as their own distinct plant types that run through the same mechanisms to compete with other plant types, could be flagged as RPS-qualifying or not, etc.

Structurally, this could be done either by expanding the "Electricity Source" subscript, or by adding a new "CCS Equipped" subscript. There are upsides and downsides to each of these approaches:

• A new CCS-equipped subscript is conceptually neater for a human and is almost certainly how it would be done if we were using a fast, typical programming language like Python. On the downside, it may have greater runspeed impacts (because we have to simulate a bunch of zeroes for CCS-equipped solar, CCS-equipped wind, CCS-equipped hydro, etc.), and it would require Todd to adjust the web app to handle policy levers with three subscripts. FoPITY is already formatted to handle policy levers with three subscripts, but WebAppData.xlsx is not, so it would need a new column added there. It also may cause us to need to add more .csv input files, since those files are limited to two dimensions.
• Expanding the "Electricity Source" subscript to include the new plant types should run faster, involves adding rows to existing input .csv files rather than adding new .csv files (which is cleaner), and avoids the need for web app updates to support policy levers with three subscripts. The main downside here is that it's less elegant and clean from a human perspective, as it's working around Vensim and web app limitations.

On the whole, I think it would be better to expand the existing "Electricity Source" subscript rather than adding a new "CCS Equipped" subscript. In some sense, it may be less elegant, but I think the benefits in terms of higher runspeed, fewer .csv input files, no updates needed to the web app, and fewer adjustments to equations throughout the electricity sector are worth it.

Completing this issue will resolve half of issue #11https://github.com/EnergyInnovation/eps-us/issues/11 (pertaining to the power sector). The remaining half of issue #11https://github.com/EnergyInnovation/eps-us/issues/11 pertains to the Industry sector.

Note that a large expansion of the power plant types will have runspeed impacts. We should not worry about that while implementing it, but after we get it working, we may need to consider reducing the number of peak days in the electricity timeslices (we might not need five summer peak and five winter peak days). And we should definitely get a profiler working and profile the C code generated by SDEverywhere to help us identify where to focus our efforts to improve runspeed, as the model is now too complicated to be able to do this by hand, without the help of a profiler tool.

- Reply to this email directly, view it on GitHubhttps://github.com/EnergyInnovation/eps-us/issues/280, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AK5N6SICQ2MUUCIH4A2D5U3XLDOH7ANCNFSM6AAAAAAZFPH37I. You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>

[mkmahajan]

I've pushed edits to add 6 new power plant types to the Electricity Source subscript: hard coal with CCS, lignite with CCS, natural gas combined cycle with CCS, biomass with CCS, small modular reactors, and hydrogen power plants (hydrogen plants are part of issue #99, and SMRs weren't previously captured in an issue request). This list is based off a review of plant types covered by other models and a check with the Electricity team.

The model is now running and the new power plant types are reflected in the graphs. However, I still need to work on a few additional data edits and modify the electricity portion of the CCS code. We will no longer need the old electricity CCS logic and will instead need to calculate CO2 capture based off generation of the CCS plant types.

But in the mean time, the model is in a stable place so that @jrissman can pick up model development tomorrow if time permits.

[mkmahajan]

I've redone the CCS section to now calculate electricity sector CO2 storage based on each CCS-equipped plant type's capture rate and generation rather than a user-driven lever. Though I have added in a policy lever for an additional CCS subsidy (specified in $/ton CO2 storage rather than a generation or construction subsidy). Endogenous learning now applies to CCS equipped plant types.

CCS capital and O&M costs are now accounted for in the electricity sector cash flow page rather than the CCS page (since they are included in the CCaMC file). However, Robbie realized that we needed to account for CCS transportation and storage costs, so we now track those separately.

The only remaining to-do on electricity sector CCS is to decide how to handle BECCS. According to EPA convention, biomass plants have a CO2 emissions factor of 0 in the US EPS. We need to decide whether we want to allow this plant type to have negative emissions (crediting the captured CO2). We also need to specially account for the transport and storage costs and 45Q credits for BECCS, since both those calculations include converting from $/ton to $/MWh values partially based on the CO2 emissions factor in PEI (and are therefore reported as $0/MWh currently). @robbieorvis said he wanted to think this question over, but I'm just logging the question here for reference.

[robbieorvis]

I think that technically the correct way to do this is to link the biomass energy demand across the model (including in power sector) with the land use module. Then biomass use could increase carbon uptake for land and ag, and BECCS would be net negative since it would result in an emissions factor of 0 (the non-CCS emissions factor would have to be set such that it is greater than zero but combined with biomass land reduction would results zero net emissions).

However, that is a very large amount of work and probably should be part of a broader conversation about restructuring linkages between biomass throughout the model with the land and ag sectors.

In the meantime, we might need something that is a capture emissions rate for all the technologies and could be applied/added. That way we can set it to a capture rate for the other techs (e.g. if PEI for coal for electricity is 1, and we are assuming a 90% capture rate, then the Capture EI would be 0.9, and we could have a value for biomass). You then add and/or subtract these to get a net emissions rate. We'd just pull a value from the literature and a given capture rate.

Thoughts?

From: mkmahajan @.> Sent: Wednesday, August 16, 2023 4:07 PM To: EnergyInnovation/eps-us @.> Cc: Robbie Orvis @.>; Mention @.> Subject: Re: [EnergyInnovation/eps-us] Add CCS-equipped power plant types (Issue #280)

I've redone the CCS section to now calculate electricity sector CO2 storage based on each CCS-equipped plant type's capture rate and generation rather than a user-driven lever. Though I have added in a policy lever for an additional CCS subsidy (specified in $/ton CO2 storage rather than a generation or construction subsidy). Endogenous learning now applies to CCS equipped plant types.

CCS capital and O&M costs are now accounted for in the electricity sector cash flow page rather than the CCS page (since they are included in the CCaMC file). However, Robbie realized that we needed to account for CCS transportation and storage costs, so we now track those separately.

The only remaining to-do on electricity sector CCS is to decide how to handle BECCS. According to EPA convention, biomass plants have a CO2 emissions factor of 0 in the US EPS. We need to decide whether we want to allow this plant type to have negative emissions (crediting the captured CO2). We also need to specially account for the transport and storage costs and 45Q credits for BECCS, since both those calculations include converting from $/ton to $/MWh values partially based on the CO2 emissions factor in PEI (and are therefore reported as $0/MWh currently). @robbieorvishttps://github.com/robbieorvis said he wanted to think this question over, but I'm just logging the question here for reference.

- Reply to this email directly, view it on GitHubhttps://github.com/EnergyInnovation/eps-us/issues/280#issuecomment-1681204195, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AK5N6SK2Y45CGKT2JJ5OPG3XVUR7NANCNFSM6AAAAAAZFPH37I. You are receiving this because you were mentioned.Message ID: @.**@.>>

[mkmahajan]

Thanks, Robbie. I agree it makes sense to address the larger land use connections in a later update. I already have a capture rate variable programmed in as part of the existing CCS calculations. I think I'll read in a single piece of input data for the BECCS emissions rate, then swap that in instead of the BECCS PEI value when I'm calculating the MMT CO2/MWh value (heat rate emissions intensity CCS capture rate).

But to confirm, that means you want the BECCS power plant type to show negative emissions in this interim handling?

[robbieorvis]

Yep!

From: mkmahajan @.> Sent: Thursday, August 17, 2023 11:34 AM To: EnergyInnovation/eps-us @.> Cc: Robbie Orvis @.>; Mention @.> Subject: Re: [EnergyInnovation/eps-us] Add CCS-equipped power plant types (Issue #280)

Thanks, Robbie. I agree it makes sense to address the larger land use connections in a later update. I already have a capture rate variable programmed in as part of the existing CCS calculations. I think I'll read in a single piece of input data for the BECCS emissions rate, then swap that in instead of the BECCS PEI value when I'm calculating the MMT CO2/MWh value (heat rate emissions intensity CCS capture rate).

But to confirm, that means you want the BECCS power plant type to show negative emissions in this interim handling?

- Reply to this email directly, view it on GitHubhttps://github.com/EnergyInnovation/eps-us/issues/280#issuecomment-1682495384, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AK5N6SMKKF2QGKRFHMF2WSDXVY2XTANCNFSM6AAAAAAZFPH37I. You are receiving this because you were mentioned.Message ID: @.**@.>>

[mkmahajan]

I've now added the special handling for BECCS plants, so I am closing out this issue.