Implementing Emissions caps and prices #859
Replies: 4 comments
-
Hi Oliver, Regarding your first point - I guess this is the flexibility you have with SpineOpt, you have the freedom to apply the costs where it seems most suitable to you, for your unique case. Regarding the cumulated emissions - what you could do, is have a different temporal resolution for your CO2 node. If it were, for example a daily CO2 cumulative limit, you could define a daily resolution temporal block and add a Does this make sense? |
Beta Was this translation helpful? Give feedback.
-
Hi, |
Beta Was this translation helpful? Give feedback.
-
Good morning :) first of all, thank you very much @DillonJ for your suggestion. I was yet unsuccesfull implementing the option with the modfiied balance_sense parameter. While changing the temporal resolution worked, the balance constraint seems not to be doing as I would expect it. I will also try out limiting the storage. Actually creating the unit_groups worked, but the DB Editor and in the following the whole Toolbox collapsed when trying to edit the unit_group object. So it could be possible that it is mainly a viewing issue. |
Beta Was this translation helpful? Give feedback.
-
@DillonJ Do you know if Oliver was able to work through this or is it something we should fix? (Maybe on the Toolbox side?) |
Beta Was this translation helpful? Give feedback.
-
Hello everyone :) While trying to implement CO2 emissions regulations I stumbeled upon a few minor points I wanted to bring to your attention:
I first started applying CO2 prices. As far as I see there are multiple possibilities to do so e.g. defining the emissions factor with a unit_node_node relationship between the CCGT unit, natural_gas node and emissions node and defining the CO2 pricing over vom_costs between unit and emissions node. The other option uses the tax_in_unit_flow on the emissions node and just applies the price there. Both options have advantages whether you want to define different CO2 prices per units or just one CO2 price per ton.
When trying to implement a CO2 cap on the other hand, I tried using the relationship parameter max_total_cumulated_unit_flow_to_node in combination with a unit group of fossil powerplants. Unfortunately the unit group seems to be corrupted so Spine crashed repeatedly. As an alternative using a storage with a max capacity may be a possibility to implement the CO2 cap?
Would it be possible to add some kind of “total_cummulated_(in)flow” as object parameter for nodes? This would facilitate adding for example CO2 caps, but could also be used to define the total exploitable amount of gas in a gas field. Maybe one parameter would be sufficient with the value being negative or positive defining whether it is a sink or a source.
What do you think about this? Did I overlook something?
Thank you and best regards
Oliver
Beta Was this translation helpful? Give feedback.
All reactions