2) H/Xpress Freezing

WHAT DO YOU DO WHEN H/XPRESS FREEZES OVER?

Have you had a run that appears to freeze in the optimize step?  It might well have already done some recursion passes, but now it’s just sitting there in the Queue Manager like it is never going to finish.

 

 

 

Stop Recursion or Kill Job (the skull-and-cross-bones) won’t help because they only interrupt the run when a step is finished.  Kill Frozen Job (the red skull –and-cross-bones) will do it – but as it also terminates all other runs and closes Excel,  it’s a bit drastic.  
 

Thaw it with Task Manager
I prefer to handle apparently frozen optimizer steps via Windows Task Manager.

 

 

 

This is probably going to show you that H/XPRESS hasn’t actually stopped.  If it is still using CPU and memory,  it is still running.   You could just leave it for a while.   One of the advantages of having GRTMPS multi-core is that you can carry on doing other runs, while this one ticks along in the background.    (My personal record is a massive MIP problem that I left for over two weeks – but that is another story.)  If you are ready to pull the plug, then terminate the H/XPRESS process from within Task Manager.  (Best to wait until it is the only job still running so you don't accidentally stop a good one.)  The GRTMPS run script will detect that the optimization has ended with an error, and will terminate itself with Error 13 in the Optimizer step - and, at the end of the SUM file,  *E* Error! in Optimize: Application failed with error code 1.

 

 

 

Why is this better?   Unlike using the Kill Frozen option, you will have the Optimizer Log in the LST file and that can be used to see what is happening.   While MIP problems can simply take a very long time, the most common reason for H/XPRESS going very slowly on an SLP iteration is a borderline infeasibility in the current matrix.   The optimizer keeps starting over again trying to find feasibility rather than detecting there is no solution.  We can send problem cases to Fair Isaac to drive improvements to their code.

Skating Over the Ice.
Of course, you still want a solution for your case.   Starting the problem case from different initial estimates, or using recursion penalties, might push the model through a different path.   It might also help to toggle some of the advanced optimizer options - turn pre-solve on/off, use a basis, change the crash settings.  (Do reset them back to the defaults for normal running). 

Avoiding Freezes
How can you avoid freezing in the first place?  Set a maximum iteration limit on the Optimizer Advanced panel (ITERMAX  in TABLE OPTIMIZE).  

 

 

800,000 should be more than generous enough for refinery SLP models – even multi-location ones – so this should only limit bad runs.  It will take 20 to 30 minutes, maybe more, depending on your machine and its work load.  But it will eventually give up and go on to the next pass.   So, it will eventually finish, freeing up the processor,  and if you happen to be lucky maybe even recover to a sensible solution.   (You can try lower limits for less time, but watch out for FEAS status passes as an indication that you have hit it; you don't want that to be a normal occurrence as it isn't great for recursion updates.)   

If you have MIP variables in your model, then you could also set MAXTIM – the number of seconds to carry on with the Branch & Bound step after it has found the first integer solution.    For instructions on how to do this, and other possibly useful adjustments to the stopping criteria, see the GRTMPS Reference Manual and the breakout session on Mixed Integer Programming Control Parameters in the Conference Papers (2016) on the Tech Support site.

Does this happen with other optimizers too?   Probably.  The same advice would apply, just with a change of names.