# [Ipopt] initial point in pyIPOPT

Seth Watts watts2 at illinois.edu
Mon Jun 9 11:42:09 EDT 2014

```Hello -

I have used IPOPT previously via its C/C++ interface, but now I am trying
to use it through the pyIPOPT interface. I am using IPOPT version 3.10.0
installed on a computer cluster.

I have noticed that the initial point x0 for the optimization that I pass
into IPOPT gets changed significantly, such that the first optimization
iteration (or the point about which finite difference derivative checks are
made) is quite different than the initial point I supplied.

discussions appear to focus on when x0 is a near-optimal point which is
near the boundary of the feasible region. In that case, IPOPT moves x0 way
from the boundary so that its interior-point algorithms work properly.

However, in my case x0 is not expected to be optimal; it is simply a
default state that I hope to improve. I observe significant changes in x0
even when no component of x0 is near its bounds, and even when I have
turned off all constraint functions and bounds on the components of x.

Example: here is the value of x0 I pass into IPOPT via the pyIPOPT
interface:

[ 0.5   0.5   0.    0.25  0.25  0.25  0.25  0.25  0.25  0.25  0.25]

with the upper/lower bounds on each component of +/- 2e19.

The value of x first encountered in IPOPT is:

[ -8.6673931   -0.41015111   6.69634436  -3.0302794    1.55978807
-9.71466175  -5.99820966  10.0586816    5.25994266  2.42452724
-2.72581804]

Since there are no bounds, I don't understand why IPOPT would modify x0,
which should certainly be an interior point. (Note - I see the same type of
behavior, although with different perturbed x0, when the upper bounds are
[1.0 1.0 2e19 0.35 0.35 0.35 0.35 0.35 0.35 0.35 0.35] and the lower bounds
are [0.0 0.0 -2e19 0.02 0.02 0.02 0.02 0.02 0.02 0.02 0.02]).

Based on reading earlier threads, I have tried playing with the bound_push,
bound_frac, etc. and other IPOPT options, including the following values
which were set for the perturbed value of x0 given above:

Name   Value          used
acceptable_obj_change_tol = 0.0001         yes
bound_frac = 1e-08          yes
bound_mult_init_method = constant       yes
bound_mult_init_val = 1e-08          yes
bound_push = 1e-08          yes
bound_relax_factor = 1e-08          yes
derivative_test = first-order    yes
derivative_test_perturbation = 1e-05          yes
derivative_test_print_all = yes            yes
findiff_perturbation = 1e-05          yes
hessian_approximation = limited-memory yes
max_iter = 100            yes
mu_init = 1e-08          no
nlp_scaling_method = none           yes
print_info_string = yes            yes
print_user_options = yes            yes
slack_bound_frac = 1e-08          yes
slack_bound_push = 1e-08          yes
tol = 1e-08          yes

(Note that since the finite difference check was on and the reported value
of x0 was taken during the first call to eval_f(), some of the options
should not come into play, e.g. the fact that I am using Hessian
approximation shouldn't be germane.)

Does anyone have any suggestions for what else I can try so that the x0
IPOPT uses is at least near the x0 I pass in?

Thank you,
- Seth Watts
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/ipopt/attachments/20140609/7fe42752/attachment.html>
```