How to define the size of output in subfunctions, for C coder

Hello everybody,

I am experiencing an issue when porting a function to C with Matlab coder.

I have a function which runs inside a parfor parallel loop like

output = myfunction(id, mystruct) ;

where id is the parfor index and mystruct an input structure with one dimensional fields which are 1xn arrays, where n is variable.

inside myfunction there is a subfunction which is called inside myfunction like

output_temp = mysubfunction(mystruct.field)

where output_temp is a 1x1 variable.

Everything works in Matlab.

When I build code to port the function in C with Matlab coder, I get the following issue.

I define the input mystruct.field as unbound :1x:Inf, but at the "check for issues" stage, in the mysubfunction the coder sees mystruct.field as :Infx:Inf so that the coder sees output_temp as :1x:Inf instead of 1x1, and this generates an error. I am run out of ideas and cannot fix this...

Can you help me in fixing this, please?

Thanks in advance,

Patrizio

[Ryan Livingston]

It's hard to give suggestions with the info provided here. Are you able to share some code and a codegen command which reproduces the problem?

Absent that, some things to think about:

• Trace through the code to see where the size of mystruct.field goes wrong. That may give a clue.
• If Coder can't figure out that the output of mysubfunction is 1x1 you can give it a clue

temp = mysubfunction(mystruct.field);
output_temp = temp(1); % Index to force a 1x1

[PatrizioGraziosi]

Hi Ryan,

thanks for your time. I’m trying to port in C by using the Matlab coder. The issue rises at the “check for issue” stage, when the subfunction is called. This is because, for example, the 'state_ID_v_x' field, which I defined as

:1 x :Inf

becomes, when entered in the subfunction argument

:Inf x :Inf

The subfunction is called at the lines 56-57 and 74-75, and I get the error with respect of the lines 59-61 and 77-79.

I attach a piece of code which is minimum yet realistic and complete, I can shorten it if it is too messy; I’m more a physicist than a programmer or computer scintist, apologize…

Thanks in advance

Patrizio

[PatrizioGraziosi]

Hi Ryan,

I am focusing the problem.

Once the code is generated, the MEX is built, at testing level I get the following error when calling the following local function

function [ one_over_tau_x_temp ] = my_local_funct(Skk, e, I, z, DOSf, vf_x, v_x_k)
                                    
    one_over_tau_temp_array(:) = z .* Skk .* DOSf./e .* I .* (1-vf_x./v_x_k);
    
    one_over_tau_x_temp = 1/(2*pi)^3 .* sum(one_over_tau_temp_array);
end

where

z, Skk , e, v_x_k

are 1x1 while

 DOSf, I , vf_x

are :1x:Inf

I want

 one_over_tau_temp_array

to be 1x:Inf but

z .* Skk .* DOSf./e .* I .* (1-vf_x./v_x_k);

turns to be 1x1.

It must be a task of arrays multiplication due to some different size spec, in Matlab this is not an issue but in the C coder it looks it is.

However, I modified the code to make

DOSf, I , vf_x

to be 1x:Inf but still

z .* Skk .* DOSf./e .* I .* (1-vf_x./v_x_k);

appears to be 1x1.

Thus, I'm doing concatenated array and scalar multiplication and the result is an array in matlab but a scalar in the code...

Any clue?

In similar yet opposite way, when I call another local function

function [ one_over_tau_x_temp_array] = ...
                                    my_locl_funct_2(Skk, e, I, z, DOSf, vf_x, v_x_k, )
    
    one_over_tau_x_temp_array = Inf(1,size(vf_x,2));
    
    one_over_tau_x_temp_array(:) = z .* Skk .* DOSf./e .* I .* (1 - vf_x./v_x_k); 
end

I get the opposite error:

one_over_tau_x_temp_array is reas as [1] [1]

whereas z .* Skk .* DOSf./e .* I .* (1 - vf_x./v_x_k) is a [1][n] array, as should be...

I really cannot figure out why

z .* Skk .* DOSf./e .* I .* (1 - vf_x./v_x_k)

is a [1][1] in the first local function and [1][n] in the second one..

Thanks in advance

Patrizio

[Ryan Livingston]

I took your my_local_funct and put it in a separate file to try with codegen:

function [ one_over_tau_x_temp ] = my_local_funct(Skk, e, I, z, DOSf, vf_x, v_x_k)
                                    
    one_over_tau_temp_array = z .* Skk .* DOSf./e .* I .* (1-vf_x./v_x_k);
    
    one_over_tau_x_temp = 1/(2*pi)^3 .* sum(one_over_tau_temp_array);
end

