Re: FACTS INCLUSION

[Ray Zimmerman]

Let’s coordinate off-line initially, and then, on MATPOWER-DEV-L when it makes 
sense.

   Ray

> On Sep 27, 2017, at 2:38 PM, Ahmad Sadiq Abubakar 
>  wrote:
> 
> Thank you Ray for the reply,
> I wish to coordinate with you on this front. 
> How to I get involved and when likely are we going to start.
> 
> I was the one who contributed the voltage and branch limits enforcement in 
> CPF termination.
> 
> Regards. 
> Ahmad.
> 
> On Sep 27, 2017 7:33 PM, "Ray Zimmerman"  > wrote:
> I am not aware of anything specific being worked on at the moment related to 
> FACTS devices. However, over the next year, I plan to do some refactoring of 
> some of the core of MATPOWER to generalize things in a way that should make 
> modeling FACTS devices much easier. So, anyone seriously planning to work on 
> this area may want to coordinate with me.
> 
>Ray
> 
> 
> > On Sep 27, 2017, at 2:14 PM, Ahmad Sadiq Abubakar 
> > > 
> > wrote:
> >
> > Hi all,
> > Is there any development or progress on FACTS models inclusion in MATPOWER?
> >
> > Or rather what is the progress so far? Can I be involved in it?
> >
> > In anticipation of your responses.
> 
> 
> 
> 

Re: FACTS INCLUSION

[Ahmad Sadiq Abubakar]

Thank you Ray for the reply,
I wish to coordinate with you on this front.
How to I get involved and when likely are we going to start.

I was the one who contributed the voltage and branch limits enforcement in
CPF termination.

Regards.
Ahmad.

On Sep 27, 2017 7:33 PM, "Ray Zimmerman"  wrote:

I am not aware of anything specific being worked on at the moment related
to FACTS devices. However, over the next year, I plan to do some
refactoring of some of the core of MATPOWER to generalize things in a way
that should make modeling FACTS devices much easier. So, anyone seriously
planning to work on this area may want to coordinate with me.

   Ray


> On Sep 27, 2017, at 2:14 PM, Ahmad Sadiq Abubakar <
ahmad.abuba...@futminna.edu.ng> wrote:
>
> Hi all,
> Is there any development or progress on FACTS models inclusion in
MATPOWER?
>
> Or rather what is the progress so far? Can I be involved in it?
>
> In anticipation of your responses.

Re: FACTS INCLUSION

[Ray Zimmerman]

I am not aware of anything specific being worked on at the moment related to 
FACTS devices. However, over the next year, I plan to do some refactoring of 
some of the core of MATPOWER to generalize things in a way that should make 
modeling FACTS devices much easier. So, anyone seriously planning to work on 
this area may want to coordinate with me.

   Ray


> On Sep 27, 2017, at 2:14 PM, Ahmad Sadiq Abubakar 
>  wrote:
> 
> Hi all,
> Is there any development or progress on FACTS models inclusion in MATPOWER?
> 
> Or rather what is the progress so far? Can I be involved in it?
> 
> In anticipation of your responses.

Advice Regarding UCED

[Stephen Suffian]

I am attempting to look at the value of reduced forecasting error by
running a deterministic 24-hour UC using MOST, followed by a re-dispatch
and each hour (where it runs the same UCED but with the correct demand
value at the first time point in the redispatch, and then the forecasted
value for the rest fo the timepoints). I am currently running into a
problem where the re-dispatch doesn't have the correct initial conditions.

For each redispatch, I was able to assign the correct ramping constraints
at t=0 using profiles that adjust the PMAX and PMIN values of each
generator. However, I then ran into a problem where the re-dispatch is
choosing to de-commit generators at t=0 that were previously committed. I
used the profiles again to enforce the units that are already committed by
changing the CommitKey in the xgd table. I believe there may have been a
bug in apply_profile.m that I found that prevents people from updating the
xgd table with a profile, but I think I found the solution and submitted it
as an issue on github.

My end goal is to look at the added system cost of forecasting error, much
like was done in this paper ,
where they conduct hourly dispatch using MATPOWER opf. My current issue is
in regards to adding reserves. I don't want to add fixed zonal reserves, as
that won't help with the forecasting error. Instead, I'd like to add some
form of ramping reserves. I've played with the
PositiveLoadFollowingQuantity in the xgd table, but that seems to provide
an additional ramping constraint on each generator rather than guarantee a
level of ramping reserve.

