Opened 6 years ago
Closed 6 years ago
#5091 closed defect (fixed)
The NF does not expand scalar product in function argument
Reported by: | casella | Owned by: | perost |
---|---|---|---|
Priority: | high | Milestone: | 2.0.0 |
Component: | New Instantiation | Version: | |
Keywords: | Cc: | rfranke |
Description
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.
Change History (2)
comment:1 Changed 6 years ago by casella
- Cc rfranke added
comment:2 Changed 6 years ago by perost
- Resolution set to fixed
- Status changed from new to closed
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.