The NF does not expand scalar product in function argument

[Francesco Casella]

Please check ​PowerSystems.Examples.AC3ph.Transformation.PhaseShifts. The following error is reported:

[PowerSystems 0.6.0/System.mo:62:5-62:23:writable] Error: 
Initialization problem is structurally singular, error found sorting equations 
146: $DER.voltage.theta = 314.1592653589793;
41: -res32.i[2] = (-0.1) * trafo3.i1[2];
11: res32.R * res32.i[2] = res32.v[2];
172: trafo1.omega[1] = 0.0;
42: -res32.i[1] = (-0.1) * trafo3.i1[1];
12: res32.R * res32.i[1] = res32.v[1];
45: res32.v[1] = 10.0 * trafo3.v2[1];
33: 0.0 = trafo3.R_n1 * $DER.trafo3.i_n1[1];
6: trafo3.omega[1] = trafo1.omega[1];
37: (trafo3.L[1] + trafo3.L[2]) * $DER.trafo3.i1[1] - trafo3.i1[2] * trafo3.omega[2] * (trafo3.L[1] + trafo3.L[2]) + trafo3.i1[1] * (trafo3.R[1] + trafo3.R[2]) = trafo3.v1[1] - trafo3.v2[1];
46: $DER.trafo3.i_n1[1] = 1.732050807568877 * $DER.trafo3.i1[3];
152: trafo3.L[2] = 0.05 * PowerSystems.Utilities.Precalculation.baseTrafoRL(true, {1.0, 10.0}, 1.0, 314.1592653589793)[2, 2];
153: trafo3.L[1] = 0.05 * PowerSystems.Utilities.Precalculation.baseTrafoRL(true, {1.0, 10.0}, 1.0, 314.1592653589793)[1, 2];
154: trafo3.R[2] = 0.05 * PowerSystems.Utilities.Precalculation.baseTrafoRL(true, {1.0, 10.0}, 1.0, 314.1592653589793)[2, 1];
155: trafo3.R[1] = 0.05 * PowerSystems.Utilities.Precalculation.baseTrafoRL(true, {1.0, 10.0}, 1.0, 314.1592653589793)[1, 1];
34: trafo3.omega[2] = $DER.voltage.theta;
44: res32.v[2] = 10.0 * trafo3.v2[2];
1: {$DER.trafo3.i1[1], $DER.trafo3.i1[2], $DER.trafo3.i1[3]} = {(-trafo3.i1[2]) * trafo3.omega[1], trafo3.i1[1] * trafo3.omega[1], 0.0};
156: trafo3.dv_tap_pu[1] = 0.1 * PowerSystems.Utilities.Precalculation.baseTrafoV(true, {1.0, 10.0})[1];
170: trafo3.top_p.w = 1.0 + /*Real*/(trafo3.tap_1) * trafo3.dv_tap_pu[1];
163: trafo3.top_p.Rot[1,2] = 1.0 - trafo3.top_p.w;
145: trafo2.v1[1] = voltage.V * cos(voltage.alpha0);
169: voltage.V = PowerSystems.Utilities.Precalculation.baseV(true, 1.0) * voltage.v0;
173: trafo3.top_p.Rot[2,1] = trafo3.top_p.w - 1.0;
36: (trafo3.L[1] + trafo3.L[2]) * $DER.trafo3.i1[2] + trafo3.i1[1] * trafo3.omega[2] * (trafo3.L[1] + trafo3.L[2]) + trafo3.i1[2] * (trafo3.R[1] + trafo3.R[2]) = trafo3.v1[2] - trafo3.v2[2];
50: trafo2.v1[1] = trafo3.v1[1] + trafo3.top_p.Rot[1,2] * trafo3.v1[2];
144: trafo2.v1[2] = voltage.V * sin(voltage.alpha0);
49: trafo2.v1[2] = trafo3.top_p.Rot[2,1] * trafo3.v1[1] + trafo3.v1[2];
 for variables 
 res32.i[1](31), meter1.Rot_dq[1,2](184), meter32.i[2](42), res32.v[3](32), meter1.Rot_dq[1,1](185), trafo3.top_p.alpha(22), res32.v[1](34), meter1.v[1](179), meter32.i_norm(38), trafo3.top_p.w(21), meter12.Rot_dq[1,1](149), trafo1.omega[2](150), trafo1.i_n2[1](151), trafo1.v2[2](154), res32.term.v[3](35), trafo3.top_p.Rot[2,1](24), meter1.i_norm(170), meter1.alpha_i(169), meter1.cos_phi(168), trafo1.v2[1](155), bus.v_norm(167), trafo1.v2[3](153), trafo2.L0[1](9), bus.alpha_v(166), trafo1.v1[3](164), meter32.alpha_i(37), meter32.i[3](41), meter12.cos_phi(130), meter32.v[2](47), trafo3.i_n2[1](58)

Looking at the output of optdaedump, I see the equation

18/27 (1): meter32.i_norm = sqrt(meter32.i * meter32.i)   [dynamic |0|0|0|0|] 

where the argument of sqrt was not expanded into its scalar components, as with the old FE:

meter32.i_norm = sqrt(meter32.i[1] ^ 2.0 + meter32.i[2] ^ 2.0 + meter32.i[3] ^ 2.0);

This could be problematic.

Also, I see equations such as

17/26 (1): meter32.alpha_i = PowerSystems.AC3ph.Sensors.PVImeter.atan2(meter32.Rot_dq[:,2] * meter32.i[1:2], meter32.Rot_dq[:,1] * meter32.i[1:2])   [dynamic |0|0|0|0|] 

which I'm not sure the back-end can handle correctly, while the old FE eventually allows the back-end to produce

19/28 (1): meter32.alpha_i = atan2(meter32.Rot_dq[1,2] * meter32.i[1] + meter32.Rot_dq[2,2] * meter32.i[2], meter32.Rot_dq[1,1] * meter32.i[1] + meter32.Rot_dq[2,1] * meter32.i[2])   [dynamic |0|0|0|0|] 

BTW, also when using the old FE, OMC obtains a singular model, see ​report, so in this case matching the old FE output would not be enough.

[Per Östlund]

This seems to have been fixed some time ago, the model is now rejected by the backend in the same way as with the old frontend.