Add multiple versions of carbon-price variables

[danielhuppmann]

This PR adds the carbon-price variables (with different forms of aggregation) as used in the ENGAGE project.

fyi @IAMconsortium/common-definitions-coordination

[orichters]

In NGFS, we also have sectoral-differentiated carbon prices because we have sector-specific policies.
Worth adding something like this?

Price|Carbon|Supply
Price|Carbon|Demand|Industry
Price|Carbon|Demand|Residential and Commercial
Price|Carbon|Demand|Transportation

[danielhuppmann]

In NGFS, we also have sectoral-differentiated carbon prices because we have sector-specific policies.

No objections from me, but looking at the NGFS variable, I notice two issues:

1. these variables do not have a description
2. these variables are all weighted by "Final Energy" (not the emissions or energy use of that sector) - is that intended?

I suggest do a follow-up PR (and discuss the two issues there) once this PR is merged (after one week unless there are any objections).

[orichters]

We weigh by Final Energy because once you go to negative emissions in some sectors, weighing by emissions creates really strange effects such as massive spikes (dividing by ~ zero) and negative carbon prices. Fine to discuss that later.

[orichters]

Question: Is it really a good idea to have variables that include a part within parantheses? I'm asking because many of our scripts use strings of the format "Variable name (Unit)" and I'm a bit concerned that may mess up some of our scripts :)

I couldn't find these variable names in the Navigate / Engage / Elevate template I have, anyway (from May 26, 2023)

[danielhuppmann]

Right, this was added in the openENTRANCE project via openENTRANCE/openentrance#154 per suggestion by @Renato-Rodrigues (after discussion with @robertpietzcker, if I recall correctly). The idea is to have an easy way to compare different computations for carbon price given the caveats of using negative weights.

If you think that this is too much of a distraction, I can also remove it and we start a separate PR and discuss there...

[orichters]

No, that is fine. If Renato proposed it, I have no doubt it is a good idea. And with the parantheses: As this basically affects only postprocessing scripts (we don't need to name it like that in REMIND), no objection to that.

[orichters]

I wonder whether aggregating by Gross Emissions|CO2 would be preferable, avoiding this really counter-intuitive and confusing issue of negative or undefined (division by 0) carbon prices

[danielhuppmann]

Not sure about that, this solution would also deviate from the "standard" solution where the price is weighted by net emissions.

[robertpietzcker]

There is no "perfect" solution. In my view, the version "weighted by final energy" would be the best default setting, as it represents the angle "how large is the energy system for which a carbon price is relevant" (this could also be "primary", but I think final is a bit better), but if one takes a different angle, other aggregations can be more fitting.

If there is a specific angle for which weighting by "gross emissions" would be better, it could be added as well, right?

[danielhuppmann]

Yes, we can always add other aggregation metrics and variables for specific projects. For example, ECEMF uses final-electricity as weight (in addition to other weights) because this has project includes electricity-only models.

[FlorianLeblancDr]

Gross and Net emissions are both fine.
Having negative mean pricing should be rare: in my understanding, this would happened if regions without NET have higher carbon prices than in regions with NET, which is really counter-intuitive and is more a modelling issue.

In the past Gross emissions were used (previous papers and the IPCC) to compute the net present value of the global carbon price in order to cover negative prices, but again I think at that time the issue was the use of a discount rate not compatible with some model results, rather than using "Gross" over "Net" emissions.

Anyway those should be moved to the "macro" list now.

[robertpietzcker]

@FlorianLeblancDr I don't understand the comment - it is quite easy to get weird results when using net emissions as weights.

Here two cases with two regions with different carbon prices - while emissions are quite similar between the two cases, they flip from -800$/tCO2 in case A to +1200 $/tCO2 in case B:

So I still think weighing by another metric that is more stable and preferably related to the overall size of the energy system (such as FE) is much more robust and useful when calculating average carbon prices - if one is interested in "what carbon prices does the world see on average", and not simply "what are carbon pricing revenues" - the second question is very different from the first one.

[FlorianLeblancDr]

Thank for this numerical example @robertpietzcker
I agree then.

With the caveat: carbon price trigger energy efficiency, which in this case decrease the weight applied.