How to access best solution after a fixed amount of time

2,286 views
Skip to first unread message

Bryan Arguello

unread,
Jun 10, 2015, 11:53:44 AM6/10/15
to pyomo...@googlegroups.com
I would like to access the best solution to a milp after running cplex for a certain amount of time.

results = opt.solve(inst, timelimit = 60*1, tee = True)
inst.load(results)
.
.
.
code to analysze inst


However, after the minute is up, I get error codes:
ERROR: "[base]/site-packages/pyomo/opt/base/solvers.py", 428, solve
        Solver (cplex) returned non-zero return code (-1)
ERROR: "[base]/site-packages/pyomo/opt/base/solvers.py", 431, solve
        See the solver log above for diagnostic information.
Traceback (most recent call last):
  File "get_tracking_schedule.py", line 2, in <module>
    import satellite_monitoring_optimization as model
  File "/Users/barguel/Documents/SatelliteTracking/milp_files/satellite_monitoring_optimization.py", line 152, in <module>
    results = opt.solve(inst, timelimit = 60*10, tee = True)
  File "/Library/Python/2.7/site-packages/pyomo/opt/base/solvers.py", line 435, in solve
    "Solver (%s) did not exit normally" % self.name )
pyutilib.common._exceptions.ApplicationError: Solver (cplex) did not exit normally


I was hoping that after the minute was up, cplex would just get the best solution found so far and call that the optimal solution.
Is there any way I can do something like this in Pyomo?

Bryan Arguello

unread,
Jun 10, 2015, 12:06:20 PM6/10/15
to pyomo...@googlegroups.com
The "best integer" objective is displayed, so it is finding feasible solutions.  I think the problem is that, since the solver hasn't reached its desired optimality gap, it returns an error code.

On Wednesday, June 10, 2015 at 10:00:12 AM UTC-6, Gabriel Hackebeil wrote:
If you examine the CPLEX output, does it indicate that an incumbent solution is found before the time expires. If not, I suspect that it returns an error code for this reason. You might fix this by increasing the time limit.

If I’m wrong about the above, we might need to fix our CPLEX solver plugin. Let is know what you find.

Gabe

--
You received this message because you are subscribed to the Google Groups "Pyomo Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-forum...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Gabriel Hackebeil

unread,
Jun 10, 2015, 12:20:38 PM6/10/15
to pyomo...@googlegroups.com
If you add keepfiles=True it should print the solution file created by CPLEX. Can you scan that file for things like

“solutionTypeString=…"
“solutionStatusValue=…"
“solutionStatusString=…”

and paste back what you find?

Gabe

Bryan Arguello

unread,
Jun 10, 2015, 12:39:43 PM6/10/15
to pyomo...@googlegroups.com
You are talking about "cplex.log" right?  The only thing I get in that file is:

"Log started (V12.6.1.0) Wed Jun 10 10:35:31 2015"

Gabriel Hackebeil

unread,
Jun 10, 2015, 12:48:20 PM6/10/15
to pyomo...@googlegroups.com
Not it should be the cplex.sol file. E.g., from output like:

Solver script file='…/tmpfPs8YZ.cplex.script'
Solver log file: ‘.../tmpKEdU2r.cplex.log'
Solver solution file: ‘.../tmpUwi0zr.cplex.sol'
Solver problem files: (‘.../tmpaMmXS7.pyomo.lp’,)

Gabe

Bryan Arguello

unread,
Jun 10, 2015, 12:54:54 PM6/10/15
to pyomo...@googlegroups.com
The sol file does not get written.  The only files that are written are the log, script, and lp files.

Gabriel Hackebeil

unread,
Jun 10, 2015, 1:04:33 PM6/10/15
to pyomo...@googlegroups.com
Okay that could be the problem. If CPLEX were to create a solution file, the last line of output from CPLEX would also be something like:

CPLEX> Incumbent solution written to file ‘…/tmp5jRxx.cplex.sol’

Maybe you could just attach the output that includes what CPLEX prints. I can’t tell if this is an issue with an older Pyomo version not showing the the solution file, or something else.

Gabe

Bryan Arguello

unread,
Jun 10, 2015, 1:09:51 PM6/10/15
to pyomo...@googlegroups.com
Absolutely!  My Pyomo version is 4.0.9682



Log started (V12.6.1.0) Wed Jun 10 10:35:31 2015

New value for time limit in seconds: 60

Problem '/var/folders/71/7t36q7wx5352pw1p7q3vm4zc002l7j/T/tmpAKesy8.pyomo.lp' read.
Read time = 1.04 sec. (64.39 ticks)

