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 
<bounce-122304208-78535...@list.cornell.edu> v imenu Ray Zimmerman 
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.



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

 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,


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, 

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.

Reply via email to