Order of heuristics affects perfomance.

[IlyaShaternik]

So I have a custom heuristic. Inside this custom heuristic I add Feasibility Pump (CbcHeuristicFPump) and RENS (Custom RENS which is basically stripped down CbcHeuristicRENS) to custom heuristic's submip CbcModel. The problem is that if Feasibility Pump is executed first and if it finds a solution, it negatively affects performance of RENS (RENS finds a better solution if no Feasibility Pump is executed). At first I thought It has to do with cutoff, But I disabled cutoff inside RENS, And checked with debugger that both model.getCutoff() and model.solver()->getDblParam(OsiPrimalObjectiveLimit, cutoff); are equal with or without Feasibility Pump, which they are (they are equal to 1e100).

Another thing that might have an effect is that inside my custom heuristic I use this options for submip's CbcModel:

model.setCutoff(objectiveValue);
model.setCutoffAsConstraint(true);

If I comment both of these settings RENS finds a solution close to the one it finds when no Feasibility Pump is executed (but still a different one).
If I comment only:

// model.setCutoffAsConstraint(true);

then again RENS finds worse solution with Feasiblity Pump.

I know that without the full code it is hard to know, but what is the possible cause of this behaviour?

[jjhforrest]

Starting from a different optimal basis can make a large difference to heuristics. This is why the Cbc option -multiple N is useful on many problems. This option starts N copies of Cbc to do the same heuristics (and also some cut generation), but it modifies the basis to try and get a different optimal basis - most problems are degenerate to some degree so this normally works. Then all different solutions and cuts are returned to the original solver, which generates additional cuts and then solves in serial (or multi-threaded) mode.

It is an interesting exercise, even when the extra effort does not pay off.