Is a Julia implementation of the newest DICE revision (2016R or 2016R2) in the works? I would like to use the most up-to-date version of the model and I want to know whether it is already in the process of being ported to the Mimi framework before attempting to do it myself.
Up to this point I don’t believe anyone has started implementing DICE2016, although there certainly has been some interest so there may be users interested in helping you out. I would also hope the source code for the implementations is the DICE 2010 and 2013 could help as a framework!
I was indeed considering looking to the former models for inspiration. The passage to DICE2016R looks relatively straightforward at first glance, that to DICE2016R2 a little less so. I will post here if this is a route I want to take and if I make progress.
1 Like
That sounds good, we’ll stay tuned to help you out however we can.
I just published a Julia implementation of the DICE-2016R model on GitHub. It is based on the Excel version 090916 available on the website of William Nordhaus. I did some tests and everything seems to be in order. Because I could not find detailed results for DICE-2016R2 runs against which to validate my output, I set the default parameters to their DICE-2016R values. As usual, those can be changed by the user though. I also added the five uncertain parameter definitions presented by William Nordhaus in “Projections and Uncertainties about Climate Change in an Era of Minimal Climate Policies” in the mcs.jl file, if one may wish to perform semi-stochastic runs of the model. Finally, some elements formerly treated as parameters in older models are now treated as variables and some non-explicit parameters are now made explicit. This is in part due to some of the uncertain parameters not being present in the older model implementations.
1 Like
Wonderful! @davidanthoff this might be something we could register in the Mimi registry if @AlexandrePavlov is interested? I can also add it to the list on our website.
Yes, of course. Let me know if you would like me to tweak some things or explain some of my code.
I’m glad you found Mimi to be useful. I’ll add your model to our list and let @davidanthoff handle the registration steps for now. If you had any suggestions or requests for improvements please do feel free to let us know here or as a specific issue on Github! We use the issues to track various to-dos and suggestions.
@AlexandrePavlov also per this update PSA Simulation API (which has been a bit longer to update than expected but will be merged soon) the API for Monte Carlo simulations will be altered slightly. When that’s done I can add a PR to your repository to update the related code for you.
@AlexandrePavlov This is awesome!! We had been discussing for a while that we really need DICE2016, and there it is 
Thanks a ton!
We are going to try to run the GAMS version of DICE2016R2 (and possibly also 2016R) and output results from those runs so that we can add those for validation results to your repo. I’m pretty sure that our team here is going to make a lot of use of your repo, so I think you can also expect occasional PRs from us in general.
Could you maybe tag a release in the github repo? Maybe a v0.1.0? That would allow me to add it to the central Mimi model registry at https://github.com/mimiframework/MimiRegistry.
@lrennels @davidanthoff I’m happy to help. It’d be great if users could switch between the two revisions in the same Mimi model with ease and confidence. I’ll be looking at the PRs and merging them as they come. I already merged @davidanthoff’s PR and tagged the initial release as v.0.1.0.
Also, since my code is slightly different from that of the usual MimiDICE models to accommodate the uncertainties Nordhaus integrated in some of his parameters in DICE-2016R2, it occurred to me that users may no longer be able to as easily modify some of its features. For instance, while one can replace the total factor productivity vector in MimiDICE2013 with the update_param!() command, I don’t think the same is possible in MimiDICE2016 because the total factor productivity vector is now a variable instead of an external parameter. Is there a way users can turn variables into parameters by supplying their own values (i.e. the supplied variable values override whatever variable values the model calculates) I’m not aware of or will compromises have to be made on which parts of the model are easier to modify?
@AlexandrePavlov in terms of switching between the two revisions, what are the main differences between the two? I infer that they are minor enough that you’d prefer they be in one Mimi model instead of two separate ones?
That’s a good question about variables versus parameters. As of now we do not have a functionality that would allow that, so instead a user would need to use the slightly more involved functions that allow you to replace a component (such as replace_comp!) with an altered one and then use set_param! etc. If there are a few such cases you think will be common, we could probably add a model-specific function of some kind to assist users with doing this step.
Lastly, I just tagged Mimi v0.9.3 which has slightly modified the syntax for Monte Carlo Simulations. I will happily update your code for you later today (it’s very minor) and open a PR for you to look at.
@lrennels I’ll run through the differences between MimiDICE2013 and MimiDICE2016 component by component to make sure I’m being thorough.
-
climatedynamics: functionally no difference
-
co2cycle:
- Carbon cycle parameters b11, b21, b22, b32, and b33 are now variables (Nordhaus defines the equilibrium carbon dioxide concentration in upper strata mueq parameter as a random variable in his stochastic run)
- Inclusion of mateq, mueq, and mleq equilibrium carbon dioxide concentration parameters (to calculate carbon cycle variables)
-
damages: removal of damadj parameter because there is no longer a difference between the GAMS and the Excel damage function, otherwise functionally no difference
-
emissions:
- Emissions-output ratio sigma becomes a variable (Nordhaus defines the initial growth of sigma gsigma1 as a random variable in his stochastic runs).
- Addition of change in sigma GSIG variable and initial carbon intensity SIG0 variable and addition of initial industrial emissions e0 parameter, initial growth of sigma gsigma1 parameter, and decline rate of decarbonization dsig parameter (to calculate SIG0, GSIG, and SIGMA).
- Emissions from deforestation parameter etree becomes variable (can be made back into a parameter with no effect on ability to do stochastic runs)
- Addition of cumulative emissions from deforestation CUMETREE variable
- Addition of initial carbon emissions from land parameter eland0, decline rate of land emissions parameter deland, and initial emissions from deforestation cumetree0 parameter (to calculate ETREE and CUMETREE variables)
- grosseconomy:
- Level of total factor productivity parameter al becomes variable (Nordhaus defines the initial growth rate for total factor productivity as a random variable in his stochastic runs)
- Addition of growth rate of productivity variable GA and addition of initial level of total factor productivity parameter a0, initial growth rate for total factor productivity parameter ga0, and decline rate of total factor productivity parameter dela (to calculate AL)
- neteconomy:
- Abatement cost function coefficient cost1 becomes variable (the parameter is dependent on SIGMA which is now a variable and it therefore needs to be made into a variable)
- Backstop price pbacktime parameter becomes a variable (can be made back into a parameter with no effect on ability to do stochastic runs)
- Addition of emissions-output ratio SIGMA parameter (to calculate COST1)
- Addition of initial cost of backstop pback parameter and initial cost decline of backstop cost gback parameter (to calculate PBACKTIME)
- Removal of partfract parameter
- radiative forcing:
- Exogenous forcing for other greenhouse gases forcoth parameter becomes variable (can be made back into a parameter with no effect on ability to do stochastic runs)
- Addition of initial forcings of other greenhouse gases fex0 parameter and 2100 forcings of other greenhouse gases fex1 (to calculate FORCOTH)
- welfare: functionally no difference
In short, the following parameters become variables: b11, b21, b22, b32, b33, sigma, etree, al, cost1, pbacktime, and forcoth. However, etree, pbacktime, and forcoth could be made back into parameters with no effect on ability to do stochastic runs. I could also bring MimiDICE2016 in line with the older models and simply tell users to modify the model if they want to do a stochastic run in the mcs file.
Yes, please update my code. I’ll look into the PR later today and merge it if everything looks good. Thanks!
Oh! I’m sorry I thought you were referring to switching between DICE2016R and DICE2016R2, but this makes more sense and is very helpful thank you so much for documenting that! This might be a type of decision that more common users like @davidanthoff and @ckingdon95 would be interested in discussing too (at this point I have been doing more of the software development than model use so don’t always have the right intuition). I’ll update the mcs for now!
@lrennels Yes, I didn’t feel comfortable including DICE-2016R2 without validation data. I could implement the R2 version regardless since I should be able to put as much trust into it as R1 given that the basic model isn’t a big departure from it. I just merged your PR, thanks.
I think it would be great if we could also get 2016R2 up and running! Maye we can plan things here a bit and then see who can pitch in and help get it off the ground?
Here are some random points:
- Do we want to put this into a new repo, MimiDICE2016R2.jl? I think that might be cleaner than if we were to start with switches inside the model.
- Do we know someone with a GAMS license who could run the original for us once, and export some key variables into a CSV file, and then we can write tests for our version that compares against those values from the GAMS version of DICE2016R2? @ckingdon95 is there maybe someone at RFF who could do these runs? I think if we knew someone who is familiar with GAMS it would save a lot of time, also just with simple things like exporting to a CSV file etc.
I think I might be able to help here. Since I last contributed, I have switched jobs to George Mason University. This semester I am working with two upper level undergrads in the Computational & Data Sciences program looking at Mimi. In preparation for my next meeting with them, I was looking at the implications of DICE in Mimi, which lead me here. A few comments and questions:
- I have access to a GAMS license, so I could run GAMS versions of DICE2016R and DICE2016R2 and provide the variables you need. Just let me know what you need.
- I found @AlexandrePavlov’s GitHub Respository for MimiDICE2016, but it does not appear in the Mimi registry, so I have been unable to install it in my system. Perhaps there is another way, or perhaps it is not considered quite ready yet.
- In going back through the Mimi tutorials and MimiDICE2010 and MimiDICE2013, it does not appear that Mimi is actually doing any optimization. Am I missing something?
Thanks, Dale
Hi @daler6, I apologize for the slow response it’s been a hectic week! @davidanthoff will respond to most of your questions soon, but I wanted to check in about the tutorials and general documentation.
I’ve written most of it, and am thrilled that you are using it for a course! I am always open to suggestions for improving the tutorials, or requests for tutorials on different topics of features. They are a work in progress and really should be guided by the needs of users exactly like you and your students. The door is open so please do let me know!
@lrennels, thanks. We’ll be sure to get back to you on the tutorials. An additional question for you and @davidanthoff. We watched your presentation at JuliaCon2019 on Thursday and I was delighted to see the figure generated by the plot_comp_graph function. When I tried to use it, though, I could not find it, at least not in the Mimi package. Is it part of another package or has it been deprecated? If the latter, why? It seemed like a great function for communication.
Ah good question! It recently got deprecated because it was based on a problematic package, and because we were finding that for models with more than just a few components it got really unwieldy. That said it’s on my list to add a new version … now that I know you find it helpful I will certainly move it up my list!