fixed_variable_treatment with ReoptimizeTNLP
a-jp opened this issue · 8 comments
Hi,
I use make_parameter (have not tried any other options) with fixed_variable_treatment and it works well within a c++ code that implements the required functions of TNLP.
I now wish to resolve an existing model, calling it in a loop. Nothing changes within the model, except that each iteration causes different variables to become fixed, and hence some of those previously fixed become unfixed. Therefore each iteration some of the variables' bounds need to be changed, and some of the initial guesses needed changed. Can i use the reoptimize approach within that context? Will that be safe and do the correct thing?
Thanks
Andy
No, reoptimization cannot be used here.
The TNLP is reformulated into an Ipopt-internal formulation where all fixed variables are removed (by default fixed_variable_treatment=make_parameter). So running with different variable fixings means that structurally different NLPs will be solved by Ipopt. But ReOptimizeTNLP is for solving a sequence of NLPs with the same structure (same numbers of variables and constraints, same nonzeros in Jacobian and Hessian). All that ReOptimizeTNLP is doing is to skip reinitialization of the structures in Ipopt that depend on the NLP.
Only with fixed_variable_treatment=relax_bounds you could use ReOptimizeTNLP, but relaxing the fixed vars is probably not what you wanted when fixing them.
Ok, that's a shame. Thanks for your help
Hi, can I just check. Given my question around changing specific variables that are fixed and then resolving an otherwise similar problem, would any of the warm_start_* type options help me?
Thanks
Andy
If you think that the solutions of the new problem are somewhere close to the previous solution, then setting a warmstart may help. The warmstart options (except for warm_start_same_structure) have nothing to do with the structure of the NLP changing due to fixing variables. They are just about giving a guess for the dual variables in addition to the primal values.
I was thinking of things like the advice provided here. It seems like there is quite a bit to get right if I'm going to use warm start. Any comments on the options/settings? Thanks
Yes, much of what is written in the GAMS/Ipopt docu also applies when not run via GAMS. The text there was taken from some post on the Ipopt mailing list, if I remember right.
There is also a section in the Ipopt docu: https://coin-or.github.io/Ipopt/SPECIALS.html#AMPL_WARMSTART And not all of this applies to use under AMPL.
I think the suggestions given in both documents give some direction on which options to try and how to set them.
Warmstarting an interior-point solver is difficult and often the performance gains are rather disappointing.
Thanks for your advice