Feature request: CO2 price

[gmantegna]

Currently there is functionality for a CO2 cap but not for a CO2 price. It is possible to add via changing the fuel price but it would be helpful to have this be a simple input for ease of modifying the price.

[JesseJenkins]

Is this addressed in v0.4 release @sambuddhac?

[sambuddhac]

Is this addressed in v0.4 release @sambuddhac?

We don't have the CO2 price in v0.4, but the CO2 slack plays a equivalent role when the CO2 cap is non-zero. We can have an explicit CO2 price input file as part of v0.4 in addition to this also.

[filippopecci]

We also have an example showing how to define a CO2 price using the slacks in the tutorials: https://github.com/GenXProject/GenX-Tutorials/blob/main/Tutorials/Tutorial_7_Setup.ipynb

[DanielNavia1]

Thank you, @sambuddhac @JesseJenkins @filippopecci

I took a quick look at the code. I think if you want to fully replicate an CO2 tax with no fixed quantity of emissions, you would need to explicitly have "CO2Cap" set to either 1, 2 or 3 (doesn't matter which one) and then set a CO2cap of 0 for every zone in the appropriate input files.

If you don't set CO2Cap the CO2 costs would not be computed, even if the CO2Cap slack files are there.

If you set CO2Cap but the CO2 caps are not 0, the results would not replicate a pure CO2 tax. You don't get a switching effect if you are operating below the cap. For example, if the problem is set such that there is a choice to operate coal or CCGT within the emission cap, the algorithm will choose the one with lower fuel cost, regardless of the CO2 price. This would be different than a CO2 tax situation, where the optimal dispatch would take into account the CO2 costs.

If you do set the parameters, I think arithmetically the result would be the same as simply adding a CO2 tax component of the variable cost objective of the problem. It may be less efficient as you add a new set of variables to the optimization, whereas directly adding a CO2 cost component to the objective function would not.

[gmantegna]

Thanks for putting this out, that's a very good point. My opinion is that longer term, we should seek to have an explicit CO2 price functionality, as this is a common input and it's a bit janky to do this through the CO2 cap slack.

…

On Mon, Mar 25, 2024 at 6:26 PM DanielNavia1 ***@***.***> wrote: Thank you, @sambuddhac <https://github.com/sambuddhac> @JesseJenkins <https://github.com/JesseJenkins> @filippopecci <https://github.com/filippopecci> I took a quick look at the code. I think if you want to fully replicate an CO2 tax with no fixed quantity of emissions, you would need to explicitly have "CO2Cap" set to either 1, 2 or 3 (doesn't matter which one) and then set a CO2cap of 0 for every zone in the appropriate input files. If you don't set CO2Cap the CO2 costs would not be computed, even if the CO2Cap slack files are there. If you set CO2Cap but the CO2 caps are not 0, the results would not replicate a pure CO2 tax. You don't get a switching effect if you are operating below the cap. For example, if the problem is set such that there is a choice to operate coal or CCGT within the emission cap, the algorithm will choose the one with lower fuel cost, regardless of the CO2 price. This would be different than a CO2 tax situation, where the optimal dispatch would take into account the CO2 costs. If you do set the parameters, I think arithmetically the result would be the same as simply adding a CO2 tax component of the variable cost objective of the problem. It may be less efficient as you add a new set of variables to the optimization, whereas directly adding a CO2 cost component to the objective function would not. — Reply to this email directly, view it on GitHub <#526 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHKPARTWSRX2HCWFJCFWOQTY2CQBLAVCNFSM6AAAAAA3TIRAT2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJZGAZDONZSG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[sambuddhac]

Thanks for putting this out, that's a very good point. My opinion is that
longer term, we should seek to have an explicit CO2 price functionality, as
this is a common input and it's a bit janky to do this through the CO2 cap
slack.

On Mon, Mar 25, 2024 at 6:26 PM DanielNavia1 @.***>
wrote:

Thank you, @sambuddhac https://github.com/sambuddhac @JesseJenkins
https://github.com/JesseJenkins @filippopecci
https://github.com/filippopecci

I took a quick look at the code. I think if you want to fully replicate an
CO2 tax with no fixed quantity of emissions, you would need to explicitly
have "CO2Cap" set to either 1, 2 or 3 (doesn't matter which one) and then
set a CO2cap of 0 for every zone in the appropriate input files.

If you don't set CO2Cap the CO2 costs would not be computed, even if the
CO2Cap slack files are there.

If you set CO2Cap but the CO2 caps are not 0, the results would not
replicate a pure CO2 tax. You don't get a switching effect if you are
operating below the cap. For example, if the problem is set such that there
is a choice to operate coal or CCGT within the emission cap, the algorithm
will choose the one with lower fuel cost, regardless of the CO2 price. This
would be different than a CO2 tax situation, where the optimal dispatch
would take into account the CO2 costs.

If you do set the parameters, I think arithmetically the result would be
the same as simply adding a CO2 tax component of the variable cost
objective of the problem. It may be less efficient as you add a new set of
variables to the optimization, whereas directly adding a CO2 cost component
to the objective function would not.

—
Reply to this email directly, view it on GitHub
#526 (comment),
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHKPARTWSRX2HCWFJCFWOQTY2CQBLAVCNFSM6AAAAAA3TIRAT2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJZGAZDONZSG4
.
You are receiving this because you authored the thread.Message ID:
@.***>

I agree @gmantegna . I also looked at and liked @DanielNavia1 's comment on his issue, which is the exact same.