Unify units across the nomenclature

openENTRANCE / openentrance

Definitions of common terms (variables, regions, etc.) for the openENTRANCE project

http://openentrance.eu

Apache License 2.0

30 stars 49 forks source link

Unify units across the nomenclature #87

Open tburandt opened 3 years ago

tburandt commented 3 years ago

Hi all,

currently, the units across the nomenclature are widely un-unified and thus, automatic transformation for large data-sets becomes tedious and hard to maintain.

E.g.,

Some units are in EUR (carbon Price), some are in US$2010 (Investments, cost data)
Maximum Storage|Electricity|Energy Storage System|Compressed Air is in GWh, but Maximum Storage|Electricity|Hydro|Pumped Storage is in MWh
Final Energy is generally in EJ/yr, but all electricity-related values are in GWh/yr (e.g., Final Energy|Electricity). @danielhuppmann the aggregation feature in pyam does not take the difference in units (aggregating GWh and EJ) into account, does it?

I would like to see a unified unit scheme across the nomenclature, with the individual unit conversion needed for specific models done on the end-user side.

danielhuppmann commented 3 years ago

This is partly a duplicate of #14, where @sandrinecharousset suggested to use only one unit if they are close (only MW or GW), but potentially several if they are alternative interpretations (volume vs energy).

In #84, @sebastianzwickl extended the nomenclature to allow lists as units, so you could now define:

<Variable>:
    description: <some text>
    unit: [<first unit>, <second unit>]

But in principle, I'd agree that moving to EUR consistently is preferable in this project. About EJ vs. GWh, I think that using the more general EJ in the context of Final Energy|* to have a consistent variable tree - and use GWh in all variables that are directly related to the power section, eg Secondary Energy|Electricity|* (because aggregating to Secondary Energy doesn't make sense and everything related to capacity, costs, ...

danielhuppmann commented 3 years ago

Re your question about pyam, currently, values associated with different units are treated as separate, see https://github.com/IAMconsortium/pyam/issues/460. If you have an idea on how to implement this better, please chime in there. But in principle, following an explicit logic "first convert units, then aggregate" is preferable compared to baking too many features into one function implicitly.