Transformer taps and phases

[GorazdB]

This branch has the transformer calculations included. Run taps_and_phases_analysis() or run the example file provided. For use the three files, apart from the example file must be in same folder or included in path. The method of modelling is based on power system sensitivity of regulation criterion (line active powers and voltage amplitudes) to taps and phases that are to be calculated. Newton's method is used to find the zero of the control mismatch vector.

It is made so that MatPower provided files for the Ybus and the Jacobi matrix are used. The function sensit_to_taps_and_phases is not optimized for systems with a very large number of transformers, because I figured nobody will want to calculate more than a few hundred transformers. If the performance is slow or it runs out of memory, the function should be adapted so that sparse() is used on matrices and that inputting the values into the matrices is done only once, and not in a for loop as it is now.

[rdzman]

First, thank you very much for this contribution and I'm sorry for the extremely long delay in responding. 😜 😞

It seems like a very straightforward implementation. Nice job! 👍

There are a few changes I would like to see before merging, which is always to be expected. I'll start with some higher level comments.

1. This functionality seems similar to the generator reactive power limit handling in runpf in the sense that it runs the power flow iteratively, making some adjustments between each run. From the user's point of view, it would seem most logical to treat this simply as another option to runpf. This would also eliminate the need for conversions back and forth from internal indexing at each iteration. So I suggest the following modifications:

   • Move the main code from taps_and_phases_analysis into the main while loop in runpf, inside a conditional similar to the existing if qlim. In this case it will depend on the existence of the tap changer and/or phase shifter data and some options.
   • Supply the data in new optional fields in the MATPOWER case struct (mpc). Let's call them tap_changer and phase_shifter. By default, running a power flow on a case that includes these fields would enable this functionality and iteratively update the taps and phase shifters as specified.
   • Introduce two new MATPOWER options, pf.ignore_tap_changers and pf.ignore_phase_shifters. These would be 0 by default, but if set to 1 they would prevent the adjustment of taps and phase shifts, respectively, even if the data fields are present in mpc.

2. Automated tests are a requirement for all new functionality. Ideally, they would test both the individual functions (sensit_to_taps_and_phases and shiftJac_taps_phases) and the overall function of runpf with this functionality enabled. The latter is critical. The former would be ideal. See MP-Test and the existing MATPOWER tests for examples.

3. Documentation of this feature needs to be added to the User's Manual.

   • Add a paragraph following the last one in section 4.1 which describes the handling of generator Q limits. In fact, I think we should add two new subsubsection divisions, one for the Q lim stuff and one for tap-changers and phase-shifters.
   • Add the new options to Table 4-2 and Table C-2.
   • Add a description of the new optional mpc fields in Appendix B.

And, a few smaller items.

• All code comments should be in English (e.g. %razmerje kako so podane moci v vektorju)
• All variable/function names should be in English (e.g. Sbazni, tip_vozlisc, stevilo_iteracij, obcutljivosti)
• It seems to me that the parentheses are in the wrong place this line, as well as here, here and here.
  • e.g. if size(tap_changers_data,1>0) --> if size(tap_changers_data,1)>0
• Regarding your last comment about the use of sparse, I definitely do think we should use sparse when dealing with sparse matrices, even if they aren't super large. In terms of forming the matrices once rather than in a loop, I'm not sure which ones you are referring to. Some profiling on very large systems could tell us whether it makes a difference. If not, my preference is to be guided by what makes the code easiest to understand.

Finally, everything here is up for discussion, so don't be shy if you have alternative ideas. And please don't hesitate to ask if you have any questions, either here for things specific to this pull request or on MATPOWER-DEV-L for more general MATPOWER development help questions.

[rdzman]

Also, before doing any more commits to this branch, make sure you force pull the latest to your local repo since I just rebased it on the current MATPOWER master branch so that it's up-to-date.

[rdzman]

Rebased again.

[AliAshrafzadeh]

Hi Gorazd and Dr.Ray Zimmerman
I tried to model the automatic tap changer in MatPower so find you.
I studied your code, in my Idea for modeling automatic tap changer in power flow, best method is to model tap (ratio) as state variable. so calculation of sensitivity is simple and optimized. In the MatPower method, sensitivity are calculated such as:
(dS ̅)/(dτ_ij )=diag(V ̅)×〖(dY_bus)/(dτ_ij )〗×V *
that τ is tap variable.
instead of:
dPijdtap = (Uvozi(-2GUvozi+GtapUvozjcos(di-dj-ph)+BtapUvozjsin(di-dj-ph)))/tap^3;
dPjidtap = (UvoziUvozj(Gcos(di-dj-ph)-Bsin(di-dj-ph)))/tap^2;
dQijdtap = (Uvozi*((2B+Bsh)Uvozi-BtapUvozjcos(di-dj-ph)+GtapUvozjsin(di-dj-ph)))/tap^3;
dQjidtap = -((UvoziUvozj(Bcos(di-dj-ph)+Gsin(di-dj-ph)))/tap^2);

I implemented first equation in my code. It is important to calculate sensitivity in form of matrix calculation in MatPower.

[rdzman]

Rebased again on latest master (release 7.0).