[Coin-ipopt] Problem with constraint scaling

[Fabian Wein]

Hi Andreas,

thank you very much for your answer. It is very helpfull to get support! :)

> My guess is that what matters is the size of the elements in the
> gradient - those values should be typically in the order of  to -10. 
> Does your scaling of 1e9 do that?  (The VALUE of the function does not
> matter that much)
Thanks for the hint. My objective is about 2 magnitudes larger than its
gradient. I scale now to make the objective gradient +/- 0.

> ... iterations or so.  I sugsest you run this problem again, but set the
> tolerance (including the "acceptable" tolerance") so that Ipopt
> continues further.  One way to do that is to set acceptable_iter to a
> integer (100000).
To be honest, the stopping criteria was max_iter. I set it now to
0.05 and the results are quite good!!

> However, you might want to consider to do the problem scaling directly
> in your problem formulation, instead of using obj_scaling_factor.
I actually just "found" the get_scaling_parameters() and removed my
own constraint scaling (value, gradient, boundary) and found another
behaviour than with get_scaling_parameters(). How can this be?
What is the difference form putting it into the problem formulation?

Isn't it, that IPOPT does in this case some scaling by it's own?

The originial IPOPT scaling is not "strong" enough for my values,
do you mean that then IPOPT "fine-scaled" my scaling within the problem?

> on? What happens if you set nlp_scaling_method=none?)
Very bad - 2 iterations and IPOPT is done because the constraint holds
exactly and the objective is many magnitudes smaller.

I played with gradient-based scaling options but found no way that IPOPT
can do reasonable scaling automatically. That is not bad as I now learned
what to adjust - thanks for the help.

Thanks,

Fabian