Originally posted by: davidrey123

Hi, I am trying to solve some MILPs and I have two approaches: I use the CPLEX Python API and I also use AMPL/CPLEX. My problem is that using the full Python approach CPLEX, will tell me that my model is infeasible quite often whereas AMPL/CPLEX will always find that the problem is feasible.

Specifically, I generate my instances (with random parameters) in a Python script and then do two things: 

• I write the data in a text file that I read using an AMPL model and solve it using CPLEX 
• I populate a CPLEX model using the Python API and solve it

I want to stress that I use the exact same code to write the AMPL text file and populate the CPLEX model through the Python API. Further, I know that my models are always feasible (by design), so CPLEX should in theory never return "infeasible problem". I am using CPLEX v12.6.1 with Python 3.4 on a Windows 8 / 64 bit machine. I attached my Python script and a few .lp files that are found to be infeasible through the CPLEX Python API but not by AMPL/CPLEX.

I suspect that the problem comes from my Python script which is specific to the CPLEX API; but there seems to be something else as well because if I reset the Python kernel and start again, CPLEX will always find the first problem that I solve to be feasible. However, after a few runs, it will start to tell me that the newly generated problem is infeasible. When I check with AMPL/CPLEX, the newly generated problem is always feasible. Any clue what could be the source of the problem?

thanks.

Here's what I see from the Python interactive prompt (CPLEX 12.6.1.0, Linux x86-64, Python 3.4):

>>> import cplex
>>> cpx = cplex.Cplex()
>>> cpx.read('MILP_1.lp')
>>> cpx.solve()
Row 'dt2_(1,_3)#54' infeasible, all entries at implied bounds.
Presolve time = 0.00 sec. (0.03 ticks)

Root node processing (before b&c):
  Real time             =    0.00 sec. (0.04 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.00 sec. (0.04 ticks)
>>> cpx.linear_constraints.delete('dt2_(1,_3)#54')
>>> cpx.solve()
Tried aggregator 2 times.
MIP Presolve eliminated 72 rows and 26 columns.
MIP Presolve modified 4 coefficients.
Aggregator did 8 substitutions.
Reduced MIP has 18 rows, 8 columns, and 57 nonzeros.
Reduced MIP has 2 binaries, 0 generals, 0 SOSs, and 0 indicators.
Presolve time = 0.00 sec. (0.13 ticks)
Found incumbent of value -1.000000 after 0.00 sec. (0.18 ticks)
Probing time = 0.00 sec. (0.00 ticks)
Tried aggregator 1 time.
Reduced MIP has 18 rows, 8 columns, and 57 nonzeros.
Reduced MIP has 2 binaries, 0 generals, 0 SOSs, and 0 indicators.
Presolve time = 0.00 sec. (0.03 ticks)
Probing time = 0.00 sec. (0.00 ticks)
MIP emphasis: balance optimality and feasibility.
MIP search method: dynamic search.
Parallel mode: deterministic, using up to 8 threads.
Root relaxation solution time = 0.00 sec. (0.02 ticks)

        Nodes                                         Cuts/
   Node  Left     Objective  IInf  Best Integer    Best Bound    ItCnt     Gap

*     0+    0                           -1.0000       -2.0000           100.00%
*     0     0      integral     0       -2.0000       -2.0000        1    0.00%
Elapsed time = 0.01 sec. (0.25 ticks, tree = 0.00 MB, solutions = 2)

Root node processing (before b&c):
  Real time             =    0.01 sec. (0.25 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.01 sec. (0.25 ticks)
>>> cpx.solution.get_status_string()
'integer optimal solution'
>>>

Is that not what you see?  I would take a closer look at your code that generates this "dt2_(1,_3)#54" constraint.

Also, I'm not an AMPL expert, but you might try exporting the model from AMPL as an .mps file (I see this is possible after doing a quick google search).  Then, run this in the cplex interactive, or with the CPLEX Python API from the Python interactive prompt.  I would bet that you'd get the same results then.  So, perhaps your code that generates the model with the CPLEX Python API is not quite right.

Originally posted by: davidrey123

Thanks for your answer. Yes I see the same output as you do: constraint "dt2_(1,_3)#54" is infeasible. But what happens is that if I restart the Python kernel and then re-generate a few instances, CPLEX will tell me that this or that row is infeasible, my point is that when is model is determined to be infeasible, the ID of the infeasible row changes all the time. However, when the model is determined to feasible and is solved, I get the exact same result than with AMPL/CPLEX (same objective value, optimal variables values); and I have verified this for several instances of different sizes. 

I did what you recommended: I exported the model to an .mps file through AMPL and solved it using the CPLEX interactive: CPLEX found the model to be feasible and solved it. I attached two files (MILP_4) which represent the same instance: one in the .lp format generated using the Python script, and the other one is in the .mps format generated by AMPL. When I run both in CPLEX interactive the .lp is infeasible whereas the .mps is feasible. However after display the problem stats, I can tell that the problem are indeed different.. which suggests that my Python script is doing something weird...

I am also attaching two files which represent the same instance and are both feasible (MILP_5). Again, displaying the problem stats, I can see that the problems are different although they give the same result. I guess there is something in my Python script that could be fixed, but at the same time I am confused why after restarting the Python kernel I always find feasible and identical outcomes.

Originally posted by: davidrey123

I found this issue, it was indeed a typo in my Python script. I found it using the conflict refiner in the interactive optimizer.