I seem to have functioning code for the small tutorial 3 bus test grid, but
when I move up to the iEEE 30 bus network, I am still running into several
issues where I either see no difference in cost or there is significant
load shedding.

Does anyone have any advice in regards to how to compare an imperfect UCED
with hourly dispatch vs. a perfect UCED in Matpower MOST? Perhaps I am
going about this all wrong. Any advice in terms of generally how to conduct
that comparison would be greatly appreciated.

Thanks!
Stephen Suffian

FACTS INCLUSION

[Ahmad Sadiq Abubakar]

Hi all,
Is there any development or progress on FACTS models inclusion in MATPOWER?

Or rather what is the progress so far? Can I be involved in it?

In anticipation of your responses.

Re: Reactive Power Flow

[Ray Zimmerman]

The flows printed in the output are the injections from the bus into the 
corresponding end of the branch. Because of reactive losses (which can be 
negative, due to reactive power injection from line charging), the absolute 
values of the reactive flows at either end of the line are not expected to be 
identical. And in fact, when the line charging injections are high enough, as 
in branch 3, you see reactive power flowing out of the line at both ends.

So, the bottom line is that I’m not sure there is a universally accepted 
definition for “reactive flow” in a branch. I suppose you could use the average 
of the flow at the two ends or something, but you have to define what you mean 
by the term.

   Ray


> On Sep 26, 2017, at 1:05 PM, Mahbubur R  wrote:
> 
> Hello everyone, 
> I have some problem understanding  the direction of the reactive power flow. 
> How do I calculate the flow of reactive power through a single line (i.e. for 
> branch 1 here)? Also how to calculate the flow when signs for both of to and 
> from buses are negative (i.e. branch 3)? 
> 
> I know it has something to do with line susceptance, but could not exactly 
> figure it out. Should not the absolute value of reactive power flow from Bus 
> 1 to 4, and from Bus 4 to 1 should be the same?
> 
> I will highly appreciate some clarification regarding this. 
> 
> Thanks and regards -
> Mahi
> 
> Brnch   From   ToFrom Bus Injection   To Bus Injection Loss (I^2 * Z) 
>  
>   # BusBusP (MW)   Q (MVAr)   P (MW)   Q (MVAr)   P (MW)   Q 
> (MVAr)
> -  -  -            
> 
>1  1  4 70.88  9.34-70.61-15.22 0.268  1.30
>2  4  5 61.46  8.89-61.22-15.77 0.237  1.13
>3  5  6-28.78-14.23 28.92 -7.72 0.140  0.69
>4  3  6 85.00  5.80-84.62-11.14 0.378  1.83
>5  6  7 55.70 18.87-55.49-25.82 0.218  1.04
>6  7  8-44.51 -9.18 44.85-11.70 0.334  1.65
>7  8  2   -161.62 -6.01163.00  5.54 1.378  6.68
>8  8  9116.77 17.70   -115.92-21.54 0.855  4.08
>9  9  4 -9.08-28.46  9.15  6.33 0.066  0.32

Re: Tap ratios set to 0, run OPF with tap changers

[Ray Zimmerman]

I should also mention that the pull request Shri referenced with respect to 
transformer taps is for power flow, not OPF.

Ray


> On Sep 26, 2017, at 11:49 AM, Elis Nycander  wrote:
> 
> Hey, thanks for your answers. 
> 
> Indeed the solution is the same if the tap ratios are set to 0 or 1 (as long 
> as the SHIFTS are all 0), it was just an error on my part.
> 
> Ah, no callback for OPF? I just assumed that there was something similar to 
> the callback functions in the CPF. Thanks for the links.
> 
> Regards,
> Elis
> 
> 
> 
> 2017-09-25 18:34 GMT+02:00 Abhyankar, Shrirang G.  >:
>  
> 
> Dear Matpower users,
> 
> I have some questions about tap ratios in Matpwer. 
> 
> What does it mean if the tap ratios TAP are set to 0?
> 
> Tap ratio=0 is used to indicate that the branch is a non-transformer branch, 
> while 1 indicates a transformer branch. Even if you set the tap ratio = 0 for 
> a transformer, MATPOWER internally uses a unity tap ratio meaning a 1:1 
> voltage transformation.
> 
>  I have previously run some power flows without caring about the tap ratios 
> (TAP = 0). Now I set them to 1, and got quite different results.
> 
> I don’t think this should happen. With 0 or 1, the power flow results should 
> be same.
> 
> I can't see that the admittance matrix in Figure 3.1 in the manual is well 
> defined for zero tap ratio, so I thought setting them to 0 was like 
> deactivating them.
> 
> Also, if I want to run an OPF with active tap changers, would it be best to 
> include the tap ratios directly in the optimization constraints or to change 
> the tap ratios in a callback function? Or maybe I can run several OPFs and 
> change the tap ratios manually between each?
> 
> 
> Incorporating tap changers in OPF is a non-trivial task. Moreover, I don’t 
> think there is a callback function in PF or OPF. 
> 
> Here are some relevant discussions from the mailing list.
> 
> https://www.mail-archive.com/matpower-l@cornell.edu/msg04162.html 
> 
> https://www.mail-archive.com/matpower-l@cornell.edu/msg03339.html 
> 
> Note that there is a pending pull request for this feature. You can try that 
> out if you like.
> 
> Shri
> 
> 
> Regards,
> Elis Nycander
> 
> 

