Cplex | Setting initial mip solution

Hi all,

i am facing a problem with setting an initial MIP solution using CPLEX. My variables are as follows:

Variables
x_ijk(V,V,M) 
y_ik(V,M)  
w_ik(V,M)  
b_ik(V,M)
rt_ik(V,M) 
GOAL;
Binary Variable x_ijk, y_ik;
Positive Variable b_ik, w_ik, rt_ik;

In my understanding by setting mipstart 1 option only binary and integer values have to be set. To construct the solution I am loading the results from a different gdx file (result from heuristic)

Parameters
x_ijk_l (instances,*,*,*)
y_ik_l (instances,*,*)

and am setting levels of integer and binary variables as follows:

x_ijk.l(i,j,k) = x_ijk_l('%INSTANCE%',i,j,k);
y_ik.l(i,k)= y_ik_l('%INSTANCE%',i,k);

Please note %instance% = ID for given testdateset.

Checking the assignment of x_ijk.l and y_ik.l via Display statement shows the same results as given in the solution gdx file (=x_ijk_l, y_ik_l).

By setting options as follows I am activating the MIP initial solution feature of cplex.

Model transport /all/ ;
Option mip=cplex;
Option optca=0.000001;
Option optcr=0.000001;
Option reslim=7200;
transport.optfile=yes;
$Onecho > cplex.opt
mipstart 1
$offecho
Solve transport using mip maximizing GOAL ;

This configuration leads to a log entry of CPLEX (when solving) like

… provided solution m1 no feasible solution…

Concluding, the given solution is not accepted (and ignored). If i am changing the .l to .fx in the assignment a feasible (and optimal solution) is obtained. I also tried to set all variable values by using mipstart 2. Again, CPLEX is not obtaining a valid solution in the startup, but setting .fx with the same values a feasible (and optimal solution) is obtained. This confuses me.

Of course, I can provide a mini sample if required to reproduce the issue. I have skipped the mini sample creation as this would cause some efforts and maybe some general thoughts are wrong from my side. What be happy to hear your thoughts/advices. Please let me know if mini sample is needed.

Edit: Maybe this topic should go to “Solver” section. Sorry for circumstances.

Kind regards,

Please ignore this post and consider it as closed. A preprocessing (tightening) step in gams was causing the problem.

Yes, we see such question (and the solution) often. Setting .l might set the level to a value outside the bounds. When GAMS generates the model it projects the values outside the bound to the closest bound. If you set .fx you also change the bounds. The equation and variable listing with its infeasibility and projection markers are really useful to debug something like this.

-Michael