PAGE2009 scc values declining over time

Hi everyone,

So I have found that the values of PAGE2009 decline over time, while the most logical thing it would be otherwise. PAGE2020 increases up to 2040, and decreases a bit in 2050, increasing again afterwards. Is this normal? Or what happened?

Thank u!

Hello,

This might be a question for the PAGE model developers (we can likely help you get in touch), as it is quite model specific, but I can at least check that I can replicate your results. Are you using the deterministic or Monte Carlo configurations of these models?

Lisa

Hi there,

I’m using a deterministic configuration.
That would be really helpful!

Thank you a lot.

Hi there, ok so for a constant discount rate of 2.5% for PAGE2009 I have:


where years = [2009, 2010, 2020, 2030, 2040, 2050, 2075, 2100, 2150, 2200]

So here I see the SCC, when calculated as current value to the year of emissions as opposed to net present value to the current year like 2022, increases when emissions year increases. This is what I would expect in the short term. Perhaps I have misunderstood your question, what values are you seeing decline?

I’ll mostly focus this forum on technical/scientific questions about Mimi and the tool, but if something seems counterintuitive to general knowledge it is helpful to know in order to sanity check the models. Thus far the results above seen in line with expectation to me.

Hi,

Thank you for your response. This is weird, because I can’t replicate your example. See my code in Julia:

julia> using MimiPAGE2009

julia> m=MimiPAGE2009.get_model()
Mimi.Model
Module: Mimi
Components:
ComponentId(MimiPAGE2009.co2emissions)
ComponentId(MimiPAGE2009.co2cycle)
ComponentId(MimiPAGE2009.co2forcing)
ComponentId(MimiPAGE2009.ch4emissions)
ComponentId(MimiPAGE2009.ch4cycle)
ComponentId(MimiPAGE2009.ch4forcing)
ComponentId(MimiPAGE2009.n2oemissions)
ComponentId(MimiPAGE2009.n2ocycle)
ComponentId(MimiPAGE2009.n2oforcing)
ComponentId(MimiPAGE2009.LGemissions)
ComponentId(MimiPAGE2009.LGcycle)
ComponentId(MimiPAGE2009.LGforcing)
ComponentId(MimiPAGE2009.SulphateForcing)
ComponentId(MimiPAGE2009.TotalForcing)
ComponentId(MimiPAGE2009.ClimateTemperature)
ComponentId(MimiPAGE2009.SeaLevelRise)
ComponentId(MimiPAGE2009.Population)
ComponentId(MimiPAGE2009.GDP)
ComponentId(MimiPAGE2009.AbatementCostParameters)
ComponentId(MimiPAGE2009.AbatementCostParameters)
ComponentId(MimiPAGE2009.AbatementCostParameters)
ComponentId(MimiPAGE2009.AbatementCostParameters)
ComponentId(MimiPAGE2009.AbatementCosts)
ComponentId(MimiPAGE2009.AbatementCosts)
ComponentId(MimiPAGE2009.AbatementCosts)
ComponentId(MimiPAGE2009.AbatementCosts)
ComponentId(MimiPAGE2009.TotalAbatementCosts)
ComponentId(MimiPAGE2009.AdaptationCosts)
ComponentId(MimiPAGE2009.AdaptationCosts)
ComponentId(MimiPAGE2009.AdaptationCosts)
ComponentId(MimiPAGE2009.TotalAdaptationCosts)
ComponentId(MimiPAGE2009.SLRDamages)
ComponentId(MimiPAGE2009.MarketDamages)
ComponentId(MimiPAGE2009.NonMarketDamages)
ComponentId(MimiPAGE2009.Discontinuity)
ComponentId(MimiPAGE2009.TotalCosts)
ComponentId(MimiPAGE2009.EquityWeighting)
Built: false

julia> run(m)

julia> years=[2009,2010,2020,2030,2040,2050,2075,2100]
8-element Vector{Int64}:
2009
2010
2020
2030
2040
2050
2075
2100

julia> for year in years
result=MimiPAGE2009.compute_scc_mm(year=year, eta=0., prtp=0.025).scc
println(result)
end
54.38849496012568
54.90304083592117
54.02683284205854
51.85329033868194
49.01452168599784
45.52600545843482
39.30021831504464
25.64654228630215

There you can see it is declining.
It does not happen with PAGE2020 though:
julia> years=[2020,2030,2040,2050,2075,2100]
6-element Vector{Int64}:
2020
2030
2040
2050
2075
2100

julia> using MimiPAGE2020

julia> for year in years
result=MimiPAGE2020.compute_scc_mm(year=year, eta=0.,prtp=0.025).scc
println(result)
end
139.41948690117192
155.18410794343478
235.71055944458882
245.09497288540553
395.239869717815
433.5959880153165

Here I get the same results as you.

I found it weird that I when use the code line in the MimiPAGE website:
“scc = MimiPAGE2009.compute_scc(year = 2020)” it does not give the same results.

