How to find SCIP version and dump all settings

[rlevinso]

Hello,

I'm using OR-Tools Python API with SCIP solver, and see major differences between solving a model within OR-Tools vs. creating the model in OR-Tools, saving out the model file, then loading it up in SCIP shell and solving in shell.

It takes 300-700 seconds to solve via OR-Tools, but only 8 seconds using the shell to solve the same exact model (which was created in OR-Tools).

It was taking ~300 seconds to solve in OR-Tools, then I saw this in the March 2022 release notes under Dependency Updates:
SCIP 7.0.1 -> v800.

Does that mean it changed to SCIP 8.0.0?

I'm using 8.0.0 in the shell so updated my OR-Tools, and it actually got much slower, taking about 650 seconds to solve, vs. ~250 secs before I updated, vs. 8 seconds using the SCIP shell.

I'd like to dump SCIP shell parameter settings to a file (I know how to do that), then load that settings file into my OR-Tools (I know how to load the file in pure SCIP but not in OR-Tools).

Specific questions:

1. How can I determine the differences between the version and parameter settings used by OR-Tools vs. the SCIP shell?
2. How can I determine what version of SCIP I'm using with OR-Tools?
3. How can I determine all of the SCIP parameter settings being used with my OR-Tools installation? This would be equivalent of SCIP> set save in the Shell.
4. How can I load a file of SCIP parameter settings into my OR-Tools Python API?

General question:
Do you have any suggestions about how to bring my OR-Tool SCIP performance in line with the SCIP shell?

Thank you,
Rich Levinson
NASA Ames Research Center

[lperron]

one comment: scip on cli uses soplex. embedded scip uses glop.

v800: we actually use a post v800 version as it contains fixes for an old memory problem.

We also set different primal tolerance (1e-7) and dual (1e-7). This slows down solving a lot.

Is your problem purely integer ? Have you tried CP-SAT ? It is generally a better solver that SCIP.

[rlevinso]

Thanks for the quick response. The soplex vs. glop difference sounds like it might be the issue. Can I configure OR-tools embedded SCIP to use soplex? We also have a C++ version of the same application, using OR-Tools C++ api, but in that case, they built SCIP from source. Would you recommend we build SCIP from source to use soplex for C++ version, and if we did that, can we get our Python version to use that same SCIP compiled from source? When I did my first OR-Tools test I used the default GLOP solver then realized it produced non-integers solutions so I switched to SCIP. I thought they were mutually exclusive solver choices within OR-Tools. Is SCIP still using GLOP behind the scenes even though I call createSolver('SCIP')? Do you think this is more likely to be the cause than SCIP parameter settings? Is there a way to read full set of SCIP parameter settings, and to import a SCIP settings file I would save from the shell? Do you know why upgrading to the latest OR-Tools today resulted in the solve time going from ~300 secs to ~700 secs, and what I can do about that? Our problem is purely integer, but we've not tried CP-SAT. We have legacy and cross-platform reasons for using a MILP formulation. * Rich Levinson NASA Ames Research Center

…

