MATLAB: Coder and passing extra parameters

global variablesmatlab coderpassing parameters

Hi all,

I have been trying to speed up the passing of extra parameters to a function that is used in fzero(). I have been trying to create code that is compatible with and can be compiled by the coder. Since nested functions and function handles aren't compatible I have been trying to get the following code compiled.

    function z = RxEqNest2(z1,pin2,pin3,pT,pVpore)%#codegen
  global in2 in3 T Vpore
  in2=pin2;
  in3=pin3;
  T=pT;
  Vpore=pVpore;
z = fzero(@RxEqPoly2,z1);
end
function out1 = RxEqPoly2(z)
global in2 in3 T Vpore
%RXEQPOLY2
%    OUT1 = RXEQPOLY2(Z1,IN2,IN3,T,VPORE)
%    This function was generated by the Symbolic Math Toolbox version 5.7.
%    15-Sep-2011 22:07:14
Keq1 = in2(:,1);
Keq2 = in2(:,2);
Keq3 = in2(:,3);
Ot = in3(:,2);
t107 = z.^2;
out1 = T.*t107.*(5.774280410608897e15./1.7592186044416e13)+Ot.^2.*T.*(5.774280410608897e15./7.0368744177664e13)+Keq2.*T.*t107.*(5.774280410608897e15./8.796093022208e12)-Ot.*T.*z.*(5.774280410608897e15./1.7592186044416e13)+Keq2.^2.*T.*t107.*(5.774280410608897e15./1.7592186044416e13)-Keq1.^2.*Vpore.*z-Keq3.^2.*Vpore.*z-Keq1.*Keq3.*Vpore.*z.*2.0-Keq2.*Ot.*T.*z.*(5.774280410608897e15./1.7592186044416e13);
end

I get errors during the compilation of the subfunction, saying that it can not find size declarations of in2,in3,T. How can passing parameters efficiently be done when this step is a major bottleneck compared the time spent evaluating the function.

Thanks

Best Answer

Hello Joseph,

Could you show us the 'codegen' command you're using to compile your code with? You need to use '-globals' to specify initial values for the global variables (even though these values will not be used). The initial values are used to determine the class/size/complexness of the global variables.

Thanks, Alexander

Related Solutions

MATLAB: How to determine which operand has type ‘RootOf’ in MuPad

It appears to be possible, but not trivial.

I do not have the Symbolic Toolbox to test with, and the type system of MuPad is not as easy to work with as the type system of Maple.

It appears to me that you would probably want to start with map() in order to traverse the set elements. The mapped function would call indets(), probably with the PolyExpr option. You would then intersect that with Type::Union(Type::Function, Type::Predicate(XXX)) where XXX is something like XXX->bool(op(0,XXX) = RootOf)

http://www.mathworks.com/help/toolbox/mupad/Type/Predicate.html

It would probably be messier than this as you want to find the part that contains the RootOf, rather than just the RootOf expression itself.

In Maple, isolating the RootOf expression would be trivial:

indets(X,RootOf)

In Maple, isolating any other specific function name (say logGAMMA for example) would be

indets(X, specfun(anything,logGAMMA))

Perhaps I missed something when I went through the MuPad type predicates, but it appeared that the type expressions I use the most often in Maple are messy in MuPad.

MATLAB: Coder and error passing handles to extrinsic functions

You need to refactor your code so that you don't pass function handles across the extrinsic function call boundary. Instead of calling FSOLVE as an extrinsic function, call your own function extrinsically and pass all the data that it needs to run FSOLVE and then to return data to your MATLAB Coder environment. Within your function, use anonymous functions or whatever.

function y = ex1(x,c) %#codegen
% Show how to call extrinsic functions that require function handles.
% This function will be compiled:
% codegen ex1 -args {zeros(2,1),0}
coder.extrinsic('mysolve');
% Some compiled calculations would normally go here. For this illustration,
% we simply copy x to x0.
x0 = x;
% Declare the output type of the extrinsic call so that the data can be
% marshaled back into the C execution environment.
y1 = zeros(size(x0));
% We pass to mysolver all the data it needs to construct the call to
% FSOLVE.  This call will be from the C execution environment into the
% MATLAB execution environment. We pass only data, but we pass all the
% data needed to define the problem to be solved in the extrinsic function.
y1 = mysolve(x0,c);
% Some compiled calculations would normally go here.  For this illustration
% we just copy y1 to y.
y = y1;

And in a separate file, mysolve.m:

function y = mysolve(x0,c)
% This function is NOT compiled.
% Construct function to be solved:
f = @(x)myfun(x,c);
y = fsolve(f,x0);
function F = myfun(x,c)
% This function can be defined either here, in a separate (not-compiled)
% MATLAB file, or even built as a mex file using a separate MATLAB Coder
% project.
F = [ 2*x(1) - x(2) - exp(c*x(1))
    -x(1) + 2*x(2) - exp(c*x(2))];

Running this:

>> codegen ex1 -args {zeros(2,1),0}
>> ex1([-5;5],-1)

Obviously, since mysolve.m is not compiled, you can do anything in it that works in MATLAB. -- Mike

Related Question