quintel / etsource

Data source for the Energy Transition Model
https://energytransitionmodel.com/
MIT License
12 stars 8 forks source link

Should curtailed and exported electricity be added to CO2 and primary demand calculation? #2172

Open marliekeverweij opened 4 years ago

marliekeverweij commented 4 years ago

Due to mechanical turk failures of the flexibility_spec.rb @redekok and I found an odd correlation. When taking the following steps:

  1. Open NL 2050 scenario
  2. Set capacity_of_energy_power_wind_turbine_inland to 30000 MW
  3. Set capacity_of_industry_chemicals_other_flexibility_p2h_electricity to 1000.0 MW

The CO2 emissions in industry decrease, but in other sectors increase: Screen Shot 2019-12-31 at 11 16 48 Screen Shot 2019-12-31 at 11 15 17

This started to occur after the heat network merge on December 20: https://semaphoreci.com/quintel/mechanical_turk/branches/master/builds/2362

However, when more wind turbines are built (for example 50GW), then the CO2 emissions decrease in all sectors.

Does somebody know how this behavior can be explained? @antw @michieldenhaan

michieldenhaan commented 4 years ago

I think the reason why all sectors except industry go up is because they do not 'profit' from P2H in industry in any way but do 'suffer' from curtailment/export going down. Curtailment/export are not included in the CO2 chart but they do influence the CO2 allocated to other sectors (as well as primary demand allocation) because the primary demand/CO2 calculations are not time-resolved.

See example below.

IMG_0363

In the case with curtailment, 20 electricity is curtailed out of a total production of 50. This means that 20/50 = 40% of CO2 emissions from electricity production are not allocated to any demand sector (households and industry in this example) since curtailment is not included in any sector. The demand sectors make up 10 (households) + 20 (industry) / 50 = 60% of electricity output, which means that only 60% of CO2 emissions from electricity production show up in the CO2 chart.

Now suppose that we use this 20 electricity to produce hydrogen. Total electricity production is still 50 but the output of energy_power_hv_network_electricity is now 30 as 20 is transferred to the excess electricity node. This means that the share of the demand sectors is 10+20 / 30 = 100% of electricity output, which means that 100% of CO2 from electricity production is allocated to households + industry. Hence, CO2 emissions have gone 'up'.

Note that the same effect occurs because energy_export_electricity is not included in any of the demand sectors either.

The conclusion is (I think) that we should include the curtailment node to both the primary demand and CO2 calculations, e.g. as part of the energy sector. The export node is a tricky one: we currently take into account CO2 emissions for import, which is why we exclude exports.

Notifying @ChaelKruip

ChaelKruip commented 4 years ago

Nice analysis @michieldenhaan!

The conclusion is (I think) that we should include the curtailment node to both the primary demand and CO2 calculations, e.g. as part of the energy sector.

We have been struggling with this in the past as well and added CO2 emissions of curtailment and export to the CO2 mekko at some point as a separate 'sector'. See also this commit

If I recall correctly, last year, we removed this category again from the mekko. I'm foggy on the details. I think we never included curtailment in the dashboard CO2 emissions. Part of the difficulty is that you have a mix of dispatchable and volatile electricity. You might argue that only the volatile part is curtailed so no CO2 is lost. On the other hand, the CO2 calculations are based on the annual mix and don't specify which part of that mix is exported/curtailed or used domestically. Electrons are electrons.

The export node is a tricky one: we currently take into account CO2 emissions for import, which is why we exclude exports.

Exactly.

marliekeverweij commented 4 years ago

Wow, I did not really realize that this is going on and I actually think that it is quite shocking.

You might argue that only the volatile part is curtailed so no CO2 is lost. On the other hand, the CO2 calculations are based on the annual mix and don't specify which part of that mix is exported/curtailed or used domestically. Electrons are electrons.

True! For example: in a scenario with lots of wind turbines and no flex technologies installed there will be a lot of curtailment. The CO2 that is associated with curtailment (because ETM calculations are based on the annual mix) will not be taken into account. Looking at Michiels first example: 8 ... CO2 is emitted but not taken into account because of curtailment.

So this bug will have most impact on scenarios with a lot of curtailment: the CO2 emissions should actually be higher than what the ETM calculates. I've added a 'Bugs'-label to this issue for now. We should discuss the priority of this issue together.

This issue has simularities with this issue: https://github.com/quintel/etmodel/issues/2841

marliekeverweij commented 4 years ago

I actually think the recursive method should be adjusted: for electricity it should not be based on the annual mix, but on the hourly profiles.

The primary demand / CO2 shares used in the recursive method should be based on the hourly curves; how much did each production technology contribute to the hourly demand? In other words: the area underneath a production technology profile should be divided by the area underneath the demand curve. But I can explain this idea better in person with a whiteboard ;)

Screen Shot 2020-01-03 at 15 21 35

ChaelKruip commented 4 years ago

I actually think the recursive method should be adjusted: for electricity it should not be based on the annual mix, but on the hourly profiles.

I agree but this might not be simple! Let's discuss this when @antw is in the office!

marliekeverweij commented 4 years ago

Putting this issue on hold for now since it's too much work to fix properly before the deploy.

github-actions[bot] commented 3 years ago

This issue has had no activity for 60 days and will be closed in 7 days. Removing the "Stale" label or posting a comment will prevent it from being closed automatically. You can also add the "Pinned" label to ensure it isn't marked as stale in the future.

github-actions[bot] commented 3 years ago

This issue has had no activity for 60 days and will be closed in 7 days. Removing the "Stale" label or posting a comment will prevent it from being closed automatically. You can also add the "Pinned" label to ensure it isn't marked as stale in the future.