Closing #21 and #32 have made necessary a few fudge factors that I can't seem to pin down why they are necessary. Either Ipopt isn't cut out for solving these problems as well as CONOPT, or we have a problem in how JuMP handles constraints.
This issue has been occurring for more than a year and I've finally managed to work around it, but in general I'm not happy that it's come to this point.
Please have a read of this discussion on the discourse to get a feel of the steps already taken.
The solution was to just make things function when they didn't by swapping out a fix for a quite constrained @constraint, and vice versa. v2016R2 as an example looks like this:
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);
@NLconstraint(model, vars.K[1] == config.k₀);
endIf either of these values are changed, the solver gets into an infinite loop where it has reached some area of convergence, but is not happy with the result somehow. This has had to be done for all of the current implemented versions to varying degrees, generally always working with some interplay of K and Tₐₜ has seemed to be the best, although this is totally just via gruelling trial and error work.
I've given up chasing this, but if you're interested in helping out and know a little more about the inner workings of JuMP, please let me know.
Closing #21 and #32 have made necessary a few fudge factors that I can't seem to pin down why they are necessary. Either Ipopt isn't cut out for solving these problems as well as CONOPT, or we have a problem in how JuMP handles constraints.
This issue has been occurring for more than a year and I've finally managed to work around it, but in general I'm not happy that it's come to this point.
Please have a read of this discussion on the discourse to get a feel of the steps already taken.
The solution was to just make things function when they didn't by swapping out a
fixfor a quite constrained@constraint, and vice versa. v2016R2 as an example looks like this:If either of these values are changed, the solver gets into an infinite loop where it has reached some area of convergence, but is not happy with the result somehow. This has had to be done for all of the current implemented versions to varying degrees, generally always working with some interplay of
KandTₐₜhas seemed to be the best, although this is totally just via gruelling trial and error work.I've given up chasing this, but if you're interested in helping out and know a little more about the inner workings of JuMP, please let me know.