Become units agnostic

[znicholls]

Is your feature request related to a problem? Please describe.

One of the most annoying things is having to do all your unit conversions yourself before you run your model. I'd love for us to find a way that users can just throw dataframes with whatever (well-defined) units and magicc will run properly.

Describe the solution you'd like

I think my ideal solution would have two components:

• find a library which can actually do unit conversions for us or build out https://github.com/znicholls/pysciunits to achieve this
• have a units module which defines all of the expected MAGICC units and can convert any input dataframes to the required units before writing files and running MAGICC

Describe alternatives you've considered

Continue to do this stuff by hand because it's tricky. That is an option but I think we could produce something really nice if we tried.

[lewisjared]

I have used the cfunits package before. It was super easy to integrate. The downside is that it requires the udunits library as an additional dependency.

It is used in https://github.com/NCAR/wrf-python to convert units

[rgieseke]

Pinging @AnnisG as well ...

The main problem is, that there is no accepted, widely used unit solution for Python/Pandas ...

The question is how far from core MAGICC we want to move away ... such functionality might also be something for a generalised SCM wrapper which handles scenarios with arbitrary units and allows calling different SCMs.

[JGuetschow]

I looked into pint because it has o called "contexts" which allow different conversions depending on the context. This is needed if we want to be able to convert under different GWPs. as of today I actually got custom built contexts to work,but so far I've only tested an example and not emissions conversion under different GWPs. But it should in general work. Most of the units would have to be added though, as the gas needs to by part of the unit. (so the unit would be e.g. GgCH4 not just Gg).

[rgieseke]

Cool, did you also take a look at https://github.com/yt-project/unyt ?

[znicholls]

unyt looks brilliant and has the ability to work with hdf5 which seems sensible for us. It also ports to pint so we could use that to do context conversions?

On Mon, 9 Jul 2018 at 2:08 pm, Robert Gieseke notifications@github.com wrote:

Cool, did you also take a look at https://github.com/yt-project/unyt ?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/openclimatedata/pymagicc/issues/76#issuecomment-403456955, or mute the thread https://github.com/notifications/unsubscribe-auth/AWh-m-gBHAbwYhBATyTcM7TwxAOXotEqks5uE0eqgaJpZM4VHebj .

[znicholls]

Pynt also looks good so we could do the other way too, use pynt then call unyt if we need hdf5 (which may make more sense for us given how easy it seems to be to add units with pint).

On Mon, 9 Jul 2018 at 2:52 pm, Zebedee Nicholls < zebedee.nicholls@climate-energy-college.org> wrote:

unyt looks brilliant and has the ability to work with hdf5 which seems sensible for us. It also ports to pint so we could use that to do context conversions?

On Mon, 9 Jul 2018 at 2:08 pm, Robert Gieseke notifications@github.com wrote:

Cool, did you also take a look at https://github.com/yt-project/unyt ?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/openclimatedata/pymagicc/issues/76#issuecomment-403456955, or mute the thread https://github.com/notifications/unsubscribe-auth/AWh-m-gBHAbwYhBATyTcM7TwxAOXotEqks5uE0eqgaJpZM4VHebj .

[znicholls]

Any progress here team? It would be good to know so we can start to build https://github.com/openclimatedata/openscm/ in a units agnostic way

ping @chrisroadmap

[znicholls]

alright I think we're on the road to somewhere https://github.com/hgrecco/pint/pull/671

[znicholls]

@chrisroadmap @JGuetschow what are the right units to be using for emissions? Mass per unit time? Or molar mass per unit time to allow easier conversion between e.g. C and CO2?

[chrisroadmap]

Mass per unit time is what FAIR uses. Implicitly at the moment as the "per year" part is not specified and an annual timestep is used. For all GHGs except CO2 and N2O there's no conversion to worry about as the emitted compounds are the same as the ones that appear in the concentration and radiative forcing calculations. It would be good for units to be defined by the user on input so that any required conversion can be performed before applying to the forward model.

[znicholls]

Ok great. With mass per unit time, how do you do the C to CO2 conversions?

On Thu, 30 Aug 2018 at 10:39 am, chrisroadmap notifications@github.com wrote:

Mass per unit time is what FAIR uses. Implicitly at the moment as the "per year" part is not specified and an annual timestep is used. For all GHGs except CO2 and N2O there's no conversion to worry about as the emitted compounds are the same as the ones that appear in the concentration and radiative forcing calculations. It would be good for units to be defined by the user on input so that any required conversion can be performed before applying to the forward model.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/openclimatedata/pymagicc/issues/76#issuecomment-417238402, or mute the thread https://github.com/notifications/unsubscribe-auth/AWh-m5x8Ky2PjokcviMNN-UEgvLWyo8Fks5uV6TdgaJpZM4VHebj .

[znicholls]

Should be solved by moving to using the openscm API