Strange solver hangs!

Support
1

Dear all!

I’m using a run-file (AMPL Version 20230912) to iteratively improve a solution for a quadratic set covering problem, using fixing and unfixing of columns. It works - but not always. Using Gurobi 10.0.3, sometimes the code enters the solver (via solve;) and hangs … so I add a small printf-line (e.g., printf “var = %d”, var;) one line before the solve-command …

… guess what: no problem anymore, the code runs to a - reasonable - end!

Recursive action? Delete the printf-line and it hangs again …

Checked the net for days, it’s full of “solver hangs/stuck/freezes” and there are countless tips, most of them based on playing with options, but nothing worked. I’m pretty confused, thanks a lot for any help,

Peter

2

This behavior might by caused by an error in a previous command. To get more help, can you post two listings like this?

  • A listing of all commands that were executed before and including the solve.
  • A listing of all output that appeared when you ran those commands.

And also, post the same listings for the case where you have added the printf statement.

3

Sorry for being late, there were some days off …

That “listing of all commands”, regarding your first point, I fear that won’t be useful, because it’s a complex code over many hundreds of lines. And, the output, if at all there is one (in the case the sovler doesn’t hang), is pretty straightforward, name of the instance, objective, some variables, nothing special. Maybe some ideas help:

  • It’s not a memory or an energy problem, I checked that.
  • I beieve it must be connected to random number use, maybe, generation depends on run-file attributes like size or so.
  • To my best knowledge there are no errors in the code, also AMPL does not complain anything.
  • Results, again if generated, are totally reasonable.

Thanks a lot for offering help!

4

To investigate your problem further, more information about your AMPL run will be needed. At least, it will be important to see the 10 lines before and including the solve that is causing the problem — both with and without the printf statement. Also, it will be essential to have the complete output in both cases — including any output from AMPL as well as from the solver (if any) — even if it looks straightforward.

5

I’ve compiled a small illustrative example. The complete output for both cases, hang and no-hang. I hope that made sense and takes us one step further. Thank you for your support, Mr. 4er!
Strange solver hangs – illustration.zip (67.5 KB)

6

The example is clear, but it provides only very limited information from Gurobi. Thus the next troubleshooting step is to turn on Gurobi logging and related output:

  • Change AMPL’s setting of solver_msg to option solver_msg 1;
  • Add the AMPL command option show_stats 1;
  • Add tech:outlev=1 to your gurobi_options string

This will produce a very large amount of output, but you can just copy the output beginning with

9: q_090 -| MH iter  23: z_best = 409 |--

into a file, which then you can attach to your reply.

7

I wrote down all the options as requested. By the way, after I changed a few comments in the code, suddenly instance 9 ran without errors. “Fortunately”, the error eventually reappeared in the same place (2nd LP in iteration 23) as before. This can also be seen in the attached screen output.

Thanks for looking!

Strange solver hangs – more output.zip (16.0 KB)

8

Thanks for sending this additional output. It suggests that Gurobi stops functioning rather quickly in the AMPL-Gurobi interface. But unfortunately, that means that more troubleshooting will be necessary to determine what is happening. (We have not received any other reports of this behavior that could immediately suggest the cause.)

We’d like to request that you take the following two steps, in whatever order is convenient:

  • Before your solve statement, put the statement
    write ghangs;
    and try to get the problem to occur again. When it does, find the file named hangs.nl and send it as an attachment. This is the file that the AMPL-Gurobi interface reads; write just makes it permanent. (Actually a file by this name will be written before every solve, but the one you send will be the last one written, which corresponds to the case where Gurobi did not return.)

  • Try again with the latest versions of AMPL and Gurobi. You can use the links at https://portal.ampl.com/user/ampl/download/ampl to download the AMPL and Gurobi modules — follow option 2 for both. Then make a duplicate of your AMPL folder, double-click the modules to uncompress them, and copy the contained files into the duplicate folder. Observe whether the problem recurs, and if it does, upload the output again. (There may be some differences.)

9

I’m not exactly fast, but still, here you go… Did the write ghangs thing (the one and only change in the code) and surprise, instance 9 ran to its happy ending, but this time instance 10 (which never caused any problems …) stuck in iteration 98. Therefore attached two files, console-output (iterations 97 to 98) and hangs.nl (full).

Next week I will test new software modules and of course report back here.

As always, thank you & have a nice weekend!

Strange solver hangs – write ghangs.zip (23.3 KB)

10

Using the file you sent, I could reproduce the hanging behavior using the Gurobi 10.0.3 build dated 20230920. However, the subsequent Gurobi build dated 20231017 solved the problem successfully. The Gurobi change log for that build states: “Fixed a bug in NL reader on Windows.”

Also, the problem is successfully solved using the build of Gurobi 11.0.0 (dated 20240115) that we’re currently distributing.

11

I can confirm that Gurobi 11.0.0 is the solution. Thank you very much for all your help and, above all, time that was invested in my problem!

With best regards,

Peter