Gurobi and TimeLimit

[mmorinosd]

Describe the bug When using the parameter TimeLimit with Gurobi solver and when that time limit is reached, CVXR outputs the following error: Error in status_map(object, solution$status) : GUROBI status unrecognized: TIME_LIMIT

To Reproduce Solve a sufficiently large model with Gurobi using the psolve function with the TimeLimit parameter set to a value such that the time limit is reached.

Expected behavior My guess: CVXR should handle the TIME_LIMIT output code as a user-defined limit.

The problem seems to be located in the setMethod("status_map", "GUROBI_QP", function(solver, status) function between the lines 334 and 349 in the qp_solvers.R file. TIME_LIMIT has value 9, here the code returns SOLVER_ERROR when status is 9 and stops when status is TIME_LIMIT.

The setMethod("status_map", "CPLEX_QP", function(solver, status) handles a time limit reached as a USER_LIMIT (when the solution is feasible, i.e., status 107). It should probably be the same for Gurobi when its tstatus is 9 or TIME_LIMIT (at least when the solution is feasible).

Output Error in status_map(object, solution$status) : GUROBI status unrecognized: TIME_LIMIT

Version R version 3.6.3 (2020-02-29) Platform: x86_64-pc-linux-gnu (64-bit)

Matrix products: default BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0 LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0

locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=C
[4] LC_COLLATE=C LC_MONETARY=C LC_MESSAGES=C
[7] LC_PAPER=C LC_NAME=C LC_ADDRESS=C
[10] LC_TELEPHONE=C LC_MEASUREMENT=C LC_IDENTIFICATION=C

attached base packages: [1] stats graphics grDevices utils datasets methods base

other attached packages: [1] readxl_1.3.1 CVXR_1.0-9 forcats_0.5.1 stringr_1.4.0
[5] dplyr_1.0.7 purrr_0.3.4 readr_1.4.0 tidyr_1.1.3
[9] tibble_3.1.2 ggplot2_3.3.4 tidyverse_1.3.1

loaded via a namespace (and not attached): [1] tidyselect_1.1.1 slam_0.1-48 haven_2.4.1 lattice_0.20-40 [5] colorspace_2.0-1 vctrs_0.3.8 generics_0.1.0 gmp_0.6-2
[9] utf8_1.2.1 rlang_0.4.11 pillar_1.6.1 glue_1.4.2
[13] withr_2.4.2 Rmpfr_0.8-4 DBI_1.1.1 Rcplex_0.3-3
[17] bit64_0.9-7 dbplyr_2.1.1 modelr_0.1.8 lifecycle_1.0.0 [21] munsell_0.5.0 gtable_0.3.0 cellranger_1.1.0 gurobi_9.1-1
[25] rvest_1.0.0 ps_1.6.0 fansi_0.5.0 broom_0.7.7
[29] Rcpp_1.0.6 scales_1.1.1 backports_1.2.1 jsonlite_1.7.2
[33] fs_1.5.0 bit_1.1-15.2 hms_1.1.0 stringi_1.6.2
[37] grid_3.6.3 cli_2.5.0 tools_3.6.3 magrittr_2.0.1
[41] crayon_1.4.1 pkgconfig_2.0.3 ellipsis_0.3.2 Matrix_1.2-18
[45] xml2_1.3.2 reprex_2.0.0 lubridate_1.7.10 assertthat_0.2.1 [49] httr_1.4.2 rstudioapi_0.13 R6_2.5.0 compiler_3.6.3

[mmorinosd]

I noticed a similar problem with CPLEX and CBC (COIN-BC). When a user_limit is reached, feasible solutions are not extracted. With CPLEX, the status is user_limit. With CBC the status is solver_error. In both cases, variable values cannot be extracted although a feasible solution has been found (according to the console output).

I tested with GLPK_MI and I was able to extract the feasible solution when a time limit is reached. The status was ("optimal", "optimal_inaccurate"), but it was really just a feasible solution. It was not optimal.

[klin333]

Same thing with SOLUTION_LIMIT?