Problem name         : /var/folders/71/7t36q7wx5352pw1p7q3vm4zc002l7j/T/tmpAKesy8.pyomo.lp
Objective sense      : Minimize
Variables            :  602563  [Nneg: 3,  Box: 301504,  Binary: 301056]
Objective nonzeros   :       1
Linear constraints   :  455371  [Less: 304841,  Equal: 150530]
  Nonzeros           : 1666151
  RHS nonzeros       :    3978

Variables            : Min LB: 0.000000         Max UB: 1.000000       
Objective nonzeros   : Min   : 1.000000         Max   : 1.000000       
Linear constraints   :
  Nonzeros           : Min   : 0.9000000        Max   : 1.000000       
  RHS nonzeros       : Min   : 1.000000         Max   : 1.000000       
Tried aggregator 1 time.
MIP Presolve eliminated 444267 rows and 591806 columns.
Reduced MIP has 11104 rows, 10757 columns, and 33527 nonzeros.
Reduced MIP has 5266 binaries, 0 generals, 0 SOSs, and 0 indicators.
Presolve time = 0.45 sec. (346.81 ticks)
Found incumbent of value 2780.000000 after 0.54 sec. (411.83 ticks)
Probing time = 0.01 sec. (3.00 ticks)
Tried aggregator 1 time.
Reduced MIP has 11104 rows, 10757 columns, and 33527 nonzeros.
Reduced MIP has 10756 binaries, 1 generals, 0 SOSs, and 0 indicators.
Presolve time = 0.03 sec. (21.60 ticks)
Probing time = 0.02 sec. (2.99 ticks)
Clique table members: 8663.
MIP emphasis: balance optimality and feasibility.
MIP search method: dynamic search.
Parallel mode: deterministic, using up to 8 threads.
Root relaxation solution time = 0.48 sec. (394.61 ticks)

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

*     0+    0                         2780.0000        0.0000           100.00%
      0     0     1985.6573  2106     2780.0000     1985.6573       19   28.57%
*     0+    0                         2028.3000     1985.6573             2.10%
      0     0     1985.8477  1806     2028.3000      Cuts: 55      788    2.09%
*     0+    0                         1990.9000     1985.8477             0.25%
      0     0     1985.8477  1758     1990.9000       Cuts: 6      822    0.25%
      0     0     1985.8477  1787     1990.9000  ZeroHalf: 14      883    0.25%
*     0+    0                         1989.9000     1985.8477             0.20%
*     0+    0                         1988.8000     1985.8477             0.15%
      0     0     1985.8477  1784     1988.8000  ZeroHalf: 10      933    0.15%
      0     2     1985.8477  1784     1988.8000     1985.8477      933    0.15%
Elapsed time = 8.41 sec. (7091.16 ticks, tree = 0.00 MB, solutions = 5)
      3     5     1986.1665  1304     1988.8000     1985.8477     3518    0.15%
      8    10     1986.1665   801     1988.8000     1985.8477     4519    0.15%
     11    13     1986.2478  1169     1988.8000     1985.8477     5796    0.15%
     13    13        cutoff           1988.8000     1985.8477     9853    0.15%
     16    16     1986.1169  1184     1988.8000     1985.8477    17748    0.15%
     27    27     1986.3938  1084     1988.8000     1985.8477    47981    0.15%
     33    31     1986.2170   858     1988.8000     1985.8477    63942    0.15%
     54    46        cutoff           1988.8000     1985.8477    84999    0.15%
     62    54     1987.6437   857     1988.8000     1985.8477    90230    0.15%
    187   170     1986.5516  1056     1988.8000     1985.8477   121264    0.15%
Elapsed time = 18.61 sec. (14117.42 ticks, tree = 0.00 MB, solutions = 5)
    217   200     1986.6497   792     1988.8000     1985.8477   129764    0.15%
    341   314     1987.6585  1060     1988.8000     1985.8477   164018    0.15%
    375   345     1986.8327  1164     1988.8000     1985.8477   177356    0.15%
    494   453     1987.8460  1082     1988.8000     1985.8477   211565    0.15%
    590   525     1988.2677   977     1988.8000     1985.8477   225855    0.15%
    691   594     1987.9213   732     1988.8000     1985.8477   249881    0.15%
    701   603     1986.1822  1579     1988.8000     1985.8477   254859    0.15%
    892   766     1986.7170   948     1988.8000     1985.8477   296710    0.15%
    917   791     1986.4739   740     1988.8000     1985.8477   300864    0.15%
    926   800     1985.9594   994     1988.8000     1985.8477   302785    0.15%
Elapsed time = 40.74 sec. (24851.98 ticks, tree = 45.25 MB, solutions = 5)
   1166  1015     1987.0826   524     1988.8000     1985.8477   340230    0.15%
   1279  1114     1986.6055   789     1988.8000     1985.8477   356269    0.15%
   1366  1191     1988.2254  1387     1988.8000     1985.8477   374531    0.15%
   1550  1361     1986.3937   927     1988.8000     1985.8581   404099    0.15%
   1695  1485     1985.9993  1053     1988.8000     1985.8581   424764    0.15%
   1881  1659     1987.2567   721     1988.8000     1985.8581   452527    0.15%
   1940  1710     1987.4249  1129     1988.8000     1985.9294   463403    0.14%

