MATLAB Answers


Deployed applications - Display from within a parfor loop and some other questions

Asked by Lipa
on 14 Jan 2013
Dear readers,
I have a number of questions regarding the Matlab program I am trying to deploy as a standalone Windows application. The program uses a single (but crucial) 'parfor' loop. (I should point out that the same code using just the simple 'for' loop works as intended.)
1.) From within the parfor loop, I am trying to display some information for the user. At the moment I am using the 'disp' function, e.g.:
parfor i = 1:10
disp(['The index of this iteration is: ', num2str(i)])
This block of code works as intended when I run it from within Matlab. However, when I compile the application and try to run it from Command Prompt, the program doesn't display the required data anymore. What seems to be the problem? Are there any other functions that could help me achieve the required result (i.e. displaying lines of text for the user)?
2.) For a number of variables, Code Analyzer gives me the following error (the program still works, but the variables are underlined in red):
"The temporary variable 'x' uses a value set outside of the PARFOR loop."
I know that for declaring the variable 'x', I am combining some data defined before the parfor loop and some data from within the loop (typically the iteration index). But what seems to be the problem?
3.) When building the deployed .exe file, I get the following warnings:
"The temporary variable 'y' will be cleared at the beginning of each
iteration of the parfor loop. Any value assigned to it before the loop will be lost."
I am well aware of this and it is OK with me, however, I don't know how to disable the warning. I tried using the warning('off, 'all'), but the warnings persist. What especially bothers me is the fact that these warnings are also displayed each time that I run the deployed application from Command Prompt.
4.) As a final question, I noticed that there is a huge difference in file size of the deployed application when I'm using the parfor loop compared to the case when I'm instead using a simple for loop. The application with the parfor loop is well over 8 MB in size, whereas the application with the for loop is only 400 kB. I guess that trying to compile the code for using parallel processing takes many more lines, but I'm interested in hearing more about this.
Thank you very much in advance for all the help!


Thanks. Any chance you could also post a short piece of code that demonstrates the messages you talk about in 2) and 3)? Would help in giving useful advice.
2) The code is (basically) something like this:
a = 1;
b = 10;
parfor i = 1:b
x = i/a
3) The code is (basically) something like this:
a = 1;
b = 10;
parfor i = 1:b
y = my_function(a,b,i)
Funny thing, I just noticed that if I try to run the above two pieces of code as solo programs, I don't get any error or warning notifications. Is it possible that the Code Analyzer is confused with my original code?
As a side note, I just noticed another warning in my code:
"The input variable 'z' should be initialized before the PARFOR loop."
But the variable in question IS initialized before the parfor loop in my code. Hm... is it possible that something is confusing the Code Anlyzer? If so, how can I suppress the warnings so that they are not displayed after the deployment of the program? Thanks!
I don't see those messages from those pieces of code either. I suspect there are other places in the large program that refer to some of the same variables as these smaller snippets, and it is these other uses that are causing the problem. My advice would be to break up the larger program into several smaller functions, where each function only has the variables it needs. This will at least make it easier to isolate the problems, and might make things completely clean.

Sign in to comment.

1 Answer

Answer by Richard Alcock on 15 Jan 2013
 Accepted Answer

1) The lack of display from inside the parfor loop is unfortunately a problem in the R2012b release of Parallel Computing Toolbox. I see the same thing on my computer. The development team are aware of the issue and are working on a fix for a future version.
If you are trying to show a progress through a long process you might be interested in one of the "parfor progress monitors" available on the File Exchange - see
2) and 3) As discussed in comments, as I can't reproduce the problem, I don't know exactly what to suggest. Try breaking code into smaller pieces.
4) When you are using parfor the application needs to include all the needed functions and other files to run your code in parallel on a MATLAB pool. The short version is that it is these files that increase the size of the application.


Show 1 older comment
After trying what you suggested, I managed to reproduce the error (2). Here's the (simplified) code:
show = true;
parfor i = 1:10
x = 3;
if (show)
The problem seems to be in the 'true'/'false' flag of the variable 'show'. If the variable is set to 'true', no errors are reported. However, when the variable is set to 'false', 'x' is reported to be in error, as I listed in the original post (note that the code still runs, I'm just confused about the error report). Any thoughts?
And now I think I also figured out the problem with the warnings (3). It seems that the issue was that some of my temporary variables within the parfor loop were declared within conditionals, e.g.:
switch (a)
case 1
y = ...;
case 2
y = ...;
y = ...;
If I initialize the variable 'y' at the beginning of the parfor loop, even though it is then overwritten within the above 'switch' sentence, I don't get the warnings anymore...
Thanks for the extra details. I can now reproduce both of these issues, and I've passed them onto the development team.
To workaround (2), you can try setting "show" to something that evaluates to false. Any other these seem to work for me:
show = false(1);
show = strcmp('yes', 'no');
show = 1<0;
Not ideal, but they do get rid of the warning!
For (3), an alternative to setting "y" at the start of the loop, is to use an if/elseif/else block instead of the switch/case/otherwise block.

Sign in to comment.