I do think it makes sense for each device type to have its own field in the mpc struct. My suggestion is to finalize the overall design using the tap changers and phase shifters and go through the whole process of integrating the code, tests, and documentation for them first, using the existing pull request <https://github.com/MATPOWER/matpower/pull/16>. After that we can add each additional device type as it’s own separate pull request.
However, I think it would be good to propose here on the developers list the format of the data for each of the new device types to allow for some discussion. We want to make sure that we include all of the relevant pieces of data for each device type so that we won’t need to modify it in the near future. There are a number of other things I would like to change about the MATPOWER case format in an upcoming version, so it would make sense to try to include as much as we can in the next version of the case format. Ray > On Feb 20, 2018, at 2:42 AM, Bone, Gorazd <gorazd.b...@fe.uni-lj.si> wrote: > > > > OK Ray, I understand what you mean now. I'll give it a go after I finish > these other two projects that I currently have. > > There is just one thing that may become a problem, I think. > If I directly implement the power flow control devices into the mpc data (and > the change is also made in loadcase() ?), then that will add 10 new structure > elements, since there are 10 very different controllable devices that are > modeled. The addition is along the lines of mpc.oltc, mpc.qbt, mpc.upfc etc. > Sure this is ok? > > > regard, Gorazd > > Od: bounce-122304208-78535...@list.cornell.edu > <mailto:bounce-122304208-78535...@list.cornell.edu> > <bounce-122304208-78535...@list.cornell.edu > <mailto:bounce-122304208-78535...@list.cornell.edu>> v imenu Ray Zimmerman > <r...@cornell.edu <mailto:r...@cornell.edu>> > Poslano: 19. februar 2018 21:51 > Za: MATPOWER Developer List > Zadeva: Re: Controlalble devices (transformers, FACTS etc) > > Hi Gorazd, > > Just a quick clarification. I was not suggesting that runpf() be called as a > subroutine, but that inside runpf() we generalize the mechanism that already > calls the underlying power flow solver in a loop. And I agree, since it’s > already quite long, to simplify the runpf() function as much as possible, the > functionality implementing the various control updates (bus type changes, tap > and phase updates, etc) should be broken out into their own files. > > Thanks, > > Ray > > > >> On Feb 17, 2018, at 5:04 AM, Bone, Gorazd <gorazd.b...@fe.uni-lj.si >> <mailto:gorazd.b...@fe.uni-lj.si>> wrote: >> >> Hey. Thanks for your review for taps and phases. >> >> Yeah, that parenthesis was obviously wrong, haha. I seem to have only tested >> the code for cases when I had tap changers present. >> >> About having a common interface which calls the runpf() as a subroutine, I >> think we have to look at the thing as a constrained optimization problem if >> we want to preserve generality. The modelling criterion function then >> enters the constrained optimization problem as an equality constraint, >> because the equations that are seen by these control devices (e.g. the >> control equation of an OLTC) have to be exactly zero, while e.g. the cost of >> running the power plants cannot be zero and only their minimum is searched >> for. >> >> So, I'll look into the runpf() and combining this with the reactive limits >> of a generator first. I'll see if it can be done elegantly. I still suggest >> that some codes are done in separate files, because some files have a few >> hundred lines each and it may be a bit too large to view the file in trying >> to understand what it does. >> >> Also, I'd have to look at the functionality currently present in terms of >> control of runpf(). If I understand correctly, there is voltage control in >> terms of Qbus controlling magnitude of Vbus? Or are there other control >> functionalities as well? >> >> Oh, I nearly forgot. The sparse matrices that I was mentioning in the >> comments are not that much related to the system size, but more to the >> quantity of controlled devices. But I guess it's more elegant to do it >> properly anyways so.....I guess I'll fix that too. >> >> cheers, Gorazd >> >> >> >> Od: bounce-122298642-78535...@list.cornell.edu >> <mailto:bounce-122298642-78535...@list.cornell.edu> >> <bounce-122298642-78535...@list.cornell.edu >> <mailto:bounce-122298642-78535...@list.cornell.edu>> v imenu Ray Zimmerman >> <r...@cornell.edu <mailto:r...@cornell.edu>> >> Poslano: 16. februar 2018 22:32 >> Za: MATPOWER Developer List >> Zadeva: Re: Controlalble devices (transformers, FACTS etc) >> >> Hi Gorazd, >> >> First, thanks for your contributions and offers to contribute more and >> please forgive the long delay in responding to your previously submitted >> pull request <https://github.com/MATPOWER/matpower/pull/16>. I just >> responded to that. >> >> I think that the suggestions I made there would probably apply to this code >> as well. In particular, it seems that the most natural structure would be to >> add the necessary data in optional fields in the MATPOWER case struct (mpc) >> and then put the code inside runpf() which already has a similar loop for >> handling generator reactive limits. >> >> We may want to think about whether there is a nice way to generalize this >> mechanism so that there is a well-defined common interface for all code that >> involves calling the power flow as a subroutine. >> >> Thanks again, >> >> Ray >> >> >> >>> On Feb 14, 2018, at 7:05 AM, Bone, Gorazd <gorazd.b...@fe.uni-lj.si >>> <mailto:gorazd.b...@fe.uni-lj.si>> wrote: >>> >>> Hi all, >>> >>> I'm finishing my PhD which was in developing a new method for modelling >>> controllable devices in LF studies. The method is based on constructing an >>> external (with respect to the LF problem) criterion function in such a way >>> that the root of this function corresponds to the correct solution. So, the >>> LF routine is unaltered and I use runpf() as a subroutine. I have completed >>> the derivations and have tested the codes using MatPower. Seeing as there >>> are quite a lot of questions about this functionality I have decide that I >>> would like to make the codes available to others. >>> >>> The modelling is developed for transformers (OLTC, PAR, QBT), 1st gen FACT >>> (Series and Shunt compensation) and for 2nd gen.FACTS (STATCOM, SSSC, UPFC, >>> IPFC, GUPFC). >>> >>> So, does anybody think there is anything special to take into consideration >>> before I upload? >>> >>> Also, a question for Ray, I previously made a pull req on GitHub with tap >>> changers and phase shifters and I was wondering if that was ok? Because >>> maybe I'd do it similarly this time. >>> >>> regards, Gorazd. >>> >>> >>> >> >> > >
