[Ipopt] run time constraint violation

[Ming Ji]

Yeah, this works if the target function is not complex. For my specific
problem, I probably can reformulated in an even simpler way to convert this
non-linear constraint to an bound constraints on the parameters. However,
for a more general solution in the library side, I would suggest checking
constraints violations earlier than calculating target/grad/hess functions.
If constraints are violated, the program should stop testing this trial
point. If there are multiple constraints, users should make sure that if
bound constraints are satisfied, it is safe to test the first general
constraint, and if the first general constraint are satisfied, it is safe
to check the second, and so on.

I dug a bit into the code, I think this part is done
in InexactLSAcceptor::CheckAcceptabilityOfTrialPoint() function.

On Wed, Apr 4, 2012 at 11:21 AM, Ming Ji <finalguy at gmail.com> wrote:

>
>
> On Wed, Apr 4, 2012 at 1:53 AM, Hans Pirnay <hans.pirnay at rwth-aachen.de>wrote:
>
>> Ipopt does not guarantee the equality constraints to hold at all
>> times. However, the bounds you specified on the variables will always
>> hold. Therefore, if you have a term like
>>
>> h(x) = sqrt(f(x))
>>
>> try introducing a variable y with
>>
>> y = f(x)
>> h(x) = sqrt(y)
>> y>=0
>>
>> or better yet, get rid of the sqrt altogether
>>
>> y = f(x)
>> z*z = y
>> h(x) = z
>> y >=0
>> z>=0
>>
>> However, note that any formulation involving bilinear terms ( x * y )
>> must not be evaluated at (x=0, y=0), because of the derivatives. So
>> you will need to specify starting values for y and z > epsilon
>>
>> hope this helps
>>
>> On Wed, Apr 4, 2012 at 5:34 AM, Ming Ji <finalguy at gmail.com> wrote:
>> > --> Starting line search in iteration 2 <--
>> > Mu has changed in line search - resetting watchdog counters.
>> > Acceptable Check:
>> >   overall_error =  3.3081951656527707e+01   acceptable_tol_
>> =
>> >  9.9999999999999995e-07
>> >   dual_inf      =  1.0184827638240758e+03   acceptable_dual_inf_tol_
>>  =
>> >  1.0000000000000000e+10
>> >   constr_viol   =  0.0000000000000000e+00   acceptable_constr_viol_tol_
>> =
>> >  1.0000000000000000e-08
>> >   compl_inf     =  4.5618525445151024e+00   acceptable_compl_inf_tol_
>> =
>> >  1.0000000000000000e-02
>> >   curr_obj_val_ =  2.7727963512437492e-01   last_obj_val
>>  =
>> >  1.3239460189118296e-01
>> >   fabs(curr_obj_val_-last_obj_val_)/Max(1., fabs(curr_obj_val_)) =
>> >  1.4488503323319196e-01 acceptable_obj_change_tol_ =
>>  1.0000000000000000e+20
>> > test iter = 2
>> > The current filter has 0 entries.
>> > Relative step size for delta_x = 1.790897e-01
>> > minimal step size ALPHA_MIN = 6.253269E-14
>> > Starting checks for alpha (primal) = 1.00e+00
>> >
>> >
>> > On Tue, Apr 3, 2012 at 9:02 PM, Ming Ji <finalguy at gmail.com> wrote:
>> >>
>> >> I am trying to solve a NLP problem with IPOPT. I noticed that
>> constraints
>> >> can be violated during the optimization. I need to take sqrt to
>> estimate one
>> >> term in my target function. So it is natural to add a constraint to
>> make
>> >> sure the sqrt calculation is always valid. However, during the
>> iterations,
>> >> IPOPT use some trial parameters that violate this constraint. The
>> >> optimization almost always terminates before it finds any solution.
>> Any work
>> >> around for this?
>> >
>> >
>> >
>> > _______________________________________________
>> > Ipopt mailing list
>> > Ipopt at list.coin-or.org
>> > http://list.coin-or.org/mailman/listinfo/ipopt
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/ipopt/attachments/20120404/aa61124f/attachment.html>