Interaction with Gurobi solver

[Marius Krömer]

Dear Ampl team,

 

I am currently working on an implementation of a warm start solution where I load the result of another implementation of the same model in my code. Somehow, the models seem to have a discrepancy as the solution is not accepted as initial model.

 

Gurobi returns the statement “User MIP start did not produce a new incumbent solution

User MIP start violates constraint R531289 by 32934.000000000”

 

Is it somehow possible to show in an alternative way which constraint is violated. I would like to see the constraint name (the term after “subject to”) and even better would be the specific constraint which is a combination of the name and the set member of the set on which it is defined.

 

After defining my problem with the “problem: …” statement, I counted among all constraints (names & sets on which they are defined) but the outcome here doesn’t show me that the constraint number 531289 is violated.

Maybe it is also possible to see in which sequence the constraints are put as row into the gurobi engine in order to identify the constraint and its set, which create the conflict.

 

 

Thank you for your help & best regards

Marius

 

Marius Magnus Krömer, M. Sc.
Research Assistant 
 

University of Mannheim
Business School
Chair of Service Operations Management | Schloss Schneckenhof Ost (Room SO 214) | 68131 Mannheim

Germany
 
Phone: +49 621 181-2657
E-mail: kro...@bwl.uni-mannheim.de
 
Web: https://www.bwl.uni-mannheim.de/schoen/
Visit us on Facebook.
Visit us on Instagram.
Visit us on YouTube.

 

[AMPL Google Group]

Gurobi numbers its constraints beginning with 0, while AMPL starts numbering with 1. So you could try the following command after loading your initial solution but before solving:

display _sconname[531290], _scon[531290].slack;

This should show you the AMPL name of the violated constraint, and should show the slack as -32934. If not, try the same test with AMPL's presolve reductions turned off:

option presolve 0;
display _sconname[531290], _scon[531290].slack;

(In this case Gurobi will do the presolve reductions, but after checking feasibility.) Gurobi only shows you the first infeasibility that it finds, however. To check for all constraint violations greater than some small tolerance, you can use a command such as the following )again, after loading your initial solution):

display {i in 1.._ncons: _con[i].slack < -0.000001} (_conname[i], _con[i].slack);

Also you can use this command to look at the violated constraints:

expand {i in 1.._ncons: _con[i].slack < -0.000001} _con[i];

(If there are a lot of these, use "> expand.out" at the end to redirect the listing to a file.)

Technical note: _ncons, _conname, and _con refer to the constraints as originally generated by AMPL, while _sncons, _sconname, and _scon refer to the constraints as seen by the solver -- after AMPL's presolve. Even though presolve is "turned off" with "option presolve 0" it will remove variables that are not used and constraints that contain no variables.

--
Robert Fourer
am...@googlegroups.com

{#HS:1637672296-106366#}