ClimateMARGO / ClimateMARGO.jl

Julia implementation of MARGO, an idealized climate-economic modelling framework for Optimizing trade-offs between emissions Mitigation, Adaptation, carbon dioxide Removal, and solar Geoengineering.
https://margo.plutojl.org/
MIT License
67 stars 13 forks source link

Problems with T_adapt and optimization in 0.2.0 #63

Closed fonsp closed 3 years ago

fonsp commented 3 years ago

In the code below, I create a model with the default parameters and optimize for the 3C goal, but the result is a 0.8C policy, according to T_adapt, and a 1.6C policy according to T:

julia> import ClimateMARGO

julia> using ClimateMARGO.Models

julia> using ClimateMARGO.Optimization

julia> using ClimateMARGO.Diagnostics

julia> model_parameters = deepcopy(ClimateMARGO.IO.included_configurations["default"])

julia> model = ClimateModel(model_parameters)

julia> opt = optimize_controls!(model; temp_goal=3, temp_final=3)
Solve_Succeeded
A JuMP Model
Minimization problem with:
Variables: 365
Objective function type: Nonlinear
`JuMP.GenericAffExpr{Float64,JuMP.VariableRef}`-in-`MathOptInterface.EqualTo{Float64}`: 180 constraints
`JuMP.VariableRef`-in-`MathOptInterface.EqualTo{Float64}`: 3 constraints
`JuMP.VariableRef`-in-`MathOptInterface.GreaterThan{Float64}`: 288 constraints
`JuMP.VariableRef`-in-`MathOptInterface.LessThan{Float64}`: 288 constraints
Nonlinear: 74 constraints
Model mode: AUTOMATIC
CachingOptimizer state: ATTACHED_OPTIMIZER
Solver name: Ipopt
Names registered in the model: A, G, M, R, cumsum_KFdt, cumsum_qMR, dAdt, dGdt, dMdt, dRdt

julia> T_adapt(model; M=true, R=true, G=true, A=true)
37-element Array{Float64,1}:
 1.184337440942364
 0.787537906821934
 0.7477434185398601
 0.7871478945091267
 0.8192416770150188
 0.8508019429556418
 0.8812762238141469
 0.9101292784278945
 0.9368415992953321
 0.960907266988229
 ⋮
 0.8649905494261693
 0.8566218041282546
 0.8485950261246218
 0.841105336595743
 0.8343842974543256
 0.8287048726667889
 0.8243868008449623
 0.8218023289015606
 0.8213822139183088

julia> T(model; M=true, R=true, G=true)
37-element Array{Float64,1}:
 1.2083551842122768
 1.0166793366004399
 0.9988527141328715
 1.061558095583236
 1.1181030178387419
 1.1750949019412522
 1.231825954851227
 1.287620584136942
 1.3418338045768445
 1.3938485321754022
 ⋮
 1.6552559115593999
 1.6514933959888565
 1.6479774883395324
 1.6449052839465927
 1.64251027800797
 1.641067327751932
 1.6408980258573558
 1.642376434920621
 1.64593509011836

Changing temp_goal and temp_final to 1.5C gives a 0.7C policy according to T_adapt, and a 1.4999C policy according to T. But it should actually be >1.5 without adaptation, not ==1.5.


julia> opt2 = optimize_controls!(model; temp_goal=1.5, temp_final=1.5)
Solve_Succeeded
A JuMP Model
Minimization problem with:
Variables: 365
Objective function type: Nonlinear
`JuMP.GenericAffExpr{Float64,JuMP.VariableRef}`-in-`MathOptInterface.EqualTo{Float64}`: 180 constraints
`JuMP.VariableRef`-in-`MathOptInterface.EqualTo{Float64}`: 3 constraints
`JuMP.VariableRef`-in-`MathOptInterface.GreaterThan{Float64}`: 288 constraints
`JuMP.VariableRef`-in-`MathOptInterface.LessThan{Float64}`: 288 constraints
Nonlinear: 74 constraints
Model mode: AUTOMATIC
CachingOptimizer state: ATTACHED_OPTIMIZER
Solver name: Ipopt
Names registered in the model: A, G, M, R, cumsum_KFdt, cumsum_qMR, dAdt, dGdt, dMdt, dRdt

julia> T_adapt(model; M=true, R=true, G=true, A=true)
37-element Array{Float64,1}:
 1.184337440942364
 0.805630939785305
 0.7602822898277861
 0.8007631178063254
 0.8319018011759127
 0.8618319642337396
 0.8903225401399625
 0.9167795973750041
 0.9406150492684733
 0.9612422531339633
 ⋮
 0.7731364359445296
 0.7688997538131482
 0.764750778624586
 0.7606876930042705
 0.7567087155999412
 0.7528121008215414
 0.7489961526870818
 0.7452592449022545
 0.7415997212435734

julia> T(model2; M=true, R=true, G=true)
37-element Array{Float64,1}:
 1.2083551842122768
 1.0163886988144255
 0.9912454659837568
 1.0531578029970985
 1.1067859481122886
 1.1601073890261746
 1.2127481958280295
 1.2639853458994832
 1.3131153417380619
 1.359449294655356
 ⋮
 1.5000000019200588
 1.4999999986636083
 1.499999993515357
 1.4999999848719763
 1.499999969561878
 1.499999943363316
 1.49999991561235
 1.4999999300287798
 1.4999999658301584

Tested on the master branch

fonsp commented 3 years ago

This is a mismatch between the optimizee and the diagnostic functions, so this would be solved by #18 , right? Or maybe you see a simpler fix

fonsp commented 3 years ago

It's fixed in #64