Version Checks (indicate both or one)
Issue Description
Problem
I was taking a look at PyPSA-Eur's approach to CO2stop dataset processing and I noticed some inconsistencies that likely lead to double or even triple counting potentials in certain cases.
The code in build_co2_sequestration_potentials.py seems to:
- Compute potentials for storage units (aquifers) and then add daughter unit potentials on top of that (
create_capacity_map_storage).
- Then, for traps, potentials are calculated (
create_capacity_map_traps).
- Both storage units and traps are combined, dropping duplicates.
From reports I've read on this dataset, the daughter unit potential is already the traps potential. The CO2Stop docs are a bit obtuse to read, but as far as I understand their methodology does mention that storage units already have the total capacity, and that 'daughter units' is the traps potential that should be subtracted from this total if necessary.
I've done a few calculations, and PyPSA-Eur's numbers ('neutral' case) are above the values from other literature using this dataset (see the Danish and JRC reports).
Proposed fix
Subtract daughter unit potential instead of adding it, or use the storage unit ID in the traps data tables to identify cases that would be double counted.
Reproducible Example
Run at a resolution that includes all CO2Stop countries.
Add CO2 sequestration potential before it is annuitised.
Expected Behavior
Double counted should be avoided. Total storage cap in the neutral scenario should be around ~480 GtCO2 for the neutral scenario.
Installed Versions
Details
I just checked the master branch.
Version Checks (indicate both or one)
I have confirmed this bug exists on the lastest release of PyPSA-Eur.
I have confirmed this bug exists on the current
masterbranch of PyPSA-Eur.Issue Description
Problem
I was taking a look at PyPSA-Eur's approach to CO2stop dataset processing and I noticed some inconsistencies that likely lead to double or even triple counting potentials in certain cases.
The code in
build_co2_sequestration_potentials.pyseems to:create_capacity_map_storage).create_capacity_map_traps).From reports I've read on this dataset, the daughter unit potential is already the traps potential. The CO2Stop docs are a bit obtuse to read, but as far as I understand their methodology does mention that storage units already have the total capacity, and that 'daughter units' is the traps potential that should be subtracted from this total if necessary.
I've done a few calculations, and PyPSA-Eur's numbers ('neutral' case) are above the values from other literature using this dataset (see the Danish and JRC reports).
Proposed fix
Subtract daughter unit potential instead of adding it, or use the storage unit ID in the traps data tables to identify cases that would be double counted.
Reproducible Example
Expected Behavior
Double counted should be avoided. Total storage cap in the neutral scenario should be around ~480 GtCO2 for the neutral scenario.
Installed Versions
Details
I just checked the master branch.