________________________________ From: Laurent Perron ***@***.***> Sent: Wednesday, August 10, 2022 4:22 PM To: google/or-tools ***@***.***> Cc: rlevinso ***@***.***>; Author ***@***.***> Subject: [EXTERNAL] Re: [google/or-tools] How to find SCIP version and dump all settings (Issue #3424) one comment: scip on cli uses soplex. embedded scip uses glop. v800: we actually use a post v800 version as it contains fixes for an old memory problem. We also set different primal tolerance (1e-7) and dual (1e-7). This slows down solving a lot. Is your problem purely integer ? Have you tried CP-SAT ? It is generally a better solver that SCIP. — Reply to this email directly, view it on GitHub<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2For-tools%2Fissues%2F3424%23issuecomment-1211394325&data=05%7C01%7Crichard.j.levinson%40nasa.gov%7C081bd0674b53496a4ae208da7b2732b9%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637957705554359732%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T9tqj0GwLV7kxNFSRW1F2A1BV0aaLiS4v%2B6c3ieKQH4%3D&reserved=0>, or unsubscribe<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-aut%2520h%2FA2PBUHACKPSPBZDPILHJFS3VYQ2S3ANCNFSM56GH26CA&data=05%7C01%7Crichard.j.levinson%40nasa.gov%7C081bd0674b53496a4ae208da7b2732b9%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637957705554359732%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9WlvAqZL3cVBAyvqOMlDysPZ%2By%2F6Cw3YfSwMkomZHLs%3D&reserved=0>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[lperron]

don't mix issues. Both soplex and glop are simplexes. This is most likely not the issue. Solving with glop and expecting integral values means you do not understand the difference between a (pseudo) polynomial simplex solver and an NP-Hard MIP solver. SCIP needs one simplex to work. Embedded SCIP is built on top of GLOP. You cannot build embedded SCIP with soplex. The difference seems to be at most 10% in the worst case. Laurent Perron | Operations Research | ***@***.*** | (33) 1 42 68 53 00 Le jeu. 11 août 2022 à 01:46, rlevinso ***@***.***> a écrit :

…

Thanks for the quick response. The soplex vs. glop difference sounds like it might be the issue. Can I configure OR-tools embedded SCIP to use soplex? We also have a C++ version of the same application, using OR-Tools C++ api, but in that case, they built SCIP from source. Would you recommend we build SCIP from source to use soplex for C++ version, and if we did that, can we get our Python version to use that same SCIP compiled from source? When I did my first OR-Tools test I used the default GLOP solver then realized it produced non-integers solutions so I switched to SCIP. I thought they were mutually exclusive solver choices within OR-Tools. Is SCIP still using GLOP behind the scenes even though I call createSolver('SCIP')? Do you think this is more likely to be the cause than SCIP parameter settings? Is there a way to read full set of SCIP parameter settings, and to import a SCIP settings file I would save from the shell? Do you know why upgrading to the latest OR-Tools today resulted in the solve time going from ~300 secs to ~700 secs, and what I can do about that? Our problem is purely integer, but we've not tried CP-SAT. We have legacy and cross-platform reasons for using a MILP formulation. * Rich Levinson NASA Ames Research Center ________________________________ From: Laurent Perron ***@***.***> Sent: Wednesday, August 10, 2022 4:22 PM To: google/or-tools ***@***.***> Cc: rlevinso ***@***.***>; Author ***@***.***> Subject: [EXTERNAL] Re: [google/or-tools] How to find SCIP version and dump all settings (Issue #3424) one comment: scip on cli uses soplex. embedded scip uses glop. v800: we actually use a post v800 version as it contains fixes for an old memory problem. We also set different primal tolerance (1e-7) and dual (1e-7). This slows down solving a lot. Is your problem purely integer ? Have you tried CP-SAT ? It is generally a better solver that SCIP. — Reply to this email directly, view it on GitHub< https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2For-tools%2Fissues%2F3424%23issuecomment-1211394325&data=05%7C01%7Crichard.j.levinson%40nasa.gov%7C081bd0674b53496a4ae208da7b2732b9%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637957705554359732%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T9tqj0GwLV7kxNFSRW1F2A1BV0aaLiS4v%2B6c3ieKQH4%3D&reserved=0>, or unsubscribe< https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-aut%2520h%2FA2PBUHACKPSPBZDPILHJFS3VYQ2S3ANCNFSM56GH26CA&data=05%7C01%7Crichard.j.levinson%40nasa.gov%7C081bd0674b53496a4ae208da7b2732b9%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637957705554359732%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9WlvAqZL3cVBAyvqOMlDysPZ%2By%2F6Cw3YfSwMkomZHLs%3D&reserved=0 >. You are receiving this because you authored the thread.Message ID: ***@***.***> — Reply to this email directly, view it on GitHub <#3424 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUPL3MB3RQVGUZR5SQGU6DVYQ5LPANCNFSM56GH26CA> . You are receiving this because you commented.Message ID: ***@***.***>

[rlevinso]

Sorry to mix issues. Here are my focused questions:

• Why is SCIP solver time when called by OR-Tools so much worse (~300 secs to ~700 secs), compared to running SCIP directly (8 seconds), and what can I do about it?

• Why did SCIP solver time when called by OR-Tools more than double from ~300 secs to ~700 secs when I updated to the latest version of OR-Tools, and what can I do about it?

For our application, we need to reduce the solve time within OR-Tools to under 30 seconds. What should we try next, to bring OR-Tools/SCIP solve-time in line with calling SCIP directly?

Thank you,
Rich Levinson

[Mizux]

My 2 cents

1. yes we are using the last release of SCIP on their public repo
   https://github.com/scipopt/scip/tags
   note: We will migrate to v801 ASAP

2. Using the CMake based build, you can ship your SCIP version or use the version we build
   note: prebuilt package are using our static version of SCIP
   you can find the configuration here:

   or-tools/cmake/dependencies/CMakeLists.txt

   Lines 205 to 232 in 82750ac

   	# ##############################################################################
   	# SCIP
   	# ##############################################################################
   	if(BUILD_SCIP)
   	message(CHECK_START "Fetching SCIP")
   	list(APPEND CMAKE_MESSAGE_INDENT " ")
   	set(SHARED OFF)
   	set(READLINE OFF)
   	set(GMP OFF)
   	set(PAPILO OFF)
   	set(ZIMPL OFF)
   	set(IPOPT OFF)
   	set(AMPL OFF)
   	set(TPI "tny" CACHE STRING "Scip param")
   	set(EXPRINT "none" CACHE STRING "Scip param")
   	set(LPS "none" CACHE STRING "Scip param")
   	set(SYM "none" CACHE STRING "Scip param")
   	FetchContent_Declare(
   	scip
   	GIT_REPOSITORY "https://github.com/scipopt/scip.git"
   	GIT_TAG "v800"
   	)
   	FetchContent_MakeAvailable(scip)
   	set(LPI_GLOP_SRC ${scip_SOURCE_DIR}/src/lpi/lpi_glop.cpp PARENT_SCOPE)
   	list(POP_BACK CMAKE_MESSAGE_INDENT)
   	message(CHECK_PASS "fetched")
   	endif()

   
   note: Feel free to tweak our configuration (and send us a PR provide you manage to build it on all platform we support)

3. if you want to use your SCIP version simply use -DUSE_SCIP=ON and -DBUILD_SCIP=OFF thus we will try to find SCIP using find_package()
   ref: https://github.com/google/or-tools/blob/main/cmake/FindSCIP.cmake

4. If using a Bazel based build, you should take a look at https://github.com/google/or-tools/blob/main/bazel/scip.BUILD

5. concerning the setup of SCIP inside or-tools you should take a look at
   https://github.com/google/or-tools/blob/main/ortools/linear_solver/scip_interface.cc

6. we are not using multi-threading see:

• Flaky Segfault in SCIPsolveConcurrent() scipopt/scip#5

[rlevinso]

Thanks for your feedback and suggestions. I give them a try.

• Rich

[lperron]

As diagnosed by the SCIP team, there is indeed a performance problem with glop/soplex.

Can you send me the model ?

[rlevinso]

The model file is attached, along with a log from solving with orTools, and the log from solving with SCIP command line, for comparison.

I think I sent this model to you previously by replying to your request for it, but don't see that reply in this thread, so here it is again, just in case it got lost somehow.

This website wouldn't let me upload a file with *.lp extension, so I renamed it to be *.lp.txt. You may need to strip off the .txt suffix to read it in.

The model:
mplan.lp.txt

The log files:
mplanOrToolsLog.txt
mplanScipCmdLineLog.txt

Thanks,
Rich Levinson

[lperron]

.lp is broken. Can you export the mps file ?

[rlevinso]

Here's the .mps file.This website wouldn't let me upload a file with *.mps extension, so I renamed it to be *.mps.txt. You may need to strip off the .txt suffix to read it in.

mplan.mps.txt

[lperron]

I just ran it on or-tools head I0829 18:42:41.259741 1 solve.cc:150] Read input proto as an MPModelProto. File : '/Users/lperron/Work/support/issue3424.mps' I0829 18:42:41.262256 1 solve.cc:181] Set number of threads to 1. Solver : SCIP_MIXED_INTEGER_PROGRAMMING Dimension : 204 x 3396 presolving: (round 1, exhaustive) 0 del vars, 0 del conss, 0 add conss, 0 chg bounds, 0 chg sides, 0 chg coeffs, 21 upgd conss, 0 impls, 21 clqs (round 2, medium) 21 del vars, 0 del conss, 0 add conss, 0 chg bounds, 21 chg sides, 21 chg coeffs, 21 upgd conss, 0 impls, 21 clqs (0.4s) probing: 1000/3375 (29.6%) - 0 fixings, 0 aggregations, 275868 implications, 0 bound changes (0.4s) probing: 1001/3375 (29.7%) - 0 fixings, 0 aggregations, 276130 implications, 0 bound changes (0.4s) probing aborted: 1000/1000 successive useless probings (0.4s) symmetry computation started: requiring (bin +, int -, cont +), (fixed: bin -, int +, cont -) (0.4s) no symmetry present presolving (3 rounds: 3 fast, 3 medium, 2 exhaustive): 21 deleted vars, 0 deleted constraints, 0 added constraints, 0 tightened bounds, 0 added holes, 21 changed sides, 21 changed coefficients 0 implications, 8113 cliques presolved problem has 3375 variables (3375 bin, 0 int, 0 impl, 0 cont) and 204 constraints 21 constraints of type <setppc> 183 constraints of type <linear> transformed objective value is always integral (scale: 10000000) Presolving Time: 0.42 time | node | left |LP iter|LP it/n|mem/heur|mdpt |vars |cons |rows |cuts |sepa|confs|strbr| dualbound | primalbound | gap | compl. t 0.4s| 1 | 0 | 0 | - | trivial| 0 |3375 | 204 | 0 | 0 | 0 | 0 | 0 |-3.961493e+15 | 6.300630e+13 | Inf | unknown p 0.5s| 1 | 0 | 145 | - | vbounds| 0 |3375 | 215 | 204 | 0 | 0 | 10 | 0 |-3.961493e+15 | 3.918796e+13 | Inf | unknown 0.5s| 1 | 0 | 411 | - | 38M | 0 |3375 | 299 | 204 | 0 | 0 | 94 | 0 | 3.351111e+13 | 3.918796e+13 | 16.94%| unknown 0.6s| 1 | 0 | 433 | - | 40M | 0 |3375 | 301 | 205 | 1 | 1 | 96 | 0 | 3.351151e+13 | 3.918796e+13 | 16.94%| unknown d 0.6s| 1 | 0 | 809 | - |farkasdi| 0 |3375 | 303 | 205 | 0 | 3 | 98 | 0 | 3.351151e+13 | 3.358555e+13 | 0.22%| unknown 0.7s| 1 | 0 | 1532 | - | 41M | 0 |3375 | 356 | 205 | 1 | 3 | 151 | 0 | 3.351151e+13 | 3.358555e+13 | 0.22%| unknown 0.8s| 1 | 0 | 1532 | - | 41M | 0 |3375 | 358 | 205 | 1 | 3 | 153 | 0 | 3.351151e+13 | 3.358555e+13 | 0.22%| unknown 0.8s| 1 | 0 | 1624 | - | 41M | 0 |3375 | 257 | 206 | 2 | 4 | 153 | 0 | 3.351164e+13 | 3.358555e+13 | 0.22%| unknown (run 1, node 1) restarting after 2051 global fixings of integer variables (restart) converted 2 cuts from the global cut pool into linear constraints presolving: (round 1, fast) 2051 del vars, 1 del conss, 0 add conss, 0 chg bounds, 0 chg sides, 1622 chg coeffs, 0 upgd conss, 0 impls, 36 clqs (round 2, exhaustive) 2051 del vars, 1 del conss, 0 add conss, 0 chg bounds, 0 chg sides, 1622 chg coeffs, 2 upgd conss, 0 impls, 36 clqs (round 3, exhaustive) 2051 del vars, 16 del conss, 0 add conss, 0 chg bounds, 0 chg sides, 1625 chg coeffs, 2 upgd conss, 0 impls, 36 clqs presolving (4 rounds: 4 fast, 3 medium, 3 exhaustive): 2051 deleted vars, 16 deleted constraints, 0 added constraints, 0 tightened bounds, 0 added holes, 0 changed sides, 1627 changed coefficients 0 implications, 36 cliques presolved problem has 1324 variables (1324 bin, 0 int, 0 impl, 0 cont) and 247 constraints 2 constraints of type <knapsack> 36 constraints of type <setppc> 183 constraints of type <linear> 26 constraints of type <logicor> transformed objective value is always integral (scale: 10000000) Presolving Time: 0.43 transformed 3/4 original solutions to the transformed problem space time | node | left |LP iter|LP it/n|mem/heur|mdpt |vars |cons |rows |cuts |sepa|confs|strbr| dualbound | primalbound | gap | compl. 0.8s| 1 | 0 | 1976 | - | 41M | 0 |1324 | 247 | 206 | 0 | 0 | 157 | 0 | 3.351164e+13 | 3.358555e+13 | 0.22%| unknown 0.8s| 1 | 0 | 1976 | - | 42M | 0 |1324 | 251 | 206 | 0 | 0 | 161 | 0 | 3.351164e+13 | 3.358555e+13 | 0.22%| unknown 0.8s| 1 | 0 | 2002 | - | 42M | 0 |1324 | 251 | 208 | 2 | 1 | 161 | 0 | 3.351181e+13 | 3.358555e+13 | 0.22%| unknown 0.8s| 1 | 0 | 2002 | - | 42M | 0 |1324 | 253 | 208 | 2 | 1 | 163 | 0 | 3.351181e+13 | 3.358555e+13 | 0.22%| unknown 0.8s| 1 | 0 | 2021 | - | 42M | 0 |1324 | 253 | 209 | 3 | 2 | 163 | 0 | 3.351194e+13 | 3.358555e+13 | 0.22%| unknown 0.8s| 1 | 0 | 2021 | - | 42M | 0 |1324 | 256 | 209 | 3 | 2 | 166 | 0 | 3.351194e+13 | 3.358555e+13 | 0.22%| unknown 0.8s| 1 | 0 | 2041 | - | 42M | 0 |1324 | 255 | 211 | 5 | 3 | 166 | 0 | 3.351214e+13 | 3.358555e+13 | 0.22%| unknown 0.8s| 1 | 0 | 2041 | - | 42M | 0 |1324 | 256 | 211 | 5 | 3 | 167 | 0 | 3.351214e+13 | 3.358555e+13 | 0.22%| unknown 0.9s| 1 | 0 | 2071 | - | 42M | 0 |1324 | 256 | 212 | 6 | 4 | 167 | 0 | 3.351250e+13 | 3.358555e+13 | 0.22%| unknown 0.9s| 1 | 0 | 2071 | - | 42M | 0 |1324 | 258 | 212 | 6 | 4 | 169 | 0 | 3.351250e+13 | 3.358555e+13 | 0.22%| unknown 0.9s| 1 | 0 | 2093 | - | 43M | 0 |1324 | 258 | 214 | 8 | 5 | 169 | 0 | 3.351258e+13 | 3.358555e+13 | 0.22%| unknown 0.9s| 1 | 0 | 2158 | - | 43M | 0 |1324 | 259 | 216 | 10 | 6 | 170 | 0 | 3.351267e+13 | 3.358555e+13 | 0.22%| unknown 0.9s| 1 | 0 | 2171 | - | 43M | 0 |1324 | 262 | 217 | 11 | 7 | 173 | 0 | 3.351273e+13 | 3.358555e+13 | 0.22%| unknown 0.9s| 1 | 0 | 2189 | - | 43M | 0 |1324 | 263 | 218 | 12 | 8 | 174 | 0 | 3.351285e+13 | 3.358555e+13 | 0.22%| unknown 0.9s| 1 | 0 | 2205 | - | 43M | 0 |1324 | 266 | 219 | 13 | 9 | 177 | 0 | 3.351290e+13 | 3.358555e+13 | 0.22%| unknown time | node | left |LP iter|LP it/n|mem/heur|mdpt |vars |cons |rows |cuts |sepa|confs|strbr| dualbound | primalbound | gap | compl. 1.0s| 1 | 0 | 2217 | - | 43M | 0 |1324 | 267 | 220 | 14 | 10 | 178 | 0 | 3.351294e+13 | 3.358555e+13 | 0.22%| unknown 1.0s| 1 | 0 | 2364 | - | 43M | 0 |1324 | 269 | 221 | 15 | 11 | 180 | 0 | 3.351299e+13 | 3.358555e+13 | 0.22%| unknown 1.3s| 1 | 2 | 3865 | - | 44M | 0 |1324 | 354 | 221 | 15 | 11 | 265 | 20 | 3.351334e+13 | 3.358555e+13 | 0.22%| unknown * 1.6s| 4 | 3 | 4127 | 761.5 |strongbr| 3 |1324 | 354 | 217 | 15 | 2 | 265 | 62 | 3.351334e+13 | 3.358317e+13 | 0.21%| unknown * 1.6s| 4 | 3 | 4131 | 762.5 |strongbr| 3 |1324 | 358 | 217 | 15 | 4 | 269 | 68 | 3.351334e+13 | 3.355845e+13 | 0.13%| unknown * 1.7s| 5 | 2 | 4290 | 641.8 |strongbr| 3 |1324 | 390 | 217 | 15 | 7 | 302 | 99 | 3.351334e+13 | 3.355762e+13 | 0.13%| 5.83% * 1.8s| 5 | 2 | 4345 | 652.8 |strongbr| 3 |1324 | 412 | 217 | 15 | 13 | 324 | 118 | 3.351334e+13 | 3.355493e+13 | 0.12%| 5.83% * 2.2s| 7 | 2 | 4621 | 505.7 |strongbr| 3 |1324 | 442 | 217 | 15 | 7 | 370 | 195 | 3.351334e+13 | 3.355000e+13 | 0.11%| 11.29% * 2.3s| 7 | 2 | 4680 | 514.1 |strongbr| 3 |1324 | 471 | 217 | 15 | 15 | 399 | 215 | 3.351334e+13 | 3.354982e+13 | 0.11%| 11.29% * 2.6s| 9 | 2 | 4941 | 428.9 |strongbr| 4 |1324 | 521 | 217 | 15 | 5 | 462 | 279 | 3.351334e+13 | 3.354694e+13 | 0.10%| 16.81% * 3.6s| 16 | 1 | 5769 | 293.0 |strongbr| 7 |1324 | 617 | 217 | 15 | 2 | 624 | 473 | 3.351334e+13 | 3.353411e+13 | 0.06%| 25.27% * 3.7s| 16 | 1 | 5862 | 298.8 |strongbr| 7 |1324 | 627 | 217 | 15 | 12 | 655 | 497 | 3.351334e+13 | 3.353405e+13 | 0.06%| 25.27% * 4.6s| 22 | 1 | 6638 | 252.6 |strongbr| 7 |1324 | 705 | 217 | 15 | 2 | 786 | 642 | 3.351406e+13 | 3.352847e+13 | 0.04%| 90.79% SCIP Status : solving was interrupted [gap limit reached] Solving Time (sec) : 7.72 Solving Nodes : 45 (total of 46 nodes in 2 runs) Primal Bound : +3.35284700000000e+13 (17 solutions) Dual Bound : +3.35259927989130e+13 Gap : 0.01 % I0829 18:42:48.988423 1 solve.cc:305] Verifying the solution Status : MPSOLVER_OPTIMAL Objective : 3.352847000000000e+13 BestBound : 3.352599279891304e+13 Iterations : 9704 Nodes : 46 Time : 7.722 Laurent Perron | Operations Research | ***@***.*** | (33) 1 42 68 53 00 Le lun. 29 août 2022 à 18:39, rlevinso ***@***.***> a écrit :