Re: Doubt regarding adding constraints

[Ray Zimmerman]

Voltage magnitude constraints are already included. Simply set the VMIN and 
VMAX columns in the bus matrix to the desired values.

For voltage angles, simply define the A, l and u corresponding to equation 
(6.25) in the User’s Manual 
. Something 
like the following …

mpc = loadcase();
nb = size(mpc.bus, 1);
ng = size(mpc.gen, 1);
mpc.A = sparse(1:nb, 1:nb, 1, nb, 2*nb+2*ng);
mpc.u = 0.26 * ones(nb, 1);
mpc.u = -mpc.l;

— Ray



> On Sep 23, 2017, at 5:25 PM, Viswanath Hariharan  wrote:
> 
> Hello Sir
> 
> I want to add voltage magnitude and voltage angle constraints to the
> opf solver but I am not able to figure out how to.
> 
> Voltage magnitude constraints --->  0.9 <= Vm <= 1.1
> Voltage angle constraints ---> - 0.26 <= Va <= 0.26 (Unrelaxed form)
> 
> I read a post where you mentioned to add these constraints to the case
> struct which looked pretty simple in the post but I didn't know how to add
> that to the case struct.
> I was wondering if you can guide me on how to do it. Hoping to hear from
> you soon.
> 
> Regards
> Viswanath Hariharan
> Graduate Research Assistant
> Electrical Engineering
> University at Buffalo

Re: Shunt looses

[Ray Zimmerman]

I’m not sure whether you are referring to bus shunts or the shunt portions of 
the transmission line model. And it’s not clear whether you are referring to 
including losses in the model itself or in the loss numbers that are output to 
the command window.

Both bus shunt and line charging losses are included in the model MATPOWER 
uses. The losses printed in the command window for branches are only the series 
losses, but you can get all of the losses via the get_losses() 
 
function.

Ray


> On Sep 22, 2017, at 1:19 PM, wgneu.katzenma...@t-online.de wrote:
> 
> Hello,
>  
> i am comparing DIgSILENT Powerfactory with Matlab Matpower.
>  
> Does Matlab Matpower include shunt looses. There is a difference about 0,977 
> % between my input shunt values in caseformat and the command window output.
>  
>  
> Thank you for the answer.
> 
> 
>  
> Gesendet mit Telekom Mail  - kostenlos 
> und sicher für alle!

Re: MATPOWER discussion forummatpowe...@list.cornell.edu

[Ray Zimmerman]

Hi Vlad,

Yes, it should work just fine to add solar in the same way. I suggest making a 
copy of addwind.m and calling it addsolar.m. Then edit addsolar.m and replace 
“wind” with “solar” everywhere and use it just like you do with addwind.m. The 
2 key differences are the fuel type that is used and the varname passed as the 
last argument to loadgenericdata(). 

For the graphical visualization, have a look at the plot_case() function that 
is defined and used in the tests, t_most_uc, t_most_suc, etc.

Ray

> On Sep 22, 2017, at 4:43 AM, Vlad  wrote:
> 
>  Dear Ray,
> 
> I would like to create a UC 24h model with a 3 coal power stations and add to 
> them wind and solar power sources.
> 
> In MOST is a special command 'addwind' for adding wind generator with the 
> determined power output profile. Can I create in the same way solar 
> generation? 
> 
> Or what is the best way of adding solar (PV) generation? I have the power 
> output profile from PV already.
> 
> Could you give me advice or maybe some examples.
> 
> And how can I do the graphical visualization of the result? The same as in 
> the examples.
> 
> Thank you!
> 
> Best regards,
> 
> Vlad
> 

