Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

For annualised PAGE: control resulting changes in variables #32

Open
pwaidelich opened this issue Jun 24, 2019 · 6 comments
Open

For annualised PAGE: control resulting changes in variables #32

pwaidelich opened this issue Jun 24, 2019 · 6 comments
Assignees

Comments

@pwaidelich
Copy link
Collaborator

We should take closer looks at some variables, compare the annualised and non-annualised time series and post the results here as well as flag potential bugs.

I just ran the model for the first time in the annualised version and checked only the te_totaleffect variable from EquityWeighting.jl. Compared to the master branch, it dropped by 7%. Besides some deviations due to interpolation, I think a possible reason is that each timestep in the non-annual version represents the years before and after it (e.g. 2150 for 2125-75) but 2300 only represents 2275-2300 because . As impacts should be higher in 2300 than for any previous year, this should lead to upward bias which is corrected by the annualisation.

@jkikstra
Copy link
Collaborator

Interpolation issues and considerinations --- Population
In PAGE-ICE, population growth is assumed to be zero after 2100 [see picture].
Currently, with the linear interpolation, growth rates are nonzero for the period 2101-2149.

There are two options here:

  1. This is not similar to the original PAGE-ICE and could be manually set to be 0 to conform with the way the picture looks.
  2. Since "letting growth rates fall to zero" seems a more natural assumption than "growth rates are zero after 2100", this change to the model actually seems pretty easy to defend and might even be considered an improvement.

N.B. In this change, interpolation happens between years of analysis. However, this is problematic if one would think of the years of analysis to be an average of the period around that year.

@pwaidelich
Copy link
Collaborator Author

pwaidelich commented Jun 24, 2019

GDP
The (linear) interpolation of parameters including growth rates blows up GDP by 2300 by ~75%.
gdp_defaultpage
gdp_annualisedpage

As pcGDP growth rates converge to zero over time, using, say, 2200's GDP growth rate for 2151-2200 results in lower growth than using interpolated rates for each year. This will remain an issue even if we switch to exponential interpolation for the growth rate parameters.

@pwaidelich
Copy link
Collaborator Author

pwaidelich commented Jun 24, 2019

Global Temperatures and Market Impacts
Global temperature smoothes out but no considerable differences due to (linear) interpolation. Temperature is down by 0.03C by 2300 in the annualised version.
rt_g_defaultpage
rt_g_annualisedpage
As regional temperatures are proportional to global ones and market impacts (in %GDP) depend directly on those temperature, the same holds for market impacts (US impacts in 2300 drop by 0.01 percentage points which is negligible)

@jkikstra
Copy link
Collaborator

GDP
The (linear) interpolation of parameters including growth rates blows up GDP by 2300 by ~75%.
gdp_defaultpage
gdp_annualisedpage

As pcGDP growth rates converge to zero over time, using, say, 2200's GDP growth rate for 2151-2200 results in lower growth than using interpolated rates for each year. This will remain an issue even if we switch to exponential interpolation for the growth rate parameters.

This is because of both higher values in GDP and Population for the interpolated years in this version, since original PAGE-ICE uses the static growth rate of t-1 for calculation GDP,Population at t=1.

@pwaidelich
Copy link
Collaborator Author

pwaidelich commented Jun 26, 2019

I switched the way we interpolate SSP growth rates: Now we use the value for 2030 for 2021-2030 and so on which matches the way the default model works. As a result, we perfectly match GDP and population time series now and deviations in costs are largely reduced.
gdp_annualisedpage_new
However, there are still some differences: Total discounted impacts (td_totaldiscountedimpacts in EquityWeighting.jl) is now at 6.8e8, for the default model it's 7.5e8. Adaptation costs (tac_totaladaptationcosts) are at 2.77e6 compared to 2.81e6 which seems a negligible difference. Abatement costs (tpc_totalaggregatedcosts) are at 3.06e7 compared to 3.32e7.
We should track down where they come from.

P.S. I certainly don't think this is the best way to use the SSP rates. But first we should be able to proof that we can reproduce the default model in the annualised version before we adjust it.

@pwaidelich
Copy link
Collaborator Author

pwaidelich commented Jun 26, 2019

Forcings:
CO2 forcing and emissions are virtually identical apart from the obvious smoothing effect.
Methane forcing changes slightly, looks like a minor parameter is affected by the annualisation.
ch4forcing_annualised
ch4forcing_default
LG forcing is virtually identical
N20 forcing is virtually identical apart from the obvious smoothing effect.
Sulphate forcing is virtually identical

Update on Methane:

  • teay_CH4emissionstoatm shows a drastic change
    Annualised:

teay_CH4_annualised

Default:

teay_CH4_default

The same holds for all other teay_X variables in CH4Cycle.jl. The issue is caused by Dmitry's permafrost additions which are currently not coded in a way that is robust to changes in timestep lengthes. Teay_X variables are calculated by taking differences in some other emissions variables (which are identical for both models) between timesteps but these differences are obviously larger, the greater the timestep. For the first year, there is a special procedure which is also based on the length between 2020 and base year 2015 but not affected by the annualisation, leading to the spikes at t=2020. Overall outcome (=forcing) is not really affected but the resulting time series are a bit misleading, so we could smooth it out at one point. Low priority imho

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants