Some array equations make the way to SimCode with the NF

[Francesco Casella]

Most of the failing models in Modelica.Electrical.Machines, about 10 models, see e.g. ​Modelica.Electrical.Machines.Examples.AsynchronousInductionMachines.AIMC_Inverter fail because of this issue;

Notification: Performance of Backend phase and start with SimCode phase: time 0.0005136/0.5278, allocations: 131 kB / 385.2 MB, free: 8.758 MB / 330.7 MB
[OMCompiler/Compiler/SimCode/SimCodeUtil.mo:5544:7-5544:48:writable]
Error: Internal error for Eqn: 1 :
aimc.ir = -{-aimc.idq_rr[1], -aimc.idq_rr[2]}
array equations currently only supported on form v = functioncall(...)
[OMCompiler/Compiler/SimCode/SimCodeUtil.mo:1366:5-1366:77:writable] Error:
Internal error createEquationsForSystems failed

This equation should obviously be expanded to two scalar equations, and I guess the NF should be responsible for that. Is it?

[Per Östlund]

Replying to casella:

This equation should obviously be expanded to two scalar equations, and I guess the NF should be responsible for that. Is it?

There's no such equation in the flat model, so it can't be expanded by the NF. I don't know where the equation comes from, but the failure happens in SimCodeUtil.createSingleArrayEqnCode. The error message is just a generic error thrown when something that function fails for whatever reason, it actually handles more cases than only v = functioncall(...).

I think this should probably be investigated in the backend. It might still be a frontend issue, but in that case it would be helpful to know why it occurs and where that equation is coming from.

[Francesco Casella]

Replying to perost:

There's no such equation in the flat model, so it can't be expanded by the NF.
I don't know where the equation comes from, but the failure happens in SimCodeUtil.createSingleArrayEqnCode. The error message is just a generic error thrown when something that function fails for whatever reason, it actually handles more cases than only v = functioncall(...).

I think this should probably be investigated in the backend. It might still be a frontend issue, but in that case it would be helpful to know why it occurs and where that equation is coming from.

@perost, before passing the buck to @lochel, the model flattened with the OF contains:

aimc.ir = {aimc.squirrelCageR.i[1], aimc.squirrelCageR.i[2]};

then there is a chain of scalar alias variables that lead to the subsitution of the two terms on the right-hand side with the ones that show up in the error message. The NF gives instead

aimc.ir = aimc.squirrelCageR.i;

and I guess this somehow throws a little stone in the cogs and causes the failure.

This equation is a binding equation defined in Modelica.Electrical.Machines.BasicMachines.AsynchronousInductionMachines.AIM_SquirrelCage, line 5028 in MSL 3.2.2:

  output Modelica.SIunits.Current ir[2]=squirrelCageR.i

Maybe you can still do something about it and make sure it is either fully expanded to its scalar components (why not?), or at least expanded as in the OF.

[Per Östlund]

Fixed by 63b9ba42 and 8b01343. The backend can now handle the non-expanded equations fine, and the model simulates successfully.