BertKramer
commented
2 years ago Hi Michael and others,
See my comments in red below.
Bert
From: Michael Tiemann @.> Sent: zondag 26 december 2021 13:47 To: os-c/ITR @.> Cc: Bert Kramer @.>; Mention @.> Subject: [os-c/ITR] Projections wrongly uses emissions data as production data (Issue #15)
This report relates to the develop branch, from which the the branch I'm working on is derived.
There are three fundamental projections that feed into the ITR calculation: emission intensities (EI), production, and emission targets. These projections in turn drive three calculations: cumulative TRAJECTORY, cumulative BUDGET, and cumulative TARGET.
get_preprocessed_company_datahttps://github.com/os-c/ITR/blob/develop/ITR/data/data_warehouse.py#:~:text=get_preprocessed_company_data performs these calculations, but while it claims to be using the company's projected production, the function get_company_projected_productionhttps://github.com/os-c/ITR/blob/523de88564977b4b0e4690ae994224424f781b5c/ITR/data/base_providers.py#:~:text=get_company_projected_production actually returns data from self.get_benchmark_projections(ghg_scope12), which is emissions, not production data.
For the MVP and MVP+ we did not have any information on production projection. The only source for production projections was the OECM document, where not only the available budgets were reported, but also the expected production levels up to 2050 that were used to set the sector emission reduction pathways reported. So in the "benchmark_production_OECM" json and the "OECM_EI_and_production_benchmarks_v2.xlsx" files contain the expected production growth rates. Furthermore, to use company specific production projections might be problematic because in that case the cumulative sector emissions might not be in line with the benchmark / decarbonization pathway.
Diagnosing the problem is further confounded by the fact that for the baseline year (2019), all the sample data uses the same metric values for both EI and target data:
company_name:"Company AG" company_id:"US0079031078" region:"North America" sector:"Electricity Utilities" target_probability:0.428571428571428 projected_targets: year:2019 value:1.6982474347547039 projected_intensities: year:2019 value:1.6982474347547039
Moreover, the range of target and intensity data all sit in a range that makes 2 degree temperature scores appear achievable (all input projection values well below 1.0 except GB0031274896 which is 1.89). The calculations I have done with publicly available data have EI data that's commensurate with the test data, but both S1+S2 emissions data (in MMT CO2e) and production data (in TWh) are 1-3 orders of magnitude larger than most of the test data, and result in temperature scores that are much different than anything imagined by the test data. US-based electricity generation is more than 4,000 TWh/year. Duke Energy generated over 200 TWh of electricity in 2018, which also points to a documentation problem.
The source code makes no mentions of units, nor explains how the 3.6 conversion factor for the Electricity_Utilities sector was derived. Of course we know that a Watt is a Joule-second, and that a Watt-hour is 3600 Joule-seconds. But the 3.6 conversion factor buries a factor of 1000 with no explanation. The documentation should make clear what unit inputs are expected.
For power utilities, the emission intensity unit should be mio t CO2e / TWh or mt CO2 / MWh. According to the RMI data dictionary, the emission intensity unit is also metric tons/MWh. So this conversion factor of 3.6 should not be used (which is indeed to convert Wh to J). When I prepared for the demo, the ITR tool code was not consistent in the use of this conversion factor. I asked Joris to remove this conversion factor, and just assume that all input is always in the correct unit. So as far as I know, for the Demo the correct units were used. But I am not sure if the code version I used for the demo is also the version that you use now.
I agree with you that the units of measurements are currently poorly documented / defined in the ITR tool and very error prone. So this is something we should definitely work on.
Note that the conversion factor was introduced because in the original MVP data provided by LSEG, energy production was provided in Giga Joules and emissions were in tons CO2e.
@BertKramerhttps://github.com/BertKramer
- Reply to this email directly, view it on GitHubhttps://github.com/os-c/ITR/issues/15, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUWPCCLNALY4R2ZYN6OO7XTUS4FETANCNFSM5KY4DYBQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.Message ID: @.**@.>>
MichaelTiemannOSC
This report relates to the develop branch, from which the the branch I'm working on is derived.
There are three fundamental projections that feed into the ITR calculation: emission intensities (EI), production, and emission targets. These projections in turn drive three calculations: cumulative TRAJECTORY, cumulative BUDGET, and cumulative TARGET.
get_preprocessed_company_data performs these calculations, but while it claims to be using the company's projected production, the function get_company_projected_production actually returns data from
self.get_benchmark_projections(ghg_scope12), which is emissions, not production data.Diagnosing the problem is further confounded by the fact that for the baseline year (2019), all the sample data uses the same metric values for both EI and target data:
company_name:"Company AG" company_id:"US0079031078" region:"North America" sector:"Electricity Utilities" target_probability:0.428571428571428 projected_targets: year:2019 value:1.6982474347547039 projected_intensities: year:2019 value:1.6982474347547039
Moreover, the range of target and intensity data all sit in a range that makes 2 degree temperature scores appear achievable (all input projection values well below 1.0 except GB0031274896 which is 1.89). The calculations I have done with publicly available data have EI data that's commensurate with the test data, but both S1+S2 emissions data (in MMT CO2e) and production data (in TWh) are 1-3 orders of magnitude larger than most of the test data, and result in temperature scores that are much different than anything imagined by the test data. US-based electricity generation is more than 4,000 TWh/year. Duke Energy generated over 200 TWh of electricity in 2018, which also points to a documentation problem.
The source code makes no mentions of units, nor explains how the 3.6 conversion factor for the Electricity_Utilities sector was derived. Of course we know that a Watt is a Joule-second, and that a Watt-hour is 3600 Joule-seconds. But the 3.6 conversion factor buries a factor of 1000 with no explanation. The documentation should make clear what unit inputs are expected.
@BertKramer