FMINCON Parallel Pool goes idle after first iteration.

My question is similar to these questions

• https://www.mathworks.com/matlabcentral/answers/179509-parallel-programming-toolbox-shutting-down
• https://www.mathworks.com/matlabcentral/answers/413802-fmincon-parallel-pool-goes-idle-after-first-iteration

But I have not yet seen an answer.

I'm running an optimization using FMINCON with 17 variables. The computations is rather difficult so it takes a couple of minutes to compute the objective. At start-up, the parallel pool icon in the bottom left corner becomes green and the CPU/Memory use goes up significantly, inidicating that the parallel pool is doing its job.

However, after the first iteration is finished, and the results are displayed in the console, the parallel pool goes idle. The icon in the bottom left becomes blue and the CPU/Memory usage goes down significantly. From that point onwards, the optimization seems to continue using one core only. Any idea what causes this?

During this time, the ParPool is not shut down, since I set the shutdown timeout to 24 hours or so. It simply shows that it has been idle for a long time.

One guess of mine could be that one of the function calls in the parallel computing returns NaN, which might ruin things. But this is just a wild guess. Any help would be very much appreciated.

Answer 1

[Matt J]

Does it happen only for this specific optimization problem, or for every problem?

In any case, a workaround might be to set SpecifyObjectiveGradient=true and supply your own parallelized finite difference calculation with the help of gradest() in this File Exchange package:

https://www.mathworks.com/matlabcentral/fileexchange/13490-adaptive-robust-numerical-differentiation

This would be functionally the same as what the UseParallel option is supposed to do, and sometimes, I find it gives superior results to fmincon's finite differencer. You would have to edit gradest.m slightly and just change the for-loop to a parfor loop:

parfor ind = 1:nx
  [grad(ind),err(ind),finaldelta(ind)] = derivest( ...
    @(xi) fun(swapelement(x0,ind,xi)), ...
    x0(ind),'deriv',1,'vectorized','no', ...
    'methodorder',2);
end

[Wouter de Gruijl]

Only for the specific problem. If I use a generic test problem (which is musch easier to solve) it doesn't happen. This looks complicated, but I will give it a try!