MATLAB Answers

Index exceeds matrix dimensions but only in parfor and not for

56 views (last 30 days)
Naty S
Naty S on 25 Feb 2013
Edited: Thomas Dolivo on 12 Apr 2018
hey I am new to parallel computing. I have been trying to get my simulation run using parfor, however when i am using parfor i am getting the following error:
I have got this weird error which i don't know how to handle. I don't get any error when using for instead of parfor. any idea? Thanks! Naty
Error using parallel_function (line 598)
Index exceeds matrix dimensions.
Error stack:
run_ode.m at 62
run_sim.m at 9
  5 Comments
Matthew Phillips
Matthew Phillips on 3 Oct 2013
I'm having this exact same problem. Pretty hard to debug given that you can't put breakpoints within a parfor loop.
Running
>> dbstop if error
halts on this block in parallel_function.m, line 579ff:
try
R = distributed_execution(...
P, base, limit, W, k, NN, NN0, consume, supply, ...
reduce, R, concatenator, ...
consume_supply_reduce_concat, ...
consume_bit, supply_bit, reduce_bit, concat_bit);
break;
catch err
...
[err, possibleSourceFiles] = iMaybeTransformMissingSourceException(err, F);
if isempty(possibleSourceFiles) || ~attachFilesAndRetryOnError
throwAsCaller(err);
end
possibleSourceFiles is empty. parallel_function.m is called directly from the file containing my parfor loop so it is not possible for me to track down its inputs (in particular, the function handle 'consume') and the possible source of this error.

Sign in to comment.

Answers (3)

F Poelwijk
F Poelwijk on 1 May 2014
One common reason for this error to occur is when you try to insert entries to an array that is not pre-defined outside the parfor loop. A for loop has no problems with this (though the editor will suggest pre-allocation for speed), but a parfor loop does. Try pre-defining the variable, e.g. x = zeros(n,m).
  2 Comments
Neill Weiss
Neill Weiss on 28 May 2014
This worked for me. I needed to preallocate an array of objects. Thanks F Poelwijk.

Sign in to comment.


Khalid
Khalid on 17 Apr 2016
Hi, I ran into the same problem with some code, and thought I'd explain the issue and fix in case someone else gets the same error for the same reason. Below is a minimal reproducible example of the problem. You will see the for and parfor loops below are identical. The for loop runs ok, but the parfor loop faults.
This is likely to come up if you have different running options and some variables are set in some of them but not in others. It appears the parfor error checking is thrown, it is probably checking that all possible execution paths through the parfor loop are acceptable, whereas in the example below they are not. Note that if you set doAssignment to true below both types of loop will run. The fix in my case is to do per-allocation for all possible running options through the parfor loop.
- Khalid.
doAssignment = false;
if doAssignment
a = zeros(2,1);
end
for i = 1:2
if ~doAssignment
disp('run here');
else
disp('dont run here');
disp(a(i)); %#ok<*SAGROW,*UNRCH>
end
end
parfor i = 1:2
if ~doAssignment
disp('run here');
else
disp('dont run here');
disp(a(i));
end
end
  1 Comment
Thomas Dolivo
Thomas Dolivo on 12 Apr 2018
Thank you very much for your comment. I had a similar situation that I identified thanks to your hint.
foo = zeros(4,1);
parfor i = 1:8
if i <= 4
bar = foo(i); % this causes an error in parfor, but not in for
else
bar = foo(i-4);
end
end
By unifying the access to the array, the error was fixed:
foo = zeros(4,1);
parfor i = 1:8
if i <= 4
j = i;
else
j = i-4;
end
bar = foo(j);
end
@Mathworks: The error message should be more clear. Why can’t it at least give a line number of where the “Index exceeds matrix dimensions” occured?

Sign in to comment.


Matt J
Matt J on 3 Oct 2013
Edited: Matt J on 3 Oct 2013
There's too little information about the code being run to say much. My guess is that the loop iterations might not really be order-independent for some subtle reason. For example, maybe some of the functions you are calling within the parfor loop contain persistent or global variables -- something which is supposed to remember the outcome of previous iterations in a for loop. That would be illegal in a parfor, of course, since the sequence of iterations can't be predicted.
  1 Comment
Matt J
Matt J on 3 Oct 2013
One way to test this would be to replace the parfor loop with a normal for loop, but run the iterations in a crazy random order
for i=randperm(1:Nsteps)
...
end
and see if the result is affected.

Sign in to comment.

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!