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> 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.
>>
>>
>>
>
>
