UseParallel not working consistently...?

[ryancoe]

While working on #140, I was looking at my activity monitor and realized that I only ever saw one instance of NEMOH's solver running (I'm using htop, which gives better update rates, etc.). At first I assumed this had something to do with the OOP programming structure, but the more I simplified my MWE the more surprised I was... Maybe I'm missing something here...?

clc
clear
close all

%% this will run in parallel
tic
parfor ii = 1:4
    y = fun(ii);
end
toc

%% this will not run in parallel
opts = optimoptions('fmincon','UseParallel',true);
tic
fmincon(@(x) fun(x),0.35,[],[],[],[],0.35,3,[],opts)
toc

%% pointless objective function
function fval = fun(x)
    [s,c] = system('sleep 2');
    fval = x;
end

[H0R5E]

I'm not sure this is a bug, maybe just a product of how fmincon works because it uses parallelisation in the gradient calculation, which is using forward finite differences by default (and may only require one more function evaluation to make a step). If you switch the finite differencing to "central" (opts.FiniteDifferenceType = 'central';) then you should see the parallel pool being used. Whether that saves you time or not, I'm not sure.

[H0R5E]

So, I'm not totally sure I know what's going on, but on these docs it does say:

Even when running in parallel, a solver occasionally calls the objective and nonlinear constraint functions serially on the host machine. Therefore, ensure that your functions have no assumptions about whether they are evaluated in serial or parallel.

Seems like it's a lot more than occasionally for us, but because you can't see the source code of the barrier function, it's hard to know if this is the correct behaviour or not.

[ryancoe]

I looked into your theory about the finite difference stencil (good idea), but didn't see a difference. What did make a difference was to increase the number of design variables from one to two.

clc
clear
close all

%% this will run in parallel
tic
parfor ii = 1:4
    y = fun(ii);
end
toc

%% this will now run in parallel (at least for some iterations)
opts = optimoptions('fmincon','UseParallel',true);
tic
fmincon(@(x) fun(x),0.35*ones(2,1),[],[],[],[],0.35*ones(2,1),3*ones(2,1),[],opts) % <- note the *ones(2,1)
toc

%% pointless objective function
function fval = fun(x)
    [s,c] = system('sleep 2');
    fval = x(1);
end

[H0R5E]

Interesting, I got different behaviour on Windows. It might be worth opening a issue about optimising the optimiser (lol). There are a lot of options we are yet to try with fmincon and a number of other methods we could test as well.

[ryancoe]

Haha... yes, this is exactly what I do not want to spend our time doing :) We (or ideally some users) can explore the different MATLAB optimization algorithms, as well as those offered as add-ons.

[ryancoe]

While running a multi-objective study (WaveBot_caseC), I also confirmed that multiple instances of solver where running (nothing new, but just a second confirmation that things are working)