Dear AMPL team,
I have a problem with AMPL exiting by itself with the following notice
exit value 18446744072635809797
I am writing to know the meaning of that, and to aks how to avoid this.
Thanks in advance for your help.
Best regards,
Dear AMPL team,
I have a problem with AMPL exiting by itself with the following notice
exit value 18446744072635809797
I am writing to know the meaning of that, and to aks how to avoid this. Please find the log file attached
Thanks in advance for your help.
Best regards,
Ampl_Output_Vivi.dat (42.6 KB)
The message exit value 18446744072635809797 is seen with many solvers. It indicates that the solver has crashed, but does not provide any specific information as to the cause. In my experience, the most common cause is running out of memory, but other causes are possible.
To give more definite help, we’ll need to get some more context for the error. As a start, copy all of the AMPL output in the run where you get the “exit value” message, and paste it into a reply in this Discourse thread. Then it should be possible to give you some additional instructions for troubleshooting the error.
Your log listing is helpful, and it supports the conclusion that Gurobi has run out of memory. There are half a billion nonzeros in the problem, which must be saved in memory until the solution is reported; and even after an hour of presolve there are 67 million nonzeros. The barrier method aborts suddenly while it is computing the elimination ordering that will be used to solve linear systems in the barrier method:
Root barrier log...
Elapsed ordering time = 8s
Elapsed ordering time = 32s
Elapsed ordering time = 35s
Elapsed ordering time = 40s
Elapsed ordering time = 45s
Elapsed ordering time = 50s
Elapsed ordering time = 55s
Elapsed ordering time = 60s
Elapsed ordering time = 65s
Elapsed ordering time = 70s
exit value 18446744072635809797
<BREAK>
An abort like this in the middle of an algorithm’s execution, while processing a very large problem, is a strong sign of an out-of-memory crash.
By default, Gurobi tries to solve using three methods in parallel:
Deterministic concurrent LP optimizer: primal simplex, dual simplex, and barrier
Showing barrier log only...
Gurobi stops when one of the methods reports an optimal solution, but the parallel execution takes up extra space. For a problem of this size, I recommend instead doing separate runs with method=0 (primal simplex), method=1 (dual simplex), and method=2 (barrier), after which you can select the method= setting that does best.
Can you make a smaller version of this problem — small enough that Gurobi can get a useful solution? It is much easier to run tests on a smaller version. After you understand how to solve the smaller problem most efficiently, you can gradually scale it up.
Dear Robert,
I going to do as you advised me. Many thanks once again.