The get_optimizer_attribute returns an error

[sylvaticus]

When used according to the documentation:

ipopt = JuMP.optimizer_with_attributes(Ipopt.Optimizer, "print_level"=>0) 
lin_solve = ma27
base = solve(BasePrice, v2016R(),  optimizer = ipopt, linear_solver = lin_solve)

I get the error:

ERROR: RawParameter with name linear_solver is not set.
Stacktrace:
[...]
  [8] get_optimizer_attribute
    @ ~/.julia/packages/JuMP/PKxEW/src/optimizer_interface.jl:152 [inlined]
  [9] 
    @ DICE ~/.julia/dev/DICE/src/2016R.jl:315

This seems related to the fact that somehow (change of JuMP API?) solve and the inner function selectLinearSolver fails to add a linear_solver option, and hence the get call returns an error.

If I indeed use directly:

ipopt = JuMP.optimizer_with_attributes(Ipopt.Optimizer, "print_level"=>0, "linear_solver" => "ma27")`
base = solve(...)

then it works.

[Libbum]

Hi! Thanks for the issue. You're probably right - there has been a lot of movement in jump over the past years and this project has been dormant for a long time. Glad you are getting some use out of it. I'd be happy to integrate your fix if you'd like to open a PR for it?

[sylvaticus]

Thank you to you for the package :-)

I have tried to follow the chain of issues, but it's a bit complicated.
If I understood it correctly, there seems to be an issue in JuMP that obliged you to make a manual fix when the linear solver is MUMS, and this led you to make a sort of workaround and make MA97 the default.
The result is a bit complicated, not least because there are now two places where to specific the linear solver, the JuMP.optimizer_with_attributes function and the "custom" DICE.solveone... perhaps before looking to adapt theselectLinearSolver` would it be possible to check if the original issue is still there with the latest versions of MULPS/Ipopt and the new non-linear API of JuMP ?
Is there a way you can test this quickly ?

I believe if the issue is solved, letting the user choose the linear solver would be a much neater solution...

[sylvaticus]

I have used the new API (see my specific PR) to test 2016R2 under the two "options" under the MUMPS trick:

Option 1:

    if typeof(scenario) <: OptimalPriceScenario
        @constraint(model, vars.Tₐₜ[1] == config.tatm₀);
        JuMP.fix(vars.K[1], config.k₀; force=true);
    else
        JuMP.fix(vars.Tₐₜ[1], config.tatm₀; force=true);
        @constraint(model, vars.K[1] == config.k₀);
    end

Option 2:

    JuMP.fix(vars.K[1], config.k₀; force=true);
    JuMP.fix(vars.Tₐₜ[1], config.tatm₀; force=true); 

and solving on both OptimalPrice and BasePrice I get using the two options the same results:

OptimalPrice option #1

OptimalPrice option #2:

I believe this means the original issue has been solved upstream and the package on this sense can be simplified.... what do you think ?