Back to the main page.
Bug 1254 - Error when running compiled qsub job
| Status | CLOSED FIXED |
| Reported | 2012-01-12 14:10:00 +0100 |
| Modified | 2012-04-11 16:48:34 +0200 |
| Product: | FieldTrip |
| Component: | qsub |
| Version: | unspecified |
| Hardware: | Other |
| Operating System: | Linux |
| Importance: | P3 blocker |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Niels Kloosterman - 2012-01-12 14:10:22 +0100
Dear Robert, Great that you started mcc compiler support! When compiling and running the job I get the following error from the qsub system. I looked it up at the Matlab site, where they have an entry that says it was a bug in a previous version of (2006b), which in the current version should be fixed (http://www.mathworks.nl/support/solutions/en/data/1-1TOBND/index.html?product=CO). Looks like the bug is still there... Can it be solved? started compiling niels_login4_p31939_b1 finished compiling submitting job niels_login4_p31939_b1_j001... qstat job id 5873120.batch1.irc.sara.nl Error in ==> qsubexec at 38 ??? Output argument "argout" (and maybe others) not assigned during call to "/home/niels/.mcrCache7.15/niels_3/home/niels/matlab/fieldtrip/qsub/qsubexec.m>qsubexec". MATLAB:unassignedOutputs Best, Niels
Robert Oostenveld - 2012-01-12 16:27:19 +0100
Hi Niels, Nice you noticed this recent and still rather experimental addition to the code. I must admit that I only tested it with "rand" and only with backend=local, so not even yet on our torque cluster. Does the problem only occur if you use compile=yes (versus compile=no)? The error is caught at line 38, which is the "try" in qsubfeval. It suggests that [argout, optout] = fexec(argin, optin); is causing the error, i.e. the error happens inside qsub/private/fexec. However, that function has argout = {}; optout = {}; before it starts with its large try-catch loop. So the output args of fexec should exist, even if it errors in the try-catch loop. I suggest that you disable line 45 in qsubexec with delete(inputfile). Then rerun qsubcellfun (with compile=yes) and then you should be able to run the command line executable and/or qsubexec multiple times for more detailed debugging, as the input.mat file will remain. Please try whether the command line as constructed in qsubexec works on the local command line and when you echo it to qsub.
Robert Oostenveld - 2012-01-12 20:28:44 +0100
I just tried it on our torque cluster, and can confirm the problem you reported.
Robert Oostenveld - 2012-01-13 09:04:33 +0100
I have identified the problem: there is a superfluous \n in the sprintf statements for the linux command (in qsubfeval).
Robert Oostenveld - 2012-01-13 10:44:00 +0100
there was another problem with the present working directory and not being able to find the input.mat file when not working in the homedir. I have fixed the known problems and made some additional improvements. The most significant is that I implemented a separate qsubcompile function (as per Marcel's suggestion) that allows more control over the compilation and re-use of the compiled function. roboos@mentat001> svn commit Sending qsub/private/fexec.m Adding qsub/private/getbatch.m Sending qsub/qsubcellfun.m Adding qsub/qsubcompile.m Sending qsub/qsubexec.m Sending qsub/qsubfeval.m Transmitting file data ...... Committed revision 5136. At the moment the only known issue is that stacking and compilation are not yet compatible with each other. See bug 1255 @Niels, please let me know if it works for you.
Niels Kloosterman - 2012-01-13 12:25:26 +0100
(In reply to comment #4) Hey Robert, I have tried it both with compiling the job on the fly in qsubcellfun, and using qsubcompile. Both do not work, it seems not to be able to find a compiled m-file in the CTF archive. But the file seems to be present in the archive when I look for it with the terminal. I did include the ~isdeployed if end statement in my startup. I use stack = 1. Cheers, Niels Ps also note the qsubget error. This also occurs sometimes when I don't compile. Not sure what this is about. K>> compiledfun = qsubcompile(@MIBexp_preproc); compiling MIBexp_preproc into niels_login3_p32586_b1 finished compiling K>> qsubcellfun(compiledfun, cfg1, cfg2, cfg3, outputfile, 'memreq', 1024^3, 'timreq', timreq*60, 'stack', stack, 'StopOnError', true); submitting job niels_login3_p32586_b2_j001... qstat job id 5874725.batch1.irc.sara.nl The file '/home/niels/matlab/MEG_analysis/preprocessing/MIBexp_preproc.m' is not in the application's expanded CTF archive at '/home/niels/.mcrCache7.15/niels_7'. This is typically caused by calls to ADDPATH in your startup.m or matlabrc.m files. Please see the compiler documentation and use the ISDEPLOYED function to ensure ADDPATH commands are not executed by deployed applications. Warning: cleaning up all scheduled and running jobs, don't worry if you see warnings from "qdel" > In qsublist at 107 In qsubcellfun>cleanupfun at 421 In onCleanup>onCleanup.delete at 61 In MIBexp_preproc_peersetup at 93 In runMIBmeg_analysis at 59 qdel: Unknown Job Id 5874725.batch1.irc.sara.nl qdel 5874725.batch1.irc.sara.nl: Signal 25 ??? Error using ==> qsubget at 75 the batch queue system returned an error for job niels_login3_p32586_b2_j001, now aborting Error in ==> qsubcellfun at 313 [argout, options] = qsubget(jobid{collect}, 'output', 'cell', 'diary', diary, 'StopOnError', StopOnError);
Robert Oostenveld - 2012-01-13 16:28:04 +0100
(In reply to comment #5) Could you try with a really simple function, like "rand"? The message > This is typically caused by calls to ADDPATH in your startup.m or matlabrc.m > files. Please see the compiler documentation and use the ISDEPLOYED function to > ensure ADDPATH commands are not executed by deployed applications seems to be relevant to me. That suggests it is a compilation problem, not a qsub problem. Did you look at the relevant documentation (see also the help in qsubcompile)? A good test would be to do !mv ~/matlab/startup.m ~/matlab/startup.bak % or whatever which startup returns restroredefaultpath ccompiledfun = qsubcompile('rand'); qsubcellfun(compiledfun, {1, 2, 3}, ...)
Robert Oostenveld - 2012-01-13 16:30:21 +0100
(In reply to comment #5) note that you might also want to check the compilation in general, e.g. make a function function test_mcc fprintf('----------------------\n') disp(rand(1)); disp(rand(2)); disp(rand(3)); fprintf('----------------------\n') and then do mcc test_mcc and subsequently from the linux command line run_test_mcc.sh
Robert Oostenveld - 2012-01-18 12:42:15 +0100
(In reply to comment #7) @Niels: can you give me an update?
Niels Kloosterman - 2012-01-18 13:08:27 +0100
(In reply to comment #8) Hey Robert, Your check from comment 7 works, so the compiler is configured properly on the cluster. But the other check: !mv ~/matlab/startup.m ~/matlab/startup.bak % or whatever which startup returns restoredefaultpath compiledfun = qsubcompile('rand'); qsubcellfun(compiledfun, {1, 2, 3}, 'memreq', 1024^3, 'timreq', 60) ... does not work. Compiling does work, but submitting the job goes wrong: >> qsubcellfun(compiledfun, {1, 2, 3}, 'memreq', 1024^3, 'timreq', 60) compiling rand into niels_login4_p30183_b1 finished compiling stacking 3 matlab jobs in each qsub job ??? Error using ==> nargout Argument must be either a string or a function handle. Error in ==> qsubcellfun at 169 numargout = nargout(varargin{1}{1}); Error in ==> qsubcellfun at 237 [stackargout{:}] = qsubcellfun(@cellfun, stackargin{:}, optarg{:}); Let me know if you need me to run other checks. Cheers Niels
Robert Oostenveld - 2012-01-20 09:49:51 +0100
(In reply to comment #9) It is probably due to the (automatic) stacking. See bug 1255 Can you try with stack=1? I will change the core around line 140 in qsubcellfun into % determine the number of MATLAB jobs to "stack" together into seperate qsub jobs if isequal(stack, 'auto') if strcmp(compile, 'yes') || strcmp(compile, 'auto') || ~isempty(fcomp) % compilation and stacking are incompatible with each other % see http://bugzilla.fcdonders.nl/show_bug.cgi?id=1255 stack = 1; elseif ~isempty(timreq) stack = floor(180/timreq); else stack = 1; end end to deal with the default stack=auto.
Niels Kloosterman - 2012-01-20 11:03:45 +0100
(In reply to comment #10) It works now, see below for output. Note that I did not update ft yet. Note the warning about DBSTOP though, even though I didn't set any breakpoints. I guess the problem is in compiling more complicated, nested scripts? compiledfun = qsubcompile('rand'); qsubcellfun(compiledfun, {1, 2, 3}, 'memreq', 1024^3, 'timreq', 60, 'stack', 1) compiling rand into niels_login3_p24487_b1 Warning: Duplicate directory name: /scratch/../home/niels/matlab/fieldtrip/qsub. finished compiling submitting job niels_login3_p24487_b2_j001... qstat job id ------------------------------------------ Setting up environment variables --- LD_LIBRARY_PATH is .:/sara/sw/matlab/64/2011a/runtime/glnxa64:/sara/sw/matlab/64/2011a/bin/glnxa64:/sara/sw/matlab/64/2011a/sys/os/glnxa64:/sara/sw/matlab/64/2011a/sys/java/jre/glnxa64/jre/lib/amd64/native_threads:/sara/sw/matlab/64/2011a/sys/java/jre/glnxa64/jre/lib/amd64/server:/sara/sw/matlab/64/2011a/sys/java/jre/glnxa64/jre/lib/amd64/client:/sara/sw/matlab/64/2011a/sys/java/jre/glnxa64/jre/lib/amd64 executing job took 0.313287 seconds and 1056768 bytes submitting job niels_login3_p24487_b2_j002... qstat job id ------------------------------------------ Setting up environment variables --- LD_LIBRARY_PATH is .:/sara/sw/matlab/64/2011a/runtime/glnxa64:/sara/sw/matlab/64/2011a/bin/glnxa64:/sara/sw/matlab/64/2011a/sys/os/glnxa64:/sara/sw/matlab/64/2011a/sys/java/jre/glnxa64/jre/lib/amd64/native_threads:/sara/sw/matlab/64/2011a/sys/java/jre/glnxa64/jre/lib/amd64/server:/sara/sw/matlab/64/2011a/sys/java/jre/glnxa64/jre/lib/amd64/client:/sara/sw/matlab/64/2011a/sys/java/jre/glnxa64/jre/lib/amd64 executing job took 0.046488 seconds and 1052672 bytes submitting job niels_login3_p24487_b2_j003... qstat job id ------------------------------------------ Setting up environment variables --- LD_LIBRARY_PATH is .:/sara/sw/matlab/64/2011a/runtime/glnxa64:/sara/sw/matlab/64/2011a/bin/glnxa64:/sara/sw/matlab/64/2011a/sys/os/glnxa64:/sara/sw/matlab/64/2011a/sys/java/jre/glnxa64/jre/lib/amd64/native_threads:/sara/sw/matlab/64/2011a/sys/java/jre/glnxa64/jre/lib/amd64/server:/sara/sw/matlab/64/2011a/sys/java/jre/glnxa64/jre/lib/amd64/client:/sara/sw/matlab/64/2011a/sys/java/jre/glnxa64/jre/lib/amd64 executing job took 0.042464 seconds and 1052672 bytes job niels_login3_p24487_b2_j001 returned, it required 0 seconds and 1.0 MB Warning: The DBSTOP function cannot be used in compiled applications. > In qsubget at 151 In qsubcellfun at 313 job niels_login3_p24487_b2_j002 returned, it required 0 seconds and 1.0 MB Warning: The DBSTOP function cannot be used in compiled applications. > In qsubget at 151 In qsubcellfun at 313 job niels_login3_p24487_b2_j003 returned, it required 0 seconds and 1.0 MB Warning: The DBSTOP function cannot be used in compiled applications. > In qsubget at 151 In qsubcellfun at 313 computational time = 0.4 sec, elapsed = 69.3 sec, speedup 0.0 x Warning: copying the jobs over the network took more time than their execution > In qsubcellfun at 359 ans = [0.3797] [2x2 double] [3x3 double] >>
Robert Oostenveld - 2012-01-20 11:46:51 +0100
(In reply to comment #11) The update about stack with compile has just now been committed manzana> svn commit Sending qsub/qsubcellfun.m Transmitting file data . Committed revision 5156.
Robert Oostenveld - 2012-01-20 11:53:12 +0100
(In reply to comment #11) > It works now, see below for output. Note that I did not update ft yet. Note the > warning about DBSTOP though, even though I didn't set any breakpoints. > > I guess the problem is in compiling more complicated, nested scripts? I have no idea where the dbstop comes from, although don't think it is a problem. It is not in my version of qsub. Might it be that you have a local change in your copy. Please keep an eye on it and see whether it is still there after an update to the latest release version. Compiling more elaborate functions (note that scripts should not be used here) is indeed more challenging, although also with those I now have some positive experience. But my impression is that the first hurdle in compiling a simple MATLAB function is actually the largest and that subsequently it is more manageable (although in the more elaborate nested functions there are more chances of using syntax that is incompatible with compiling). In case of using feval with sprintf you should use the following "pragma" statement %#function whatever to ensure that the "whatever" function also gets compiled into the exe. I suspect that we'll have to open a FAQ on this...
Niels Kloosterman - 2012-01-20 14:06:15 +0100
(In reply to comment #13) I suspect that we'll have to open a FAQ on this... -Yes, it would be great to have a list of do's and don'ts when you want to compile your functions. From my side it is worth investing some effort in this feature, since I only have a limited amount of matlab licenses available, and lots of data ;) This probably goes for other users. I will continue to play around and let you know if I run into issues. Let me know if you make changes or you require beta testing. Cheers, Niels
Robert Oostenveld - 2012-01-20 14:40:48 +0100
(In reply to comment #14) I have made a first version of the FAQ, see http://fieldtrip.fcdonders.nl/faq/how_to_compile_matlab_code_into_stand-alone_executables Please add all information to it that you consider to be potentially relevant and that you discover while using the compiled qsub distribution. best Robert
Niels Kloosterman - 2012-01-26 10:55:48 +0100
(In reply to comment #15) Hey Robert, So we know the compiler and qsubcompile routines work. But I am still having trouble executing a compiled program, because the compiled program can't find the expanded CTF archive. After successfully compiling and submitting the program I get this error: >> runMIBmeg_analysis compiling MIBexp_preproc into niels_login3_p13349_b1 finished compiling submitting job niels_login3_p13349_b2_j001... qstat job id 5900513.batch1.irc.sara.nl The file '/home/niels/matlab/MEG_analysis/preprocessing/MIBexp_preproc.m' is not in the application's expanded CTF archive at '/home/niels/.mcrCache7.15/niels_17'. This is typically caused by calls to ADDPATH in your startup.m or matlabrc.m files. Please see the compiler documentation and use the ISDEPLOYED function to ensure ADDPATH commands are not executed by deployed applications. MIBexp_preproc is a simple function that calls the ft functions I use for preprocessing. I use the isdeployed function in startup, so that's not it. It seems like extraction of this CTF archive goes wrong, since the compiled MIBexp_preproc.m indeed is present in the path specified by this error message. In the mcc compiler online help it says CTF data is "extracted automatically to user_name\AppData\Local\Temp\userid\mcrCachen.nn by default". I can't find this file. Do you have any idea what's going on? Best, Niels
Robert Oostenveld - 2012-01-26 11:27:06 +0100
(In reply to comment #16) I suggest we follow up on this discussion outside bugzilla and keep the bug closed. It is not sure whether it is a bug in the FT qsub code, a general user configuration error (e.g. path being set incorrectly), or a problem with the particular piece of code that you try to distribute. Item 1 would be appropriate to address here, item 2 would require documentation improvements, item 3 is not neccessary a FT problem (depends on whether the particular piece of code is from FT or not).
Niels Kloosterman - 2012-01-26 11:50:30 +0100
(In reply to comment #17) Right. I tried now with a simple ft function cfg=[]; cfg.dataset = 'datafile.fif'; compiledfun = qsubcompile('ft_preprocessing'); qsubcellfun(compiledfun, {cfg}, 'memreq', 1024^3, 'timreq', 1) and I get the same error message, so it's not item 3. Please let me know how and where to continue this discussion. -N
Robert Oostenveld - 2012-01-26 23:31:25 +0100
(In reply to comment #18) I can reproduce the error with ft_preprocessing, but also with ft_channelselection.m The file '/Users/robert/matlab/fieldtrip-trunk/ft_channelselection.m' is not in the application's expanded CTF archive at '/Users/robert/.mcrCache7.16/robert5'. This is typically caused by calls to ADDPATH in your startup.m or matlabrc.m files and even with fieldtrip/utilities/istrue, which is a really simple function that only does a few sting comparisons and does not depend on other FT stuff. Looking in the CTF archive, every time I do see that the indicated function is present, including the other functions on which it seems to depend. So the error is confusing. I tried disabling the addpath in ft_defaults, but that did not solve it I tried disabling the path adjustment in qsubexec->feval->setcustompath, and that does seem to make a difference. Can you please try changing it into the following and try whether it also solves the problem on your side? After the change below, I was able to do compiledfun = qsubcompile('istrue'); value = qsubcellfun(compiledfun, {'yes'}, 'memreq', 1024^3, 'timreq', 300); ----- function setcustompath(option_path) % SUBFUNCTION that changes the path % these are for remembering the path on subsequent calls with the same input arguments persistent previous_argin previous_path % the following pertains to path settings, which does not apply in case % this code is included in a compiled MATLAB application if ~isdeployed if isequal(previous_argin, option_path) && isequal(previous_path, path) % no reason to change the path again return end if ~isempty(option_path) f = mfilename('fullpath'); % this is .../peer/private/getcustompath.m f = fileparts(f); % this is .../peer/private f = fileparts(f); % this is .../peer [p, d] = getcustompath; % ensure that the default path is maintained path(d); % add the custom path path(option_path, path); % ensure that the peer functions are maintained on the path path(f, path); end % remember the current settings for the next call previous_argin = option_path; previous_path = path; end ----- P.S. Not causing this particular problem, but nevertheless a bug is that with backend=local and when starting the compilation from a directory different from the homedir, it cannot find the correct xxx_input.mat file. For torque and sge the pwd path is passed along on the linux command line, but for local execution not (yet). For the time being, please try to get it working for a job in your home directory, and not while being in another directory.
Niels Kloosterman - 2012-01-27 11:33:47 +0100
(In reply to comment #19) I found setcustompath in qsubexec->fexec, not feval. I guess that was what you mean. I made the changes and was able to run the simple ft_preprocessing command: >>cfg=[]; % simple test >>cfg.dataset='/home/niels/MIBeeg/DummyData/DummyRecording_01.vhdr'; >>compiledfun = qsubcompile('ft_preprocessing'); >>data = qsubcellfun(compiledfun, {cfg}, 'memreq', 1024^3, 'timreq', 3, 'backend', 'torque'); compiling ft_preprocessing into niels_login3_p13349_b1 finished compiling submitting job niels_login3_p13349_b2_j001... qstat job id 5903504.batch1.irc.sara.nl job niels_login3_p13349_b2_j001 returned, it required 6 seconds and 49.6 MB computational time = 5.7 sec, elapsed = 116.5 sec, speedup 0.0 x It worked both with backend local and torque (output shown here for torque). I ran it from my home directory. I couldn't find an output log after running it (with local it prints a whole lot of execution messages and the ft output, all successful), that would be useful to have at some point to check if ft did the right thing. I will try now with my own scripts and real data on torque, and let you know if that too works. -N ps the data output comes out as a cell array. I have to use cell2mat to convert to struct. is this normal when using output variables? I always save output files within my functions so I never use output variables.
Niels Kloosterman - 2012-01-27 12:00:42 +0100
(In reply to comment #20) There is one issue with the trialfun when using compiled preprocessing. The trialfun is not compiled, presumably because it only gets evaluated at runtime. Error using ==> ft_definetrial at 147 cannot locate the specified trialfun (sortTrials_MIBexperiment)
Robert Oostenveld - 2012-01-27 12:14:59 +0100
Good that the problem is now pinned down. (In reply to comment #20) regarding the cell-array output. The handling of the outputs and whether outputs should be handed back or not (e.g. not in case you use cfg.outputfile) should indeed be improved. At the moment the number of output arguments is determined by looking at the function to be executed, not by looking at the number thaht is requested by the user from qsubcellfun. I will file this as separate bug. (In reply to comment #21) regarding the trialfun: at compile time MATLAB does not know the name of the function, because it fevals a string that will be in the cfg at a later time. This raises the issue that it should be made possible to explicitely include m-files that MATLAB might not be able to find.
Robert Oostenveld - 2012-02-04 10:23:26 +0100
(In reply to comment #22) qsubcompile now allows dependencies to be passed, e.g. fcomp = qsubcompile({@ft_definetrial, @trialfun_custom}) mbp> svn commit Sending qsub/qsubcellfun.m Sending qsub/qsubcompile.m Transmitting file data .. Committed revision 5236. The cell-array aspect in comment #22 has not yet been addressed.
Niels Kloosterman - 2012-02-06 12:58:29 +0100
(In reply to comment #23) Hey Robert, I tested this new feature with backend= 'local' and my trialfun is indeed succesfully included in the compiled program. But the next problem is the signal processing toolbox that MATLAB cannot find. It gives a large number of warnings like this: Warning: cannot change path settings for /home/niels/.mcrCache7.15/niels_4/home/niels/matlab/fieldtrip/template/layout in a compiled application > In ft_hastoolbox>myaddpath at 371 In ft_hastoolbox at 305 In ft_defaults at 79 In ft_artifact_zvalue at 99 In MIBexp_artefact_muscle at 30 In MIBexp_preproc at 33 In qsub/private/fexec at 137 In qsubexec at 50 Finally it produces this: searching for artifacts in 204 channels searching trials.Reading 74280 ... 79030 = 59.424 ... 63.224 secs... [done] Undefined function or method 'hilbert' for input arguments of type 'double'. Error in ==> ft_preproc_hilbert at 52 Error in ==> preproc at 367 Error in ==> ft_artifact_zvalue at 199 Error in ==> MIBexp_artefact_muscle at 30 Error in ==> MIBexp_preproc at 33 Error in ==> fexec at 137 Error in ==> qsubexec at 50 So it seems hilbert (part of the signal processing toolbox, right?) is not included in the compiled program... Should it also be specifically included at compilation? Best, -N
Robert Oostenveld - 2012-02-08 11:46:08 +0100
(In reply to comment #24) I am at the FIL in London, discussing stuff with the SPM guys. Guillaume mentioned that his experience with the MATLAB compiler is that it not very robust in detecting dependencies and that sometimes it forgets to put a function in the executable package. That is consistent with your problem, i.e. MATLAB forgot to include hilbert. Possible solution: use depfun to figure out all dependencies before passing it onto qsubcompile. If that works, it can also be done inside qsubcompile. Could you try depfun('yourfunction') and then do something with the output to change it into a cell-array and then pass it along with your own function to qsubcompile?
Niels Kloosterman - 2012-02-08 14:20:57 +0100
(In reply to comment #25) I have found it out already with the mcc help. When calling mcc in qsubcellfun you have to use the '-p' with the toolbox dir to specifically include it after clearing the path with '-N'. So I changed it to: mcc('-N', '-p', '/sara/sw/matlab/64/2011a/toolbox/signal', '-p', '/sara/sw/matlab/64/2011a/toolbox/stats', '-R', '-nodisplay', '-o', batchid, '-m', 'qsubexec', 'cellfun', fname, fdeps{:}); When I did depfun('MIBexp_preproc') I noticed the stats toolbox was also required in my own preprocessing function (probably for z-transforming during artifact rejection) so I also included this too. It works now. So qsubcellfun needs to figure out which toolboxes are required by the the to be compiled function and pass them on to the mcc command. Will now try it out with my freqanalysis and let you know if it works.
Niels Kloosterman - 2012-02-08 15:40:34 +0100
(In reply to comment #26) With my freqanalysis function it also works. Great!
Robert Oostenveld - 2012-02-10 16:21:54 +0100
(In reply to comment #27) Good. This relates to bug 1114 and bug 1104, which pertain to the dependencies. Finding all dependencies with depfun takes ages. Nevertheless, we have to improve the detection. There is a test_bug1014 script that detects compats. Along that line we can make a script that determined which toolboxes are used where.
Robert Oostenveld - 2012-03-11 11:12:16 +0100
Another solution instead of using depfun to find the dependencies is to have the user specify the toolboxes. It is not as user-friendly for the novice, but much faster for the expert. I have added some code and the following documentation % toolbox = string or cell-array with strings, non-standard % Mathworks toolboxes to include (see below). ... % If you need to include Mathworks toolboxes that are not automatically % detected as dependencies by the MATLAB compiler, you can specify them % likt this % compiledfun = qsubcompile(fname, 'toolbox', {'signal', 'image', 'stats'}) The toolbox path is detected by looking for signal/Contents.m, i.e. the contents file that Mathworks nicely places in each toolbox directory. In case the toolbox is not found, an error is given.
Robert Oostenveld - 2012-03-11 11:33:17 +0100
committed three improvements to qsub in one go: enhancement - this addresses bug #1254, bug #1331 and bug #1361. Allow the user to specify toolbox names when compiling. Allow the user to specify a custom batchid instead of user_host_pid_bM. Implemented backend=local using a call to qqubexec inside qsubfeval (i.e. really local execution), renamed the existing implementation to backend-system. mbp> svn commit Sending qsub/private/generatejobid.m Sending qsub/qsubcellfun.m Sending qsub/qsubcompile.m Sending qsub/qsubfeval.m Transmitting file data .... Committed revision 5435.