Originally posted by: SystemAdmin

Hi everyone,

The following is how I setup MIPstart in my code, where X and Z are decision variables of my model. But it seemed that the MIPstart I setup didn't take affect at all. Why is that?

// Define arrays for MIPstart setting IloNumVarArray startVar(env); IloNumArray startVal(env);   

int zIndxO = 0; 

for (

int i = 0; i < h; i++) 
{ 

for (

int j = i+1; j < h; j++) 
{ 

for (

int s = 0; s < l; s++) 
{ 

for (

int t = s+1; t < l; t++) 
{ 

if (s >= m[i] - x_DQ && s <= m[i] + x_DQ && t >= m[j] - x_DQ && t <= m[j] + x_DQ )
{ 
// assign starting solution to X startVar.add(X[i][s]); 

if (m[i] == s) 
{    
// Provide m[] as starting solution for MIP  startVal.add(1); 
} 
// only h of the validX set have value of 1, and the rest are taking 0  

else 
{ startVal.add(0); 
} 
// assign starting solution to Z startVar.add(Z[zIndxO]); 

if (m[i] == s && m[j] == t) 
{ startVal.add(1); 
} 

else 
{ startVal.add(0); 
}     ..... 
//add MIP start and end it cplex.addMIPStart(startVar, startVal); startVal.end(); startVar.end();

#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

The last one just got posted before I hit the submit button:( sorry about the messy code.

Before I tried MIPstart option, I also got the same feasible solution and computed its corresponding objective value which then used as a cutupper value later in CPLEX parameter setting. And as I expected, the cutupper option did help the model prune more nodes and run faster.

I thought MIPstart would do the similar work as cutupper, but I didn't get much improvement just after adding the above codes in my model.
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Perhaps I'm reading your code wrong, but it seems that you repeatedly the same variable Z[zIndxO] to startVar, with different starting values. I think only the last one will take effect. Shouldn't you be modifying that index within the loop?

Paul

Mathematicians are like Frenchmen: whenever you say something to them, they translate it into their own language, and at once it is something entirely different. (Goethe)
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Hi Paul, thanks for your quick reply. Sorry I just forget to include all relevant code, and I did increase the index of Z variables in the loop. But your comments reminds me that I should have included X variable in the same loop since X basically only relate to index s and t, but I nested X in a 4-layer loop which just repeat each X variable I want multiple times.

But the problem is that the running time doesn't change at all (much slower than using "CutUp" option) even after I fixed the above bugs.
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Do you see the starting solution reflected in the node log?

A couple of things to try: (a) check the (integer) value returned by addMIPStart (I think it should be zero if successful, nonzero if an error occurred); (b) set the optional effort argument of addMIPStart to IloCplex::MIPStartEffort::MIPStartRepair and see if that makes a difference. If the extra effort makes a difference, perhaps your starting solution is not entirely correct (?), or at least needs a little polishing.

Paul

Mathematicians are like Frenchmen: whenever you say something to them, they translate it into their own language, and at once it is something entirely different. (Goethe)
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Thanks Paul and Daniel for your advices!! I solved my problem. The trick was that I put addMIPstart part before extracting model to CPLEX. Before I fixed it, the log didn't give msg like "no sol form MIP start" or " or "MIP start provides one solution with obj...".

One thing I don't understand is why CutUp runs sometimes faster sometime slower than MIPstart. P.S. the CutUp value just simply equals to the obj value computed from the same MIPstart feasible solution.

Thanks again for your kind help!
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

> Deanna1125 wrote:
> One thing I don't understand is why CutUp runs sometimes faster sometime slower than MIPstart. P.S. the CutUp value just simply equals to the obj value computed from the same MIPstart feasible solution.

Here's a quote from the CPLEX user manual:

Having an incumbent from the very beginning of branch and cut allows CPLEX to eliminate portions of the search space and thus may result
in smaller branch-and-cut trees. Having an incumbent also allows CPLEX to use heuristics which require an incumbent, such as 
relaxation induced neighborhood search (RINS heuristic) or solution polishing.

The CutUp value will have the same effect on early pruning (the first sentence) as the MIP start will. If the MIP start is a feasible solution (which I understand to be the case with you), however, it will allow early application of the RINS heuristic, and may have other effects that can alter the search path in ways other than just early pruning. So CutUp and MIP start are liable to generate different search paths. MIPs are notoriously capricious, so changing the search path can make the algorithm either faster or slower.

Paul

Mathematicians are like Frenchmen: whenever you say something to them, they translate it into their own language, and at once it is something entirely different. (Goethe)
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Could you post the log here?
If a MIP start is present then it should say something like "no solutions found from 1 MIP start" or "MIP start provided solution with objective ...". Do you see any of this in the log?
#CPLEXOptimizers
#DecisionOptimization