openclimatedata / globalwarmingpotentials

Global Warming Potentials as assessed by the IPCC in CSV format, and as Python and Node modules
Creative Commons Zero v1.0 Universal
22 stars 8 forks source link

Error in AR6 supplement for CFC-11 and CFC-12 #16

Closed chrisroadmap closed 2 years ago

chrisroadmap commented 3 years ago

Hello guys,

We discovered an error in the GWP and GTP values of CFC-11 and CFC-12 in the Chapter 7 Supplement. They are understated by 12%, because the tropospheric rapid adjustment was not added (section 7.3.2.4).

Compare values for CFC-11 in table 7.SM.7 and table 7.15. Table 7.15 is correct.

In light of this error I'm also making the calculations of the GWPs public on the AR6 repository (I didn't originally do them). They are not as straightforward as they were in AR5.

Will update this issue when I have a new GWP table. Sorry for the error.

znicholls commented 3 years ago

Ah well it happens, thanks for letting us know

jkikstra commented 3 years ago

Thanks for update Chris

chrisroadmap commented 3 years ago

I've updated this table on my own repository if you want to use it (https://github.com/chrisroadmap/ar6/blob/main/data_output/7sm/metrics_supplement_cleaned.csv, with raw version at https://raw.githubusercontent.com/chrisroadmap/ar6/main/data_output/7sm/metrics_supplement_cleaned.csv). I've just asked for the IPCC fork to be updated to reflect this.

GWPs and GTPs have changed for CFC-11 and CFC-12. CGTPs have changed for all gases as they were initially wrong but I don't think you use them. AGWPs and AGTPs sometimes change in the third significant figure due to rounding conventions, but again I don't think you used them.

rgieseke commented 3 years ago

I was trying to map the files from @chrisroadmap back to this package (thanks Chris!) and now i have a question for @znicholls and @danielhuppmann:

Is the naming format/convention used in openscm and pyam documented somewhere? The "Acronym" and "Formula" columns in Chris' file don't map perfectly :-)

E.g. is there a specific convention to use formula for chlorides but acronym for fluoromethanes?

znicholls commented 3 years ago

Is the naming format/convention used in openscm

Sort of (RCMIP) but it's pretty ad-hoc, just based on what has been used in RCMs over the years (i.e. what has been used in MAGICC basically). If we can support multiple that would be great... I know that anything with hyphens in the units will explode with pint though so those would have to be stripped out.

is there a specific convention to use formula for chlorides but acronym for fluoromethanes?

I've never seen a deliberate decision...

mikapfl commented 3 years ago

Over in openscm-units we also have aliases for substances (e.g. https://github.com/openscm/openscm-units/blob/fcada9ec83e155e4b80f120d2294053a42f1e8e7/src/openscm_units/_unit_registry.py#L189). Maybe it makes sense to also have aliases in globalwarminpotentials?

rgieseke commented 3 years ago

Maybe it makes sense to also have aliases in globalwarminpotentials?

Definitely! I also though that Chris' sheet gave the opportunity to add some aliases and/or more info like lifetimes.

(The naming is just all so messy :-) Which is i once started https://github.com/openclimatedata/ghgrenamer)

danielhuppmann commented 3 years ago

Is the naming format/convention used in .. pyam documented somewhere?

pyam doesn't implement any convention on units, it will take any string (including '') or None. Only when needed for operations like unit-conversion or data operations, it will try pint, then iam-units - and iam-units inherits directly from this repository.

What is more challenging are the conventions used in various projects like AR6-WG3, openENTRANCE, etc. - there is not a lot of consistency across or within projects about emissions... (e.g., Emissions| except for Emissions|Sulfur in AR6 WG3)