I’m also confused on how to know if these values are current value to the year or net present value, only from the keywords.

Hello, so compute_scc_mm and compute_scc from MimiPAGE2009 should output the same values, and do on a fresh download, so it seems there must be something going on with your version downloaded or something you might have changed. If you continue to have that problem we should move this discussion to the MimiPAGE2009 repository perhaps in Issues since this is very model specific. I would recommend removing MimiPAGE2009 from your environment with

] # enter package mode
rm MimiPAGE2009`

and then re-add it

add MimiPAGE2009

and try again, perhaps a change was made or you had an old version. If it does not return new values we can continue this conversation with the authors on Github Issues.

Per the current vs. NPV that is a decision made by the model authors, and perhaps is not clear in their documentation, but I would expect it to be current value for those future pulse years based on convention. You can compare to published values in their literature if you are unsure, or feel free to reach out to them on Github etc. if you need more details.

1 Like

@fcidmora I did notice this in the current documentation: Future considerations for computing the SCC · Issue #185 · anthofflab/MimiPAGE2009.jl · GitHub which mentions some of what you were finding, from back in 2019. When I went in to check, I tried checking out the version 3:

add MimiPAGE2009@3

and then got what you get ie.

So it seems that previously the NPV was given, but now it is current value.

It looks like this approach was updated in version 4 to be more consistent with what is normally done in these models. If you type

] st

you want to see that your environment has v4.1.0 of PAGE ie.

 Status `~/.julia/environments/page/Project.toml`
  [e4e893b0] Mimi v1.4.0
  [e25d4f70] MimiPAGE2009 v4.1.0

Then you’ll get what I’m getting, which looks to be in current value.

All of that said, the MimiIWG (GitHub - rffscghg/MimiIWG.jl) package matches what was done by the US government in 2008, and might be better documented, and the MimiPAGE2020 is the more current version of PAGE, so one of those might be more useful for your purposes.

Thank you a lot, @Irennels, you have been really helpful.

I have checked and now I’m the lastest version of the PAGE 2020 and 2009. For PAGE2009 I also get the same values as you with the same discount rate. It may have been a mismatch between MimiPAGE2009 part of the MimiIWG. Finally, I removed both packages and installed the last version of MimiPAGE2009 and get them right.

If I would like to check the values with different discounting, is there any keyword that I can use to get the marginal damages for this and other packages, different than the MimiIWG? I want to get the damage values and discount them myself, so I can compare them with the model discount rates (and maybe apply a decreasing discount rate). In this case, I would like to know if there is a way to get the future damages undiscounted per pulse year of the model.

Since this is a MimiPAGE2009 question let’s move this to discussion on the PAGE repository here:Obtaining Marginal Damages · Issue #90 · openmodels/MimiPAGE2020.jl · GitHub

1 Like

Hi @lrennels, this is a follow-up question on the same topic. So I’ve been exploring the marginal damages of PAGE2020 and got the results I wanted, the marginal values matched the undiscounted flow given by the platform, as well as the discounted flows. However, when I tried to replicate the exercise a few days later, it now gives a undiscounted flow per region that doesn’t match with the total value expected by 2020.

Here is the code line:
julia> md=m[:TotalCosts, :total_costs_aggregated]
10×8 Matrix{Union{Missing, Float64}}:
491513.0 3.45122e5 2.16682e5 … 9.28713e5 1.03099e6 4.00999e5 3.05293e5
7.33397e5 1.04245e6 4.59552e5 3.08457e6 3.78785e6 1.81589e6 1.14505e6
1.32407e6 2.27146e6 9.33207e5 6.02064e6 9.02629e6 5.00392e6 2.74336e6
4.07537e6 7.18288e6 2.95067e6 1.84364e7 3.22367e7 1.89499e7 9.27437e6
1.71851e7 2.87536e7 1.20419e7 6.69463e7 1.57166e8 1.28878e8 3.98425e7
4.06494e7 6.7161e7 2.67059e7 … 1.26417e8 4.18243e8 5.28539e8 1.04614e8
1.02962e8 1.5916e8 6.08536e7 2.27814e8 1.12584e9 2.38928e9 2.88771e8
2.54665e8 3.26253e8 1.3149e8 4.05062e8 2.30969e9 6.29073e9 5.92125e8
3.41211e8 4.32507e8 1.72733e8 4.96027e8 3.21119e9 1.03625e10 8.2704e8
2.04533e8 2.57673e8 1.02425e8 2.83292e8 1.97755e9 7.02247e9 5.09623e8

Sum: 4286, whilst the scc computed is 5005.
Note the years are:[2020,2030,2040,2050,2075,2100,2150,2200,2250,2300]

I also tried to get the marginal values of DICE2016R2, but it seems that the undiscounted flows don’t add up. When I get the marginal damages from the model with no discount rate, it doesn’t match with the values given by the platform (using eta=0., prtp=0.).
The total sum of the marginal values goes up to 50,000 ich, whilst the scc computed value is 21,000 ich.