If I understand correctly, persistent should work if it appears at the
top-level within the function (as opposed to inside if-then blocks like this
particular case). So I think you should be able to fix this one by moving that
line to the first line in the function. I don’t see any other persistent calls
that should require changing. That is, I believe they are all already at the
top level of their function.
As far as num2cell(), my first idea is to try replacing all calls with a call
to a new function, say mp_num2cell() that simply creates a cell array of the
same dimensions as the input and copies the contents element by element,
something like …
function c = mp_num2cell(num)
c = cell(size(num));
for k = 1:length(num(:))
c{k} = num(k);
end
Let me know if that works and if anything else pops up.
Ray
On Apr 13, 2020, at 9:58 AM, Lode De Herdt
<[email protected]<mailto:[email protected]>> wrote:
Hi Ray,
Thank you for the reply. I've spent a little time trying to remove the things
that are unsupported from the MATPOWER code but it looks like I'm opening a
Pandora's box here; each error I solve just leads to the next errors so it's
difficult to solve without good knowledge of MATLAB and the inner workings of
MATPOWER.
The first error was:
PERSISTENT declarations may only appear at the top-level.
Function 'moption.m' (#57.41253.41263), line 697, column 9:
"persistent"
So I replaced persistent nsc_opt with nsc_opt = []; and did the same for other
places where 'persistent' was used as was suggested in message
05192<https://www.mail-archive.com/[email protected]/msg05192.html> of
this forum, but that then leads to this:
This assignment writes a 'struct' value into a 'double' type. Code generation
does not support changing types through assignment. Check preceding assignments
or input type specifications for type mismatches.
Function 'mpoption.m' (#34.71098.71101), line 1531, column 5:
"opt"
One of the other errors indicates that the num2cell function is not supported
for code generation, but who knows what else will appear once that one is
solved.
Let me know if you or anyone else has any other ideas, or experience with
MATPOWER and code generation.
Best regards,
Lode
On Mon, Apr 13, 2020 at 4:36 PM Ray Daniel Zimmerman
<[email protected]<mailto:[email protected]>> wrote:
I can’t think of another option. I’ve not personally worked with the C code
generation in MATLAB, so I’m not familiar with the requirements. Do you know
what specifically is used by MATPOWER that is not supported? If there are easy
ways to avoid those things, it would certainly make sense to do so.
Ray
On Apr 13, 2020, at 7:53 AM, Lode De Herdt
<[email protected]<mailto:[email protected]>> wrote:
Dear Matpower users,
I am trying to run a simulation of a distribution grid on an OPAL-RT real-time
digital simulator, using Matpower. The simulator requires a Simulink model,
which it converts to C code in order to run the model on its hardware. Using
the MATLAB Function block in Simulink, I can integrate a few lines of Matlab
code into the model that run a power flow with Matpower.
Unfortunately it seems that not all of the code used for Matpower is supported
for C code generation, so the Simulink model cannot run.
Other than manually re-writing the Matpower code to avoid everything that's
unsupported for code generation, is there any easier way of running Matpower in
Simulink? It must be compatible with code generation so using an extrinsic
coder or something similar is unfortunately not an option.
Thank you for your help!
Best regards,
Lode
