A colleague of mine get’s the folowing error message:
Error at _cmdno 7525 executing “solve” command
(file ./AMPL/LIB/ampl_ELYRD_TimeLoop.run, line 66, offset 3368):
Bug: dc0 botch in solve_out
He told me, that his code worked so far using different input data (data sets). Now, this error appear using an additional data set which looks quite the same like the others - of course there are different data values. The code itself was only modified in a “cosmetic way”.
Line 66 simply contains the solve command.
Can anybody give some background information about this bug?
We do not have any previous reports about this bug. Please ask your colleague to send us files that can be used to reproduce the bug on our computers. That will enable us to determine a fix (and perhaps also a temporary workaround).
If your colleague cannot provide the files right now, the following information will at least help us to get a start on fixing the problem:
The output from the AMPL command “option version;”.
The extra output that results when “option times 1, gentimes 1, show_stats 1;” is set before the solve command that causes the error.
Here is the output related the command “option version”:
'AMPL Version 20240606 (Linux-5.15.0-1064-azure, 64-bit)\
Licensed to ... <...> academic floating (localhost).\
Maintenance expires with version 20250430.\
Using license file "....lic".\
My colleague told me that the error appear after a runtime >24 hours. He is looking for the other output.
Unfortunatelly, providing the files seems not to be possible.
The solve command’s presolve phase finishes successfully, so it appears that the bug is in the next phase of the solve command. The next phase is the output phase, which is consistent with the reference to solve_out in the error message.
I also see that when presolve finishes just before the error, AMPL has allocated 438,336,835,672 bytes of memory. This is very likely beyond the physical memory of the computer, requiring the use of slow virtual memory which may account for the runtime of over 24 hours.
We recommend looking at the complete “genmod times” output to see which model variables or constraints are taking the most memory to generate. Then study the model to determine why there are so many of those components, and whether it is possible to avoid generating a lot of them — as one example, there might be an excessive number of variables that are generated but are then set to zero or are never used.
Also, it may help to look at the times, gentimes, and show_stats statistics for one of the datasets that could be solved successfully. The model may be easier to study when working first with a dataset that generates a smaller problem.
Thank you very much for your reply. The model runs on a cluster with allocated memory of 1.5TB which is sufficient for this job.
I dont quite understand why the presolve phase is followed by a solver output. AMPL should first send the problem to gurobi to solve it. However, i dont see any Gurobi output (yes, output is switched on) in the output files.
I have already checked the gentimes output and indeed there are some variables and parameters that take excessive time to be computed. I will try to fix this. Nonetheless, this should not be the reason for the error message.