-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] *Direct Handling of Electrical Parameters in JSON Interface* #642
Comments
Hi @sudo-ac , what would you propose the JSON interface would look like? Can you provide an example? |
Hi, "transformer": |
The electrical parameters in these examples refer to the high voltage side |
My expectation is that it will not be straightforward to add this without introducing a significant memory overhead unless we have the columnnar data format mentioned in #548 , but we will discuss this in the near future. c.c. @petersalemink95 |
After discussing with the maintainers we concluded the following. Instead of extending the transformer/3w_transformer we would want to make a new component: generic_branch (naming is pending), which would model branches as a Pi model, i.e. the user can specify:
@sudo-ac would this work for you? |
Maybe trivial, but |
@petersalemink95 I have some doubt about the transformer ratio. Do you mean to:
|
Apologies for my late response. I find the proposal to add a general Pi model for the transformer to be good. I would suggest using the model from Matpower. See https://matpower.org/docs/MATPOWER-manual-8.0.pdf page 27ff. Yes, the ratio should be a float and the shift_angle should be a float as input values. However, Y_shunt and Z_series need to be passed as complex values, so I would prefer the values
|
@sudo-ac Noted. Thanks for answering. In the current form of PGM tap changer modeling, we are basically doing enumeration to find the optimal tap, although it's less suboptimal than that in reality. If I understand your answer correcly, you are suggesting a continuous range for the ratio. If PGM were to solve for a real root (floating point) as requested here, we might need to revisit the core of our tap changer design and work out the mathematics. Eventually it will be a totally different way of optimization than what we are currently doing. Think for example a linear programming or even NR process for tap position.f |
As an input parameter, the tap can be defined as an integer value or enumeration. The background of the issue was the data import from CIM/CGMES files. In these files, the equivalent circuit elements for power transformers are directly defined (see here). To process CIM/CGMES data with PGM without further conversions, an adjustment of the interface would be required. A PI-branch, as proposed, would be conceivable for this. In your calculation algorithm, you will ultimately work with a complex transformation ratio, which is initially irrelevant for the interface. An adjustment of the algorithm for automatic tap calculation will not be affected by this. According to my understanding, the solutions for tap calculation always involve the additional voltage that results from the specified or unknown transformer tap and is a complex number (magnitude + angle). Once the additional voltage is determined by the solver, the tap must be calculated from it. Typically, the determined tap is a floating-point number that must be suitably rounded to an integer. But as mentioned, this requirement should not impact the internal calculations of the program. |
@sudo-ac Thank you for the clarification. I think there is some mis-understanding from both sides:
The additional voltage is a result of changing to a different tap, not the other way around.
The finite tap, which is now an integer, determines the floating point ratio, not the other way around.
If I now understand you correctly, you would want to have floating point ratios next to the integer based tap positions. The floating point ratios are finite and not continuous. Based on these two, the internal would not be affected indeed. |
That was exactly what I had had in mind. I wrote is as Z_series (r/x), meaning the user would specify R and X, as you mention. My notation wasn't that clear, but good that we're on the same page! |
@sudo-ac I think @Jerry-Jinfeng-Guo means that the proposed generic_branch component would not fit the current automatic tap changer algorithm, due to having a floating ratio On the long term planning we want to implement the transformer ratio as an unknown in the Newton-Raphson calculations, which will result in floating transformer ratio's. Most of the mathematics are already worked out, but the actual implementation requires some more discussions and is not yet prioritized/planned. |
Thank you very much for the lively discussion. As mentioned, the algorithm or the method for the transformer tap calculation is a problem separate from this use case. For me, it would be important to work directly with the electrical parameters instead of the short-circuit and no-load test parameters. For the transformer taps, the existing format can be used (i.e., maximum tap, minimum tap, current tap, voltage change per tap, etc.). |
In order to add a new component to Power Grid Model the following steps need to be taken:
Note: the order is recommended, but not necessary |
@petersalemink95 please create a new issue with the actual action, namely the new compnent |
The first promising work has begun, so this issue can be closed. |
Description
This feature introduces the capability to directly handle electrical parameters (r, x, g, b) within the JSON interface of the Power Grid Model (PGM). This enhancement aims to eliminate the need for conversion between transformer parameters and electrical parameters, thereby improving accuracy and simplifying the data handling process.
Detailed Description
Current Process:
Proposed Change:
Benefits:
The text was updated successfully, but these errors were encountered: