Implementing Emissions caps and prices

[OliverLinsel]

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 “totalcummulated(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

[DillonJ]

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 node__temporal_block relationship between the CO2 node and the daily temporal block. All flows in/out of that node will then be at daily resolution. To set a limit, then give the node a demand (by default this will mean an eqaulity constraint between the net input flow and the demand.). To change this, use the balance_sense parameter and change it to <=. This will mean that input flows - output flows must be less than the demand, at daily resolution. The input flows to your unit will be at whatever your default resolution is (probably hourly), but the output flows to the CO2 node will be daily, in this case. If you also want to track hourly CO2 flows, you could have a dummy pass-through unit between an hourly CO2 node and a daily CO2 node with a limit.

Does this make sense?

[mihlema]

Hi, I do like the idea of using a storage to represent the carbon cap, which I think might be the most powerful way to do it in SpineOpt. Still interested though in what happens with the unit_groups. Is this happening on SpineOpt or SpineToolbox side? For example, I remember my toolbox crashing sometimes when creating/viewing groups. Or is it e.g. as soon as the constraint gets created (probably SpineInterface issue)?

[OliverLinsel]

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.

[clizbe]

@DillonJ Do you know if Oliver was able to work through this or is it something we should fix? (Maybe on the Toolbox side?)