CODEWITHSUNDEEP
matlabvariablesparallel-processingsequentialparfor
Sumbul
Sumbul

Reputation: 167

Sliced Variables in PARFOR loop: Sequential to Parallel Conversion in MATLAB

I have a code in MATLAB in which I'm running monte-carlo simulations using parfor instead of simple for loop to convert the code from sequential to parallel. Following is the piece of code which is inside the parfor loop.

But MATLAB gives an error saying "Valid indices for local_Q_mega_sub_seed are restricted in parfor loop". Suggested action says to "Fix the index" and it suggests to use "Sliced Variables". I've been struggling to use this concept. I have read https://blogs.mathworks.com/loren/2009/10/02/using-parfor-loops-getting-up-and-running/#12 and https://www.mathworks.com/matlabcentral/answers/123922-sliced-variables-in-parfor-loop-restricted-indexing along with MATLAB documentation https://www.mathworks.com/help/distcomp/sliced-variable.html and https://www.mathworks.com/help/distcomp/parfor.html but I'm not getting it right.

Could anyone please let me know how can I use sliced variables in the given piece of code so that I could get an idea?

index_f = 1;
subseed_step = (sub_seed_transmitted_at/fs_local)*sintablen_mega_frequency;
for i = 1 : fs_local
local_Q_mega_sub_seed(i) = SINTAB(round(index_f));
local_I_mega_sub_seed(i) = COSTAB(round(index_f));
index_f = index_f + subseed_step;
if index_f>sintablen_mega_frequency
    index_f = index_f - sintablen_mega_frequency;
end

Upvotes: 0

Views: 826

Answers (1)

Edric
Edric

Reputation: 25140

You're not showing enough context here, but I bet the problem here is similar to this one:

parfor ii = 1:10
    for jj = 1:10
        tmp(jj) = rand
    end
    out(ii) = sum(tmp);
end

In this case, the parfor machinery cannot categorically prove that the way tmp is being used is independent of the order of iterations of the parfor loop. This is because it appears as though values assigned to tmp in one iteration of the parfor loop are still being used in the next iteration.

Fortunately, there's a very simple workaround for this case - convince parfor that you are not doing anything dependent on the order of evaluation of the iterations of the loop by resetting the variable. In the simple case above, this means:

parfor ii = 1:10
    % reset 'tmp' at the start of each parfor loop iteration
    tmp = [];
    for jj = 1:10
        tmp(jj) = rand
    end
    out(ii) = sum(tmp);
end

Upvotes: 1

Related Questions