…

Here's the .mps file.This website wouldn't let me upload a file with *.mps extension, so I renamed it to be *.mps.txt. You may need to strip off the .txt suffix to read it in. mplan.mps.txt <https://github.com/google/or-tools/files/9446312/mplan.mps.txt> — Reply to this email directly, view it on GitHub <#3424 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUPL3MT26JNF6ETGKUU6HDV3TRS7ANCNFSM56GH26CA> . You are receiving this because you commented.Message ID: ***@***.***>

[rlevinso]

Is that the same version of OR-Tools I have or the a pre-release version? Perhaps the pre-release version has already fixed the problem?

We are not actually loading the .mps or .lp file, we are constructing the model in Python via OR-Tools and then calling solve without exporting the file (except for debugging).

[lperron]

This is pre-release. I bumped scip to 8.0.1. I do not think glop has changed. You can build it easily. Le lun. 29 août 2022, 19:02, rlevinso ***@***.***> a écrit :

…

Is that the same version of OR-Tools I have or the a pre-release version? Perhaps the pre-release version has already fixed the problem? We are not actually loading the .mps or .lp file, we are constructing the model in Python via OR-Tools and then calling solve without exporting the file (except for debugging). — Reply to this email directly, view it on GitHub <#3424 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUPL3ORAE4TNDM5OX262ETV3TUJ3ANCNFSM56GH26CA> . You are receiving this because you commented.Message ID: ***@***.***>

[rlevinso]

I'm not sure if this will make a difference, but here's another version of the .mps file. The first one I sent was created by loading the .lp file into SCIP and then exporting it out as .mps. But this one below was created directly inside OR-Tools using solver.ExportModelAsMpsFormat(False, False).
mplan.mps.txt

I think these model files may not trigger the bug since our problem is when we construct the model and solve it all within OR-Tools, without reading or writing any model files.

You suggested I can build it easily which I might try. If I build from source, will I get the pre-release version you used to tested the .mps file?

[Mizux]

github default branch is stable which is basically a tag where we tried to generate all artifacts
see: https://github.com/google/or-tools/releases
Our "development" branch is main which contains lastest development but is often broken (we use to git push directly in main (then fix ASAP if needed) than: doing a branch, creating a PR, waiting for CI then merge into main...)