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

Future considerations for computing the SCC #185

Open
corakingdon opened this issue May 24, 2019 · 0 comments
Open

Future considerations for computing the SCC #185

corakingdon opened this issue May 24, 2019 · 0 comments

Comments

@corakingdon
Copy link
Collaborator

  • In the new compute_scc function, marginal emissions are perturbed in the manner that the IWG did in the Excel version. You run the base model first, because you need to run it in order to calculate what the marginal emissions growth needs to be in the marginal model. So the actual value you are modifying in the marginal model is emissions growth. I'm not sure if there is different code somewhere with an example of how to add marginal emissions in PAGE, but this is what I did for now. We can probably simplify by using a Mimi.adder component somehow instead.
  • I did allow for eta and prtp keywords in compute_scc, however this means that if the user provides these values, the compute_scc function actually updates the values of emuc_utilitiyconvexity and ptp_timepreference within the model. This is explained in the docstring and the README, but should we issue a warning if the user provides a modified model and also provides values for eta and prtp, that warns that we are updating these parameters in the provided model?
  • I'm not sure using the td_totaldiscountedimpacts out of the EquityWeighting component is actually the right way to go for calculating the SCC, because I think it's discounted all the way back to the present day, rather than to the SCC year. For example, later years actually have lower values when calculated this way:
julia> using MimiPAGE2009
julia> [MimiPAGE2009.compute_scc(year=y) for y in 2010:10:2050]
5-element Array{Float64,1}:
 52.326389484803975
 50.40718696472138
 46.18869923466474
 41.7423347017315
 36.36017887025624

The IWG did this differently where they took this value, then divided back out the discount factor that was used, and then rediscounted it for the SCC year. This results in later years having higher discount values. I'm not sure which way is "right"

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

1 participant