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

Reply via email to