<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hello Ambrose,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thanks for looking into this and for your helpful feedback. I will try your suggested setting experimentations and OR-Tools team is also looking this further.  </div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<ul>
<li><span>Rich Levinson</span></li><li style="display:block">NASA Ames Research Center</li></ul>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Scip <scip-bounces@zib.de> on behalf of Ambros Gleixner <gleixner@zib.de><br>
<b>Sent:</b> Thursday, August 11, 2022 8:24 PM<br>
<b>To:</b> scip@zib.de <scip@zib.de><br>
<b>Subject:</b> [EXTERNAL] Re: [SCIP] Performance problem using SCIP with OR-Tools vs. SCIP shell</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Dear Rich,<br>
<br>
I am not familiar with how SCIP is included in OR-Tools, but by quickly <br>
looking at the logs the difference in performance could indeed be <br>
related to the underlying LP solver.<br>
<br>
You can see the output line "(node 1) unresolved numerical troubles in <br>
LP 7 -- using pseudo solution instead (loop 1)", which indicates that <br>
SCIP in OR-Tools is not able to process the root node properly.  One can <br>
also see that the dualbound is massively worse on the OR-Tools runs and <br>
does not improve during tree search.<br>
<br>
As a result, the OR-Tools runs mainly look like enumeration to me (or <br>
branch-and-propagate) rather than branch-and-bound.<br>
<br>
(The 200s vs. 600s degradation is most likely only performance <br>
variability, I would not read anything into this.)<br>
<br>
Hope that helps a bit at least.  You might want to experiment with the <br>
parameters regarding LP numerics such as<br>
<br>
numerics/dualfeastol<br>
lp/checkdualfeas<br>
lp/checkprimfeas<br>
lp/checkstability<br>
<br>
but it might be that only exchanging the LP solver will help.<br>
<br>
Best,<br>
Ambros<br>
<br>
<br>
<br>
Am 11.08.22 um 21:14 schrieb Levinson, Richard J. (ARC-TI)[KBR Wyle <br>
Services, LLC]:<br>
> Hello,<br>
> <br>
> We are using Google OR-Tools with SCIP solver and see huge differences <br>
> in solve times, using exactly the same lp model file, when we call SCIP <br>
> directly vs. within OR-Tools.<br>
> <br>
> We create the model inside OR-Tools, and save the lp file so we can load <br>
> it into SCIP's shell.<br>
> <br>
> Using OR-Tools/SCIP, solve times are (~200 secs to ~700 secs). It took <br>
> 200 secs until we updated to the latest OR-Tools (to ensure OR-Tools was <br>
> using SCIP 8), and now it takes 700 secs (the update more than doubled <br>
> the solve time).<br>
> <br>
> However, if we load that same model into the SCIP shell, or call ./scip <br>
> -f and pass in the file, then it only takes ~ 7 seconds to solve (100 <br>
> times faster than solving it via OR-tools).<br>
> <br>
> Our application requires solve times < 30 seconds. We'd appreciate any <br>
> suggestions about why this is happening and what we can do to reduce our <br>
> solve time within OR-Tools so it's closer to the 7 seconds we get with <br>
> SCIP shell or command line?<br>
> <br>
> My guess is perhaps the SCIP parameter settings are different between <br>
> the two cases, but not sure how to load a SCIP settings file into <br>
> OR-Tools. Is that possible?  Originally I thought it might be that <br>
> OR-Tools and the SCIP shell are using different versions of SCIP, but <br>
> since I updated OR-Tools, I think both cases use SCIP 8+. OR-Tool <br>
> support says they are using a post v8 because it contains a bug fix.<br>
> <br>
> OR-Tool support tells me that SCIP shell uses SOPLEX but the embedded <br>
> SCIP uses GLOP, but he thought that would only account for 10% <br>
> difference at most. Is this a possible cause of the problem?<br>
> <br>
> I'm attaching 5 files, the lp file and the solver log for 2 fast cases <br>
> (SCIP without OR-Tools) and 2 slow cases (OR-Tools calling SCIP):<br>
> <br>
> All cases produce the same optimal objective, but the fast and slow <br>
> cases show very different solver behaviors. The fast cases do a restart <br>
> quickly after pre-solving, but the slow cases don't.<br>
> <br>
> Both fast cases have only 91 nodes, while the 200 sec case has 25,000 <br>
> and the 600 sec case has 117,000 nodes. I am hoping someone can look at <br>
> the log files and figure out what settings would be appropriate to get <br>
> OR-Tools behavior to match the SCIP standalone behavior.<br>
> <br>
>  1. *mplan.lp: *The model file created within OR-Tools but then saved<br>
>     out and loaded into the shell/command line. When we load this into<br>
>     SCIP shell, it takes 7 seconds to solve.<br>
>  2. *scipShell.txt *(fast): The solver progress log when we load<br>
>     mplan.lp into the SCIP shell, which takes only 7 seconds to solve.<br>
>  3. *scipCmdLine-f.txt *(fast):  The solver progress log when we call<br>
>     scip from command line with -f option to supply mplan.lp. This also<br>
>     takes about 7 seconds to solve.<br>
>  4. *orToolsPythonCmdLine_200s.txt *(slow):  The solver progress log<br>
>     when we call your Python code (which calls OR-Tools) from a command<br>
>     line. This was before I updated to the latest OR-tools.<br>
>  5. *orToolsPythonCmdLine_660s.txt (*slow): Same as<br>
>     orToolsPythonCmdLine_200s.txt above, except this is after updating<br>
>     to the latest OR-Tools. This caused the solve times to more than<br>
>     double from 200s to 670s.<br>
> <br>
> Any suggestions are appreciated.<br>
> <br>
> Thank you,<br>
>        Rich Levinson<br>
>        NASA Ames Research Center.<br>
> <br>
> _______________________________________________<br>
> Scip mailing list<br>
> Scip@zib.de<br>
> <a href="https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.zib.de%2Fmailman%2Flistinfo%2Fscip&amp;data=05%7C01%7Crichard.j.levinson%40nasa.gov%7Cb76ae1b4ba494b02f23408da7c12c1c3%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637958717246645392%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=cp1BLFsiDHw8Muvj6hRaUOomEu4S9MTziKlKl4JrKsY%3D&amp;reserved=0">
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.zib.de%2Fmailman%2Flistinfo%2Fscip&amp;data=05%7C01%7Crichard.j.levinson%40nasa.gov%7Cb76ae1b4ba494b02f23408da7c12c1c3%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637958717246645392%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=cp1BLFsiDHw8Muvj6hRaUOomEu4S9MTziKlKl4JrKsY%3D&amp;reserved=0</a><br>
_______________________________________________<br>
Scip mailing list<br>
Scip@zib.de<br>
<a href="https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.zib.de%2Fmailman%2Flistinfo%2Fscip&amp;data=05%7C01%7Crichard.j.levinson%40nasa.gov%7Cb76ae1b4ba494b02f23408da7c12c1c3%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637958717246645392%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=cp1BLFsiDHw8Muvj6hRaUOomEu4S9MTziKlKl4JrKsY%3D&amp;reserved=0">https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.zib.de%2Fmailman%2Flistinfo%2Fscip&amp;data=05%7C01%7Crichard.j.levinson%40nasa.gov%7Cb76ae1b4ba494b02f23408da7c12c1c3%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637958717246645392%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=cp1BLFsiDHw8Muvj6hRaUOomEu4S9MTziKlKl4JrKsY%3D&amp;reserved=0</a><br>
</div>
</span></font></div>
</body>
</html>