search

IAMconsortium / pyam

Analysis & visualization of energy & climate scenarios
https://pyam-iamc.readthedocs.io/
Apache License 2.0
222 stars 116 forks source link

supporting emissions units in operations #666

Open gidden opened 2 years ago

gidden commented 2 years ago

Overview

When trying to do operations on emissions, e.g., 

df = pyam.IamDataFrame(pd.DataFrame(
    [
        ["model_a", "scen_a", "World", "foo", "Mt CO2/yr", 1, 6.0],
        ["model_a", "scen_a", "World", "bar", "Mt CO2/yr", 0.5, 3],
    ],
    columns=pyam.IAMC_IDX + [2010, 2020],
))
df.add('foo', 'bar', 'baz')

we get an error as

UndefinedUnitError: 'CO2' is not defined in the unit registry

standard unit conversion works fine, so we somehow have the capability to work with the emissions units

df.convert_units("Mt CO2/yr", "Gt CO2/yr") # etc

It seems that there was quite some discussion on pyam unit support in https://github.com/IAMconsortium/units/pull/19.

Desired Outcome

I would argue that this is a situation where operations should "just work". In a worst case scenario, if I want to add two emissions time series with the same units, I shouldn't have to worry about units at all. In a best and ideal case scenario, we should leverage the power of pint to do the auto conversions as any other pint-dependent library.

So, I am wondering if we can lay out what are the pros and cons - and what are the options in terms of supporting such a feature.

@khaeru curious what you think as the units master =)

cc others who might be interested - @coroa @danielhuppmann @znicholls

znicholls commented 2 years ago

I'm not sure how essential it is, but if you just compared strings in the line below rather than casting to Unit first, the case where units are the same would just work (might cause other issues of course)

https://github.com/IAMconsortium/pyam/blob/de6b47bb1ea7e937ad32dc8a6c284beddca98685/pyam/_ops.py#L84

On the rest, having read the previous discussions, I leave this up to others

znicholls commented 2 years ago

The irony of this happening today is not lost on me, but if you want an example of our non-SI shortcut falling over, have a look here (https://github.com/openscm/openscm-units/issues/36). The caveat I would put on this is that this is the first time in two years that we've been bitten by this, although our use cases are probably narrower than what you're doing.