Different feasibility gives different results in cplex
541 views
Skip to first unread message
Junlin W
Nov 27, 2021, 9:39:18 PM11/27/21
to AMPL Modeling Language
Hi Professor Fourer
May I ask why different feasibility gives different optimal solutions in cplex? Sorry for being lengthy.
This is my option settings:
CPLEX 20.1.0.0: feasibility=1e-9
presolve=0
integrality=1e-9
mipgap=0
CPLEX 20.1.0.0: optimal integer solution; objective -0.08689655172
154 MIP simplex iterations
0 branch-and-bound nodes
The objective is supposed to be >= 1 and definitely not negative. After I employ 'mipdisplay=2', it shows it's infeasible. Then why the above says it's the optimal integer solution?
CPLEX 20.1.0.0: feasibility=1e-9
presolve=0
integrality=1e-9
mipgap=0
mipdisplay=2
MIP emphasis: balance optimality and feasibility.
MIP search method: dynamic search.
Parallel mode: deterministic, using up to 8 threads.
Root relaxation solution time = 0.02 sec. (7.94 ticks)
Nodes Cuts/
Node Left Objective IInf Best Integer Best Bound ItCnt Gap
* 0+ 0 -0.0869 0.00%
0 0 infeasible -0.0869 154 ---
Root node processing (before b&c):
Real time = 0.05 sec. (17.10 ticks)
Parallel b&c, 8 threads:
Real time = 0.00 sec. (0.00 ticks)
Sync time (average) = 0.00 sec.
Wait time (average) = 0.00 sec.
------------
Total (root+branch&cut) = 0.05 sec. (17.10 ticks)
CPLEX 20.1.0.0: optimal integer solution; objective -0.08689655172
154 MIP simplex iterations
0 branch-and-bound nodes
However, if I change the feasbility to 1e-8 or 1e-7..., I get:
CPLEX 20.1.0.0: feasibility=1e-8
presolve=0
integrality=1e-9
mipgap=0
mipdisplay=2
MIP emphasis: balance optimality and feasibility.
MIP search method: dynamic search.
Parallel mode: deterministic, using up to 8 threads.
Root relaxation solution time = 0.03 sec. (8.38 ticks)
Nodes Cuts/
Node Left Objective IInf Best Integer Best Bound ItCnt Gap
* 0+ 0 -0.0869 0.00%
* 0 0 integral 0 1.0000 1.0000 154 0.00%
Elapsed time = 0.03 sec. (19.41 ticks, tree = 0.00 MB)
Root node processing (before b&c):
Real time = 0.03 sec. (19.53 ticks)
Parallel b&c, 8 threads:
Real time = 0.00 sec. (0.00 ticks)
Sync time (average) = 0.00 sec.
Wait time (average) = 0.00 sec.
------------
Total (root+branch&cut) = 0.03 sec. (19.53 ticks)
CPLEX 20.1.0.0: optimal integer solution; objective 1
154 MIP simplex iterations
0 branch-and-bound nodes
Strangely, I also tried to move to gurobi with using all the same options and setting feastol 1e-9:
option gurobi_options 'presolve 0 \
feastol 1e-9 \
integrality 1 \
mipgap 0 \
bestbound=1';
option presolve 0;
option solver gurobi;
option display_precision 0;
And I get:
Gurobi 9.1.2: presolve 0
feastol 1e-9
integrality 1
mipgap 0
bestbound=1
Gurobi 9.1.2: optimal solution; objective 1
120 simplex iterations
1 branch-and-cut nodes
plus 428 simplex iterations for intbasis
suffix bestbound OUT;
How could this happen?
Besides, since I have multiple different models. I find the option settings might not suit every problem. Probably feasibility=1e-7 could likely suit all the problems. But actually in some problems, I don't need all these options.
May I ask would it be possible to use different option settings for different problems? Then would the results between models still be considered as consistent?
And could I please ask if my option settings all together being too strict and generating more problems?
Many thanks for your help,
Junlin
AMPL Google Group
Nov 29, 2021, 2:05:09 PM11/29/21
to AMPL Modeling Language
It can happen that an optimization problem has a solution that is feasible to within a tolerance of 1e-8, yet it has no feasible solution to within the stricter tolerance of 1e-9. In this situation, when you apply CPLEX with feasibility=1e-8, it will report an optimal solution, although with some constraints slightly violated; but when you change to feasibility=1e-9, CPLEX will not report a feasible solution.
You will have to use your knowledge of the problem to determine what feasibility tolerance is acceptable. I suggest that you start by making tests with the tolerances at their default values, and then only increase the feasibility (and integrality) tolerances if the solver is returning infeasibilities that are unacceptably large. (AMPL's display statement is useful for this.) To make comparisons between tests of similar models, or of the same model with different data, it is best to use the same feasibility tolerances in all runs.
CPLEX's report of "optimal integer solution; objective -0.08689655172" may be a bug of some kind, especially since the log makes it clear that no feasible solution was found. If you can post model and data files for this case, we can try to reproduce the incorrect message it and to see how it can be fixed.
The AMPL interface to Gurobi actually does a second solve, with all integer variables rounded and fixed to the nearest integer value. To get Gurobi results that are comparable to CPLEX results, you should add basis=0 to gurobi_options to suppress this second solve.
You will have to use your knowledge of the problem to determine what feasibility tolerance is acceptable. I suggest that you start by making tests with the tolerances at their default values, and then only increase the feasibility (and integrality) tolerances if the solver is returning infeasibilities that are unacceptably large. (AMPL's display statement is useful for this.) To make comparisons between tests of similar models, or of the same model with different data, it is best to use the same feasibility tolerances in all runs.
CPLEX's report of "optimal integer solution; objective -0.08689655172" may be a bug of some kind, especially since the log makes it clear that no feasible solution was found. If you can post model and data files for this case, we can try to reproduce the incorrect message it and to see how it can be fixed.
The AMPL interface to Gurobi actually does a second solve, with all integer variables rounded and fixed to the nearest integer value. To get Gurobi results that are comparable to CPLEX results, you should add basis=0 to gurobi_options to suppress this second solve.
--
Robert Fourer
am...@googlegroups.com
Junlin
Nov 30, 2021, 5:48:58 PM11/30/21
to AMPL Modeling Language
Thank you very much for your reply, Professor Fourer.
May I update some findings:
Below is my cplex option settings:
option cplex_options 'feasibility=1e-9 \
presolve=0 \
integrality=1e-9 \
mipgap=0';
option presolve 0;
option solver cplex;
option display_precision 0;
1. If I remove option cplex_options 'presolve=0', I get objective=1. May I ask is that ok to disable both AMPL's and CPLEX's presolve at the same time? What do the two different presolves do exactly?
2. If I use an older version of cplex (12.6.3.0), the objective becomes 1. But version 12.9.0.0 still produces -0.08689655172.
3. After I add basis=0 to gurobi_options, the objective is 1 which is inconsistent with cplex.
Many thanks.
Junlin
Dec 2, 2021, 6:04:37 PM12/2/21
to AMPL Modeling Language
Could I please send my model and data file to your individual email address instead of posting in the group? As this is a work in progress.
Thank you.
在2021年11月29日星期一 UTC 19:05:09<AMPL Google Group> 写道：
AMPL Google Group
Dec 2, 2021, 6:19:57 PM12/2/21
to AMPL Modeling Language
All presolve phases transform the optimization problem with the goal of making it smaller and easier to solve. AMPL's presolve is described in Experience with a Primal Presolve Algorithm. CPLEX's presolve uses the same ideas, but also others that are applicable when there are some integer variables. I do not know of specific documentation for CPLEX's presolve, but I expect it is a lot like what is described in the attached paper by Achterberg, Bixby, Gu, Rothberg, and Weninger.If you disable both AMPL's and CPLEX's presolve, then CPLEX will have to solve the original problem without presolve reductions, but there is nothing obviously wrong with that.
It does appear that something changed in CPLEX, no later than version 9.0, causing it to find a wrong solution for your problem under very specific option settings. If you can send the model and data file as attachments to sup...@ampl.com (which is private), we can try to reproduce and suggest how to fix it or work around it. But if we determine that the problem is due to a bug inside the CPLEX code, then we would have to report it to the CPLEX team at IBM, and it would be up to them whether to try to fix it.
It does appear that something changed in CPLEX, no later than version 9.0, causing it to find a wrong solution for your problem under very specific option settings. If you can send the model and data file as attachments to sup...@ampl.com (which is private), we can try to reproduce and suggest how to fix it or work around it. But if we determine that the problem is due to a bug inside the CPLEX code, then we would have to report it to the CPLEX team at IBM, and it would be up to them whether to try to fix it.
--
Robert Fourer
am...@googlegroups.com
On Thu, Dec 2, 2021 at 11:04 PM UTC, AMPL Modeling Language <am...@googlegroups.com> wrote:
Could I please send my model and data file to your individual email address instead of posting in the group? As this is a work in progress.
Thank you.
On Tue, Nov 30, 2021 at 10:49 PM UTC, AMPL Modeling Language <am...@googlegroups.com> wrote:
Thank you very much for your reply, Professor Fourer.
May I update some findings:
Below is my cplex option settings:
option cplex_options 'feasibility=1e-9 \
presolve=0 \
integrality=1e-9 \
mipgap=0';
option presolve 0;
option solver cplex;
option display_precision 0;
1. If I remove option cplex_options 'presolve=0', I get objective=1. May I ask is that ok to disable both AMPL's and CPLEX's presolve at the same time? What do the two different presolves do exactly?
2. If I use an older version of cplex (12.6.3.0), the objective becomes 1. But version 12.9.0.0 still produces -0.08689655172.
3. After I add basis=0 to gurobi_options, the objective is 1 which is inconsistent with cplex.
Many thanks.
在2021年11月29日星期一 UTC 19:05:09<AMPL Google Group> 写道：
It can happen that an optimization problem has a solution that is feasible to within a tolerance of 1e-8, yet it has no feasible solution to within the stricter tolerance of 1e-9. In this situation, when you apply CPLEX with feasibility=1e-8, it will report an optimal solution, although with some constraints slightly violated; but when you change to feasibility=1e-9, CPLEX will not report a feasible solution.
You will have to use your knowledge of the problem to determine what feasibility tolerance is acceptable. I suggest that you start by making tests with the tolerances at their default values, and then only increase the feasibility (and integrality) tolerances if the solver is returning infeasibilities that are unacceptably large. (AMPL's display statement is useful for this.) To make comparisons between tests of similar models, or of the same model with different data, it is best to use the same feasibility tolerances in all runs.
CPLEX's report of "optimal integer solution; objective -0.08689655172" may be a bug of some kind, especially since the log makes it clear that no feasible solution was found. If you can post model and data files for this case, we can try to reproduce the incorrect message it and to see how it can be fixed.
The AMPL interface to Gurobi actually does a second solve, with all integer variables rounded and fixed to the nearest integer value. To get Gurobi results that are comparable to CPLEX results, you should add basis=0 to gurobi_options to suppress this second solve.
--
Robert Fourer
On Mon, Nov 29, 2021 at 7:04 PM UTC, AMPL Google Group <am...@googlegroups.com> wrote:
It can happen that an optimization problem has a solution that is feasible to within a tolerance of 1e-8, yet it has no feasible solution to within the stricter tolerance of 1e-9. In this situation, when you apply CPLEX with feasibility=1e-8, it will report an optimal solution, although with some constraints slightly violated; but when you change to feasibility=1e-9, CPLEX will not report a feasible solution.
You will have to use your knowledge of the problem to determine what feasibility tolerance is acceptable. I suggest that you start by making tests with the tolerances at their default values, and then only increase the feasibility (and integrality) tolerances if the solver is returning infeasibilities that are unacceptably large. (AMPL's display statement is useful for this.) To make comparisons between tests of similar models, or of the same model with different data, it is best to use the same feasibility tolerances in all runs.
CPLEX's report of "optimal integer solution; objective -0.08689655172" may be a bug of some kind, especially since the log makes it clear that no feasible solution was found. If you can post model and data files for this case, we can try to reproduce the incorrect message it and to see how it can be fixed.
The AMPL interface to Gurobi actually does a second solve, with all integer variables rounded and fixed to the nearest integer value. To get Gurobi results that are comparable to CPLEX results, you should add basis=0 to gurobi_options to suppress this second solve.
--
Robert Fourer
am...@googlegroups.com
Junlin
Dec 3, 2021, 11:52:41 AM12/3/21
to AMPL Modeling Language
Thank you for your kind reply. I have sent my files to your support service.
AMPL Google Group
Dec 8, 2021, 9:28:47 AM12/8/21
to AMPL Modeling Language
I tried solving your problem in several different ways. All of my tests had AMPL's presolve turned off (option presolve 0). Also in all tests the MIP optimality gap was 0, and all of the delta variables were exactly 0 or 1, so there was never any reason to set integrality= or mipgap= in cplex_options. The CPLEX version was 20.1.
In model0.run, no other CPLEX options are set. The optimum is 1 and there are no infeasibilities. This is the setting I would recommend, unless you have some specific reason to change the CPLEX options.
In model1.run, also CPLEX's presolve is turned off. There is at least one constraint infeasibility of about 1.4e-09, which CPLEX ignores since its default feasibility tolerance is 1e-6. The optimum is 0.9999999999999987, which is 1 when rounded to any reasonable number of decimal places. In AMPL, an infeasibility in a constraint is indicated by a negative slack, so following command shows all constraints that have some infeasibility:
In model2.run, also the feasibility tolerance is decreased to 1e-9. Thus the solution from model1.run is considered infeasible by CPLEX. In fact the best feasible solution that CPLEX is able to find within a feasibility tolerance of 1e-9 has an optimum of -0.08689655172413793. (When mipdisplay=2 is also set, you see "infeasible" in the log, but that refers only to a subproblem that is solved as part of CPLEX's optimization procedure.)
In model3.run, also the input_volume constraint is replaced by this scaled version:
After this scaling, the constraint input_volume['EX'] -- which had the infeasibility that was > 1e-9 in model1.run -- has much smaller coefficient values. The optimum is 1.000000000000001, which is again 1 to any reasonable number of places, and there are no infeasibilities > 1e-12. The success of this test suggests that turning off CPLEX's presolve might also be turning off CPLEX's automatic scaling (though the CPLEX documentation does not mention that).
In model0.run, no other CPLEX options are set. The optimum is 1 and there are no infeasibilities. This is the setting I would recommend, unless you have some specific reason to change the CPLEX options.
In model1.run, also CPLEX's presolve is turned off. There is at least one constraint infeasibility of about 1.4e-09, which CPLEX ignores since its default feasibility tolerance is 1e-6. The optimum is 0.9999999999999987, which is 1 when rounded to any reasonable number of decimal places. In AMPL, an infeasibility in a constraint is indicated by a negative slack, so following command shows all constraints that have some infeasibility:
ampl: display {i in 1.._ncons: _con[i].slack < 0} (_conname[i],_con[i].slack);
: _conname[i] _con[i].slack :=
2 "input_volume['TE']" -2.842170943040401e-14
3 "input_volume['EX']" -1.3969838619232178e-09
27 'ratio_linearized[141992]' -4.440892098500626e-16
4459 equals -4.440892098500626e-16
;In model2.run, also the feasibility tolerance is decreased to 1e-9. Thus the solution from model1.run is considered infeasible by CPLEX. In fact the best feasible solution that CPLEX is able to find within a feasibility tolerance of 1e-9 has an optimum of -0.08689655172413793. (When mipdisplay=2 is also set, you see "infeasible" in the log, but that refers only to a subproblem that is solved as part of CPLEX's optimization procedure.)
In model3.run, also the input_volume constraint is replaced by this scaled version:
subject to input_volume {i in SETE}:
(1/Data[o,i]) * sum {j in SETA} lambda[j]*Data[j,i] <= 1;After this scaling, the constraint input_volume['EX'] -- which had the infeasibility that was > 1e-9 in model1.run -- has much smaller coefficient values. The optimum is 1.000000000000001, which is again 1 to any reasonable number of places, and there are no infeasibilities > 1e-12. The success of this test suggests that turning off CPLEX's presolve might also be turning off CPLEX's automatic scaling (though the CPLEX documentation does not mention that).
--
Robert Fourer
am...@googlegroups.com
On Fri, Dec 3, 2021 at 4:52 PM UTC, AMPL Modeling Language <am...@googlegroups.com> wrote:
Thank you for your kind reply. I have sent my files to your support service.
On Thu, Dec 2, 2021 at 11:19 PM UTC, AMPL Google Group <am...@googlegroups.com> wrote:
All presolve phases transform the optimization problem with the goal of making it smaller and easier to solve. AMPL's presolve is described in Experience with a Primal Presolve Algorithm. CPLEX's presolve uses the same ideas, but also others that are applicable when there are some integer variables. I do not know of specific documentation for CPLEX's presolve, but I expect it is a lot like what is described in the attached paper by Achterberg, Bixby, Gu, Rothberg, and Weninger.If you disable both AMPL's and CPLEX's presolve, then CPLEX will have to solve the original problem without presolve reductions, but there is nothing obviously wrong with that.
It does appear that something changed in CPLEX, no later than version 9.0, causing it to find a wrong solution for your problem under very specific option settings. If you can send the model and data file as attachments to sup...@ampl.com (which is private), we can try to reproduce and suggest how to fix it or work around it. But if we determine that the problem is due to a bug inside the CPLEX code, then we would have to report it to the CPLEX team at IBM, and it would be up to them whether to try to fix it.
--
Robert Fourer
am...@googlegroups.com
On Thu, Dec 2, 2021 at 11:04 PM UTC, AMPL Modeling Language <am...@googlegroups.com> wrote:
Could I please send my model and data file to your individual email address instead of posting in the group? As this is a work in progress.
Thank you.
On Tue, Nov 30, 2021 at 10:49 PM UTC, AMPL Modeling Language <am...@googlegroups.com> wrote:
Thank you very much for your reply, Professor Fourer.
May I update some findings:
Below is my cplex option settings:
option cplex_options 'feasibility=1e-9 \
presolve=0 \
integrality=1e-9 \
mipgap=0';
option presolve 0;
option solver cplex;
option display_precision 0;
1. If I remove option cplex_options 'presolve=0', I get objective=1. May I ask is that ok to disable both AMPL's and CPLEX's presolve at the same time? What do the two different presolves do exactly?
2. If I use an older version of cplex (12.6.3.0), the objective becomes 1. But version 12.9.0.0 still produces -0.08689655172.
3. After I add basis=0 to gurobi_options, the objective is 1 which is inconsistent with cplex.
Many thanks.
Reply all
Reply to author
Forward
Message has been deleted
0 new messages