Add support for MEMORY_LIMIT termination status

[henriquebecker91]

My situation: I am writing a paper that compares many formulations of the literature for a specific problem in the same computer setup (to be fair) and using both CPLEX and Gurobi (to be complete). Some formulations do not do well with some instances from literature datasets, and ask for more memory the computer setup has available. I do not want: to change the formulations (they are from the literature and should be executed as is); to buy more memory (the computer setup is from the university, and some instances will probably have problems even if I had the maximum allowed by the setup); to manually verify if a pair of formulation/instance has memory problems (they are thousands). Theoretically, I can solve this in CPLEX setting the memory limits for the branch-and-bound tree: this make it not throw any exceptions but instead return a different termination status. However, not every solver has memory limits or act the same way, in fact, Gurobi has no configurable memory limit, and instead will throw an exception when it perceive it will need more memory than the one provided by the system. Gurobi.jl wrapper actually deals with this kinda gracefully, capturing the exception and throwing it again. So I can theoretically capture the exception, and if it checks as out-of-memory I can mark this on the output and continue with the experiment.

My questions: Can I depend on the exception thrown by a solver wrapper? (Can it be changed in a patch version? Or minor one after 1.0.0?) Will the solver wrappers maintained by jump-dev follow the same string pattern ("$SOLVER_NAME Error $ERROR_NUMBER: $ERROR_MESSAGE_FROM_SOLVER_IF_ANY") and be of type ErrorException? What is the rationale for having something as termination status or as exception?

Sorry if this is not the right channel, but I was not sure where to ask about the solver wrappers maintained by jump-dev in general (i.e., not about a specific solver wrapper).

[mlubin]

We have a MEMORY_LIMIT termination status code. Whenever feasible, solvers should be using it instead of throwing an exception. If that's all you need, then we don't need to get into a larger style discussion about exceptions. On that I would say, error strings are generally not considered part of the API for deciding what's a breaking change and what isn't. It's fair to argue that changing the exception type should be considered a breaking change.

[henriquebecker91]

The best for me would Gurobi.jl to return a MEMORY_LIMIT termination status code. Then I would have to change nothing in my code. I can work on a PR for that, if you allow me. I just want to be sure, before working on this, that the perception that Gurobi should return a MEMORY_LIMIT termination status code will not change. I am not sure if there is not any pitfalls, like other information that could be queried from Gurobi in such state ends up returning invalid values. Can I open an issue and PR on Gurobi.jl?

P.S.: Changing error messages probably should not be considered breaking changes, I agree, but maybe, in the future, would be interesting to have an unified exception type (or maybe an exception interface) that answered something like is_solver_error and solver_error_code because, as of now, there is only breaking ways to behave based on solver exceptions (thats is, checking the error message).

[odow]

Please open a PR in Gurobi. You can probably check the return code of optimize! is GRB_ERROR_OUT_OF_MEMORY (10001) and set a flag in the optimizer for the next call to TerminationStatus.

I'll move this to Gurobi.jl.

[henriquebecker91]

Okay. I will probably submit a draft of the PR tomorrow. I was thinking of doing the way you outlined but was worried it would be considered too hacky.

Do you think there may be other points, outside of termination status, that may need to check this flag to not trip over invalid state?

[henriquebecker91]

The PR is #398.

[odow]

Closed by #398