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.