error using cluster computing

I am running a matlab script I wrote using a cluster on a company's server. My code includes parfor loops, which have been modified using opts=parforOptions(cluster).

While running the code I receive the following message:

" Error: The parallel job was cancelled because the task ID 1 terminated abnormally for the following reason: Shapes requires a RF_PCB_Toolbox license".

I am not using Shape anywhwere in the code as I am simply solving a system of equations using lsqnlonlin and fmincon through functions that appear in the parfor loops.

Any idea what this error implies? The error does not appear when running the code on my local machine. In fact on my local machine the code runs just fine (e.g., without any errors appearing).

[Walter Roberson]

Do you happen to be load()'ing a .mat file that might happen to have a variable of class Shapes inside it? If so then at the time you do the load() specify the list of variables to load: the license restrictions only apply to variables that are actually loaded.

[Luigi]

I stripped down my code; now the function i) calls another script that contain some numeric variables (parameters of the model), ii) constructs some function handles and then iii) runs a solver; below I am showing 4 function handles, 4 initial guesses and then the solver I am running.

f = @(x) [eq1(x);eq2(x);eq3(x); eq4(x)];
x0=[x1_guess,x2_guess,x3_guess,x4_guess];  
lb=[0,0,0,0];
ub = [10,10,10,1];
[sol,~,error,flag]=lsqnonlin(f,x0,lb,ub);

the same problem persists. I tried with another solver (fsolve) and the problem persists. I removed the last line of code (that is lsqnonlin) and the code runs smoothly, so the issue originates from lsqnonlin. I also tried to rewrite f inside the solver as:

@(x)norm(f(x))

without success. I want to re-iterate that the same code runs smoothly on my local machine where I do not have the RF_PCB_Toolbox. I checked and there are no Shapes objects in my mat.

[Walter Roberson]

Time to start debugging, such as putting a whos right before the parfor, and putting a whos right before the lsqnonlin . If the whos before the lsqnonlin execute successfully then you would have isolated the problem to somewhere in the lsqnonlin call; meanwhile the whos before the parfor tell you whether you reached the start of the parfor at all.

[Raymond Norris]

What's odd about this is that really the only way you could have triggered a call to shapes is with a PrintedLine object and therefore you should have seen the license issue regarding PrintedLine before shape was instantiated.

To me, there's a scoping issue here. f() is anonymous and not nested, correct? At the top level, are you running a script or a function?

Can you show us more of how you run the parallel code? How are you calling parfor? (and side note, I'm gathering you're not using parallel in your solver?)

Answer 1

[Luigi]

Issue resolved. Turns out one of the parameters that I am using in the functions handle was "delta" and delta seems to be a reserved object https://www.mathworks.com/help/rfpcb/ref/delta.html

I take that the lesson is to never use greek letters to name objects. The issue was surprising to the extent that I have frequently used this parameter name before in other occasions and never encountered this problem, until today when running my code in the cluster.

[Edric Ellis]

That's really weird, and pretty unexpected. I'm glad you found a workaround. Is there any chance you can post a minimal reproduction that demonstrates the problem for you? I'd like to see if we can avoid this in future.

[Luigi]

OK, will try submitting a snippet in the coming days.

[Raymond Norris]

I wouldn't say don't use greek names anymore than I would say don't use any MATLAB function name as a variable (not necessarily easy to do). In fact only nine of the greek letters are MATLAB functions.

[Walter Roberson]

Where you happening to "poof" delta into existance, such as using load() with no output variable, or using assignin('caller') or assignin('base') ?