5
$\begingroup$

I have a NLP problem at hand, which I am trying to solve via Pyomo + ipopt. I try to run several different instances of the optimizer with different conditions, out of which I notice that I am able to optimize for ~90% of times. In the other 10% cases, I hit infeasibility.

Upon looking into the reason for infeasibility via Pyomo's log_infeasible_constraints, I found that there is one common constraint in all of those cases that is unmet and that too by just a little margin. I provide an example below:

INFO: CONSTR Cnstr_ethylene_turb2_exhaust_temp: 860.0000011442067 > 860.0

In here, the soft-constraint named Cnstr_ethylene_turb2_exhaust_temp is not satisfied, but only by a slight amount (upper limit is set to be 860). My initial thought was to nudge the upper limit by some amount, however upon doing it I notice that even then the optimizer is not able to optimize for it and leaves me with an infeasible solution by again not meeting the constraint by a little amount. I provide an example below, where I increase the upper limit to 862.5.

INFO: CONSTR Cnstr_ethylene_turb2_exhaust_temp: 862.5000010274459 > 862.5

I am curious to know (i) why is this happening and what is going on here in terms of mathematics, and (ii) if its possible to be handled, then how to handle such cases.

Looking forward to inputs from the community.

Important Note: This happens because of very low tolerance. Pyomo also recognizes that this is mainly from tolerance issue because the solver status is still rendered as optimal and not infeasible. The confusion was caused because it still in the log_infeasible_constraints , prints the constraint.

$\endgroup$
  • 2
    $\begingroup$ This looks like a tolerance issue. Is the tolerance threshold a parameter in your model? $\endgroup$ – Kuifje Oct 13 at 8:09
  • $\begingroup$ @Kuifje, Indeed it resulted from tolerance parameter. Setting the tol parameter in ipopt solved this issue. On an important note, Pyomo also recognizes that this is mainly from tolerance issue. The confusion was mainly caused because although in the log_infeasible_constraints , it prints the constraint, the solver status is still rendered as optimal and not infeasible. $\endgroup$ – your_boy_gorja Oct 13 at 13:05
4
$\begingroup$

In cases like that, I usually add a variable to the constraint (slack or surplus, depending on the direction off the inequality) measuring the infeasibility. The variable should then have a large unfavorable coefficient in the objective (positive for minimization and negative for maximization) so it takes the smallest possible value.

| improve this answer | |
$\endgroup$
2
$\begingroup$

This happens because of very low tolerance. Setting the tol parameter in ipopt solved this issue. Pyomo also recognizes that this is mainly from tolerance because the solver status is still rendered as optimal and not infeasible. The confusion was caused because it still in the log_infeasible_constraints , prints the constraint. Something to take note of.

| improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.