JGCRI / gcam-core

GCAM -- The Global Change Analysis Model
http://jgcri.github.io/gcam-doc/
Other
272 stars 160 forks source link

Stabilization Scenario at 450 PPM resulting in errors #8

Closed djtrainwreckx closed 7 years ago

djtrainwreckx commented 7 years ago

Hi, I'm trying to run GCAM 4.3 scenario that stabilizes CO2 concentration at 450 PPM

the following text results and the final output is just the reference scenario

issues with stabilization at 450 ppm

I am using this code for 'stabilization_450_PPM' policy (this one has look forward of 5, the problem happened with 1 too) and config file attached as txt (xml files can't be uploaded)

450_PPM_stabilization.txt

configuration.txt

results never go past reference

-Osman

djtrainwreckx commented 7 years ago

Same thing occurred when I tried to stabilize at 725 PPM, BAU is 748 PPM

issues with stabilization at 750 ppm

725_PPM_stabilization.txt

configuration.txt

rplzzz commented 7 years ago

@djtrainwreckx There are a couple of things going on here:

  1. You have set your target type to "stabilization". This requests an "emissions stabilization" target, which is not what you had intended. You want a "concentration" target with the stabilization option set (which it is).
  2. There is a bug in the HectorModel::getEmissions method, which causes it to reject requests for emissions in the final year. That's the source of the "invalid year" error message in your runs, and it causes the run to bail early. The other target types don't use the emissions directly (they call getConcentration, getTotalForcing, or getTemperature), so if you switch to one of them, you won't see those errors.
  3. You set your target-tolerance parameter to be exactly 0. That's not going to work. You should stick with the default of 0.01. You could go lower if you want, say to 0.001, but then you're doing a lot of additional computing for no real benefit.

So, to summarize, there are a couple of small bugs we need to fix here, but you can get the runs you want to do working by selecting the correct target type ("concentration" in your case) and raising target-tolerance to something greater than zero.

djtrainwreckx commented 7 years ago

Thanks for the reply, rplzzz!

Prior to seeing your reply, I tried the unaltered forcing_4p5 policy with no alterations to it and the config only changing 'find path' to 1. There was that error but the actual results look like it worked

gcam 4 3 not working on default forcing 4 5 policy

forcing_4p5 does look like it works

I will try your recommendations, especially using 'concentration' instead of 'stabilization'

-Osman

rplzzz commented 7 years ago

I believe that what's happening in your run is that the stabilization algorithm is having a difficult time dealing with the lags in the energy and climate systems. You can see some of this in the CO2 prices, where the price drops immediately after the onset of the stabilization (as contrasted with mitigation) regime, as the model tries to slow down the pace of emissions reductions. This turns out to be an overcorrection, and so the carbon price has to rise dramatically in 2090 to keep us on track, and that turns out to be an overcorrection to the overcorrection, so the price has to drop again in 2095. By 2100 there is enough mitigation baked into the system that even a zero carbon price causes us to undershoot the target, and that's the cause of the error message. The resulting scenario is valid, but it doesn't exactly meet the goal of stabilizing the forcing at 4.5 W/m2. Forcing ticks slightly above 4.5 in 2090 and then well below 4.5 by 2100.

djtrainwreckx commented 7 years ago

rplzz, these kinds of problems popped up for me since I started using GCAM (4.1?).

By increasing the forward look, I think the GCAM solver usually found the more realistic solution

forward look solves crazy swings

4p5 with forward look.txt

rplzzz commented 7 years ago

Good stuff. The stabilization part of the target finding hasn't been looked at in while. We've got some ideas on how to improve it, so keep an eye out.