I am using matlab to automatically parameter and launch a finite element method code. I write a parameter text file that the FEM code will read, and then call for the FEM code with :
[status,cmdout]=system(['FEMApp ' current_folder '\MyFile']);
Sometimes, the FEM App will be unable to complete its task, and send an error message in the command window. Until now, I was able to detect the error message in cmdout, and proceed to the next paramter set.
For an unknown reason, the system command started to behave differently : it gets stuck for seemingly forever (Matlab is always in "busy" mode). Did I change anything without realizing it ?
For now, I am using the following solution :
[status,cmdout]=system(['FEMApp ' current_folder '\MyFile &']);
pause(45)
system(['taskkill' 'FEMProcessus')
It works correctly, but it slows my computation a lot (~ x5), because Matlab will always wait 45 secondes even when the task is completed in much less time.
Can anyone explain the change in behaviour of Matlab ?
Does anyone has a cleverer work around than mine ?
It should be noted that Matlab is an interpreter rather than a compiler. That means it performs a lot of internal operations, hidden from the developer, some of which may require a lot of CPU resources. Finite Element applications are very numerically intense in terms of using CPU and RAM resources. It might not be a good idea to use Matlab for FEM programming. Try to use some numerically-oriented language, like C or Fortran, where you will have full control over memory allocation and arithmetic operations.
Related
It is very easy to hang entire system with Matlab. It is sufficient to run any operations on very large matrices to do this.
In hang situation Matlab is apparently neither give the system to work and nor works itself. I.e. this "operation mode" is completely useless and harmful.
Is it possible to disable Matlab from jumping over it's head? Is it possible to disable/minimize swapping or something?
It would be much better if Matlab just fail to complete an operation than if it is simulating some work which is not true.
This guide outlines a few strategies that you can put to use
http://in.mathworks.com/help/matlab/matlab_prog/resolving-out-of-memory-errors.html
I run a pretty computationally expensive genetic algorithm with MATLAB. The code has been running for 3 whole days, and I am pretty sure it gets stuck somewhere, because it is not printing out the progress information for debugging purpose.
I now wish to stop it. I did CTRL+C, but no luck. The bottom left of the window still displays "Busy".
I cannot simply quit the whole MATLAB, because I need to find out where it gets stuck by inspecting the variables in the variable window.
Given the CTRL+C is not working, how can I
stop the execution, OR
save the variables for inspection purpose?
Sometimes ctrl-C stops working if you have a memory over-allocation problem -- if you are trying to allocate a matrix that doesn't fit in memory, and so virtual memory begins thrashing.
It's also likely that crtl-C won't work while execution is passed to COMSOL.
I think you have little choice now but to kill matlab and try to debug by either stepping through the code or inserting fprintf statements.
How compatible are Matlab and .EXE files? Is it possible to make win32 APIs send messages to matlab and for matlab to read them in real time?
More precisely can I make Matlab to receive and handle messages from another application at real time?
When I am handling such messages, I also have a concern with the type of loop I would have to use in Matlab. Is an infinite for/while loop a good practice?
for example
while(infinite loop)
if (received message)
do something
end
end
Note, above is algorithm only, not intended as code.
The first part of your question: the Matlab Engine seems to be what you are after.
The second part of your question: in many coding standards, it's often recommended to avoid infinite loops. The problem with infinite loops is, well, that they may never end :) It's all too easy to incorrectly or incompletely code the exit condition(s), causing your loop to never end and the program's execution to stall. This sort of bug can pop up in unit testing (often-failing exit condition), or only after the first batch of your customers start complaining about your program crashing (not-so-often failing exit condition). These (and many other) pitfalls of infinite loops are often avoidable by
translating the infinite loop to a finite one
setting a maximum on the amount of iterations
using a whole different paradigm altogether.
With IPC, where part of the program is listening to messages from other parts of the program or other programs alltogether, the last option is best. Using an event based approach prevents an infinite loop. MATLAB supports this in the form of events and listeners. This is part of OOP in MATLAB, so you'd have to have followed OOP already, or convert everything you have to OOP in order to use it.
I have built an standalone Matlab application. I was expecting it to be faster than running the application from the Matlab environent but it is indeed a bit slower (1.3 seg per iteration vs 1.5 seg per iteration)
I am not counting the init time required by MCR but the execution of my code.
Is that the expected performance or should I be obtaining a performance improvement?
I haven't found any settings on the deployment tool that could help to reduce execution time.
Thanks in advance
Applications built with MATLAB Compiler should execute at pretty much exactly the same speed as within MATLAB.
MATLAB Compiler does not convert your MATLAB code into machine code in the same way as a C compiler does for C. What it does is to archive and encrypt your MATLAB code (note, it properly encrypts it, not just pcodes it as a comment suggests), create a thin executable wrapper and package them together, possibly also with MATLAB Compiler Runtime (MCR). MCR is very similar to MATLAB itself, without a graphical user interface, and is freely redistibutable.
When you run the executable, it dearchives and decrypts your MATLAB code and runs it against the MCR. It should run exactly the same, both in terms of results and speed.
Very old versions of MATLAB Compiler (pre-version 4.0) worked in a different way, converting a subset of the MATLAB language into C code, and compiling this. This provided a potentially significant speed-up, but only a subset of the language was supported and results, unless you were careful, could sometimes be different. Similar functionality is now available in the separate MATLAB Coder product.
There are a few small things you can do to improve performance: for example, within deploytool you can specify which toolboxes your application uses. deploytool uses a dependency checker to package up all MATLAB functionality that it thinks your code might possibly depend on, but it can't always tell exactly, as the functions your code needs might change at runtime. It therefore errs on the side of caution and includes more than necessary. By specifying only the toolboxes you know to be necessary, you can speed things up a little (it also speeds up the build process quite a bit).
I am working on a time series based calculation. Each iteration of the calculation is independent. Could anyone share some tips / online primers on using utilising parallel processing in Matlab? How can this be specified inside the actual code?
Since you have access to the Parallel toolbox, I suggest that you first check whether you can do it the easy way.
Basically, instead of writing
for i=1:lots
out(:,i)=do(something);
end
You write
parfor i=1:lots
out(:,i)=do(something);
end
Then, you use matlabpool to create a number of workers (you can have a maximum of 8 on your local machine with the toolbox, and tons on a remote cluster if you also have a Distributed Computing Server license), and you run the code, and see nice speed gains when your iterations are run by 8 cores instead of one.
Even though the parfor route is the easiest, it may not work right out of the box, since you might do your indexing wrong, or you may be referencing an array in a problematic way etc. Look at the mlint warnings in the editor, read the documentation, and rely on good old trial and error, and you should figure it out reasonably fast. If you have nested loops, it's often best parallelize only the innermost one and ensure it does tons of iterations - this is not only good design, it also reduces the amount of code that could give you trouble.
Note that especially if you run the code on a local machine, you may run into memory issues (which might manifest in really slow execution in parallel mode because you're paging): Every worker gets a copy of the workspace, so if your calculation involves creating a 500MB array, 8 workers will need a total 4GB of RAM - and then you haven't even started counting the RAM of the parent process! In addition, it can be good to only use N-1 cores on your machine, so that there is still one core left for other processes that may run on the computer (such as a mandatory antivirus...).
Mathworks offers its own parallel computing toolbox. If you do not want to purchase that, there a few options
You could write your own mex file and use pthreads or OpenMP.
However make sure you do not call any Mex api in the parallel part of the code, because they arent thread safe
If you want coarser grained parallelism via MPI you can try pmatlab
Same with parmatlab
Edit: Adding link Parallel MATLAB with openmp mex files
I have only tried the first.
Don't forget that many Matlab functions are already multithreaded. By careful programming you may be able to take advantage of them -- check the documentation for your version as the Mathworks seem to be increasing the range and number of multithreaded functions with each new release. For example, it seems that 2010a has multithreaded ffts which may be useful for time series processing.
If the intrinsic multithreading is not what you need, then as #srean suggests, the Parallel Computing Toolbox is available. For my money (or rather, my employers' money) it's the way to go, allowing you to program in parallel in Matlab, rather than having to bolt things on. I have to admit, too, that I'm quite impressed by the toolbox and the facilities it offers.