Back to the main page.
Bug 1742 - problem with number of qsubcellfun output argument
Status | CLOSED FIXED |
Reported | 2012-09-25 17:32:00 +0200 |
Modified | 2012-10-29 13:44:58 +0100 |
Product: | FieldTrip |
Component: | qsub |
Version: | unspecified |
Hardware: | PC |
Operating System: | Mac OS |
Importance: | P3 normal |
Assigned to: | Robert Oostenveld |
URL: | |
Tags: | |
Depends on: | |
Blocks: | |
See also: |
Robert Oostenveld - 2012-09-25 17:32:54 +0200
Irina reported the following: I’ve got an error when using the qsub: ??? The left hand side is initialized and has an empty range of indices. However, the right hand side returned one or more results. Error in ==> fexec at 153 [argout{:}] = feval(fname, argin{:}); Error in ==> qsubexec at 54 [argout, optout] = fexec(argin, optin);
Robert Oostenveld - 2012-09-25 17:33:32 +0200
and she can reproduce it when simply calling for randn: Numargout at qsubcellfun line 202 is 0 qsubcellfun(@randn, {2,2,2}, 'memreq', 1024, 'timreq', 60) stacking 3 matlab jobs in each qsub job submitting job xirisim_mentat286_p18528_b8_j001... qstat job id 785564.dccn-l014.dccn.nl job xirisim_mentat286_p18528_b8_j001 returned, it required NaN seconds and NaN GB %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % an error was detected inside MATLAB, the diary output of the remote execution follows %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ??? The left hand side is initialized and has an empty range of indices. However, the right hand side returned one or more results. Error in ==> fexec at 153 [argout{:}] = feval(fname, argin{:}); Error in ==> qsubexec at 54 [argout, optout] = fexec(argin, optin);
Robert Oostenveld - 2012-09-25 17:49:59 +0200
I found the problem and fixed it roboos@mentat001> svn commit qsub/ test/test_bug1742.m Sending qsub/private/fexec.m Adding test/test_bug1742.m Transmitting file data .. Committed revision 6540.
Eelke Spaak - 2012-10-10 13:41:16 +0200
The test script test_bug1742 was failing because the Torque cluster killed it. This happened because the child jobs that this test script submits of course were submitted at the end of the queue, thereby causing the test script itself to run for far too long. I now changed the script to specify the option backend=local to qsubcellfun. Since this also spawns a new process and also makes use of fexec, it should still test the same phenomenon. If I misunderstand this, just let me know :)