Hello, I am new at the community. I am catching up with the discussion, I look forward to contribute.
I am the authored of the publication that @robbie.morrison just mentioned, it describes how the distributed slack bus model is successfully implemented in HELM. The slack voltage bus is embedded and there are two models for the PV buses, I believe these are what @Zalnd referred to where Q was eliminated or Q is taken as a variable. The distributed slack bus is implemented by adding an extra variable that represents the total active power losses and an extra equation that constrains the active power generated at the slack bus, this equation happens to be part of the same equation for a PV bus.
All this is implemented and validated in the python repository: https://github.com/HELMpy/HELMpy which was publish on august of the last year. This repository contains fully functional implementations of HELM. The repository needs work but I will start working on it.
Do you mean that the B shunt on Bus 11 is 4.4 Mvar?
If so, we are looking to the same network now. Have you tried to reach the 0.99183 load factor after correcting the network data?
Iâm almost finishing to implement my formulation in GridCal. I havenât finished it yet because I started to investigate the admittance matrices. Somehow, the calculated Ybus, Yseries and Yshunt doesnât obey âYbus = Yseries + Yshuntâ. I guess itâs a numerical issue since Iwamotoâs network is ill-conditioned. Could you confirm that the equation hold in your working station?
The following file contains the variable created by the functions âcomputeâ and âcalc_connectivityâ in âsnapshot_static_inputs.pyâ. It was saved using pickle.
Hello @Zalnd,
From what I understand the relation âYbus = Yseries + Yshuntâ must be satisfied even if the network is ill-conditioned. If there exist phase shifters, the Yseries matrix must be separated in its symmetric and unsymmetric parts, and the relation â Y = Yseries_symmetric + Yseries_unsymmetric + Yshuntâ must be satisfied.
I have made a script that calculates this three matrixes, it is part of a module of my repository. It is ready to be applied to the Iwamoto 11 bus.
Hope this may help.
Iâm not questioning from a mathematical point of view. Iâm questioning specifically GridCal implementation. The code adapts an âincidence matrix formulationâ and all the three terms, Ybus, Yseries and Yshunt are calculated using independent equations. I mean that the formulation doesnât calculate two terms independently and enforce the equality by calculating the last one using the equality itself. The formulation obtains the three terms using completely independent equations.
Somehow Iâm getting 00041723356008991144 as the maximum absolute error from âYbus - Yseries - Yshuntâ. I didnât have enough time to take a good look at it but the formulation seems to be correct. If the formulation is correct but it leads to a wrong answer, the issue may be numerical.
I found the source of the problem. Itâs the GridCal formulation. Considering the Universal Branch Model, I think the âfrom-from primitive admittance vectorâ should be calculated by:
The shunt element on HV side shouldnât be reflected through the âReal Transformerâ. Just through the âHV Virtual Transformerâ.
It also must be pointed out that virtual taps are completely ignored in Yseries and Yshunt calculation. This doesnât make any difference to the Iwamotoâs 11 Bus System, though.
I need to carefully look at this from all angles. I am refactoring the engine to remove the generic branch to specialise into lines, transformers, and other branch models like HVDC or VSC. The virtual taps are a thing that have their use for transformers and should keep working after changes.
The way to proceed is to split each device into symmetric, unsymmetric and shunt as Jose Juan points out. A reverse enforcing of Yshunt by a subtraction is not a good practice. Iâll check the change that you propose and report back.
âEditâ
I added a test, to check that Ybus = Yseries + Yshunt, and yes it is equal.
I have noticed that the Yshunt from the output of ânumerical_circuit.compute()â is â.Ysh_helmâ and updated the main function of helm_power_flow.py a couple days ago. So, this isnât the source of the issue.
Have you updated series_static_inputs.py since 3.7.0 version? I restate that this series_static_inputs.py fails to calculate coherent admittance matrices.
When looking deeper into this issue, it seems that the Ybus formulation considers the matpower branch model (page 26) and the Yshunt formulation considers this universal branch model. The position of the shunt element on HV side is different. The solution I pointed out above corrects the Ybus formulation in order to represent the universal branch model.
EDIT: I was treating the âseries_static_inputs.pyâ as the âsnapshot_static_inputs.pyâ all along. You have updated the âseries_static_inputs.pyâ since the 3.7.0. But you havenât updated the âseries_static_inputs.pyâ. Perhaps only the old formulation causes the issue.
EDIT2: The formulation havenât changed, so the problem still persists. I think you should change your test code to compare the absolute value of the difference. It seems that numpy less function completely ignores the imaginary part.
Yes, the admittance matrix looks the same and everything seems to match.
However, I still canât figure out the right s_0 vector to work with. According to the Sigma plot the system has a solution. The conformation of the s_0 vector I implemented is quite rudimentary, but still, it worked nice with a total loading factor of about 0.9. You mentioned that your initial load factor was 0.1, so what where the other ones?
Since this is a scientific forum, I posted a test proving that the admitances match. However it seems that you still disagree with such test, so I would like to see code from you testing the hypothesis that you propose.
Furthermore, it has been implied that somehow I changed the code to correct a bug that only you seem to find, but cannot prove. You may check the commits. I promise I did not hack GitHub.
In the master branch, there is a matpower-like branch model enhanced with the virtual taps (model that has been checked against ETAP) However thais is going to change soon, since in a separated branch I have reworked all the internals to get rid of the branch model and replace it with particular models (line, transformer, etcâŠ)
Currently, the admittance splitting is between Series and Shunt, whereas in the future there shall additionally be a split between symmetrical-series, unsymmetrical-series and shunt. That is the only change that is concerning me at the moment since it enables P-W.
On the personal side, I dialogue with people that show value, humbleness and act with respect.
@jfb
I donât understand why you have to define all the transformations a priori. I think you should find the next transformation based on the maximum mismatch obtained along s real axis.
I agree, you are correct on that. My implementation initializes all the s values at once, despite that I manually select them while computing each step. I am still puzzled to know the value you have chosen in each step. Can you please share them so I can test the system and find out if the mismatch improves?