Hi, all Sorry for the late response, Jose. Thanks for the input. I agree that the tap changers will have to be modeled with the voltage band and I think that the same goes for the phase shifters. I think that the problem of correctly applying the limitations, the voltage band and discrete taps might actually be larger that the routine currently, so it will have to wait a little. I agree with Ray that we should go one step at a time with this, because the underlying calculation of the phases and taps remains the same.
So I think it is best if I first finish applying the MatPower's standard to what I have and upload that. I am hoping I can do it this week or the next. regards and thanks for the input, Gorazd ________________________________ Od: bounce-121588580-78535...@list.cornell.edu [bounce-121588580-78535...@list.cornell.edu] v imenu Ray Zimmerman [r...@cornell.edu] Poslano: 8. junij 2017 17:12 Za: MATPOWER Developer List Zadeva: Re: Calculation of Taps and Phases of Transformers Hi all, I like the voltage deadband idea. And I do think that something like Jose recommends is probably the way to go. However, if the algorithm is going to be set up with a continuous, unlimited tap problem as a sub-problem, we could consider adding these features one step at a time. Get this sub-problem working and tested, then deal with outer loop to enforce tap limits and possibly discreteness as a separate problem and subsequent contribution. What do you think? Ray On Jun 6, 2017, at 12:21 PM, Jose Luis Marín <mari...@aia.es<mailto:mari...@aia.es>> wrote: Hi Gorazd, I've been following with much interest this new feature you're contributing. Let me add my 2 cents here. I agree with Ray that adding limits is extremely important, but doing it right is also quite difficult. The algorithm you describe might be OK for not too-large and not too-stressed powerflow cases, but it's bound to find problems.At every step 3 (powerflow recalc), one should re-check whether the taps that "maxed out" in the previous step 2 are still correcly maxed out under the new scenario. For instance, assuming that the local sensitivity V vs. r is positive and r has been fixed at its maximum r_max in the previous step, then the value of the regulated voltage V should be *lower* than the commanded setpoint Vset. If it turns out to be higher, it means we have to undo the operation. For the sake of the discussion, let us call this a "tap rebound". So the problem is that, in general, nonlinear interactions between controls may conspire to cause tap rebounds; in the worst case, they lead to "ping-pong" behavior, slowing down or even preventing convergence (when they go cyclic). The same thing happens when trying to deal with generator Mvar limits, by the way. As I said, this only happens very seldom in not too-large and not too-stressed powerflow cases. But then planners tend to work with difficult, "peak" cases... To tackle this rigorously one needs to resort to OPF-like techniques, which is proably overkill here. So let me propose a simpler alternative: consider a regulation *deadband*, instead of a setpoint. I think this is actually closer to the way an actual ULTC is operated, but my point here is that by considering a deadband you will considerably reduce the chances of tap rebounds. This is how I would envision it: 1. Ask the user to provide a band [Vmin, Vmax] instead of a single Vset point. 2. Mode 1: a calculation with unlimited and continuous taps (make Vset the midpoint between Vmin and Vmax). This is useful to inspect the solutions and see where there are tap-limit violations, as this flags where there is a deficit or surplus in reactive power. 3. Mode 2: a calculation that observes limits and tap discreteness. Internally, calculate as in Mode 1, applying the algorithm you described, aiming for Vset at the midpoint of the deadband. But then, when checking for tap rebounds, take into account the deadband: that is, do not back-off tap limits unless the voltage gets out of the deadband (in the direction it shouldn't, for this to be a rebound). Once the calculation converges, relax tap values to their discrete positions and perform one last calc. I realize that Mode 2 is a lot of work, and still not 100% bullet-proof, but it would avoid many of the problems I mentioned in large stressed cases. PS: I checked PSS/E manuals and it turns out they also use deadbands for ULTC control. Not only that, they recommend that the band between Vmax and Vmin should be at least twice the transformer tap-step, percentage-wise. They recommend a band of 2% for the normal case of 0.625% tap ratio steps. -- Jose L. Marin Grupo AIA 2017-06-06 11:59 GMT+02:00 Bone, Gorazd <gorazd.b...@fe.uni-lj.si<mailto:gorazd.b...@fe.uni-lj.si>>: Hi Ray, I've been mulling your recommendations. While I do think that the discrete tap and phase ability will generally be used by a user I think it is best left to the user at the moment, because the algorithms that I can come up with are not noticeably better than simply rounding the values to their discretely attainable levels. The transformer limits are something that I am contemplating of doing currently. With most regulable Load Flow devices I found it is generally the case that, if a limit is exceeded that limit is considered instead of the regulation criterion. I was thinking of doing this exact thing myself by using the following approach: 1. Run the routine that calculates taps and phases 2. check the values of taps and phases - those that are out of limits are fixed to their limits. If all values were within limits return the results and exit. 3. rerun the entire thing again and go to step 2 Now this may not produce the most optimal solution, but it does provide a way for the user to consider limitations without manually changing the inputs. Does anyone think of any other better algorithms (preferably not too complicated)? ________________________________ Od: bounce-121571424-78535...@list.cornell.edu<mailto:bounce-121571424-78535...@list.cornell.edu> [bounce-121571424-78535...@list.cornell.edu<mailto:bounce-121571424-78535...@list.cornell.edu>] v imenu Ray Zimmerman [r...@cornell.edu<mailto:r...@cornell.edu>] Poslano: 31. maj 2017 19:48 Za: MATPOWER Developer List Zadeva: Re: Calculation of Taps and Phases of Transformers Hi Gorazd, Thanks again for your work on this and for offering to contribute to MATPOWER. There are several possible levels of integration with MATPOWER, two in particular that make sense to me. One is, as you appear to be suggesting, adding a new function that calls runpf() as a subroutine that takes additional inputs as you defined. The other option is to integrate it more tightly by implementing tap-changing and phase-shifter control as an option to runpf(). While this may be more intuitive for the user, it does require updating the MATPOWER case format to include the necessary data (control modes and regulation targets etc.) and it requires more work on your part. So, I agree we go with the first approach at least for now. We may consider the tighter integration at some point in the future. Below are some specific comments, questions, and responses to your questions: * Have you thought of a name for the function? How about something like runpf_w_taps()? * I think what you propose for the tap changer and phase shifter input data seems fine for a very basic implementation. You may also want to include upper and lower limits on the tap ratio and phase shift angles. You might also want the number of tap positions, if you are considering discrete tap change values, though let’s limit it now to what you need for what you’ve implemented. * I think you do want to allow the user to pass in a MATPOWER options struct too. * Simply returning the power flow results struct should be fine. * So, something like … results = runpf_w_taps(mpc, tap_changer_data, phase_shifter_data, mpopt); * We should avoid unnecessary code duplication, so yes, it would make sense to adapt things to work with MATPOWER’s own code for building Ybus and Jacobian matrices. Feel free to set up your initial pull request with what you have now, but we will want to adapt it to use the MATPOWER versions before the pull request is merged. The pull request just gives us a place to discuss concrete changes to the code. * And, yes, for robustness, all functions that access the columns of the bus, branch, etc. matrices, should always use the constants defined by idx_bus, idx_branch, etc, rather than the literal column numbers. Thanks again, Ray On May 31, 2017, at 4:37 AM, Bone, Gorazd <gorazd.b...@fe.uni-lj.si<mailto:gorazd.b...@fe.uni-lj.si>> wrote: Hi. The transformer calculation is finished and I want to discuss what the flow of the function should be like (inputs and outputs, etc.) and how the function is constructed. Firstly, I should elaborate what the method does. It calculates the values for the taps and the phases of transformers according to the desired values for their regulation (taps control nodal voltage of some desired node, while phaseshifters control line power through their line). The transformers are connected at the first node of the line in the data. Calculations are carried out externally to the load flow calculation; the method looks at the results, calculates the first order sensitivity and minimizes the missmatch by Newton search. Unless I have made some mistakes the routine should work with correct first order sensitivities even when a tap changer and phase shifter are being calculated in the same branch. So, I have made it so that the case must be defined (e.g. case118) and the desired regulated tap and phase changers are then calculated(the ones that are not specifically marked as "to be calculated" will remain fixed). I was thinking to have the input in the form of (casedata_name_of_file , tap_changer_data, phase_shifter_data). Where the phase_shifter_data has the form [branches_of_transformers , controlled_nodes , desired_voltages] and the phase_shifter_data has the form [branches_of_phaseshifters , desired_power flows]. The output I think may be only the struct results, since the taps and phases are readily accessible in results.branch. The routine uses several additional functions, some of them are probably already present in the MatPower as it is (e.g. I calculated my own Ybus and my own Jacobian for power-missmatch-LoadFlow). I wonder if it I should adapt to work with provided MatPower capabilities or can I keep it the way it is. I also read the dev guide https://github.com/MATPOWER/matpower/blob/master/docs/MATPOWER-dev-guide.md and it recommends to work with idx_branch and idx_bus etc. I wonder if all the functions must follow that form? Also, should the inputs and outputs be in some other form? Regards, Gorazd ________________________________ Od: bounce-121560494-78535...@list.cornell.edu<mailto:bounce-121560494-78535...@list.cornell.edu> [bounce-121560494-78535...@list.cornell.edu<mailto:bounce-121560494-78535...@list.cornell.edu>] v imenu Ray Zimmerman [r...@cornell.edu<mailto:r...@cornell.edu>] Poslano: 25. maj 2017 22:08 Za: MATPOWER Developer List Zadeva: Re: Calculation of Taps and Phases of Transformers Hi Gorzad, Sorry for my slow response, swamped with other things, as usual … and thanks for your offer to contribute your work. The best way to contribute this is to follow the instructions<https://github.com/MATPOWER/matpower/blob/master/CONTRIBUTING.md#submitting-additions-or-modifications-to-the-code> from the MATPOWER Contributors Guide<https://github.com/MATPOWER/matpower/blob/master/CONTRIBUTING.md> on GitHub. This gives us a simple way for us to review your code, suggest or offer changes to it, and finally merge it into MATPOWER when it is ready. Please let me know if you need any help with getting things set up to make your pull request. By the way, for those of you considering having your contributions included in MATPOWER, it is always a good idea to discuss the idea here on the MATPOWER-DEV-L list early on in the process so that it can benefit from early feedback. It’s not problem if you don’t, it just has the potential of saving some effort on your part in the long run. Thanks again, Ray On May 22, 2017, at 3:22 AM, Bone, Gorazd <gorazd.b...@fe.uni-lj.si<mailto:gorazd.b...@fe.uni-lj.si>> wrote: Hi all, We're finishing up a routine that can calculate the Taps and Phases of Transformers in an OPF - like manner and would like to inquire what are the policies regarding contributions to MatPower. regards, Gorazd
