Closed djtrainwreckx closed 7 years ago
Same thing occurred when I tried to stabilize at 725 PPM, BAU is 748 PPM
@djtrainwreckx There are a couple of things going on here:
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.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.
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
I will try your recommendations, especially using 'concentration' instead of 'stabilization'
-Osman
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.
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
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.
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
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
-Osman