Reorganizing benchmark hierarchy (scopes vs. sectors)

[MichaelTiemannOSC]

The TPI document "TPI Sectoral Decarbonisation Pathways" dated February 2022 provides (on Page 6) a list of sectors for which they have calculated decarbonization pathways for a variety of benchmarks (1.5 degrees, less than 2 degrees, 2 degrees, and some others). Notable is the fact that for some sectors (Electricity Utilities, Airlines, Shipping, and Cement), the benchmark only considers Scope 1 emissions. And for Autos, it only considers Scope 3 Category 11. In yet other cases, Scope 1, 2, and some Scope 3 emission are considered for Oil & Gas and Diversified Mining. All of this militates against the idea that we should choose, at the outset, a set of scopes we are interested in, and then to try to get the tool to tell us alignment against those scopes.

Rather, if we are trying to score temperature alignment for a set of companies, it is the Sector that tells us the scopes of the benchmark (if the benchmark covers the sector), and it is the Sector+Region info together that tells us the benchmark's decarbonization pathway.

The following functions should be re-written to work from the basis of Sector selecting scope and Sector+Region selecting the correct pathway:

• BaseProviderIntensityBenchmark _get_projected_intensities
• BaseProviderIntensityBenchmark _get_intensity_benchmarks
• BaseProviderProductionBenchmark _get_projected_production creates the fiction that a production benchmark defines a scope, when (1) it's the sector that defines it and (2) TPI does not even publish production-based benchmarks!
• Ditto BaseProviderProductionBenchmark get_company_projected_production

As well,

• EITrajectoryProjector _add_projections_to_companies might consider only making projections actually needed by the benchmark, rather than attempting to project all scopes for which we have data (no sense projecting 15 categories for Scope 3 if the benchmark uses only Scope 1).
• EITargetProjector project_ei_targets can be similarly lazy.

Effecting this change will also require changes to the benchmark automation code in the https://github.com/os-climate/itr-data-pipeline repository.

OECM doesn't highlight this problem quite as clearly because it's Production-centric benchmark shifts all the Scope 3 action into Scope 1, leaving the benchmark as an S1+S2 benchmark across all sectors. It's default benchmark is S1+S2+S3, across all sectors. The regularity of the OECM scope data (all sectors need essentially the same scope information) makes it relatively easy to ignore the fact that the scope should be derived from the sectors, not the other way around.

Comments, questions, concerns?

@kmarinushkin @joriscram

[kmarinushkin]

I think we need a more careful read through the dicument "TPI Sectoral Decarbonisation Pathways" of February 2022.
It is possible, to interpret it as a call for action, just as you suggest.
An alternative way to interpret is as a report, which doesn't require modifications from our side. "Here is what we collected" kind of way. In this case, they had a limited set of data, and that's what they used. If we have a wider set of data, our model is more complete. Maybe they found other categories of Scope 3 insignificant per sector, and that's why they excluded them from their manual calculations. For our automatic tool, we may easier include full set of data instead, even including insignificant categories, which will just add insignificant difference.

In conclusion, I think we need a more careful read through the dicument "TPI Sectoral Decarbonisation Pathways" of February 2022. For now, I suggest we prioritize our attention to the hanging work of S3-only and Template-v2

[MichaelTiemannOSC]

xref #152