Re: Zonal reserve with stochastic Wind generation in MOST

[Ray Zimmerman]

The zonal reserves in MOST are designed for deterministic problems. See 
footnote 19 at the bottom of page 35 in the MOST User’s Manual 
.

So, it is designed to handle either zonal reserve requirements or stochastic 
wind, but not both simultaneously. A clear understanding of MOST's problem 
formulation as described in the manual should help here.

   Ray


> On Sep 21, 2017, at 8:53 PM, Quarm JNR, Edward A 
>  wrote:
> 
> 
> Dear All,
> 
> I am running a multi-period simulation with :
> 
> Zonal reserve requirement
> Stochastic Wind generator
> Load profile 
> 
> My output for reserve generation always includes an extra row for the wind 
> generator but with zero output. For example, I have 5 generators in my system 
> and I add a Wind generator making it 6 generators. The output for reserve 
> generation will have 6 rows with the last row having zero output.
> 
> I would like to know, how does MOST consider the wind generator in running 
> unit commitment simulations with regards to zonal reserve.
> Is the wind generator constrained to have zero output or is it totally 
> ignored when optimizing the multi period reserve generation?
> What if the Wind generator belongs to a reserve zone?
> If the wind generators don't play any role in zonal reserve why are they 
> included in the output?
> 
> Thanks in advance for your clarification. 
> 
> Best regards,
> Edward

Re: How to calculate the power flow for specific branch and curtail the generator accordingly

[Ray Zimmerman]

If you are trying to adjust the generation to respect a branch flow limit it 
sounds like you want to do an optimal power flow. In an OPF the flow limits are 
respected and the generator dispatch depends (primarily) on the generator 
limits and the relative costs of the generators, as well as other network 
constraints such as those on branch flows.

Ray


> On Sep 20, 2017, at 6:53 PM, Charalambos Ioannou  
> wrote:
> 
> Hello guys,
> 
> I have a 3 bus system with 3 generators (at bus 1 type PQ with generated 
> power 100 MW and demand 50 MW, bus 2 Type PV solar generator with generated 
> power maximum 50 MW and demand 50 MW, bus 3 the sluck bus)
> 
> What i am trying to do is:
> 
> I defined different demands (A) as shown in the code below and change the 
> demand every minute for busses 1 and 2 and i am saving the results from the 
> branches.
> 
> mpc = loadcase('micha');
> A = [10;20;30;40;50;60;70;80];
> x = [];
> for i = 1:8
> mpc.bus(1:2,3) = A(i);
> results = runpf(mpc);
> x = [x;results.branch(2,14)];
> if x(i) > 80 
> mpc.gen(2,2) = 0;
> end
> end
> What i am trying to do next is to check the violation between bus 2 and 3 
> based on the results i am saving from the branches. I want the power flow to 
> be equal to 80 MW or less through that branch (2 and 3). So in the code i 
> define it above and based on the results i am getting from the branches i 
> want to change the generated power from the solar generator.
> 
> For example if generator 1 generate 100 MW and the solar generator 50 MW i 
> have in total 150 MW if the demand changed in 10 MW each the total demand 
> will be 20 MW and the power flow through branch 2 and 3 will be 130 MW but i 
> don't want this i want 80 MW and i have to curtail the solar generator. So in 
> that case i curtail the solar generator at 0 MW and run again the power flow 
> to check if its satisfy the limits i set but i am not getting the results i 
> want.
> 
> How can i do that in programming and set the demand for different values and 
> curtail the solar generator each time to respect the limits i want??
> 
> Thanks in advance!

Re: Adding Wind Generation to Profiles

[Ray Zimmerman]

Josh,

Looks like you got it working by splitting out the individual wind profiles. It 
should also work to set the rows field to [1:7] and then define a matrix of 
profiles for each of the 7 generators by assigning an nt x 7 matrix to 
windprofile(:, 1, :).

Hope this helps,

Ray




