The Emissions|CO2|Energy and Industrial Processes variable of the Shell Sky scenario actually seems to include net CO2 emissions that have significant detail, and "2 Agriculture & Other Industry" (see tab "World" here). So perhaps it should be split up in multiple categories, or alternatively, we should consider renaming it altogether to Emissions|CO2.

The panels showing the breakdown of contributions to global net CO2 (see below) shown in Figure SPM3b of the SR15 are not included in the related notebook, which compiles the indicator table of that figure.

See this tread on Climate/EnergyTwitter for a request related to these panels.

For MESSAGE-GLOBIOM 1.0|ADVANCE_* and MESSAGE-GLOBIOM 1.0|EMF33_*, the timeseries
Carbon Sequestration|CCS is not equal to the sum of the two CCS subcategories, Carbon Sequestration|CCS|Biomass and Carbon Sequestration|CCS|Fossil.

Several notebooks (I specifically checked sr15_2.3.3_short-lived_climate_forcers.ipynb and sr15_2.3.3_global_emissions_statistics.ipynb) by default still load release 1.1 data via the following command:
sr1p5 = pyam.IamDataFrame(data='../data/iamc15_scenario_data_world_r1.1.xlsx')
It would be useful to adjust this to loading release 2.0 data by default.

Also, in the introduction it is mentioned that the metadata file needs to be generated via the sr15_2.0_categories_indicators.ipynb notebook, but it seems metadata is readily available for download from the SR1.5 Scenario Explorer ([https://data.ene.iiasa.ac.at/iamc-1.5c-explorer]) which simplifies the process for the user and could be mentioned as an alternative.

The variable Diagnostics|* was mistakenly dropped during migration for all scenarios.

This data is required to compute one column in Table 2.A.12, in the Supplementary Material of Chapter 2. The omission during migration does not affect any figures or tables printed in the SR15.

Looking at the Capital Cost variables with a specific focus on solar PV (Capital Cost|Electricity|Solar|PV), my impression is that there are several issues related to regional aggregation across different models that report these variables.

• AIM/CGE 2.1: The value reported under World region appears to be the sum of the values reported at the 5-regional level.
• REMIND 1.7/REMIND-MAgPIE 1.7-3.0/MERGE-ETL 6.0/GENeSYS-MOD 1.0: The values reported at the 5-regional level appear to be multiples of the value reported under World. It seems that the number of native regions model regions per "5-region" determines the factor.
• IEA Energy Technology Perspective Model 2017, IEA World Energy Model 2017 and IMAGE 3.0.1 don't seem to report World aggregates, so it is harder to diagnose whether the same holds for these models, but it would make sense to double check this.

The variable Final Energy|Residential and Commercial of the IEA Energy Statistics has a typo, missing the "l" at the end.

This typo does not affect any assessment in the SR15.

Hi,

thanks for publishing these resources and for the open issue tracking, that should be super helpful!

I have a question on the scenario DB license:

The scenario data is licensed under a derivative of the Creative Commons CC-BY 4.0 License. If appropriate reference is made to the data source, it is permitted to use the data for scientific research and science communication. However, redistribution of substantial portions of the data is restricted.

When I first skimmed the release info i thought this was actually released under a CC-BY license - the CC-BY license text can be re-used but I guess in order to avoid such confusion it is not allowed to use the name "Creative Commons" with modified licenses as I understand the conditions on https://creativecommons.org/licenses/by/4.0/legalcode
(Of course, I am not a lawyer ...)

Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at creativecommons.org/policies, Creative Commons does not authorize the use of the trademark “Creative Commons” or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses.

Personally, I would of course prefer if the data were released under an established Open Data license, as creating new licenses and including vague terms like "substantial" often causes problems. (But that's probably an entirely different discussion.)

In any case, I think it would be better not to mention Creative Commons if it's not a Creative Commons license.

IAMC data template (as implemented at IIASA, as far as I understand) accepts "comments" for each variable. Issues have been report for some variables (#18; #19). It is great to see that these issues have been clearly documented. On the other hand, since the data tends to take its own life, it'd be nice to include some cautions within the database itself (I mean, the xlsx files). Would it be possible to add a comment? I can see two tiers of comments: one for each variable, and one for model/scenario.

Reaching out regarding something odd I noticed in the wind capacity data for POLES ADVANCE models while using the IAMC 1.5°C Scenario Explorer. For these models and scenarios, the database seems to indicate anomalously high fractions of offshore wind throughout the 21st century. A screenshot from the online Explorer highlighting this:

It looks to me like the onshore and offshore labels may have gotten transposed here? I wanted to check this, as I'm utilizing the capacities for different generation technologies for the models/scenarios in the ADVANCE project for one of my own projects.

I emailed Daniel Huppmann who took a quick look and produced some plots that seem to confirm that the onshore/offshore wind capacity values for POLES ADVANCE scenarios definitely seem odd, suggesting a reporting error:

The SSP runs are reported as not having climate variables in the database, which creates problems when filtering and sorting by temperature.

Since the SSP runs were designed to be linked to MAGICC, it would be helpful for the data users if MAGICC results were not only printed in diagnostics, but also reprinted in the regular climate variables (such as temperature).

I'm very excited that this is available on GitHub! Thank you everybody involved in this!

I'd love to help out making it runnable by the click of a badge on mybinder.org. Like this one, allowing you to re-execute some data analysis part of the LIGO teams work to analyze the gravitational wave sensor data.

https://mybinder.org/v2/gh/minrk/ligo-binder/master?urlpath=lab/tree/index.ipynb

Below are my notes on trying to run the notebooks without any previous experience of this work.

Notes

In short, mybinder.org will given a given github repo build a docker image and install dependencies found in typical configuration files like conda's environment.yml etc. As far as I can tell though, this repo does not yet contain any information on its python package dependencies other than perhaps information about pyam that should be of version 0.2.0.

So, I set out to try to figure out what made the code runnable, create an environment.yml file, and add a mybinder.org badge to the README.md in a PR.

But, I run into some issues though.

pyam=0.2.0 pandas=0.24 and ipython
I started out cloning the repo, created a fresh conda environment with Python 3.7, and installed pandas and pyam. That led me to the following error when importing pyam though.

Apparently that issue was resolved with pandas=0.24 instead of pandas=0.25. And another issue went away by installing ipython.

Downloading of data

1. I needed to register an account here: https://data.ene.iiasa.ac.at/iamc-1.5c-explorer/
2. I needed to https://data.ene.iiasa.ac.at/iamc-1.5c-explorer/#/downloads and manually download data
3. I needed to make it available at my data directory

Minor renaming of metadata file imports
I needed to adjust the import of the metadata.

# old failing
# sr1p5.load_metadata('sr15_metadata_indicators.xlsx')
# new functional
sr1p5.load_metadata('../data/sr15_metadata_indicators_r1.1.xlsx')

Notebook execution success
After the above, no errors occurred running spm_sr15_figure_3a_global_emissions_pathways.ipynb and all files down to the one with sr15_2.4.1 in its name.

Summary of impressions

• It wasn't so easy to get going
• I had to rely on some faith, when I saw the lack of environment.yml, requirements.txt, Pipfile, etc that specified dependencies, I knew I probably would be in for some additional unknown amount of work.
• I would have liked the ability to get an API token for the user to download the data to the /data folder, then the manual steps could be reduced significantly. Perhaps that is actually already possible without me knowing about it? Hmmm...

I found zero carbon price for SSP from the IMAGE model
(for periods such as 2030). The following is an R code.
I heard that it is a reporting error. The world average was not properly
produced. I don't know how this should be resolved and I'm writing this issue
here. (I contacted some people from the IMAGE team.)

===== R code =======
library(tidyverse)

df_org <- readxl::read_xlsx("iamc15_scenario_data_world_r1.1.xlsx",sheet=2)
df <- df_org

names(df) <- tolower(names(df))
col_names <- names(df)
year_col_names <- col_names[grep("^[0-9].*?$", col_names)]
df <- gather_(df, "period", "value", year_col_names)

df %>% filter(variable=="Price|Carbon") %>%
filter( str_detect(scenario,"SSP") & (!
str_detect(scenario,"baseline")) &
str_detect(model,"IMAGE") &
variable == "Price|Carbon"& !is.na(value) &
period == 2030) -> df_IMAGE_temp
df_IMAGE_temp

For some mode/scenario combinations, this seems to be computed based on discounted, for other on undiscounted consumption losses relative to the given baseline scenario.

The metadata excel file (and related filters in the Scenarios Explorer) are not fully set up to filter for scenarios with zero BECCS. For example, the MESSAGEix-GLOBIOM 1.0 | LowEnergyDemand scenario implicitly has 0 cumulative BECCS (due to having 0 CCS). However, the spreadsheet is missing a value in the BECCS column. There are several dozen other scenarios that have a blank in either the cumulative CCS or cumulative BECCS metatdata columns, or both. It is not clear to me, given the existing metadata notes, how to filter and categorize these scenarios when querying data based on the CCS and BECCS metadata filters.

The variable Emissions|CO2|Energy|Demand|Residential and Commercial was mistakenly dropped during migration for SSP, CD-LINKS and LED projects.

This data is required to generate Table 4.A.1, in the Supplementary Material of Chapter 4. The error during migration does not affect any figures or tables printed in the SR15.

When users land at:

https://data.ene.iiasa.ac.at/sr15_scenario_analysis/assessment.html

It's not obvious that there is also an accompanying github repository, so link the github repository from the notebooks / documentation.

The regional data (i.e., other than global timeseries, World) of the 'POLES|EMF33*' scenarios are not correct. This is due to an error in the regional mapping during the migration of these data from the EMF33 project database to the scenario ensemble database for this particular model.

The issue was raised in private communication with Brian O'Neill and Kimon Keramidas.

This error does not affect any assessment in the SR15.

While using the Diagnostics|MAGICC6|Harmonized Input|Emissions|HFC* variables, @znicholls noticed that the reported emission units (kt HFC23 / yr) for all HFC emissions are incorrect - for e.g., the unit for Diagnostics|MAGICC6|Harmonized Input|Emissions|HFC|HFC125 is mislabelled kt HFC23 / yr, while the values reported are appropriate when the correct unit (kt HFC125 / yr) is applied.

We corrected this in the data used using the unit mapping dictionary below:

unit_mapping = {
    "Emissions|HFC|HFC125":"kt HFC125 / yr",
    "Emissions|HFC|HFC134a":"kt HFC134a / yr",
    "Emissions|HFC|HFC143a":"kt HFC143a / yr",
    "Emissions|HFC|HFC227ea": "kt HFC227ea / yr",
    "Emissions|HFC|HFC245ca": "kt HFC245ca /yr",
    "Emissions|HFC|HFC32": "kt HFC32 / yr",
    "Emissions|HFC|HFC43-10": "kt HFC4310 / yr"
}

cc - @gidden

The hydrofluorocarbons variables: Diagnostics|MAGICC6|Harmonized Input|Emissions|HFC|* all have the units of kt HFC23/yr and not of the individual hydrofluorocarbons.

"Diagnostics|MAGICC6|Harmonized Input|Emissions|HFC|HFC125"	"kt HFC23/yr"
"Diagnostics|MAGICC6|Harmonized Input|Emissions|HFC|HFC134a"	"kt HFC23/yr"
"Diagnostics|MAGICC6|Harmonized Input|Emissions|HFC|HFC143a"	"kt HFC23/yr"
"Diagnostics|MAGICC6|Harmonized Input|Emissions|HFC|HFC227ea"	"kt HFC23/yr"
"Diagnostics|MAGICC6|Harmonized Input|Emissions|HFC|HFC23"	"kt HFC23/yr"
"Diagnostics|MAGICC6|Harmonized Input|Emissions|HFC|HFC245ca"	"kt HFC23/yr"
"Diagnostics|MAGICC6|Harmonized Input|Emissions|HFC|HFC32"	"kt HFC23/yr"
"Diagnostics|MAGICC6|Harmonized Input|Emissions|HFC|HFC43-10"	"kt HFC23/yr"

We noticed the following data for POLES

global_df.filter(variable='Carbon Sequestration|CCS|Fossil', model='POLES*').data

systematically reports significantly lower values for this variable than other SR15 scenarios. My guess is that values for this variable were reported in GtCO2/yr sequested rather than MtCO2/yr.

Here is an example from the SR15 low and no overshoot scenario set that includes a variety of other models (you can see POLES at the bottom)

Our best guess is that these are off (too low) by a factor of 100

It would be nice to have a handful of "standard" derived variables added to the database without the need to calculate them by hand. Initial candidates would be per capita values for final/primary energy (total), GDP, emissions, and intensities of energy/GDP, emissions/GDP, or emissions/energy. The Kaya decomposition indicators would be a good first step: https://en.wikipedia.org/wiki/Kaya_identity

(I'm new to ipcc scenario analysis with python/notebooks: apologies if overlooking something simple/obvious, or if opening a github issue is not the preferred way of raising this kind of question...)

I am trying to run the notebook spm_sr15_statements.ipynb. At:

with open("sr15_specs.yaml", 'r') as stream:
specs = yaml.load(stream, Loader=yaml.FullLoader)

it throws:

ConstructorError: could not determine a constructor for the tag 'tag:yaml.org,2002:python/object:pyam.run_control.RunControl'
in "sr15_specs.yaml", line 48, column 14

Relevant (?) version info:

python 3.7.10
pyam 1.2.0
pyyaml 6.0
yaml 0.2.5

I've tried randomly downgrading pyam and pyyaml but to no effect.

As a workaround, I have just commented out the entire definition of run_control from sr15_specs.yaml. That allows everything in spm_sr15_statements.ipynb to run. I have not checked the other notebooks that also use sr15_specs.yaml, so there may or may not be limitations to this workaround. Any other suggestions welcome.

The data for the variable "Emissions|CO2|Energy|Demand|Transportation" must be replaced for all EMF33 scenarios for the REMIND-MAgPIE runs for all regions.
the data was send to Daniel Huppmann on April 7, 2020.

The units on Price|Agriculture|Non-Energy Crops and Livestock|Index and Price|Agriculture|Non-Energy Crops|Index say "Index (2010 = 1)", but the AIM data appear to be indexed to 2005.

Would it be possible to include the scenario data used by the stylised climate models as part of the SR1.5 climate assessment process as part of the next data release? This would be very helpful for many researchers and ensure that assumptions required to go from native model data to scenarios which can be used by stylised climate models are consistent and publicly available.

The values reported by MESSAGE-GLOBIOM 1.0|EMF33_* for Primary Energy|Fossil are not aggregates of coal, gas and oil. This reporting error does not affect subcategories (with and without CCS).

This error affects one cell in Table 2.6 in the Final Government Review (FGR) version of the SR15, with share of primary energy from fossils greater than 100%.

This file is needed by many notebooks. It can be built from the "categories_indictors" notebook, but it would be better to save users the effort.

The set of EMF33_* scenarios from the MESSAGE-GLOBIOM_1.0 have actually been created with the newer version MESSAGEix-GLOBIOM_1.0. This is a minor issue, but should be addressed in a future update of the SR1.5 scenario data set.

During the compilation of the IAMC 1.5°C Data, we mistakenly applied a summation to all variables when aggregating model-native regions to the R5-regions. Instead, we should have used averages weighted by the respective quantities (carbon emissions, etc.).

As the SR15 assessment is only concerned with global assessments, this error does not affect any findings in the published report.

@danielhuppmann has the API changed? Why do you get meta and subannual columns now when you download SR1.5 data via pyam?

The variable Emissions|CO2|Energy|Supply|Electricity was mistakenly dropped during migration for SSP, CD-LINKS and LED projects.

This error affects the pre-release of the assessment notebooks at https://data.ene.iiasa.ac.at/sr15_scenario_analysis/assessment/sr15_2.4.1_final_energy.html, but it does not affect any figures printed in the SR15.