>> t = coder.typeof(1,[1, Inf], [1,1]);
>> codegen my_local_funct -args {1,1,t,1,t,t,1} -report

Looking at the report shows that Coder computed the size of one_over_tau_temp_array to be :1x:Inf as expected. Screenshot from clicking the "View report link":

Do you see similar sizes when you look at the report for your larger example?

Assuming so, I continued on. When I then try to run the generated MEX I get an error:

>> vec = 1:3;
>> my_local_funct(1,1,vec,1,vec,vec,1)

ans =

   -0.0887

>> my_local_funct_mex(1,1,vec,1,vec,vec,1)
Error using sumprod (line 46)
The dimension to operate along was selected automatically, is variable-length, and has length 1 at run time. This is not supported. Manually
select the dimension to operate along by supplying the DIM argument.

Is that what you're seeing? Or do you get a different error?

[PatrizioGraziosi]

Hi Ryan,

thank you so much for your time!

I attach the screenshot from the coder app. Like you observed, I also get the error by running the MEX file.

The size is 1x:Inf as expected, it is not :1x:Inf in the screenshot because I tried to modify the upper code to cut the input data to rule out empty vectors, even if I prefer to not do this, however, this does not solve the problem, but the error is different

The coder returns as error " (line 1112)

Sizes mismatch: [1][3234] ~= [1][1]. "

it looks like the right hand expression, z .* Skk .* DOSf./e .* I .* (1 - vf_x./v_x_k), returns a scalar instead of an array, maybe it is the same error that you get, just told in a different way.

what is surprising to me, possily not to you, is that DOSf and vf_x are 1x:Inf arrays, and matlab returns a 1x:Inf array...do you have any clue?

[Ryan Livingston]

There are some behavior differences to consider with MATLAB Coder and variable size arrays. Those are documented here:

https://www.mathworks.com/help/coder/ug/limitations-with-variable-size-support-for-code-generation.html

Without being able to run your exact code with your exact inputs, I can't tell what's going on. Here's an idea, at line 1111 can you print out the runtime sizes of all the operands? Then run the MATLAB code and the generated code so we can compare the sizes in both. So you can add something like:

disp(size(z))
disp(size(Skk))
% and so on

Then run the code in MATLAB and run the MEX. Let's see what the sizes all return as that should help identify the issue.

Another possible difference to keep in mind is that MATLAB Coder doesn't support MATLAB's generic expansion for binary operators. So we may be hitting an instance of that.

[PatrizioGraziosi]

Hi Ryan,

many thanks for the support!

So, when I run the matlab function I see the following sizes for one run, as example (the 2046 can vary from few ones to tens of thousands)

z 1 1

Skk 1 1

DOSf 1 2046

e 1 1

vf_x 1 2046

v_x_k 1 1

one_over_tau_temp_array 1 2046

one_over_tau_x_temp 1 1

If I run the MEX file I get the same until v_x_k, then the code crashes with the error

Error using tau_calc_funct_ELECTRA_C_v0>tau_ODP_funct (line 1119)

Sizes mismatch: [1][1866] ~= [1][1].

More information

line 1119 is where the code does the multiplication

one_over_tau_temp_array = z .* Skk .* DOSf./e .* I .* (1-vf_x./v_x_k);

and the "More information" links to the "Incompatibility with MATLAB for Scalar Expansion" doc page. It looks that the z .* Skk .* DOSf./e .* I .* (1-vf_x./v_x_k) returns a scalar, although before doing this the sizes are as in Matlab

Forgive me one question, I'm using the coder to port in C the function file, where there is a function and, at the end the local function. That is, in the coder GUI app I call the function file, inside this file there are a main function plus the local functions, is this correct?

Thanks

Patrizio

[PatrizioGraziosi]

Hi Ryan,

I think I got a clue. The issue that I detected was due to the variable 'I', which can be a 1D array but inside the local function only a scalar is entered, so inside the local function I modified as follows

one_over_tau_temp_array = Inf(1,size(vf_x,2)); 
           
one_over_tau_temp_array(1,:) = z .* Skk * I(1) * DOSf/e .* (1-vf_x./v_x_k);

Then I got the same error as you, but it was located after processing the results as I was summing a 2D varable 'V',

sum(sum( V ))

whereas I understand it is necessary to specify the sum dimensions like

sum(sum( V, 1), 2).

Now the specific local function looks fine, I'll implement this finding to all the local functions and I'll see...

I'm grateful to you for having accompained me in debugging my file, thank you so much!!!

I wish you a happy new year,

Patrizio

[Ryan Livingston]

Excellent! Happy new year Patrizio!