Gurobi not respecting parameter bounds

22 views
Skip to first unread message

chris.man...@gmail.com

unread,
May 25, 2017, 10:23:39 PM5/25/17
to AMPL Modeling Language
Hi again,

I am running a problem with an array of binary decision variables, but the first step of the problem involves solving the LP relaxation (it's actually the same problem as described in my previous post, and that particular problem was solved very cleanly, thanks for the help!). So, in the "Master LP", I define:
param supp {CELL} binary;
and then I use
option relax_integrality 1;
to solve the LP relaxation, and at the end of everything I set the relaxation back off and solve the IP.

However, for some test data I am using, I hit an error because when I use the relaxed values of supp as input to the second stage of the process, one of the values of supp is negative (about -1x10^-8).

I have tried a couple of things to enforce the bounds, including including it in the parameter definition as either of the following:
param supp {CELL} binary >= 0, <= 1;
param supp
{CELL} integer >= 0, <= 1;
and also as an explicit constraint
subject to ValidSupp {i in CELL}: 0 <= supp[i] <= 1;

and I still get the same results.

Gurobi is reporting that it has found an optimal solution, so the problem isn't that it's stopping prematurely. For the purpose of the problem I suspect I can set the problem values to zero and continue, but I'd rather avoid a hack like that if there's something else I can do to make it work.

Cheers,
Chris


Robert Fourer

unread,
May 26, 2017, 1:49:05 PM5/26/17
to am...@googlegroups.com
Gurobi does not require the values of the variables to be exactly feasible, but only within a certain tolerance of feasibility. Thus slightly negative values on the order of -1e-8 do occasionally appear in a solution that is declared to be optimal. These are meaningless values that should be regarded as zeros.

There is an option to change the tolerance value, but that may only get you smaller negative values, and a zero value for the tolerance is not accepted. Hence it is usually better to deal with small magnitudes in your code. You can force them to zero in the solution returned to AMPL, by setting, say,

option solution_round 7;

or you can explicitly round them where they are used with the function round(supp[i],7). Both of these have the effect of rounding at the 7th place past the decimal point, so that magnitudes of 1e-8 or less are rounded to zero.

Bob Fourer
am...@googlegroups.com

=======
Reply all
Reply to author
Forward
0 new messages