> On Sep 23, 2017, at 9:20 PM, Joshua Sebben  wrote:
> 
> Stephen,
>  
> Thank you so much! That works a treat!
>  
> Regards,
>  
> Josh
>  
> From: Stephen Suffian 
> Sent: Saturday, 23 September 2017 3:03 AM
> To: MATPOWER discussion forum 
> Subject: Re: Adding Wind Generation to Profiles
>  
> Check out the 'help get_profile'. Much like you pass the previous profiles 
> object on the load profile line, you can pass the previous profiles object on 
> the other lines:
> 
> profiles = getprofiles('wind_profile1',iwind);
> profiles = getprofiles('wind_profile2',profiles,iwind);
> profiles = getprofiles('load_profile_30',profiles)
> 
> See if that works!
>  
> On Thu, Sep 21, 2017 at 7:24 PM, Joshua Sebben  > wrote:
> Stephen,
>  
> Thank you for your reply.
>  
> casefile = 'case30_modified_MedPen';
> mpc = loadcase(casefile);
> xgd = loadxgendata('xgd_uc_30_MedPen', mpc);
> [iwind, mpc, xgd] = addwind('wind_uc_30_MedPen', mpc, xgd);
> profiles = getprofiles('wind_profile1', iwind);
> profiles = getprofiles('wind_profile2', iwind);
> profiles = getprofiles('wind_profile3', iwind);
> profiles = getprofiles('wind_profile4', iwind);
> profiles = getprofiles('wind_profile5', iwind);
> profiles = getprofiles('wind_profile6', iwind);
> profiles = getprofiles('wind_profile7', iwind);
> profiles = getprofiles('load_profile_30', profiles);
> nt = size(profiles(1).values, 1);   % number of periods
>  
> I created the 7 wind profiles with each of the row counts changed to 1 to 7 
> for their respective generators.
>  
> This would then change my main code assuming to the snippet above? 
> This again also has the problem of only changing the last generator in the 
> list as each of the previous wind profile changes are overwritten by the new 
> getprofile?
>  
> Regards,
> Josh
>  
> On 22 September 2017 at 04:02, Stephen Suffian  > wrote:
> 
> I also couldn't figure it out, but I got around it by adding a separate 
> profile for each generator and changing the rows value. So if a wind 
> generator is in row 5, you would have the struct look like this below.
> 
>  
> windprofile = struct( ...
> 'type', 'mpcData', ...
> 'table', CT_TGEN, ...
> 'rows', 5, ...
> 'col', PMAX, ...
> 'chgtype', CT_REL, ...
> 'values', [] );
>  
> And then for row 6 you would add another profile with the struct looking 
> tlike this:
>  
>  
> windprofile = struct( ...
> 'type', 'mpcData', ...
> 'table', CT_TGEN, ...
> 'rows', 6, ...
> 'col', PMAX, ...
> 'chgtype', CT_REL, ...
> 'values', [] );
>  
> It is a bit of a work around, but I believe it should work (I did something 
> similar to set the Pmax for each conventional generator in a profile, so I 
> imagine it will work the same).
>  
> On Thu, Sep 21, 2017 at 1:52 PM, Stephen Suffian  > wrote:
> I also couldn't figure it out, but I got around it by adding a separate 
> profile for each generator and changing the rows value. So if a wind 
> generator is in row 5, you would have the struct look like this below.
> 
>  
> windprofile = struct( ...
> 'type', 'mpcData', ...
> 'table', CT_TGEN, ...
> 'rows', 5, ...
> 'col', PMAX, ...
> 'chgtype', CT_REL, ...
> 'values', [] );
>  
> And then for row 6 you would add another profile with the struct looking 
> tlike this:
>  
>  
> windprofile = struct( ...
> 'type', 'mpcData', ...
> 'table', CT_TGEN, ...
> 'rows', 6, ...
> 'col', PMAX, ...
> 'chgtype', CT_REL, ...
> 'values', [] );
>  
> It is a bit of a work around, but I believe it should work (I did something 
> similar to set the Pmax for each conventional generator in a profile, so I 
> imagine it will work the same).
>  
> On Thu, Sep 21, 2017 at 5:39 AM, Joshua Sebben  > wrote:
> By the way,
>  
> I have also tried setting the row count to [1 2 3 4 5 6 7] for my 7 extra 
> generators that I want to add, however when I run my code I get an error:
>  
> Error using apply_profile (line 148)
> apply_profile: third dimension of profile.values should match length of pro=
> file.rows
>  
> Error in loadmd (line 508)
> optab =3D apply_profile(profiles(p), optab);
>  
> Error in Test (line 33)
> mdi =3D loadmd(mpc, transmat, xgd, [], [], profiles);
>  
> Regards,
> Josh
>  
> On 20 September 2017 at 22:17, Joshua Sebben  > wrote:
>