Originally posted by: James82

Hi all

I'm working with a MIP written in GAMS and solved by CPLEX. I've noticed different behaviour at the root node when explicitly setting the heuristic frequency (e.g. heurfreq=50). This surprises me a bit since I thought all this setting did was change the frequency that the node heuristic is applied as CPLEX works through the nodes and I thought the heuristic was always applied at the root node regardless.

Specifically:

1) If I don't explicitly set this setting then I often see:

        Nodes                                         Cuts/
   Node  Left     Objective  IInf  Best Integer    Best Bound    ItCnt     Gap

*     0+    0                      6.53908e+008    52544.8000      899   99.99%
Found incumbent of value 6.5390770e+008 after 127.11 sec. (45226.46 ticks)
      0     0  2541345.8063  2574  6.53908e+008  2541345.8063      899   99.61%
Heuristic still looking.
Heuristic still looking.
      0     2  2541345.8063  2574  6.53908e+008  2541345.8063      899   99.61%
Elapsed time = 181.40 sec. (83381.15 ticks, tree = 0.01 MB, solutions = 1)
      1     3  2542278.0843  2320  6.53908e+008  2541345.8063     5045   99.61%
      2     4  2543119.9087  2107  6.53908e+008  2541385.2348     8763   99.61%
      4     6  2543055.6684  2363  6.53908e+008  2541385.2348    13302   99.61%

In my understanding this means the node heuristic has been tried, found a new incumbent, then tried again until some kind of time or usage limit is reached before CPLEX moves on to branching.

2) If I set the setting to, e.g. heurfreq=50, the model solves at the root node before branching:

        Nodes                                         Cuts/
   Node  Left     Objective  IInf  Best Integer    Best Bound    ItCnt     Gap

*     0+    0                      6.53908e+008    52544.8000     3987   99.99%
Found incumbent of value 6.5390770e+008 after 149.20 sec. (51460.40 ticks)
      0     0  2541345.8063  2574  6.53908e+008  2541345.8063     3987   99.61%
*     0+    0                      2549197.1142  2541345.8063     3987    0.31%
Found incumbent of value 2549197.114192 after 299.29 sec. (160148.95 ticks)

In smaller versions of my model (that is, the full model is run hourly for a year but if I shorten this to hourly for 2 weeks) this gives a speed up (as identified by tuning). However, the full model is yet to solve after 48 hours run time and I wonder if the time taken to solve the node heuristic at the root is stalling things.

So my question is, does setting the heurfreq explicitly change anything else than the frequency it is applied? Is the heuristic applied multiple times at the root in some cases?

Thanks!

Indeed, the parameter controls a little more than just the frequency.

If you set this parameter to a positive value then CPLEX assumes you know that heuristics will do good on your model and therefore allocates a bigger time budget to heuristics. This may allow heuristics to find solutions they cannot find in default settings.

Whether the heuristics at the root node are problematic or not should be visible in the log since you should see the time it takes to process the root node. Does it look as if the root node is stuck?

Originally posted by: James82

Hi again

Thanks for this. Really useful to know that setting heurfreq also implies a larger time budget for heuristics - which do indeed do a good job of solving this problem.

Regarding stalling, I'd forgotten about changing the mipdisplay parameter so I could see in the logs what is actually going on at the root node after the initial relaxation. It turns out that the stalling I am seeing in the progress of the full model is caused by the second root relaxation not solving within the 48 hour run time (endless iterations). Dual simplex struggles because of degeneracy (I guess because of early pertubations) and numerical difficulties (I'm already using maximum scaling and Markowitz tolerance = 0.9999). Which is why barrier seems to always solve the root but then I was hoping to benefit from warm/hot starts during the following solves/nodes.