On a recent post I was told that there are differences between the way parallel toolbox handles warnings and the way regular matlab deoes it. I felt that poster hand gone someway to answering my question so I marked it as answered. But I still have some additional questions (hope this doesn't contitute double posting).
Error only triggers when I don't use parfor?
I just wondered if someone can explain to me what these differences are?
Also what is meant by parfor being sandboxed?
Is it still possible to use try catch type structures with the parallel tool box or using some other mechanism to chain the same thing?
To be clear when I run using parfor warning messages are still produced telling me the matix is illconditioned but it doesn't seem to be being picked up as an error despite me adding the lines
warnState(1) = warning('error', 'MATLAB:singularMatrix');
warnState(2) = warning('error', 'MATLAB:illConditionedMatrix');
However, when I run using a regular for loop it is picked up as an error.
So the parallel tool box is producing the warnings correctly its just not translating them into errors via the code above so they can be used in a try catch structure.
Kind Regards
Hugh
I think the problem in your original code is that you changed the warnings to errors on the MATLAB client only. To make that change on the workers, you need to do
spmd
warnState(1) = warning('error', 'MATLAB:singularMatrix');
warnState(2) = warning('error', 'MATLAB:illConditionedMatrix');
end
There's also the pctRunOnAll function to run things everywhere.
Also, I don't know what the OP meant about matlabpool workers being 'sandboxed'. The differences between your MATLAB client and the workers are:
The workers always run in single threaded mode; and
The workers run with no display (although they can produce off-screen graphics and save to file)
Related
Does the execution of addpath/rmpath/savepath in one MATLAB instance affect other instances?
Motivation: Imagine that you are developing a MATLAB package, which provides a group of functions to the users. You have multiple versions of this package being developed on a single laptop. You would like to test these different versions in multiple instances of MATLAB:
You open one MATLAB window, type run_test(DIRECTORY_OF_PACKAGE_VERSION1), and hit enter;
While the first test is running, you open another MATLAB window, type run_test(DIRECTORY_OF_PACKAGE_VERSION2), and hit enter.
See the pseudo-code below for a better idea about the tests.
No code or data is shared between different tests --- except for those embedded in MATLAB, as the tests are running on the same laptop, using the same installation of MATLAB. Below is a piece of pseudo-code for such a scenario.
% MATLAB instance 1
run_test(DIRECTORY_OF_PACKAGE_VERSION1);
% MATLAB instance 2
run_test(DIRECTORY_OF_PACKAGE_VERSION2);
% Code for the tests
function run_test(package_directory)
setup_package(package_dirctory);
RUN EXPERIMENTS TO TEST THE FUNCTIONS PROVIDED BY THE PACKAGE;
uninstall_package(package_directory);
end
% This is the setup of the package that you are developing.
% It should be called as a black box in the tests.
function setup_package(package_dirctory)
addpath(PATH_TO_THE_FUNCTIONS_PROVIDED_BY_THE_PACKAGE);
% Make the package available in subsequent MATLAB sessions
savepath;
end
% The function that uninstalls the package: remove the paths
% added by `setup_package` and delete the files etc.
function uninstall_package(package_directory)
rmpath(PATH_TO_THE_FUNCTIONS_PROVIDED_BY_THE_PACKAGE);
savepath;
end
You want to make sure the following.
The tests do not interfere with each other;
Each test is calling funtions from the correct version of the package.
Hence here come our questions.
Questions:
Does the execuation of addpath, rmpath, and savepath in one MATLAB instance affect the other instance, sooner or later?
More generally, what kind of commands executed in one MATLAB instance can affect the other instance？
3. What if I am running only one instance of MATLAB, but invoke a parfor loop with two loops running in parallel? Does the execution of addpath/rmpath/savepath in one loop affect the other loop, sooner or later? In general, what kind of commands executed in one parallel loop can affect the other loop? (As pointed out by #Edric, this can be complicated; so let us not worry about it. Thank you, #Edric.)
Thank you very much for any comments and insights. It would be much appreciated if you could direct me to relevant sections in the official documentation of MATLAB --- I did some searching in the documentation, but have not found an answer to my question.
BTW, in case you find that the test described in the pseudo code is conducted in a wrong/bad manner, I will be very grateful if you could recommend a better way of doing it.
The documentation page for the MATLAB Search Path specifies at the bottom:
When you change the search path, MATLAB uses it in the current session, but does not update pathdef.m. To use the modified search path in the current and future sessions, save the changes using savepath or the Save button in the Set Path dialog box. This updates pathdef.m.
So, standard MATLAB sessions are "isolated" in terms of their MATLAB Search Path unless you use savepath. After a call to savepath, new MATLAB sessions will read the updated pathdef.m on startup.
The situation with a parallel pool is slightly more complex. There are a couple of things that affect this. First is the parameter AutoAddClientPath that you can specify for the parpool command. When true, an attempt is made to reflect the desktop MATLAB's path on the workers. (This might not work if the workers cannot access the same folders).
When a parallel pool is running, any changes to the path on the desktop MATLAB client are sent to the workers, so they can attempt to add or remove path entries. Parallel pool workers calling addpath or rmpath do so in isolation. (I'm afraid I can't find a documentation reference for this).
For the use case of being able to abort parallel simulations with a MATLAB GUI, I would like to stop all scheduled simulations after the user pressed the Stop button.
All simulations are submitted at once using the parsim command, hence something like a callback to my GUI variables (App Designer) would be the most preferable solution.
Approaches I have considered but were not exactly providing a desirable solution:
The Simulation Manager provides the functionality to close simulations using its own interface. If I only had the code its Stop button executes...
parsim uses the Simulink.SimulationInput class as input to run simulations, allowing to modify the preSimFcn at the beginning of each simulation. I have not found a way to "skip" the simulation at its initialization phase apart from intentionally throwing an error so far.
Thank you for your help!
Update 1: Using the preSimFcn to set the the termination time equal to the start time drastically reduces simulation time. But since the first step still is computed there has to be a better solution.
simin = simin.setModelParameter('StopTime',get_param(mdl,'StartTime'))
Update 2: Intentionally throwing an error executing the preSimFcn, for example by setting it to
simin = simin.setModelParameter('SimulationCommand','stop')
provides the shortest termination times for me so far. Though, it requires catching and identifying the error in the ErrorMessageof the Simulink.SimulationOutput object. As this is exactly the "ugly" implementation I wanted to avoid, the issue is still active.
If you are using 17b or later, parsim provides an option to 'RunInBackground'. It returns an array of Future objects.
F = parsim(in, 'RunInBackground', 'on')
Please note that is only available for parallel simulations. The Simulink.Simulation.Future object F provides a cancel method which will terminate the simulation. You can use the fetchOutputs methods to fetch the output from the simulation.
F.cancel();
Is there a way to limit the amount of time an evaluation is allowed to run? Or limit the amount of memory that MatLab is allowed to take up so it doesn't freeze my laptop?
Let's answer your questions one at a time:
Question #1 - Can I limit the amount of time MATLAB takes to execute a script?
As far as I know, this is not possible. If you want to do this, you would need a multi-threaded environment where one thread does the actual job while another thread keeps an eye on the timer... but even with that functionality, AFAIK, MATLAB does not have this supported. The only way to stop your script from running is if you punch Ctrl + C / Cmd + C. Depending on what is actually being executed... for example a MEX script or a LAPACK routine, or just a simple MATLAB script, it may work by just pushing it once... or you may have to mash the sequence like a maniac.
(Note: The above image was introduced to try and be funny. If you don't know where that image is from, it's from the movie Flashdance and one of the songs from the soundtrack is She's a maniac, where I've also provided a YouTube link to the song above.)
See this post for more details: How can I interrupt MATLAB when it gets really really busy?
Question #2 - Can we limit the amount of memory that MATLAB uses?
Yes you can. From what I have seen in your posts, you're using Windows. You can change this by changing the page size of the virtual memory that is used for your computer. Specifically, instead of allowing it to grow dynamically, you could set it to be a certain size and once MATLAB exhausts that, it'll give you an out-of-memory error rather than freezing your computer.
See this post from MathWorks forums for more insight:
http://www.mathworks.com/matlabcentral/answers/12695-put-a-limit-on-memory-matlab-uses
Also see this guide from MathWorks on how to handle out-of-memory errors:
http://www.mathworks.com/help/matlab/matlab_prog/resolving-out-of-memory-errors.html
Finally, take a look at this link on how to change / modify the page size of your computer via Windows:
http://windows.microsoft.com/en-ca/windows/change-virtual-memory-size#1TC=windows-7
I have a question about inner Matlab error management. Right now I have quite a large program with a lot of variables and functions that cumulated over my code writting and I'm 100 percent sure that I did not catch all the bugs and mistakes in the program and I don't want it to crash completely when is used by layman user. So, is there a way to display errordlg message and for example restart the program when there will be any given error directly by Matlab (for example when I forgot to declare a global variable etc.)?
Thanks for answers, Peter
Crashes are good, because they force users to report bugs.
If you don't want to go that route, Matlab provides try-catch: wrap your code in a try-catch block. If there is an error, you'll find yourself in the catch block where you can have Matlab send you an email with the error message, and restart the program if necessary.
You can use try/catch statements to respond to errors in your program. There's more information here.
Do the risks caused by bypassing Perl safe signals for example like shown in the second timeout example in the DBI documentation concern only the code that uses such bypassing?
The code in that example works hard to localize the change to just that section of code, or any code called from it.
There is not 100% guarantee that no code will be effected outside the code that bypasses safe signals, because signals are no longer safe. In the example the call being timed out is a DBI->connect. For most DBD's this will be implemented mostly in C, unless the C code can handle being aborted and tried again you might find that some data structures internal to the DBD, or the libraries it uses, are left in a inconstant state.
The chances of the example code going wrong is probably incredibly tiny. My personal anecdote on the issues is that I had used the traditional Perl signal handling for years before safe signals were introduced and for a long time I had never had a problem. I hadn't even been very cautious about what I did in my signal handlers. Then we managed to hit a data set that actually did trigger memory corruptions in about 1 out of ever 100 runs. Just modifying the signal handlers to use better practices, similar to those in the example, eliminated our issues.
What does that even mean? By using unsafe signals, you can corrupt Perl's internals and Perl variables. It can also cause problem if a non-reentrant C library call is interrupted.
This can lead to SEGFAULTs and other problems, and those may only manifest themselves outside the block where the timeout is in effect.