Gabriel Hackebeil

unread,
Jun 10, 2015, 1:13:59 PM6/10/15
to pyomo...@googlegroups.com
So you are saying what immediately follows that output what you first attached? I.e.,

ERROR: "[base]/site-packages/pyomo/opt/base/solvers.py", 428, solve
        Solver (cplex) returned non-zero return code (-1)
ERROR: "[base]/site-packages/pyomo/opt/base/solvers.py", 431, solve
        See the solver log above for diagnostic information.

If so, I’m at a loss. I’ve seen the timelimit option work well in other situations. I can’t think of anything we could do to handle this better. You might have better luck with a mipgap.

Gabe

Bryan Arguello

unread,
Jun 10, 2015, 1:35:48 PM6/10/15
to pyomo...@googlegroups.com
This is correct.  I get the cplex log output followed by the ERROR messages.  Does Pyomo just have a timer and interrupt CPLEX at the end of the timer? i.e. just like what would happen if a user interrupted the script manually

I realized that I can alternatively pass the timelimit through the option parameter.  That worked just fine, so my problem is solved.  This may be something that the Pyomo team may want to look into though.

Gabriel Hackebeil

unread,
Jun 10, 2015, 1:40:11 PM6/10/15
to pyomo...@googlegroups.com

On Jun 10, 2015, at 10:35 AM, Bryan Arguello <brome...@gmail.com> wrote:

I realized that I can alternatively pass the timelimit through the option parameter.  That worked just fine, so my problem is solved.  This may be something that the Pyomo team may want to look into though.

Ah yes, I should have payed closer attention. I had assumed you were passing a timelimit through the CPLEX options in the first place. Sorry. Glad you got that figured out.

Gabe

Bryan Arguello

unread,
Jun 10, 2015, 1:56:32 PM6/10/15
to pyomo...@googlegroups.com
No worries.  So is that "timelimit" Pyomo parameter deprecated in the current version?

Gabriel Hackebeil

unread,
Jun 10, 2015, 2:03:52 PM6/10/15
to pyomo...@googlegroups.com
I don’t think so. I believe it just represents a more generic and forceful way to enforce a time limit for those applications that require it. I’m not sure what the documentation says about it. It’s possible it doesn’t do a good job distinguishing this this timelimit from the more well-behaved solver-specific version that must be passed directly to the solver through options.

Gabe

Bryan Arguello

unread,
Jun 10, 2015, 2:05:26 PM6/10/15
to pyomo...@googlegroups.com
Got it!  I'll make it a policy to use solver options if possible.  Thanks for your help, Gabe!

Gabriel Hackebeil

unread,
Jun 10, 2015, 2:14:35 PM6/10/15
to pyomo...@googlegroups.com
No problem.

Gabriel Hackebeil

unread,
Jun 10, 2015, 12:00:12 PM6/10/15
to pyomo...@googlegroups.com
If you examine the CPLEX output, does it indicate that an incumbent solution is found before the time expires. If not, I suspect that it returns an error code for this reason. You might fix this by increasing the time limit.

If I’m wrong about the above, we might need to fix our CPLEX solver plugin. Let is know what you find.

Gabe

ty.b...@gmail.com

unread,
Mar 10, 2018, 8:37:25 AM3/10/18
to Pyomo Forum
Hi Bryan, 

I have the same problem. Can you explain how you solved the problem?

Thanks in advance.

Tang Yu

Bryan Arguello

unread,
Mar 10, 2018, 9:31:06 AM3/10/18
to pyomo...@googlegroups.com
Hi Tang,

Yes, it turns out that using a Pyomo timelimiy forces a silver interruption.  What you want to do instead is use the solver option time limit.  That will make it so that the silver stops the solve instead. In that case, you should get a solution back.

-Bryan 

--
You received this message because you are subscribed to a topic in the Google Groups "Pyomo Forum" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pyomo-forum/lcHeY7Xrf8w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pyomo-forum...@googlegroups.com.

Venkatachalam Lakshmanan

unread,
Apr 9, 2018, 6:38:23 AM4/9/18
to Pyomo Forum
Hi Bryan,

Do you mean to say 
     "results = opt.solve(instance, tee=True,options_string="TimeLimit=1200")" will use pyomo to interrupt the solver and 
and      
     "opt.options["TimeLimit"] = 1200" will pass the parameter to the solver and there will be safe landing of the solver

I have same result for both the case.

Please clarify.

Thanks in advance

Best regards,
Venkat.
Reply all
Reply to author
Forward
0 new messages