0

I've got a problem with a parfor loop: when I want to run a code whose structure is very similar to that of the code shown below, I obtain the

Subscripted assignment dimension mismatch error

I run the code with

dbstop if error

and I've observed that the indexes i and j are well iterated but the results aren't avalaible to my wokspace. Do you have any idea?

    matlabpool 12;
Nx = 51;
Ny = 53;
Nc = 11;
Ns = randn(Ny,Nx);
Nr = randn(Nc, 2^14);
Ne = randn(1, Nc);

parfor j = 1:Ny
    tic
    for i = 1:Nx
        idx = randi([1,Nc],1,19);
        if isempty(idx)
            continue
        end
        a = Nr(idx,:);  
        b = Ne(idx)';

        nrr = sum(bsxfun(@(a, b) a.*b, a, b)/(Ns(j,i)),1); 
        nrrr(j,i,:) = nrr;
    end
    toc
end

PS: This code isn't the real one but I can assure you that the types of operations are kept as those in the real one (the real one is found inside a very large script).

Teodor Petrut
  • 63
  • 1
  • 8
  • Debugging paralel code its not an easy task at all, and most likely you can not acces the variables, as tehy are different per worker. Being your code not that buf (sizes are quite small) I suggest you run this without the parfor, and debug it. Once it works, just add the parfor again. – Ander Biguri Oct 14 '15 at 16:00
  • This example does not error for me. You probably have bad indices in you real data that the random selection is filtering out. – Matt Oct 14 '15 at 16:05
  • Since this is a script did you clear `nrrr` between runs? Once it is run through it has a size. You cannot then use `nrrr(j,i,:)` without first clearing it. It takes on the size of `nrr` the first time. If `nrr` grows it will not longer fit. – Matt Oct 14 '15 at 16:09
  • Yes @AnderBiguri I've verified without using the parfor and it worked. Even this piece of code shown above works with/without the parfor, but inside the very large script it doesn't work using the parfor (I've also modified the variables to give an idea of their sizes) – Teodor Petrut Oct 14 '15 at 16:11
  • @P.Teodor That is weird. Make sure you initialize all your variables before the loop. – Ander Biguri Oct 14 '15 at 16:12
  • @Matt, yes but the nrr will be replaced no matter the worker – Teodor Petrut Oct 14 '15 at 16:14
  • @P.Teodor the `nrr` will be replaced, but not the `nrrr`. as you know the size of `nrrr` before the loop, initialize it. It will run faster and solve the problem most likely. – Ander Biguri Oct 14 '15 at 16:19
  • That's right @AnderBiguri, I didn't initialize the nrrr variable in the larger script. Thanks! But still, this piece of code works, without having to initialize the variable 'nrrr', which is not the case for the large script. Any explain? – Teodor Petrut Oct 14 '15 at 16:24
  • @P.Teodor the explanation is: there is something in the large script that is not here – Ander Biguri Oct 14 '15 at 16:29
  • Some general observations about `parfor` can be found [here](http://stackoverflow.com/questions/32146555/saving-time-and-memory-using-parfor-in-matlab/32146700#32146700). Did you initialise `nrrr`? `parfor` can't grow arrays, that's why the orange wiggles in `for` are red in `parfor`. The error is straightforward though, it tells you you are trying to store more elements into a matrix than the matrix can hold. Check the line were the error occurs for that. – Adriaan Oct 15 '15 at 19:37
  • @Adriaan: Indeed, I had to initialize the 'nrrr' within the large program the above piece of code is found. But, if you run only the above piece of code, it works without having the 'nrrr' initialized. I'm using R2011b version and I haven't any error from the parser. – Teodor Petrut Oct 16 '15 at 08:16
  • Hum R2011b is a so old version that `matlabpool` docs arent even freely available anymore. That does make life difficult to read up on. – Adriaan Oct 16 '15 at 08:28
  • [continue and parfor don't like each other](http://stackoverflow.com/a/35201609/2732801), I recommend simply not to use it. – Daniel Feb 06 '16 at 01:53

0 Answers0