Re: MOST preventive security

[Carlos E Murillo-Sanchez]

  
  
Dear Igor, please see comments below.
  
  Igor Verbruggen wrote:


  
  
  
  
  
Dear all,
 
I am attempting to use
MOST to formulate a DC security constrained OPF, with
preventive and corrective redispatch/curtailment.

If I understand MOST’s approach to security correctly, it is
aimed at determining a base case dispatch (e.g. a day-ahead
schedule), and corresponding contingency state dispatches
(e.g. a real-time dispatch) that are reachable from the base
case (within ramping and reserve constraints). Hence, the
approach is mostly corrective, yet some preventive action is
also taken as the optimization attempts to converge to a
secure base case dispatch. By assigning the
PositiveActiveDeltaPrice and NegativeActiveDeltaPrice, it is
possible to set a preference for the generators to use for
corrective actions, by penalizing them more or less compared
to the others.
  

There is one key feature in MOST's treatment of the day-ahead
optimal quantities for generators which is unlike other optimal
stochastic planning models in the literature.  These day ahead
optimal quantities (called contracted quantities in MOST) do not
necessarily correspond to base case dispatches.  In MOST, there may
be several base case dispatches for a given time period, each
representing a realization of an uncertain parameter associated to
continuous-varying uncertainty such as wind or solar resources. 
Thus, there isn't a single base case day ahead dispatch.  Instead,
MOST computes the optimal day-ahead contracted quantities (the
optimal contract posture, Pc in MOST) from which it will be feasible
to reach any realization of these uncertain parameters during
operation.  This decoupling of the notion of "base case dispatch"
and "optimal day ahead contracted quantities" is a major conceptual
characteristic in MOST.

Typically, when modeling wind, you will have several base cases in a
time period, each with a different PMAX value for the wind
generator.  If there is a curtailment penalty for wind, the
corresponding cost function could even have negative marginal cost.

  

 
Now, in my case the grid
is being supplied by a number of wind generators that can be
curtailed to any value below PMAX. When I remove all
corrective costs, and set the maximum contingency reserves
to 0, the dispatch in base case and all contingency states
will be “preventively” secure (and equal). However, the
dispatch is made entirely on a market basis (all
curtailments are driven by the generator cost functions). I
would therefore like to add penalty costs, say, a
curtailment cost per MW that the base case deviates from
PMAX. That way, for preventive actions it is possible to
control which generators are most likely to curtail.
  

Reserves are meant to be used for dealing with the other kind of
uncertainty considered in MOST: discrete events such as line and
generator outages, but they also define a "range" over which a
generator can be redispatched (from the contracted quantity) during
operation in order to reach a dispatch that is appropriate for a
given renewable source realization.  In MOST's model, it doesn't
make much sense to set the limits of the reserves to zero for
renewable sources, since they will vary their dispatch according to
the realization of the resource.  If reserve limits are set to zero
the only feasible solution will be to uniformly set the dispatch to
the minimum of the PMAX values considered for the resource - hardly
an optimal choice.  Instead, normally the reserve limits for these
generators are  set free (very large values).

It is also important to see that for the lowest marginal cost
resources, their redispatch deltas actually constitute flexibility
that will be exacted from the system in order to accommodate the low
cost resource - the contrary of the usual notion of flexibility.


  
Is there a
straightforward/documented way to edit the objective
function and achieve this? I have seen a similar question
previously
(https://www.mail-archive.com/matpower-l@cornell.edu/msg07231.html)
where the response was to add new variables / constraints in
the appropriate places of the most.m file, but I struggle to
find documentation on how this works exactly.
 
Kind regards,
Igor Verbruggen
  

If you use the multiple scenario/base 

Re: Calculate shunt capacitance

[Carlos E Murillo-Sanchez]

  
  
naime ahmadi wrote:


  
  
  
Hello,
I want to calculate shunt capacitance (c) in the
  attached figure.
In the branch data of MATPOWER we have b.
Is it correct to use this formulation to calculate c
c=b/(2*pi*f)
  

  
Kind regards,
Naime
  
  

Hi;
  
  You need to consider that B is in p.u. , so the physical
  capacitance computation must take that into account:
  
  C (Farads) =  (Pbase/Vbase^2) * Bpu / (2*pi*f)
  
  Carlos.
  

  

Re: Ybus

[Carlos E Murillo-Sanchez]

  
  
Slight correction:
  
  Sf = V( mpc.branch(:, F_BUS) ) .* conj(Yf * V);
  St = V( mpc.branch(:, T_BUS) ) .* conj(Yf * V);

  carlos.
  
  Ray Daniel Zimmerman wrote:


  
  
  In matrix form, you can do the corresponding calculations as
  follows (e.g. for 
case9):
  
  
  define_constants
  mpc = loadcase('case9');
  [Ybus, Yf, Yt] = makeYbus(mpc);
  V = mpc.bus(:, VM) .* exp(1j * mpc.bus(:, VA)*pi/180);
  Sbus = V .* conj(Ybus * V);
  Sf = V .* conj(Yf * V);
  St = V .* conj(Yt * V);

Here Sbus are the
  bus injections into the branches (equal to the generation –
  load), and
  Sf and 
St are the branch power flows at the from
  and 
to ends, respectively.


    Ray





  
On Oct 10, 2022, at 1:41 AM, naime ahmadi 
  wrote:


  
I have forgotten to attach the picture.


  
  
  
On Mon, Oct 10, 2022
  at 3:40 PM naime ahmadi 
  wrote:


  
Hello,
I have a question regarding equations
  (2) and (3) in the attached picture.
I am not sure equation (3) is correct.
  But sj is the power injection and
  f{i,j} is the power flow.
I am a littel bit confused, how should
  I calculate y*{j,k}  and 
Yjk  in Matpower?  
According to the attached picture 
  y*{j,k} is line adminance vector and Yjk bus
  adminance matrix. How can I calculate them from
  Ybus?

Thank you,

Naime

  

  
  
  


  


  

Re: Question about case9

[Carlos E Murillo-Sanchez]

  
  
Ahmad Bariq Al Fahri wrote:


  
  
  
Thank you Carlos for the information. 
As in Case 9, all bus voltage is specified to be 345 kV. If
  the transformer defaults ratio is 1:1, does it mean that the
  generator is connected in 345 kV as well? Thank you.


Best regards,

  

  

  Ahmad

  

  

  

Dear Ahmad:

No, it just means that the winding ratio corresponds exactly to the
ratio of the nominal voltages on both sides of the transformer.  The
TAP setting corresponds to off-nominal deviations, not to the
physical winding ratio.  In fact, the nominal voltages at the
generator buses for case9.m are really  16.5, 18, and 13.8 KV, while
the nominal transmission voltage is 230 KV if I recall correctly. 
MATPOWER only uses the (already converted to pu) branch impedances,
the system MVA base, and the off-nominal TAP ratio; the BASE_KV
column in the bus matrix is not used for power flows.

Carlos.

  

Re: Question about case9

[Carlos E Murillo-Sanchez]

  
  
Ahmad Bariq Al Fahri wrote:


  
I would like to ask about case9.m (9 bus, 3 generators
  case) system configuration. As I know that the parameters of
  'TAP' (column 9) in the branch data are set to zero, does it
  mean that the system does not consider transformer modelling?
  Is the generator directly connected to the 345 kV bus? I am
  looking forward to your reply. Thank you in advance.


Best regards,

  

  
Ahmad

  

  

  

Dear Ahmad:

In MATPOWER, if the TAP column has a zero, then the ratio defaults
to 1:1, in the sense that 1 pu at the "FROM" end produces 1 pu at
the "TO" end of the ideal transformer in the generalized branch
model.  Indeed, if you assign 1.0 to the TAP column you will get the
same results.

Carlos.

  

Re: How to change the power injection

[Carlos E Murillo-Sanchez]

  
  
naime ahmadi wrote:


  

  Hello,

How can I change
the power
  injection
to flow
measurement?
For
example, in the IEEE 14-bus system, bus 2 is connected to
buses 1, 3, 4, and 5. We have injection measurement at bus
2. From here:

  
Sbus_lf
= V .* conj(Ybus * V);
P_inj= real(Sbus_lf);
P_inj(2)

  
After
this, I do not know how to translate power injection to
flow?
  

I think (but I could be wrong) that what you want to do is to
compute the injections into branches.  makeYbus provides the line
admittance matrices into their "from" and "to" ends.  Thus, the
vectors of complex power injections into the "from" and "to" ends of
the branches can be computed as follows:

define_constants;
mpc = loadcase('case30');
[Yb, Yf, Yt] = makeYbus(mpc);
V = mpc.bus(:, VM) .* exp(1j*mpc.bus(:, VA)*pi/180);
Sf = V(mpc.branch(:, F_BUS)) .* conj(Yf * V);
St = V(mpc.branch(:, T_BUS)) .* conj(Yt * V);

Carlos.


  

Re: Building Bus Impedance Matrix for IEEE 33-Bus Radial System - Matpower

[Carlos E Murillo-Sanchez]

Harun Hökelek wrote:

Dear all,

I’m trying to obtain bus impedance matrix of IEEE 33-Bus test system by 
inversing admittance matrix.
However inv(makeYbus(case-data)) gives badly scaled or singular warning.
Is there any way to get the bus impedance matrix of this system?
Sincerely,

Harun
Dear Harun, it is very likely that your network does not have any return 
path to ground.  This can happen if all your branches are just serial 
elements, and there are no shunt elements.  In that case, we can say 
from first principles that the impedance matrix does not exist;  think 
about it for a moment: what happens when you connect a current source to 
the terminals of a network that does not offer a return path?


Carlos.

Re: DC Jacobian calculation

[Carlos E Murillo-Sanchez]

naime ahmadi wrote:

Dear Professor Ray,
I have a 3 bus system and want to calculate the DC Jacobian. I 
attached the result that I want. My problem is that I do not know 
which function in MATPOWER does exactly this calculation.

I also attached the 3 bus system in MATPOWER format.

Look at the function makeBdc.m

>> [Bdc, Bf, Io, Iof]=makeBdc(mpc);
>> J = [  Bf ; -Bf ; Bdc ]


carlos.

Re: Issue with flattening piecewise linear cost function in OPF

[Carlos E Murillo-Sanchez]

  
  
Müller, Tobias wrote:


  
  
  
  
  
Hello everyone,
 
I have problems when I
have a piecewise linear cost function on some generators
which increases slower after a break point as the power
increases in my OPF. You can see an exemplary figure of the
cost function here:

 
 
 
 
 
 
 
 
 
 
 

  

Hi Tobias;

Unfortunately, the CCV formulation that MATPOWER uses for modeling
piecewise linear cost functions only works for convex cost functions
(see section 6.4.1 in the manual
https://matpower.org/docs/MATPOWER-manual-7.1.pdf). 

Carlos.




  

Re: nodal prices become zero, when using flexible generators

[Carlos E Murillo-Sanchez]

  
  
Matthias:
  
  You are specifying piece-wise linear costs with corner points at
  (100, 1000) and (110,1000).  That's a single flat linear segment,
  which of course will have a marginal cost of zero.  In general, if
  these flexible generators are not against a limit, they will set
  the nodal price at the bus that they're at to zero.
  
  Carlos.
  
  Matthias Greiml wrote:

Dear Matpower Community,
  
  
  I've been trying for several
days, but
I can't find the reason for following Matpower behaviour.
  
  
  In my generator list, there are
several
"flexible generators" (explaination below image), this is how
GEN matrix looks like:
  
  
  
  The values in row 9 and 10 are
determined
based on a bus' flexibility potential (e.g. comming from pumped
hydro,
heat pumps, combined cycle power plants at each corresponding
bus), therefore
power can be consumed or produced by the generator. 
  
  The associated cost function is
as following:
  
  
  
  
  My question is: whenever I active
above
mentioned generators (column 8 = 1), the nodal prices of all
buses are
zero. If I deactivate all flexible generators, the nodal prices
are nonzero.
I don't understand why - can anyone explain this behaviour to
me? (Note
there are several other generators implemented as well, which
are operated
as generator only at costs between 20 to 100 $/MWh:
  
  
  
  
  Thank you for any idea / solution
in
advance.
  
  
  Best regrards from Austria,
  
  Matthew
  
  
    
  
  


  

Re: Constructing IEEE second benchmark for subsynchronous resonance using matpower

[Carlos E Murillo-Sanchez]

  
  
yangyang wrote:


  
  Thank you Carlos, I have also found it; the tap should be the
ratio of per unit voltages instead of nominal voltages. But
after changing the tap to 1, the power flow shows that all buses
are 1 pu 0 degree, and it still differs from the load flow
results in the Simulink example calculated using load flow block
in Simulink's powergui, in which the angle at bus 4 is around
-30 degree. I think it is because of the tap ratio and shift;
the transformer has some resistance and inductance, and matpower
manual says that the ratio has something to do with the
impedence of the transformer, but I dont know how to calculate
the tap ratio correctly based on the transformer impedence.
  


  Best Regards,
  Yang Yang

  
   
  

The transformer after the generator is most likely a delta-wye
connection,  which would explain the generator's voltage lagging by
30 degrees the rest of the system.  Set the tap ratio to 0 or 1.0 (0
means no off-nominal tap ratio), and the angle shift parameter to 30
degrees (SHIFT column) and you'll get what you need.

carlos.
  

Re: Constructing IEEE second benchmark for subsynchronous resonance using matpower

[Carlos E Murillo-Sanchez]

  
  
yangyang wrote:


  
  Hi Carlos, I think there is a bus labeled 1 in the bus field,
next to the "mpc.bus" in the file, and it is a slack bus. If
there was not a slack bus, runpf() will report an error. So this
may not be the problem of my case...
  


  Best Regards,
  Yang Yang

  

You're right, my bad.  A 5 second glance is a bad idea.  I now see
a  problem: you have an impossible  22.7273:1 tap ratio in branch 4,
leading to outrageous losses and reactive dispatches in the power
flow solution.  

carlos.
  

Re: Constructing IEEE second benchmark for subsynchronous resonance using matpower

[Carlos E Murillo-Sanchez]

  
  
yangyang wrote:


  
  
Dear all,
I am trying to construct the
  power flow of IEEE 2nd benchmark for SSR study; and my
  implementation is as attached. The capacity compensation is
  55% and the other data can be found in the paper
  (https://ieeexplore.ieee.org/document/4118844) I am not
  attaching the paper because there is size limit. However, the
  power flow results differ a lot from the example in Simulink;
  runpf() shows that the angle at all buses are 0 but the
  example in Simulink (https://www.mathworks.com/help/physmod/sps/ug/steam-turbine-and-governor-system-subsynchronous-resonance.html?searchHighlight=subsynchronous%20resonance&;s_tid=srchtitle)
  shows that the angle at the terminal of the generator is
  around -30 degrees. How can I reproduce this correctly? Thank
  you.

  
  
Best Regards,
Yang Yang
  

  

After a five second glance at your file, I see that your fist
generator is assigned to a bus with a label of '1';  however, in
your bus table there is no bus with such a label.  Also, you don't
have a reference bus.  Additionally, the interconnections in your
branch table would imply the existence of at least four buses
labeled "1", "2", "3" and "4", but as said earlier, "1" is missing.

carlos.
  

Re: loss as objective function

[Carlos E Murillo-Sanchez]

  
  
Hi all;
  
  Actually, what  you need to do is to set equal linear costs for
  all generators.  If all linear cost coefficients are 1.0, for
  example, then you get to minimize the sum of all generation, which
  is a proxy for minimizing losses.
  
  carlos.
  
  Michal Polecki wrote:


  Hello,
  
  
  if you set operation costs of power plants to zero, than
power losses costs are the only one left. Have you tried this
approach?
  
  
  BR,
  Michal Polecki
  
  
  On 03/01/21 11:54, Karthikaikannan D 
 wrote:
  


  

  

  Dear all,
  how to make the total active power loss as
the objective function instead of summation of
all cost function in opf
  
  
  
Regards,
  Dr.D.Karthikaikannan
  Assistant Professor III,
  

  

  

  
  


  

Re: circulating current (MVAR loss)

[Carlos E Murillo-Sanchez]

  
  
Russ Patterson wrote:


  
  
  
  
Hi
- I am still trying to hand calculate the flow
into branch 2 from bus 1 to bus 2.  I can’t get my results
to match MATPOWER.
 
I
get Q into the banks from bus 1 of,
   
Bank #1:    24.00 MVAR
   
Bank #2:  -25.02 MVAr
 
Attached
is my short calculation and the .m file.  Is there a way to
have MATPOWER barf out the YBUS matrix?
  

>> help makeYbus

If buses are numbered consecutively starting from 1 in the bus table
(see ext2int if not), simply type:

>> mpc = loadcase('mycase');
>> [Yb, Yf, Yt] = makeYbus(mpc)

To get all the relevant current injections in the solved case,
simply do

>> mpc = runpf(mpc);
>> define_constants;
>> V = mpc.bus(:, VM) .* exp(1i * mpc.bus(:, VA)*pi/180);
>> Ibus = Yb * V
>> Ifrom = Yf * V;
>> Ito = Yt * V;

From there, compute power injections as

>> Sbusinj = V .* conj(Yb * V);
>> Sfrominj = V(mpc.branch(:, F_BUS)) .* conj(Yf * V);
>> Stoinj  = V(mpc.branch(:, T_BUS)) .* conj(Yt * V);

carlos.

  

Re: pf.nr.max_it

[Carlos E Murillo-Sanchez]

  
  
Russ Patterson wrote:


  
  
  
  
Hi friends,
 
Per Table 4-2 in the manual, I
want to increase the number of iterations to solve my power
flow.  So, I added a line to my .m file as you see below. 
But, it seems to be ignored as I only get 10 iterations.  Is
this the proper place to specify?
 
 
%% MATPOWER Case Format : Version 2
mpc.version
  =
'2';
%
%% Try to run more than the default
10 iterations
%pf.alg
= 'NR';
pf.nr.max_it
  =
30;
 
Here was result:
 
Newton's
method power flow (power balance, polar) did not converge in
10 iterations.
 
> 
Did NOT converge (3.60 seconds)  <
 
 
Thank
you,
russ
 
p.s. Just fyi, when I search the
pdf manual on “pf.nr.max” it works fine.  Searching on
“pf.nr.max_it” finds nothing.   If I replace the underscore
with a space then search will find occurences of
pf.nr.max_it just fine (“pf.nr.max it”). Weird!
  

Russ:

The options structure must be passed along as an optional argument
to runpf().  Something along these lines:

method 1: tell mpoption to modify a specific field in the returned
structure
>> myoptions = mpoption('pf.nr.max_it', 20)
>> mpc_out = runpf('case30', myoptions);

method 2: create a default options structure and manually modify a
field in it:
>> myoptions = mpoption;
>> myoptions.pf.nr.max_it = 20;
>> mpc_out = runpf('case30', myoptions);

Note that all MATPOWER functions also use the traditional MATLAB
"help" documentation;  I suggest that you do these at least:

>> help caseformat
>> help mpoption
>> help idx_bus
>> help idx_gen
>> help idx_brch
>> help idx_cost
>> help runpf

carlos.


  

Re: infinite bus, 1 branch/1 gen

[Carlos E Murillo-Sanchez]

  
  
Russ Patterson wrote:


  
  
  
  
Hi
Carlos,
 
Thank
you.  That makes sense.  Based on that, I would expect to be
able to set the bus voltage, Vm, and it stick, but it
doesn’t.  If I set Vm=2 and run the load flow it solves
properly with the resulting bus voltage being 1.154pu.
 
So,
in essence, I am specifying the magnitude for the
slack bus in the “mpc.gen Vg” setting, and then I am
specifying the angle for the slack bus in the
“mpc.bus Va” setting.  You would expect both mag and angle
to be specified in the same place.
 
This
is counterintuitive, which is why I ask if this level of
detail about how input is used/overridden is documented
anywhere – or if it will just be a learn-by-trying approach.
 
Either
way, I’m very happy to have found this fantastic software. 
Thank you for your help.
 
Best
regards,
Russ
  

Dear Russ:

You are right;  the data structure for MATPOWER was originally
chosen to resemble what where then popular industry formats for
power flow, with the corresponding outstanding assumptions about
what is input data and what is output data in the power flow
problem.  When using this data for other problems (such as optimal
power flow), it becomes even less clear if you haven't been a
long-time follower of the development of those data formats.  For
example, for power flow the generator voltages are input from the VG
column of the gen() matrix as you discovered. But for optimal power
flow, the bus voltage limits (which then the generators must also
respect) are specified in columns VMAX and VMIN in the bus() matrix.

Carlos.

  

Re: infinite bus, 1 branch/1 gen

[Carlos E Murillo-Sanchez]

  
  
Russ Patterson wrote:


  
  
  
  
  
Hi
Uriel,
 
Is
there documentation (apologies if I missed it) that explain
how the power flow handles input data?  For example,  from
the case you just got working for me (attached):
 
1)  The
mpc.bus field “Vm” appears to just be treated as the initial
  guess for the bus voltage magnitude.
2)  The
mpc.bus field “Va” actually fixes the bus angle permanently.
 
If
you change Va to, say 10°,
then the load flow result will be:
 

|
Bus Data  
  |


Bus  Voltage  Generation Load
 
#   Mag(pu) Ang(deg)   P (MW)   Q (MVAr)   P (MW)   Q (MVAr)
-
---         
   
1  1.154   10.000* 
-149.60    -39.69   - -
   
2  1.174   13.313   
149.60 49.10   - -
   
      
  
Total: -0.00  9.41  0.00  0.00
 
That
is a perfectly good result of course.  I am playing around
to see what values matter and what don’t – but  I’m
wondering if there is a document that explains things like
“this is an initial guess” or “this setting fixes this
angle” etc.  
 
Best
regards,
Russ
  

Dear Russ:  Bus #1 is designated as the slack bus (and hence, also
for angular reference).  Thus, for this particular bus alone, the
angle is assumed known and taken from the respective column in the
bus table.  This is a standard power flow assumption.

carlos.

  

Re: Storage Dependencies

[Carlos E Murillo-Sanchez]

Rene Kruessmann wrote:

Hello everyone,

I have a question regarding how storages can get connected at different
positions within the grid. I want to add 2 storages, one at the top of the
grid and the other one at the bottom, that are connected with each other
to reduce the costs of redispatch. That means if storage_1 feeds 100 MW,
storage_2 should operate as a load and charge for the same amount (100 MW)
and vice versa.

Is it possible to implement this dependence/ constraint in Matpower, and
if so I would appreciate any advice.
I am not sure that I understand what "top of the grid" and "bottom of 
the grid" means here.  Are you talking about chained hydroelectric 
reservoirs?  If so,  are you considering this in the context of a 
multi-period OPF, and how does the transport time between reservoirs 
compares with length of the time periods in the multi-period OPF?


Carlos.

Re: Commitment status and actual generation in zero cost units in MOST

[Carlos E Murillo-Sanchez]

  
  
Carlos Ferrandon Cervantes wrote:


  Hello everyone:
  
  
  I’ve been working quite a while with a UC problem
in MOST, using the IEEE RTS. I realised that when I compare the
mdo.UC.CommitSched results with mdo.results.ExpectedDispatch
there are differences in the commitment status and real power
output. This happens only with machines with zero starting cost
in my system. i.e. hydro and wind. Say for example, I have a
commitment status of 1, but a power output of 0 for certain
machine. In some cases, i have six hydro units In a bus, and
there could be differences in three of them. It might be a dumb
question, but do you have an idea why this could be happening ?
or how should I interpret this results?
  
  
  Thank you so much in advance and stay safe,
  
  
  Carlos
  -- 
  
Carlos
Ferrandon
  

Carlos:

 I've had this happen if, for example, I forget to add some kind of
sensible RAMP_30 number for a unit.  A zero there
might produce this behavior.

Carlos.

  

Re: Extensible OPF

[Carlos E Murillo-Sanchez]

Dear Yang:

If I understand correctly what you have in mind, then it seems to me 
that you have two choices:  1) approximate the exponential in a limited 
range with a higher order polynomial (which MATPOWER can easily handle), 
or 2) write matlab code to implement user-defined cost functions (i.e., 
exponential, including their gradients and hessians!).  If you are not 
adept at writing code at that level, I suggest that you go for option 1, 
and take into account the modeling error incurred by using a polynomial 
approximation.


carlos.

Yang wrote:
Ray, thanks for your guidance. And for runopf_w_res()I have some 
problems. Actually, I read a paper, it divide the 30 buses into 3 
areas, I don' know the basis, and how can I realize it in matpower, 
whether the areas are zones in matpower.
The mannual is very well, but my coding is at a low level, so I can't 
absorb it quickly and easily.

In fact, what I want to do is about the following:
Part One, there are two types of objectives function:
the first is
.
It is like runopf_w_res(), and I want to divide it into 3 areas like 
the paper I read.

And the second is
It adds the environment factor. And the Exponential term is key need 
to deal with.
Part Two is I want to make the second objective function dynamic, like 
diving 1h into 6 periods, each period is 10 minutes. If I finish Part 
One, I can do this by modifying the data, but how can I make it smarter.


Thanks for your patience and guidance.

Warm regards.
Yang.






At 2020-01-03 01:36:43, "Ray Daniel Zimmerman"  wrote:

Hi Yang,

It’s not clear whether you simply want to use the fixed reserves
extension (see Section 7.6.1 in the MATPOWER User’s Manual
) or you want
to implement your own OPF extension. In the first case you can
simply use runopf_w_res(). In the second, please see Chapter 7 and
the code for the various extensions described in Section 7.6.

   Ray



On Dec 25, 2019, at 8:11 PM, Yang mailto:yang_hong_...@163.com>> wrote:

Dear sir,
I want to do the extensible OPF, and I read paper /MATPOWER’s
Extensible Optimal Power Flow Architecture/.
The objective function is min f(x)+fu(x,z),and fu=sum(ci*ri),
following the code:
Ar = [I I];
om = add_vars(om, 'R', ng, [], Rmin, Rmax);
om = add_constraints(om, 'Pg_plus_R', Ar, [], Pmax, {'Pg', 'R'});
om = add_constraints(om, 'Rreq', Az, Rreq, [], {'R'});
om = add_costs(om, 'Rcost', struct('N',I,'Cw',Rcost), {'R'});

I add these into .m file, as for add_vars if I should change [],
Rmin, Rmax into data I need, and do the same with other codes.
I don't know if it's right.
Best regards.

Yang.

Re: Violation of Voltage Magnitude Constraints

[Carlos E Murillo-Sanchez]

  
  
#FOO CEJUN, JOEL# wrote:


  
  
  
I am a student working on an OPF model for a 15 bus power
system.
  

  
  
I discovered an issue whereby the converged voltage magnitude
output values do not keep within the voltage constraints, which
I have set to be
Vmax= 1.05 and Vmin= 0.95.
  
This happens primarily for the PF study only. 
  

  
  
I would like to know why would there still be a converged output
even if the voltage constraints are not met. 
  

  
  
Thank you in advance for any response to this query. Please
refer to the following screenshots for reference.
  

Hi Joel;

The traditional power flow problem, as conceived, is only about
"solving the circuit", not about dispatching generators to meet
voltage or transmission constraints.  There's no reason to expect
that the solution of a power flow will meet such constraints. 
Please study the statement of the power flow problem in any power
systems textbook.  If you want the solution to meet those
constraints, then you solve a different kind of problem, not a power
flow.  One way is with an optimal power flow; there are others.

Carlos.

  

Re: How to estimate transformer ratio

[Carlos E Murillo-Sanchez]

Pfeifer, Lars Philipp wrote:

Hello everybody,

I have a question about the usage of the transformer in the branch matrix.
I have been reading the manual a few times and also took many looks in the 
example cases.
But I still don’t really understand how I have to fill in the matrix for the 
transformer.
My problem is the value of the ratio in the table. As an example: How is the 
ratio of 1.03 in the case IEEE24 estimated? If I calculate the currents with 
equation 3.1 and 3.2 of the manual I get a very different relation between the 
currents compared with the relation of the voltage. Because usually the 
relation/ratio should be 230/138=1.6667.
I would be very about some help, maybe I am just thinking in the wrong way.

Best regards
Lars Pfeifer

Lars:  the FROM:TO ratio in MATPOWER is
    tau * exp(i*theta)

where tau is the _off-nominal_ turns ratio, relative to the _nominal_ 
turns ratio.  If a transformer connects a 230kV bus to a 138 kV bus and 
the winding taps are at the nominal position value, then tau=1.0 .   A 
value of tau=1.03 means that the tap in the primary is at a position 
that yields a physical voltage of 1.03*230kV in it should you apply the 
nominal 138kV in the secondary.


Remember that the ideal transformer part of a transformer model 
"disappears" when you convert the whole network to per-unit.  It is only 
if the taps are in an off-nominal position that this has to be taken 
into account using tau.


carlos.

Announcing MATPOWER-Natural Gas 0.99a

[Carlos E Murillo-Sanchez]

Dear all:

We have implemented a combined OPF + Natural gas network solver. Version 
0.99a can now be cloned from


https://github.com/MATPOWER/mpng

The natural gas network consists of wells, pipes, compressors (both 
electric and natural gas fed-turbines), and stratified demands 
(different market segments).  The natural gas and electric networks 
interact at thermal plants and electrically operated compressors. 
Natural gas flow is modeled using the Weymouth equation.  The 
user-defined general nonlinear constraints capability of MATPOWER was 
used to implement the nonlinear gas network.


Please use it, break it, and tell us about any issues that you find.

Sincerely,

Carlos E. Murillo-Sanchez, Universidad Nacional de Colombia - Manizales
Sergio García Marín,  Universidad Nacional de Colombia - Manizales
Wilson González Vanegas, Universidad Tecnológica de Pereira

Re: About the branch violation

[Carlos E Murillo-Sanchez]

  
  
To expand a little bit on Ray's
  response:  In power systems, we tend to have labels for very
  specific kinds of problems;
  one such label is "power flow" or "load flow".  This refers to a
  problem in which given some input parameters (values
  of loads, generator voltage setpoints, and real power dispatch for
  every generator but one, which is called the slack generator), 
  the resulting circuit  analysis problem is solved, yielding what
  would be the consequences of the input parameters, namely,
  complete information about voltage phasors in every busbar, as
  well as individual line flows. The traditional power flow problem
  does not care about generator reactive limits nor branch flow
  limits.  Why, it doesn't even care about the slack
  generator active power capability.  It is just about solving the
  circuit.  The pf.enforce_q_lims option in MATPOWER deviates
  from the traditional power flow formulation by trying to stay
  within the reactive capabilities of the generators at the
  expense of renouncing to bus voltage control.
  
  In order to try to address other kinds of limits such as line flow
  ones, you have to turn to another kind of problem (and another
  label for it) instead of the so-called load flow problem.  One
  such possibility is the Optimal Power Flow.  There are others.
  
  carlos.
  
  Ray Zimmerman wrote:


  
  The power flow solver runpf(),
  by default, simply solves for the flows given the specified loads
  and generator voltage and active power set points. It does not
  alter any set points in an attempt to keep flows, voltages or
  generator reactive powers within feasible limits. There is one
  exception to this, and that is when you set the pf.enforce_q_lims option to 1 or 2, in
  which case, it attempts to respect reactive power limits on
  generators in exchange for relaxing the corresponding voltage set
  point.
  
  
  If you need to solve a problem that respects other
limits, as it appears you do, you’ll want to use runopf() and set up the costs to
indicate how you want to prioritize changes in the set points.
  
  
  Hope this helps,
  
  
     Ray
  

  

  On Sep 24, 2019, at 10:29 AM, 赤心 肖 
wrote:
  
  



  
Sorry, I forgot the benchmark is 'case 30'. Thanks.
  
Regards,
  
Chixin
  
  
  From: bounce-123952714-44420...@list.cornell.edu
  
  on behalf of chixinx...@hotmail.com
  
  Sent: 25 September 2019 01:24
  To: matpowe...@list.cornell.edu
  
  Subject: About the branch
  violation
 
  
  
  

  Dear all,

     I am programming by the use of 'runpf' and to
  be required not to ignore any limits such as the
  generator, the branch flow and the voltage.

     Although I have set the 'pf.enforce_q_lims'
  into 1 or 2, the 'pf.tol' into 10e-20 and the
  'pf.nr.max_it' into 40, the branch flow still has
  violation at branch 10.
  


      Can anybody give me some suggestion when you
  are at convenience? Thanks a lot.


  Regards,

  Chixin

  

  

  
  

  


  

Re: [MOST] Speed up repeated optimization of dispatch

[Carlos E Murillo-Sanchez]

Reinhold Bertram wrote:

Dear all,

is it possible to speed up the repeated solving of a deterministic 
multi-period dispatch problem with MOST when only the loadprofile changes?


At the moment SetupTime is about 2 seconds for each iteration. Is it 
possible to skip/shorten this time?


Best regards
Reinhold Bertram
This is actually possible, and MOST was designed for this sort of 
eventuality, but you need to understand how the constraints are built 
inside MOST.  The different phases of building the constraints, building 
the costs,  optionally adding extra "coordination" costs for some 
variables (when MOST is used in a decomposition and coordination scheme 
as a subproblem), and actually solving the problem are controlled by 
several flags. Hence, if you solve a problem the first time, you can 
re-use the output structure which already contains the formulation of 
the problem in the .QP field, setting the flags so as to not to re-build 
the problem, and so that all of the constraint-building code is not 
re-executed.  But you need to manually alter the corresponding elements 
of the L and U vectors in the L <= A*x <= U constraints corresponding to 
the bus power balances (you can use the constraint-indexing mechanism in 
the optimization model for this) to reflect the changes in the bus 
demand vector for each flow.


This query falls in the advanced user category for MOST.

Carlos.

Re: Least squares OPF

[Carlos E Murillo-Sanchez]

  
  
Actually, since the quadratic costs
  that Mariusz wants are diagonal, it
is possible to use the normal polynomial cost mechanism in
mpc.gencost (including the cost on the reactive generations; see
the footnote in the manual at page 152).

carlos.
  
  Ray Zimmerman wrote:


  
  MATPOWER does not currently include an option for that objective
  function, but it should be straightforward to implement an
  extension to do it. With MATPOWER 7, I believe you should be able
  to do it with the standard quadratic costs in (6.47) in the User’s Manual.
  
  
     Ray
  

  
On Jun 17, 2019, at 5:43 AM, m.drabe...@onet.eu wrote:


  
Dear All,
 
 
I am currently working on
extensions of OPF problem and got one question.
 
Could you please advise  if
Matpower provides any possibility for easy coding of
“least squares” OPF problems of the following form:
 
Minimize   sum( (P_setpoint^i –
  P_G^i)^2+(Q_setpoint^i – Q_G^i)^2)
 
Subject to:   standard OPF constraints
 
Where: 
- P_setpoint^i / Q_setpoint^i
is the desired output of active/reactive power of
generator “i” (parameter known a priori)
- P_G^i / Q_G^i  - output of
generator “i” (variables)
 
I am looking forward to your
reply.
 
 
Best regards,
Mariusz Drabecki
  
  

  

  
  Wolny od wirusów. www.avg.com

  

  

  


  


  

Re: How to solve pf with one bus faulted?

[Carlos E Murillo-Sanchez]

Ismael K Abdulrahman wrote:

Dear Matpower community,

I have a system with one load bus faulted to ground (v=0). The system with 
normal operation works fine. The system with the fault, however, cannot be 
solved owing to low voltage problem. I tried to deal the faulted load bus as a 
generator bus with V=0. I converted all loads from constant powers to constant 
impedances as suggested by Shri in this group in my previous question. The 
system still cannot be solved. Is there any idea to get around this problem?

Thanks in advance
Ismael
Ismael:  The methods that are generally used to analyze a fault have 
major differences with respect to the assumptions of the classical power 
flow problem.  A normal power flow solution algorithm can be expected to 
fail on a network with a fault.  A good classical reference for this is 
"Analysis of Faulted Power Systems" by Anderson.


Carlos.

Re: Query regarding incorporating equations or modifying equations while running AC PF

[Carlos E Murillo-Sanchez]

Jubeyer Rahman wrote:

Hi,

I have several questions regarding the AC power flow in matpower.

a. I would like to know whether the AC Power Flow command ('runpf') 
,when called, does it have any constraint to constrain the transformer 
power rating violation which is related to the real and reactive power 
flows into the transformers both at origin bus and destination bus?
No, it doesn't; the traditional formulation of the power flow does not 
include this feature (it would not be what is normally calle a "power 
flow").  MATPOWER does include the option to try to remain within 
reactive generation limits, though.  This requires changing the type of 
the conflicting generator's bus from "PV" to "PQ".
b. How to incorporate transformer's magnetizing conductance in the 
power flow equations? Or does matpower already takes care of it? ( I 
didn't see it in the matpower AC PF formulation)
The magnetizing susceptance is not included in the general branch model 
that MATPOWER employs.  At the transmission level, neither the core loss 
conductance nor the magnetizing susceptance are usually modeled.  If you 
assume that either the "from" side voltage or the "to" side voltage is 
what is actually present at the terminals of these two elements, then 
they could be added as shunt elements in the corresponding bus.  Just 
not in the branch specification.
c.Is there any way to change the power balance equations at buses? Any 
matpower example or reference to the example will be greatly appreciated.

Ray answered this.
d. I have observed after running a power flow, one generator's real 
power has gone below its minimum, this happens when I took one branch 
out to simulate a branch contingency event. Do you know why this is 
happening? I mean, this is violating the Pmax and Pmin constraints?


That generator could only be the slack generator, since all other 
generator's active power output remains fixed in a traditional power 
flow.  The problem seems to be in the specification of the power output 
for non-slack generators.  The slack  generator must adjust the overall 
active power balance, that's what it is for. This is one of the 
underlying assumptions in the formulation of a traditional power flow.


Regards,
Jubeyer

carlos.

Re: warning- after make new network

[Carlos E Murillo-Sanchez]

amir ali Hosseini wrote:

Dear Sir,
i trying make a new network. 37 bus
but ! after runpf  .i have warning!
can you help me ?
thanks a lot.
my warning is :
Warning: Matrix is singular to working precision.
> In newtonpf (line 89)
  In runpf (line 204)
find attachment .
new network with 37 node.


This is the output of case_info.m applied to your case file:

>> case_info(mpc)
Checking connectivity ... single connected network, plus 1 isolated bus
Elapsed time is 0.245606 seconds.

    Full   Island Isolated
   System 1 Buses
Number of:   --  --  --
  buses    37  36   1
  loads    36  35   1
    on 36  35   1
    off -   -   -
    fixed  36  35   1
    dispatchable    -   -   -
  on    -   -   -
  off   -   -   -
  generators    1   1   -
    on  1   1   -
    off -   -   -
  shunt elements    -   -   -
  branches 36  36   -
    on 36  36   -
    off -   -   -
    ties (off)  -   -   -

Load
  active (MW)
    dispatched  9.6 9.5 0.1
  fixed 9.6 9.5 0.1
  dispatchable  -   -   -
    curtailed   -   -   -
    nominal 9.6 9.5 0.1
  on    9.6 9.5 0.1
  off   -   -   -
  fixed 9.6 9.5 0.1
  dispatchable  -   -   -
    on  -   -   -
    off -   -   -
  reactive (MVAr)
    dispatched  4.6 4.6 0.0
  fixed 4.6 4.6 0.0
  dispatchable  -   -   -
    curtailed   -   -   -
    nominal 4.6 4.6 0.0
  on    4.6 4.6 0.0
  off   -   -   -
  fixed 4.6 4.6 0.0
  dispatchable  -   -   -
    on  -   -   -
    off -   -   -

Generation
  active (MW)
    dispatched 11.5    11.5 -
    max capacity   10.0    10.0 -
  on   10.0    10.0 -
  off   -   -   -
    min capacity    -   -   -
  on    -   -   -
  off   -   -   -
  reactive (MVAr)
    dispatched  -   -   -
    max capacity    1.5 1.5 -
  on    1.5 1.5 -
  off   -   -   -
    min capacity   -0.2    -0.2 -
  on   -0.2    -0.2 -
  off   -   -   -

Shunt Injections
    active (MW) -   -   -
    reactive (MVAr) -   -   -

Branch Losses
    active (MW) -   -   -
    reactive (MVAr) -   -   -

DC line
  export (MW)
    dispatch    -   -   -
    max capacity    -   -   -
  on    -   -   -
  off   -   -   -
    min capacity    -   -   -
  on    -   -   -
  off   -   -   -

Reference Buses
  num of ref buses  1   1   0
  ref bus numbers   1   1
>>

It seems that you have an isolated bus; is this what you intend in your 
case file?


carlos.

Re: power flow problem

[Carlos E Murillo-Sanchez]

  
  
Therein lies the problem.  Your
  optimization procedure, as formulated, has no say on the resulting
  voltages.   I can think of two suggestions for dealing with this:
  
  1) Instead of a power flow, use an OPF with all non-slack
  generators' active power outputs fixed to whatever values were
  assigned by the optimization algorithm at the current iteration
  (set Pmin=Pg=Pmax for those generators).  What this will do is
  essentially a reactive redispatch which will try to comply with
  voltage limits, generation limits and transmission limits.  You
  can expect the slack generation to vary a little bit to compensate
  for the differing amount of losses.
  
  2) Include the reactive generation variables in your formulation
  and continue using a simple load flow.
  
  carlos.
  
  Mohamed Shaheen wrote:


  No, I don't
  
  
On Sun, Feb 10, 2019, 1:24 AM Carlos E
  Murillo-Sanchez <ce.murillosanc...@gmail.com
  wrote:


  
Do you
  include reactive generation in the decision variables of
  your formulation?  If you don't, then your optimization
  algorithm does not really have much impact on voltages.
  
  carlos.
  
  Mohamed Shaheen wrote:


  I'm currently using penalty functions with
GA and Tree-Seed, But after running Tree-Seed algorithm
including 'runpf' inside, All solutions have violations
and the algorithm chooses the minimum of these solutions
which is also a false solution. 
  ᐧ
  
  
On Sat, 9 Feb 2019 at
  15:42, Carlos E Murillo-Sanchez <ce.murillosanc...@gmail.com>
  wrote:


  
Rather,
  it seems that your optimization method should take
  into account any constraint violation and fix the
  issue by itself.  In some methods, such as GA, one
  way to do this is by using penalty functions on
  constraint violations.
  
  carlos.
  
  
  Mohamed Shaheen wrote:


  I need to enforce limits, but I aim
to get the optimal solution and best parameters
using another optimization method called 'Tree
Seed' and compare it with 'Genetic Algorithm'
after running normal power flow, So I'm not
seeking the optimal solution using
Matpower itself.
Can Matpower help to do this? 


  
  ᐧ
  
  
On Fri, 8 Feb
  2019 at 23:53, Ray Zimmerman <r...@cornell.edu>
  wrote:


  The power flow problem solved by runpf does not take
into account voltage limits. If you need to
enforce limits, you can use an appropriately
constrained OPF.


In this case, it just so happens that
  the initial voltage specified for bus 31
  in the case57.m file happens to be the
  voltage at the power flow solution.


    Ray

  

  On Feb 8, 2019, at 2:54 PM,
Mohamed Shaheen <mohamed.shaheen9...@gmail.com>
wrote:
  
  
Dear Sir,
  
  
  Regarding the case57, the
voltage of bus 31 is 0.936 p.u
which is less than the min.
limit of bus voltage (0.94).
Every time I run 'runpf', the
v

Re: power flow problem

[Carlos E Murillo-Sanchez]

  
  
Do you include reactive generation in
  the decision variables of your formulation?  If you don't, then
  your optimization algorithm does not really have much impact on
  voltages.
  
  carlos.
  
  Mohamed Shaheen wrote:


  I'm currently using penalty functions with GA and
Tree-Seed, But after running Tree-Seed algorithm including
'runpf' inside, All solutions have violations and the algorithm
chooses the minimum of these solutions which is also a false
solution. 
  ᐧ
  
  
On Sat, 9 Feb 2019 at 15:42,
  Carlos E Murillo-Sanchez <ce.murillosanc...@gmail.com>
  wrote:


  
Rather,
  it seems that your optimization method should take into
  account any constraint violation and fix the issue by
  itself.  In some methods, such as GA, one way to do this
  is by using penalty functions on constraint violations.
  
  carlos.
  
  
  Mohamed Shaheen wrote:


  I need to enforce limits, but I aim to get
the optimal solution and best parameters using another
optimization method called 'Tree Seed' and compare it
with 'Genetic Algorithm' after running normal power
flow, So I'm not seeking the optimal solution using
Matpower itself.
Can Matpower help to do this? 


  
  ᐧ
  
  
On Fri, 8 Feb 2019 at
  23:53, Ray Zimmerman <r...@cornell.edu>
  wrote:


  The power flow problem solved by runpf does not take into
account voltage limits. If you need to enforce
limits, you can use an appropriately constrained
OPF.


In this case, it just so happens that the
  initial voltage specified for bus 31 in the
  case57.m file happens to be the voltage at the
  power flow solution.


    Ray

  

  On Feb 8, 2019, at 2:54 PM, Mohamed
Shaheen <mohamed.shaheen9...@gmail.com>
wrote:
  
  
Dear Sir,
  
  
  Regarding the case57, the voltage of
bus 31 is 0.936 p.u which is less than
the min. limit of bus voltage (0.94).
Every time I run 'runpf', the voltage
value is 0.936 and it doesn't change
although it is a PQ bus.
  I need your help, please.   
  
  
  
  Regards,
  Mohamed Shaheen.
  
  
  Msc. student at Ain Shams University
in Egypt
  Teaching Assistant in Future
University in Egypt

ᐧ
  

  
  

  

  


  

  


  

Re: power flow problem

[Carlos E Murillo-Sanchez]

  
  
Rather, it seems that your optimization
  method should take into account any constraint violation and fix
  the issue by itself.  In some methods, such as GA, one way to do
  this is by using penalty functions on constraint violations.
  
  carlos.
  
  
  Mohamed Shaheen wrote:


  I need to enforce limits, but I aim to get the
optimal solution and best parameters using another optimization
method called 'Tree Seed' and compare it with 'Genetic
Algorithm' after running normal power flow, So I'm not seeking
the optimal solution using Matpower itself.
Can Matpower help to do this? 


  
  ᐧ
  
  
On Fri, 8 Feb 2019 at 23:53,
  Ray Zimmerman  wrote:


  The power flow problem
solved by runpf does not take
into account voltage limits. If you need to enforce limits,
you can use an appropriately constrained OPF.


In this case, it just so happens that the initial
  voltage specified for bus 31 in the case57.m file happens
  to be the voltage at the power flow solution.


    Ray

  

  On Feb 8, 2019, at 2:54 PM, Mohamed Shaheen 
wrote:
  
  
Dear Sir,
  
  
  Regarding the case57, the voltage of bus 31
is 0.936 p.u which is less than the min. limit
of bus voltage (0.94). Every time I run 'runpf',
the voltage value is 0.936 and it doesn't change
although it is a PQ bus.
  I need your help, please.   
  
  
  
  Regards,
  Mohamed Shaheen.
  
  
  Msc. student at Ain Shams University in Egypt
  Teaching Assistant in Future University in
Egypt

ᐧ
  

  
  

  

  


  

Re: Are there any crossing in power system

[Carlos E Murillo-Sanchez]

naime ahmadi wrote:

Hi,
I have question about branch data in case 57 bus system in matpower.
When I look at diagram of IEEE 57 bus system, I can see it have some 
crossing in the network between lines.

Are there any crossing in power system?
Thanks,
Naime

Hi Naime:  Short answer is yes.  Longer answer:  At a given voltage 
level, networks tend to be mostly planar and crossings are not very 
common but they do exist nevertheless. However, once you consider 
several voltage levels in the same p.u. diagram, crossings are actually 
very common.


carlos.

Re: solving SCDCOPF with rescheduling in MOST

[Carlos E Murillo-Sanchez]

  
  
Indeed, binding limits are likely to
  influence both the base cases and the contingency cases so that
  they _jointly_ meet all limits.  This is so because explicit
  constraints are included that tie these states together, affecting
  the dispatch of both.  So to answer your question, the joint
  constraint affects both states.
  
  With regards to bench limits:  currently, the limits used for
  branch flows are hard; there is no flexible-limit option like
  there is for
  MATPOWER's OPF.  However, it is not unreasonable to raise the
  transmission limit for a post-contingency state, under the
  assumption
  that when a contingency occurs, it is likely to trigger further
  actions by the system operator and thus the post-contingency state
  will
  not last for long.  The way to do this is to use a multi-row
  contingency specification in contab;  one row specifies the
  contingency
  (i.e., loss of some equipment), and another row specifies the
  change in the transmission limits for the post-contingency state.
  Both rows should have the same contingency label.
  
  carlos.
  
  Carlos Ferrandon Cervantes wrote:


  Thank you Doctor for your reply. I have been using
the "contab" matrix, adding contingencies to the original case I
am working with. In the results output I've realised that once
certain  adjacent branch reaches its limit, this constrain is
considered to be binding (please help me out if I get this ok!).
In order to do this, I understand that in the optimisation
process certain generation rescheduling has to be done -which is
something I have seen it is actually happening for the
K-contingency mdo.resultsExpectedDispatch matrix.  What I do not
have quite clear is that how each of this K-contingency case
updates the base case as final result of the simulation, and
also; can MOST include branches limits relaxation, considering
the ramping up/down limits of the generation?


Kind regards,


Carlos Ferrandon
  
  
  
El mar., 4 dic. 2018 a las 16:30, Carlos E
      Murillo-Sanchez (<ce.murillosanc...@gmail.com>)
  escribió:


  
Carlos: 
  MOST models post-contingency states explicitly, and these
  states influence the possible base case states directly so
  that the base cases are secure in light of the specific
  contingencies considered.
  
  carlos.
  
  Carlos Ferrandon Cervantes wrote:


  Hello:


I would like to know if MOST can perform security
  constrained dc opf with rescheduling, specifically if
  it's possible to update the limits of the problem
  elements using Benders decomposition. 


Thank you so much for your help in advance!


Best wishes,
  
  
  -- 
  
Carlos
Ferrandon
  

  


  

  
  
  
  
  -- 
  
Carlos
Ferrandon
  


  

Re: solving SCDCOPF with rescheduling in MOST

[Carlos E Murillo-Sanchez]

  
  
Carlos:  MOST models post-contingency
  states explicitly, and these states influence the possible base
  case states directly so that the base cases are secure in light of
  the specific contingencies considered.
  
  carlos.
  
  Carlos Ferrandon Cervantes wrote:


  Hello:


I would like to know if MOST can perform security
  constrained dc opf with rescheduling, specifically if it's
  possible to update the limits of the problem elements using
  Benders decomposition. 


Thank you so much for your help in advance!


Best wishes,
  
  
  -- 
  
Carlos
Ferrandon
  

  


  

Re: derivative of real current w.r.t voltage

[Carlos E Murillo-Sanchez]

Shiva Moshtagh wrote:

Hello

Can I use rectangular coordinates in matpower ? for example I know 
that there are real and imaginary parts of  power injections and power 
flows as well as bus voltages, but for branch current there is not 
rectangular coordinate. Suppose that I want to add derivative of real 
branch current w.r.t voltage to jacobian matrix. How can I do that ?


Regards,
Shiva,
Equation (72) in the TN2-OPF-Derivatives.pdf document gives you an 
algebraic expression for the complex current derivative with respect to 
voltage magnitude.  Just take the real part of it to obtain the 
derivative of the real current.  Look at the function dSbus_dV in MATPOWER.


carlos.

Re: HVDC and SVC

[Carlos E Murillo-Sanchez]

  
  
To clarify a little further on Ray's
  advice:
  
  An SVC can be approximated by a generator under voltage control
  that can sink QMIN or source QMAX MVArs, but this would be
  accurate for an SVC with a slope of infinity (i.e., constant
  voltage).  If you want to approximate the behavior of an SVC in
  the linear operational region, then, in an optimal power flow (but
  not in a simple power flow) you can relate the voltage of the
  controlling bus to the reactive output of the SVC using the
  generalized linear constraints feature.
  
  Carlos.
  
  Ray Zimmerman wrote:


  
  For HVDC lines, see section 7.6.3 in the User’s Manual. And an SVC
  can be modeled as a generator with PMIN and PMAX equal to 0.
  
  
     Ray
  

  
On Nov 14, 2018, at 5:43 AM, in...@gotalk.net.au wrote:


  
Dear Ray
 
Does MATPOWER support any form of HVDC or
SVC?
 
Kind Regards
 
Alberto Sarnari
  

  


  


  

Re: Configuration of OPF

[Carlos E Murillo-Sanchez]

  
  
The equations are generally available
  in the OPF literature.  For specific GAMS modeling, you may want
  to look at
  
  https://www.gams.com/latest/psoptlib_ml/libhtml/index.html
  
  carlos.
  
  Jane Cheung wrote:


  
Dear all,

  I have
been tried to solve the
OPF problem with GAMS. In GAMS the problem configuration is
just like what printed on paper and books.
  In Matpower,
  where could find these 
Equation and inequality formulations.
  
  
  Thanks in advance!
  
  
  Best regards!

  


  

Re: magnitude and the phase angle of the current in the branches

[Carlos E Murillo-Sanchez]

  
  
Of course; sorry, the part about
  "branch" current slipped to the back of my mind.  The code would
  be similar:
  
  % Run power flow
  results = runpf(mpc);
  % Get column pointers
  define_constants;
  % Compute vector of complex bus voltages
  V = results.bus(:, VM) .* exp(sqrt(-1)*results.bus(:, VA)*pi/180);
  % Compute nodal admittance matrix, and line admittance matrices at
  both the 'from' and 'to' ends of branches
  [Ybus, Yf, Yt]  = makeYbus(results);
  % Compute vector of complex bus injection currents
  Ibus = Ybus * V;
  % Compute vector of complex currents injected at 'from' end of
  branches
  If = Yf * V;
  % Compute vector of complex currents injected at 'to' end of
  branches
  It = Yt * V;
  
  Carlos.
  
  Arkan Arkan wrote:


  Thank you so much. I appreciate your help. What do
you mean by starting from 1? I think all of the buses in
Matpower are number consecutively and start from 1. The
injection current is different than branch current. How about
phase angle of the branch current. Thanks.
  
On Sat, Mar 31, 2018 at 12:41 PM,
      Carlos E Murillo-Sanchez <ce.murillosanc...@gmail.com>
  wrote:
  

  Assuming
that the system data is in structure 'mpc', and that the
buses are numbered consecutively starting from 1,  this
should give you the injection currents:

% Run power flow
results = runpf(mpc);
% Get column pointers
define_constants;
% Compute vector of complex bus voltages
V = results.bus(:, VM) .* exp(sqrt(-1)*results.bus(:,
VA)*pi/180);
% Compute nodal admittance matrix
Ybus = makeYbus(results);
% Compute vector of complex bus injection currents
Ibus = Ybus * V;

Carlos.

Mostafa Mohammadpourfard wrote:
  
  

  

  Thank you,
Carlos. May I ask you to write the code here? I
am not a power system student. Thanks
  
  


  On Sat, Mar 31, 2018 at
    9:41 AM, Carlos E Murillo-Sanchez <ce.murillosanc...@gmail.com>
wrote:
You have the bus
  voltages; now you just need to multiply the
  system's nodal admittance matrix by the
  complex voltage vector to get the complex
  currents vector.  See the makeYbus function in
  MATTPOWER.
  
  Carlos.
  
  Arkan Arkan wrote:
   Thank
  you, Ilias. But, unfortunately, there is
  not any direct information about current
  in the Manpower like you mentioned and we
  should calculate based on the information
  obtained from runpf.
  
 On Fri, Mar 30, 2018 at 9:06
  AM, Ilias Sarantakos <il.saranta...@gmail.com
  <mailto:il.saranta...@gmail.com>>

  wrote:
  
      Hi Arkan,
  
      If you type ''result = runpf(mpc)'',
  then you will get the power
      flow results of your network, stored
  in the ''result'' variable.
      Now that you have the voltages
  (magnitudes and angles) at all
      buses, you can calculate the current
  at each branch. I think it
      would be helpful to check Appendix B
  in MATPOWER manual, which can
      guide you how to access the results of
  your network. For example,
      ''result.bus(1,8)'' and
  ''result.bus(1,9)'', contain the magnitude
      and angle of voltage at bus 1.
  
   

Re: magnitude and the phase angle of the current in the branches

[Carlos E Murillo-Sanchez]

  
  
Assuming that the system data is in
  structure 'mpc', and that the buses are numbered consecutively
  starting from 1,  this should give you the injection currents:
  
  % Run power flow
  results = runpf(mpc);
  % Get column pointers
  define_constants;
  % Compute vector of complex bus voltages
  V = results.bus(:, VM) .* exp(sqrt(-1)*results.bus(:, VA)*pi/180);
  % Compute nodal admittance matrix
  Ybus = makeYbus(results);
  % Compute vector of complex bus injection currents
  Ibus = Ybus * V;
  
  Carlos.
  
  Mostafa Mohammadpourfard wrote:


  
Thank
  you, Carlos. May I ask you to write the code here? I am not a
  power system student. Thanks


  
  
On Sat, Mar 31, 2018 at 9:41 AM, Carlos
  E Murillo-Sanchez <ce.murillosanc...@gmail.com>
  wrote:
  You have
the bus voltages; now you just need to multiply the system's
nodal admittance matrix by the complex voltage vector to get
the complex currents vector.  See the makeYbus function in
MATTPOWER.

Carlos.

Arkan Arkan wrote:

Thank you, Ilias. But, unfortunately, there is not any
direct information about current in the Manpower like
you mentioned and we should calculate based on the
information obtained from runpf.

  
On Fri, Mar 30, 2018 at 9:06 AM, Ilias Sarantakos <il.saranta...@gmail.com
<mailto:il.saranta...@gmail.com>>
wrote:

    Hi Arkan,

    If you type ''result = runpf(mpc)'', then you will
get the power
    flow results of your network, stored in the
''result'' variable.
    Now that you have the voltages (magnitudes and
angles) at all
    buses, you can calculate the current at each branch.
I think it
    would be helpful to check Appendix B in MATPOWER
manual, which can
    guide you how to access the results of your network.
For example,
    ''result.bus(1,8)'' and ''result.bus(1,9)'', contain
the magnitude
    and angle of voltage at bus 1.

    Hope this helps.

    Kind regards,

    Ilias Sarantakos

    2018-03-29 2:25 GMT+01:00 Arkan Arkan <arkan.m2...@gmail.com
  
      <mailto:arkan.m2...@gmail.com>>:

        Hi everyone,

        I am wondering how can I get the magnitude and
the phase angle
        of the current in the branches of any case file
in the Matpower.

        Thanks for your help.



  


  


  


  

Re: magnitude and the phase angle of the current in the branches

[Carlos E Murillo-Sanchez]

You have the bus voltages; now you just need to multiply the system's 
nodal admittance matrix by the complex voltage vector to get the complex 
currents vector.  See the makeYbus function in MATTPOWER.


Carlos.

Arkan Arkan wrote:
Thank you, Ilias. But, unfortunately, there is not any direct 
information about current in the Manpower like you mentioned and we 
should calculate based on the information obtained from runpf.


On Fri, Mar 30, 2018 at 9:06 AM, Ilias Sarantakos 
> wrote:


Hi Arkan,

If you type ''result = runpf(mpc)'', then you will get the power
flow results of your network, stored in the ''result'' variable.
Now that you have the voltages (magnitudes and angles) at all
buses, you can calculate the current at each branch. I think it
would be helpful to check Appendix B in MATPOWER manual, which can
guide you how to access the results of your network. For example,
''result.bus(1,8)'' and ''result.bus(1,9)'', contain the magnitude
and angle of voltage at bus 1.

Hope this helps.

Kind regards,

Ilias Sarantakos

2018-03-29 2:25 GMT+01:00 Arkan Arkan >:

Hi everyone,

I am wondering how can I get the magnitude and the phase angle
of the current in the branches of any case file in the Matpower.

Thanks for your help.

Re: Power Flow in Matpower

[Carlos E Murillo-Sanchez]

  
  
The Ybus matrix computed from the data
  in your file has NaN's and Inf's because branch # 69 from bus 16
  to bus 17 has zero series impedance.  You must collapse buses 16
  and 17 into a single bus before applying any algorithm to the
  system because the electrical "distance" between these two buses
  is zero.
  
  Carlos.
  
  Mohammed Alhajri wrote:


  i got






  19980               NaN
  19981               NaN
  19982               NaN
  19983               NaN
  19984               NaN
  19985               NaN
  19986               NaN
  19987               NaN
  19988               NaN
  19989               NaN
  19990               NaN
  19991               NaN
  19992               NaN
  19993               NaN
  19994               NaN
  19995               NaN
  19996               NaN
  19997               NaN
  19998               NaN
  1               NaN
  2               NaN
  Gauss-Seidel power flow did not converge in 2
iterations.
  
  
  >  Did NOT converge (47.99 seconds) 
<



  
  
On 20 March 2018 at 19:44, Ray
  Zimmerman 
  wrote:
  
Unfortunately,
  I do not have time to work on this myself. I was just
  giving a suggestion for another direction to try if you
  want to understand the issue that MATPOWER is having with
  your case. Could you post the output (using verbose set to 2) of runpf() when using a MATPOIWER
  case file that corresponds to the solved case from
  the Hadi Sadat code?
  
  
  And if you have any questions about the MATPOWER case
format or MATPOWER power flow options, feel free to ask.


  
    Ray
  

  

  
On Mar 20, 2018, at 11:28 AM, Mohammed
  Alhajri 
  wrote:


  Ok, i have attached the
case information in format of Hadi
Saadat code, can you please try it in
MATPOWER? 


because we have spent
  more than three weeks checking the
  format, but still dose not
  converge... 


Regards,,, 
  
  
بتاريخ
  ٢٠١٨/٠٣/٢٠ ٦:٢٦ م، كتب "Ray Zimmerman"
  :
  
It’s
  possible that the modeling is not
  identical or that there is some
  error in your conversion to
  MATPOWER format. You can check by
  talking the solved case from your
  other software, converting that
  solved case to MATPOWER and then
  trying the MATPOWER power flow. It
  should converge in a single
  iteration. If it does not, then
  you know that there is either a
  mistake somewhere or a difference
  in modeling.
  
  
     Ray
  

  
On Mar 16, 2018, at
  12:42 PM, Mohammed Alhajri
  
  wrote:

  

Re: Power Flow in Matpower

[Carlos E Murillo-Sanchez]

  
  
Let's see,  Mohammed:  I tried the data
  in MATPOWER format that you posted originally, and applied the
  case_info(0) function to it, yielding the following results:
  
  >> case_info(mpc)
  Checking connectivity ... 3 connected groups, 1 isolated bus
  Elapsed time is 0.149655 seconds.

      Full   Island  Island 
  Island Isolated  
     System 1   2  
  3 Buses   
  Number of:   --  --  -- 
  --  -- 
    buses   154 146   4  
  3   1   
    loads    77  69   4  
  3   1   
      on 77  69   4  
  3   1   
      off -   -   -  
  -   -   
      fixed  77  69   4  
  3   1   
      dispatchable    -   -   -  
  -   -   
    on    -   -   -  
  -   -   
    off   -   -   -  
  -   -   
    generators   13  10   3  
  -   -   
      on 13  10   3  
  -   -   
      off -   -   -  
  -   -   
    shunt elements   45  44   -  
  -   1   
    branches    172 167   3  
  2   -   
      on    167 162   3  
  2   -   
      off 5   5   -  
  -   -   
      ties (off)  -   -   -  
  -   -   
  
  Load    
    active (MW)   
      dispatched   6416.2  5599.8   196.0  
  528.4    92.0 
    fixed  6416.2  5599.8   196.0  
  528.4    92.0 
    dispatchable  -   -   -  
  -   -   
      curtailed   -   -   -  
  -   -   
      nominal  6416.2  5599.8   196.0  
  528.4    92.0 
    on 6416.2  5599.8   196.0  
  528.4    92.0 
    off   -   -   -  
  -   -   
    fixed  6416.2  5599.8   196.0  
  528.4    92.0 
    dispatchable  -   -   -  
  -   -   
      on  -   -   -  
  -   -   
      off -   -   -  
  -   -   
    reactive (MVAr)   
      dispatched   2125.7  1855.6    64.4  
  173.7    31.9 
    fixed  2125.7  1855.6    64.4  
  173.7    31.9 
    dispatchable  -   -   -  
  -   -   
      curtailed   -   -   -  
  -   -   
      nominal  2125.7  1855.6    64.4  
  173.7    31.9 
    on 2125.7  1855.6    64.4  
  173.7    31.9 
    off   -   -   -  
  -   -   
    fixed  2125.7  1855.6    64.4  
  173.7    31.9 
    dispatchable  -   -   -  
  -   -   
      on  -   -   -  
  -   -   
      off -   -   -  
  -   -   
  
  Generation  
    active (MW)   
      dispatched   6621.8  6234.6   387.3
  -   -   
      max capacity    -   -   -  
  -   -   
    on    -   -   -  
  -   -   
    off   -   -   -  
  -   -   
      min capacity    -   -   -  
  -   -   
    on    -   -   -  
  -   -   
    off   -   -   -  
   

Re: how to add constraints by direct specification

[Carlos E Murillo-Sanchez]

In the actual optimization problem, everything is in per unit.  
Therefore, you probably want to specify the right hand side of your 
inequality as 70/mpc.baseMVA .


Carlos.

Teiji Ponishi wrote:

Dear all,

I am trying to add the following simple constraints by direct 
specification.


0 <= Pg1 + Pg3 + Pg5 + Pg7 + .. + Pg299 <= 70

To do so, I added the following statements.
(The number of buses are 100. The number of generators are 300. 
Therefore, the number of generators at some buses are between 10 to 20.)


%
A_Va = sparse(1, 100); % number of buses are 100
A_Vm = sparse(1, 100); % number of buses are 100
A_Pg = sparse([ 1 0 1 0 1 0 1 0 1 0   1 0 1 0 ... 0 1 0 1 0 ] ); % 
number of generators are 300

A_Qg = sparse(1, 300); % number of generators are 300
mpc1.A = [A_Va A_Vm A_Pg A_Qg];
mpc1.l = [0];
mpc1.u = [70];
mpopt = mpoption('opf.ac.solver','KNITRO','out.branch', 0, 
'out.lim.all', 0, 'out.sys_sum', 0, 'out.gen', 1);

[results, success]=runopf(mpc1, mpopt);
%

Actually, AC-OPF calculations can be performed successfully.
However, by checking the total output of odd-number generators in 
simulation results,
the added constraints are not effective. The total output of 
odd-number generators is more than 70.


Would you please help me in this aspect.

Kind Regards,

Teiji

Re: Implementing Transmission Switching in MATPOWER

[Carlos E Murillo-Sanchez]

Matt:  I have proof-of-concept code that implements line switching with 
disjunctive constraints. Email me separately.


Carlos.

Matt Roveto wrote:

Hello,

I hope you are all well. I am trying to implement a transmission 
switching DCOPF model to MATPOWER for use in a research project 
according to the formulation provided in E. B. Fisher, R. P. O’Neill, 
and M. C. Ferris, “Optimal transmission switching,” IEEE Trans. Power 
Syst. vol 23, no. 3, August 2008. To be concise, the main difference 
from the standard DCOPF and the model implementing transmission 
switching is the flow constraints on the lines given by


B_k(\theta_n - \theta_m) - P_{nk} = 0

is split into two separate inequality constraints

B_k(\theta_n - \theta_m) - P_{nk} + (1 - z_k)M >= 0

B_k(\theta_n - \theta_m) - P_{nk} - (1 - z_k)M <= 0

with an additional constraint on the integer variable z_k to limit the 
number of open lines in the network, namely


\sum_k (1 - z_k) <= j

In this formulation, z_k is an integer value that takes on either 1 or 
0 for a closed or open line, M is a large number greater than or equal 
to B_k(\theta_n - \theta_m), and j is the total number of lines that 
can be opened. My problem is that I do not know what to do in order to 
add these new constraints or modify the usual constraints. I 
understand there is a section in the user manual on how to add 
constraints, but it is my understanding from reading through past 
threads that it is not possible to simply add integer constraints in 
this manner. I believe I would need to change the solver to 'MIPS' or 
'IPOPT', but I am still unsure how to incorporate the new constraints. 
Any help would be greatly appreciated, and sorry I do not have much to 
go on right now. Thank you.


Best,
Matt

Re: PF and OPF did not converge

[Carlos E Murillo-Sanchez]

  
  
Yes, both of them.  Some reactances are
  larger than unity ... that's a lot for a branch.  And for the OPF,
  you certainly need the slack generator with much larger PMAX.  I
  tried a simple test reducing all branch parameters by a tenfold
  and the power flow converged.
  
  Carlos.
  
  Charalambos Ioannou wrote:


  
  Dear Carlos, 
  
  
  So you are suggesting to check again the loads and
also to reduce the reactances of the branches ? 
  
  
  Moreover to define a value for PMAX of the slack bus
?
  
  
  Thanks

  
On 4 Oct 2017, at 18:12, Carlos E
  Murillo-Sanchez <ce.murillosanc...@gmail.com>
  wrote:


  
Dear Charalambos: 

To begin with, you have a load of 894.31 MW (computed
with sum(mpc.bus(:,PD))  and a total generation capacity
of 30 (computed with sum(mpc.gen(:, PMAX)) .  Your slack
generator has PMAX specified as zero.  And it seems to
me that many of your branch reactances are way too high
to allow a poser flow solution with a total load of 8.1
p.u. ,

Carlos.


Charalambos Ioannou wrote:
  
  

  
  

  Hi
Abhyankar, 
  
  
  I already
did that you send before but i am facing the
same problems.
  
  
  Thanks 
  
  
  Regards 
  
  
  Charalampos 



Get Outlook for iOS
  


From: bounce-121902634-79270...@list.cornell.edu <bounce-121902634-79270...@list.cornell.edu> on behalf of
Abhyankar, Shrirang G. <abhy...@anl.gov>
Sent: Tuesday,
October 3, 2017 3:43:04 PM
To: MATPOWER
discussion forum
Subject: Re: PF and
OPF did not converge
   


  

  http://www.pserc.cornell.edu/matpower/#pfconvergence

   

  
From: <bounce-121902459-73493...@list.cornell.edu> on
  behalf of Charalambos Ioannou<xaralambo...@hotmail.com>
  Reply-To: MATPOWER
  discussion forum <matpowe...@list.cornell.edu>
  Date: Tuesday,
  October 3, 2017 at 9:12 AM
  To: "MATPOWER-L@cornell.edu" <MATPOWER-L@cornell.edu>
  Subject: PF
  and OPF did not converge


  
 


  
Dear Ray, 
  
 
  
I am trying to run PF and OPF for the
  following case but every time it doesnt
  converged the system. Please can you give me
  any advice??
  
 
  
The system consist 62 buses, 23
  transformers, 8 photo voltaic plants and 1
  Natural gus generator. 
  
 
  
I consider all the buses as Type
  1(PQ) and the natural gas generator as Type 2
  (PV). The real power demand (Pd) for the photo
  voltaic plants i gave them a negative sign.  
  
 
  

  function mpc =
IsleExample3()
  
  

   
  
  

  TCL MERGE ERROR (

Re: PF and OPF did not converge

[Carlos E Murillo-Sanchez]

  
  
Dear Charalambos: 
  
  To begin with, you have a load of 894.31 MW (computed with
  sum(mpc.bus(:,PD))  and a total generation capacity of 30
  (computed with sum(mpc.gen(:, PMAX)) .  Your slack generator has
  PMAX specified as zero.  And it seems to me that many of your
  branch reactances are way too high to allow a poser flow solution
  with a total load of 8.1 p.u. ,
  
  Carlos.
  
  
  Charalambos Ioannou wrote:


  
  
  
  
  
  
  


  
Hi Abhyankar, 


I already did that you send
  before but i am facing the same problems.


Thanks 


Regards 


Charalampos 
  
  
  
  Get Outlook for iOS

  
  
  From:
  bounce-121902634-79270...@list.cornell.edu
   on behalf
  of Abhyankar, Shrirang G. 
  Sent: Tuesday, October 3, 2017 3:43:04 PM
  To: MATPOWER discussion forum
  Subject: Re: PF and OPF did not converge
 
  
  

  http://www.pserc.cornell.edu/matpower/#pfconvergence
   
  
From:

on behalf of Charalambos Ioannou

Reply-To: MATPOWER discussion forum

Date: Tuesday, October 3, 2017 at 9:12 AM
To: "MATPOWER-L@cornell.edu"

Subject: PF and OPF did not converge
  
  
 
  
  
Dear Ray, 
 
I am trying to run PF and OPF for the
following case but every time it doesnt converged the
system. Please can you give me any advice??
 
The system consist 62 buses, 23
transformers, 8 photo voltaic plants and 1 Natural gus
generator. 
 
I consider all the buses as Type 1(PQ) and
the natural gas generator as Type 2 (PV). The real power
demand (Pd) for the photo voltaic plants i gave them a
negative sign.  
 

  function mpc = IsleExample3()


   


  TCL MERGE ERROR ( 10/03/2017 10:44:16 ):
  "invalid command name "MATPOWER"" OutmailID:
  121902634, List: 'matpower-l', MemberID: 79270638
  SCRIPT: "MATPOWER Case Format : Version 2


  mpc.version = '2';



  " -  Power Flow Data  -TCL MERGE
  ERROR ( 10/03/2017 10:44:16 ): "invalid command name "
  "" OutmailID: 121902634, List: 'matpower-l', MemberID:
  79270638 SCRIPT: "


  " system MVA base



  mpc.baseMVA = 100;



  TCL MERGE ERROR ( 10/03/2017 10:44:16 ):
  "invalid command name "bus"" OutmailID: 121902634,
  List: 'matpower-l', MemberID: 79270638 SCRIPT: "bus
  data



  % bus_i  type Pd  Qd Gs Bs
  area Vm
  Va baseKV
  zone Vmax
  Vmin



  mpc.bus = [


      1   3   30.4   14.7   0   0   1   1 
   0   132 1   1.06    0.94;


      2   1   30.4   14.7   0   0   1   1 
   0   132 1   1.06    0.94;


      3   1   22.8   22.8   0   0   1   1 
   0   132 1   1.06    0.94;


      4   1   22.8   22.8   0   0   1   1 
   0   132 1   1.06    0.94;


      5   1   113    55     0   0   1   1 
   0   132 1   1.06    0.94;


      6   1   113    55     0   0   1   1 
   0   132 1   1.06    0.94;


      7   1   0   0   0   0   1   1   0 
   132 1   1.06    0.94;


      8   1   113    55     0   0   1   1 
   0   132 1   1.06    0.94;


      9   1   113    55     0   0   1   1 
   0   

Re: Hydropower in MATPOWER MOST

[Carlos E Murillo-Sanchez]

Stephen:

For hydro plants with reservoir, the way I have done this is by 
assigning a daily (or weekly, depending on the length of the planning 
horizon)  amount of energy as the initial storage state, to be used 
throughout the horizon optimally.  As for the cost, it could even be 
zero;  the price of water will be set by virtue of the thermal 
generation displaced by hydro power.


Carlos.

Stephen Suffian wrote:

Ray and all,

I was wondering if anyone has experience in modeling hydro commitment 
in MOST. I understand that a comprehensive hydropower commitment 
incorporates medium and long-term solutions.


However, I am hoping to build a simplified model that possibly assumes 
energy constraints on the hydro at the daily or weekly level, and then 
looks to solve hourly commitment based on these constraints. Have 
other people incorporated hydro in some way? Perhaps there is a way to 
consider it a form of storage that can only be externally recharged 
(through rainfall)? Do I develop a profile in order to have a 
time-dependent cost function? Any help on the matter would be greatly 
appreciated!


Stephen Suffian

Re: How to form the connection or bus incidence matrix ?

[Carlos E Murillo-Sanchez]

  
  
Saeed: you need to add the sdp_pf
  sub-folder to MATLAB's execution path.
  
  carlos.
  
  Saeed Ahmed wrote:


  
Hi
  Community, 


For
  Making the he connection or bus incidence  matrix  i use
  following function

  function [Ainc] = makeIncidence(bus, branch)

But
  i get following result



  Undefined function or variable
  'makeIncidence'.
  Error
  in test1 (line 73)
  
  [Ainc] =
  makeIncidence(cd.bus,cd.branch)






  

  

  
Regards
Saeed
Ahmed


  

  

  

  


  

Re: Asymmetrical transmission line limits

[Carlos E Murillo-Sanchez]

  
  
You can get an approximation to this on
  the active power flow using the angular difference limits in
  specified in the branch table.  Columns ANGMAX and ANGMIN tell the
  opf solver to implement
  
  ANGMIN  <=  \theta_f - \theta_t  <=  ANGMAX
  
  Carlos.
  
  Stalinski, Danisz wrote:


  
  
  
  
Hello,
 
I was working on an OPF problem with
  MATPOWER where I was trying to set asymmetrical limits on the
  transmission lines between nodes.
  
 
E.g.
For a transmission line between two buses,
  A and B, I was hoping to set the transmission limit from A to
  B as some value x, and the transmission limit from B to A is
  some
  different value y (i.e. x ~= y).
 
As far as I can tell when a branch is
  declared in ‘mpc.branch’, it is always bidirectional and the
  limits imposed are the same regardless of the direction of
  power flow.
 
Does anyone know how I could possibly set
  asymmetrical limits on the transmission lines? If anyone could
  provide some insight into this problem it would be greatly
  appreciated.
 
Danisz Stalinski
  


  

Re: DCOPF with non-convex obj. function

[Carlos E Murillo-Sanchez]

  
  
Oh, and by the way, do try IPOPT if you
  still have not done so.
  Carlos
  
  Carlos E Murillo-Sanchez wrote:


  
  Enrico:

I would certainly experiment with the values of the reactive
component of loads.  In fact, an extreme measure intended to
make this problem more like a DC OPF, while still retaining the
AC solver, would be to add synchronous capacitors (generators
with Pmin=Pmax =0) to as many load buses as possible, with
voltage setpoint of 1.0 .  Then you'd have automatic reactive
compensation essentially everywhere, and the active dispatch
would pretty much be free of reactive considerations.

Carlos.

Enrico Vaccariello wrote:
  
  
Dear Dr. Sanchez,
  Thank you very much for your input.
  According to the manual, the DC-OPF should not take in
consideration voltage magnitudes and reactive powers. I
believe I have understood that what you are suggesting is to
"manually" implement the simplifying assumptions of a DC-OPF
in such a way that the AC-OPF provides similar results.
  I have already set all the branch resistances and
charging susceptances to zero. Anyway, I am still having
some convergence issues, but I believe they are not being
merely numerical as before.
  
  
  Now, do you think it would be right to set equal to zero
all the bus reactive loads as well? In fact, since my
original intentions were to run the simulation in AC, all my
loads had been originally defined as ohmic-inductive with
non-zero reactive demand. The necessity of simplifying my
problem down to a DC model was born after I faced too many
unexplained convergence issues.
  
  
  Thank you.
  Best regards,
  
  
        Enrico
  
2017-02-25 22:01 GMT+01:00 Carlos E
      Murillo-Sanchez <ce.murillosanc...@gmail.com>:
  Perhaps

you can try to run an AC OPF with branches that are
represented only by the series reactance (no line
charging capacitance nor resistance); one of the AC
solvers might be able to solve the resulting problem.

Carlos.

  

Enrico Vaccariello wrote:

  Dear all MATPOWER developers and users,
  
  I will briefly explain my issue.
  I am trying to run a DC-OPF on my 285-bus case,
  whose generators costs' curves have been defined
  as second-order polynomials.
  Some of these polynomials have negative convexity,
  as the one shown by the red line of the graph I am
  attaching.
  
  When I try to run the DC-OPF it does not converge.
  This happens with all the simplex, dual-simplex
  and primal-simplex OT and the MIPS solver.
  In the case of the first three linprog solvers, I
  get the error message: "The problem is
  non-convex".
  Therefore, I have changed the convexity of my cost
  curves polynomials, just as a test, by modifying
  their first coefficient:
  mpc.gencost(:,5)=abs(mpc.gencost(:,5)). The
  result of the changes is shown by the blue curve
  of the graph I am attaching. Both the curves refer
  to the same CCGT generator.
  
  Performing the same DC-OPF simulation with such
  modifications leads to convergence.
  Therefore (excuse me if that's trivial) the
  convexity of the cost curves guarantees the
  convexity of the objective function.
  Anyway, since my actual cost curves are
  non-convex, could you please indicate any other
  solver allowing to work with non-convex objective
  functions?
  
  Thank you, any help will be very appreciated.
  Best regards,
  
        Enrico
  
  



  

  


  

  
  


  

Re: DCOPF with non-convex obj. function

[Carlos E Murillo-Sanchez]

  
  
Enrico:
  
  I would certainly experiment with the values of the reactive
  component of loads.  In fact, an extreme measure intended to make
  this problem more like a DC OPF, while still retaining the AC
  solver, would be to add synchronous capacitors (generators with
  Pmin=Pmax =0) to as many load buses as possible, with voltage
  setpoint of 1.0 .  Then you'd have automatic reactive compensation
  essentially everywhere, and the active dispatch would pretty much
  be free of reactive considerations.
  
  Carlos.
  
  Enrico Vaccariello wrote:


  Dear Dr. Sanchez,
Thank you very much for your input.
According to the manual, the DC-OPF should not take in
  consideration voltage magnitudes and reactive powers. I
  believe I have understood that what you are suggesting is to
  "manually" implement the simplifying assumptions of a DC-OPF
  in such a way that the AC-OPF provides similar results.
I have already set all the branch resistances and charging
  susceptances to zero. Anyway, I am still having some
  convergence issues, but I believe they are not being merely
  numerical as before.


Now, do you think it would be right to set equal to zero
  all the bus reactive loads as well? In fact, since my original
  intentions were to run the simulation in AC, all my loads had
  been originally defined as ohmic-inductive with non-zero
  reactive demand. The necessity of simplifying my problem down
  to a DC model was born after I faced too many unexplained
  convergence issues.


Thank you.
Best regards,


      Enrico

  2017-02-25 22:01 GMT+01:00 Carlos E
        Murillo-Sanchez <ce.murillosanc...@gmail.com>:
Perhaps
  you can try to run an AC OPF with branches that are
  represented only by the series reactance (no line charging
  capacitance nor resistance); one of the AC solvers might
  be able to solve the resulting problem.
  
  Carlos.
  

  
  Enrico Vaccariello wrote:
  
Dear all MATPOWER developers and users,

I will briefly explain my issue.
I am trying to run a DC-OPF on my 285-bus case,
whose generators costs' curves have been defined as
second-order polynomials.
Some of these polynomials have negative convexity,
as the one shown by the red line of the graph I am
attaching.

When I try to run the DC-OPF it does not converge.
This happens with all the simplex, dual-simplex and
primal-simplex OT and the MIPS solver.
In the case of the first three linprog solvers, I
get the error message: "The problem is non-convex".
Therefore, I have changed the convexity of my cost
curves polynomials, just as a test, by modifying
their first coefficient:
mpc.gencost(:,5)=abs(mpc.gencost(:,5)). The
result of the changes is shown by the blue curve of
the graph I am attaching. Both the curves refer to
the same CCGT generator.

Performing the same DC-OPF simulation with such
modifications leads to convergence.
Therefore (excuse me if that's trivial) the
convexity of the cost curves guarantees the
convexity of the objective function.
Anyway, since my actual cost curves are non-convex,
could you please indicate any other solver allowing
to work with non-convex objective functions?

Thank you, any help will be very appreciated.
Best regards,

      Enrico


  
  
  

  

  
  

  


  

Re: DCOPF with non-convex obj. function

[Carlos E Murillo-Sanchez]

Perhaps you can try to run an AC OPF with branches that are represented 
only by the series reactance (no line charging capacitance nor 
resistance); one of the AC solvers might be able to solve the resulting 
problem.


Carlos.

Enrico Vaccariello wrote:

Dear all MATPOWER developers and users,

I will briefly explain my issue.
I am trying to run a DC-OPF on my 285-bus case, whose generators 
costs' curves have been defined as second-order polynomials.
Some of these polynomials have negative convexity, as the one shown by 
the red line of the graph I am attaching.


When I try to run the DC-OPF it does not converge. This happens with 
all the simplex, dual-simplex and primal-simplex OT and the MIPS solver.
In the case of the first three linprog solvers, I get the error 
message: "The problem is non-convex".
Therefore, I have changed the convexity of my cost curves polynomials, 
just as a test, by modifying their first coefficient: 
mpc.gencost(:,5)=abs(mpc.gencost(:,5)). The result of the changes is 
shown by the blue curve of the graph I am attaching. Both the curves 
refer to the same CCGT generator.


Performing the same DC-OPF simulation with such modifications leads to 
convergence.
Therefore (excuse me if that's trivial) the convexity of the cost 
curves guarantees the convexity of the objective function.
Anyway, since my actual cost curves are non-convex, could you please 
indicate any other solver allowing to work with non-convex objective 
functions?


Thank you, any help will be very appreciated.
Best regards,

  Enrico

Re: Error running PF

[Carlos E Murillo-Sanchez]

Brenda: That is exactly what the slack generator is expected to do in a 
traditional load flow.  I suggest that you look up any classic textbook 
(Bergen, Wood & Wollenberg, etc.) and learn about the load flow problem 
and its standard assumptions.


carlos.

BRENDA ROJAS DELGADO wrote:

Hi, everyone:

I was running a power flow for case9 and I noticed that the slack bus 
gives some wrong behavior. I give two examples:


1. Running first PF with Matlab 2015a and Matpower 5.0.b1 and later 
with Matlab 2016a and Matpower version 6.


mpc=loadcase('case9');
mpc.gen(1,9:10)=[10 0];
mpc.gen(3,9)=300;
results=runpf(mpc);

MATPOWER Version 5.0b1, 01-Jul-2014 -- AC Power Flow (Newton)
MATPOWER Version 6.0, 16-Dec-2016 -- AC Power Flow (Newton)

Newton's method power flow converged in 4 iterations.

Converged in 0.01 seconds

| System Summary   |


How many?How much?  P (MW)  Q (MVAr)
----  - 
 -

Buses  9 Total Gen Capacity 610.0-900.0 to 900.0
Generators 3 On-line Capacity   610.0-900.0 to 900.0
Committed Gens 3 Generation (actual)320.0  34.9
Loads  3 Load   315.0 115.0
  Fixed3   Fixed315.0 115.0
  Dispatchable 0   Dispatchable  -0.0 of -0.0  -0.0
Shunts 0 Shunt (inj) -0.0   0.0
Branches   9 Losses (I^2 * Z) 4.95   51.31
Transformers   0 Branch Charging (inj) -  131.4
Inter-ties 0 Total Inter-tie Flow 0.0   0.0
Areas  1

  Minimum  Maximum
 - 
 

Voltage Magnitude   0.958 p.u. @ bus 9  1.003 p.u. @ bus 6
Voltage Angle  -4.35 deg   @ bus 9  9.67 deg   @ bus 2
P Losses (I^2*R) -  2.46 MW  @ line 8-9
Q Losses (I^2*X) - 16.74 MVAr  @ line 8-2


| Bus Data   |

 Bus  Voltage  Generation Load
  #   Mag(pu) Ang(deg)   P (MW)   Q (MVAr)   P (MW)   Q (MVAr)
- ---         
1  1.0000.000*71.95 24.07   - -
2  1.0009.669163.00 14.46   - -
3  1.0004.771 85.00 -3.65   - -
4  0.987   -2.407   - - - -
5  0.975   -4.017   - -   90.00 30.00
6  1.0031.926   - - - -
7  0.9860.622   - -  100.00 35.00
8  0.9963.799   - - - -
9  0.958   -4.350   - -  125.00 50.00
      
   Total:319.95 34.88315.00  115.00


| Branch Data  |

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 71.95 24.07-71.95  -20.75-0.000 
 3.32
   2  4  5 30.73 -0.59-30.55  -13.69 0.174 
 0.94
   3  5  6-59.45-16.31 60.89  -12.43 1.449 
 6.31

   4  3  6 85.00 -3.65-85.00  7.89-0.000  4.24
   5  6  7 24.11  4.54-24.01  -24.40 0.095 
 0.81

   6  7  8-75.99-10.60 76.50  0.26 0.506  4.29
   7  8  2   -163.00  2.28163.00 14.46 0.000 16.74
   8  8  9 86.50 -2.53-84.04  -14.28 2.465 
12.40

   9  9  4-40.96-35.72 41.23 21.34 0.266  2.26
     
Total: 4.955 51.31

The results are exactly the same, but what is not normal is that if I 
am forcing both active and reactive power on the slack bus to be 10 MW 
and 0 MVAr respectively, slack bus power is 72 MW, which by far bigger 
than the initial value I impossed it.


So, why is this happening?

Thanks in advance for any reply. Best regards.

Re: generate a new case file

[Carlos E Murillo-Sanchez]

  
  
With the loading pattern in your
  network, it is simply not possible to attain the voltage levels
  that you want without using some sort of voltage compensation at
  one or more locations.  Even setting the voltage setpoint of the
  source at 1.1 p.u., the resulting voltages are:
  

  | Bus
  Data
  |

   Bus  Voltage  Generation Load    
    #   Mag(pu) Ang(deg)   P (MW)   Q (MVAr)   P (MW)   Q (MVAr)
  - ---         
      1  1.100    0.000*    31.33 20.53   - -   
      2  0.958   -2.552   - - - -   
      3  0.939   -2.770   - - - -   
      4  1.060   -0.783   - -    2.00  1.60 
      5  1.025   -1.566   - -    3.00  1.50 
      6  1.054   -1.014   - -    2.00  0.80 
      7  1.053   -1.020   - -    1.50  1.20 
      8  0.958   -2.552   - -    4.00  2.70 
      9  0.975   -2.217   - -    5.00  3.00 
     10  0.946   -2.670   - -    1.00  0.90 
     11  1.011   -1.742   - -    0.60  0.10 
     12  0.969   -2.420   - -    4.50  2.00 
     13  0.939   -2.770   - -    1.00  0.90 
     14  0.937   -2.807   - -    1.00  0.70 
     15  0.942   -2.711   - -    1.00  0.90 
     16  0.941   -2.739   - -    2.10  1.00 
            
     Total: 31.33 20.53 28.70 17.30
  
  Carlos.
  
  siddique tomal wrote:


  Dear Ray,
Thanks for reply. Actually I just needed the
  load flow with facility of voltage constraints but later on I
  found that it's not possible in normal load flow that's why
  I'm now interested in opf. it provides the facility of voltage
  constraints. And my voltage constraints limit is 0.95-1.05 .
  but now you're saying to set bus voltage at 0.85 which is
  lower than lower constraint value. I would be so much grateful
  to you if you kindly say if there is any other way to
  accomplish my demand.
Thanks
  
  
On Jan 31, 2017 11:34 PM, "Ray
  Zimmerman" 
  wrote:
  
The problem is not
  feasible due to voltage constraints. Notice that voltages
  in the power flow solution go as low as 0.813 p.u., but
  your case includes OPF lower bounds on voltages at every
  bus of 0.95 p.u. Relaxing those voltage constraints allows
  the OPF to converge.
  
  
  define_constants;
  mpc = loadcase('case_radial16');
  mpc.bus(:, VMIN) = 0.85;
  r = runopf(mpc);
  
  
  
  
     Ray



  

  
On Jan 31, 2017, at 9:55 AM, siddique tomal
  
  wrote:


  
Dear Ray,
  Thanks for your reply. I
have prepared a 16 bus system. The power
flow program runs OK with that but when
I go for Optimal Power Flow it shows  it
did not convergence. I have attached the
file below here. Please would you check
the file and direct me what to change ?
Waiting to hear from you.
  Thanks


  On Jan 6, 2017
1:33 AM, "Ray Zimmerman" 
wrote:

  See
Section 2.3.1 and Appendix B in the User’s Manual.
It’s probably easiest to start with
an existing case file and modify it
for your data. Let us know if you

Re: capacitive transformer branches in casefiles?

[Carlos E Murillo-Sanchez]

  
  
Hi;
  
  Looking at the diagram of the 118 bus system, it seems that the
  branches in question are a combination of  a transformer and a
  line.  Evidently, the pi model in the case data is an
  approximation of this combined setup.  But that is how the
  original data in the IEEE
  cdf file is coded.
  
  Carlos.
  
  Leon Thurner wrote:


  
  
  
  
Dear All,
 
we are trying to
translate the matpower casefiles to pandapower but have
encountered problems when converting cases with
transformers. We would expect transformers always to behave
inductive, but the transformer branches in the cases always
seem to have a positive b value. If I am not mistaken, that
models a capacitive behaviour. An example of this can be
found in case118 with the branches that connect buses 68
(345 kV) and bus 116 (138kV) as well as a branch that
connects bus 86 (138kV) and bus 87 (161kV). Both of these
branches have a positive susceptance while connecting
different voltage levels.
 
Is there an
explanation for that, i.e. do these branches not only model
a transformer but a whole substation with reactive power
compensation device as well? Or am I missing something else?
 
Thanks for your help
Leon
 
-
 
Leon
Thurner, M.Sc.
 
Universität
Kassel
Fachgebiet
Energiemanagement und Betrieb elektrischer Netze
Wilhelmshöher
Alle 73
34121
Kassel
 
Tel.:
+49 561 804 6377
E-Mail:
leon.thur...@uni-kassel.de
 
  


  

Re: Ybus-matrix

[Carlos E Murillo-Sanchez]

  
  
Hmm... that is an odd question. 
  Looking at the Kron reduction myself, I find that there are six
  off-diagonal elements with positive real parts, which would imply
  six "lines" in this 54 bus "network" with negative resistance.  I
  suppose that you could actually synthesize values for pi models
  that would give you the observed coefficients in the reduced
  matrix, but some of the parameters would not be physically
  possible.
  
  carlos.
  
  Philip Adedotun Olaniyi wrote:


  
  
  
  
Thank you so
much sir. My next question would be, is it possible to
compute the bus and branch tables from the 54-by-54
admittance matrix? Thank you
 

  
From:
bounce-120671035-76197...@list.cornell.edu
[mailto:bounce-120671035-76197...@list.cornell.edu]
    On Behalf Of Carlos E Murillo-Sanchez
Sent: Friday, August 05, 2016 11:10 AM
To: MATPOWER discussion forum
<matpowe...@list.cornell.edu>;
MATPOWER-L@cornell.edu
Subject: Re: Ybus-matrix
  

 

  When you simplified away the PQ buses,
you lost the ability to specify loads in them.  So,
theoretically, you could perform a load flow in which you
can only have loads at the 54 generator buses.  You cannot
use runpf, though,  as runpf starts by building the Ybus
matrix from the bus and branch tables; it does not take Ybus
as an input.  You would have to call newtonpf.m directly
with suitable parameters.

carlos.

Philip Adedotun Olaniyi wrote:


  Hi MATPOWER community,
   
  I asked a question earlier and would like
to modify it. I have a reduced 54-by-54 admittance matrix
for case118. Can I use this as an input in MATPOWER for my
power flow analysis? How do I go about it?
  I would appreciate your help. Thank you.

 
  


  

Re: opf

[Carlos E Murillo-Sanchez]

The LMP are shadow prices (Lagrange multipliers) on the active nodal 
balance.  Even if there is no load at a bus, its balance equation must 
still be fulfilled and it carries with it a multiplier in the lagrangian 
function.


Mounika Vanjarapu wrote:
I have a doubt regarding the LMPs in an IEEE-14 bus system.In 14 bus 
system there are no loads at 7th and 8th buses but there is LMP value 
which is equal at both buses. How it is possible.

Re: Ybus-matrix

[Carlos E Murillo-Sanchez]

  
  
When you simplified away the PQ buses,
  you lost the ability to specify loads in them.  So, theoretically,
  you could perform a load flow in which you can only have loads at
  the 54 generator buses.  You cannot use runpf, though,  as runpf
  starts by building the Ybus matrix from the bus and branch tables;
  it does not take Ybus as an input.  You would have to call
  newtonpf.m directly with suitable parameters.
  
  carlos.
  
  Philip Adedotun Olaniyi wrote:


  
  
  
  
Hi MATPOWER community,
 
I asked a question earlier and would like
  to modify it. I have a reduced 54-by-54 admittance matrix for
  case118. Can I use this as an input in MATPOWER for my power
  flow analysis? How do I go about it?
I would appreciate your help. Thank you.
  


  

Re: MOST example

[Carlos E Murillo-Sanchez]

  
  
To further ellucidate:  MOST was
  developed with lots of user options so that you can really
  customize it to many kinds of problems; the design decisions arose
  after using it ourselves in many different ways. This will
  probably make for a steep learning curve, but we hope that it will
  be useful for most people and most problems. 
  
  carlos.
  
  Carlos E Murillo-Sanchez wrote:


  
  Because modeling as a dispatchable
(up to Pmax) generator allows the optimization to curtail the
wind intake for security reasons.  Of course, if the wind is
considered must-take, you can always set Pmin=Pmax .  Modeling
this way gives you more options.

carlos.


Bai, Wenlei wrote:
  
  




  Thanks

  Carlos. I see. That makes sense. But why not always
  maximizing the wind power and model it as negative PQ bus?
  
   
  Wenlei
   
  

  From:
  bounce-120538094-71172...@list.cornell.edu
  [mailto:bounce-120538094-71172...@list.cornell.edu]
  On Behalf Of Carlos E Murillo-Sanchez
  Sent: Friday, June 03, 2016 11:29 AM
  To: MATPOWER discussion forum <matpowe...@list.cornell.edu>
  Subject: Re: MOST example

  
   
  
For each time period, there can be
  several wind scenarios. The idea is to capture the
  variability of wind, given a forecast, using those
  plausible wind realizations.  In each scenario, the Pmax
  value of the wind generator varies to indicate the
  availability of wind for that particular scenario.  The
  optimization then will decide on whether to push the Pg of
  the wind turbine all the way to that Pmax or somewhere in
  between if there is a need to curtail some of the wind
  generation.
  
  Carlos.
  
  
  Bai, Wenlei wrote:
  
  
Thanks

Ray, I’ll try to get CPLEX.
Another

question about the wind power integration, do you model
wind power injection as a control variable to be solved
after optimization,
or

you model wind power injection as negative load on PQ
bus since wind power can be known by forecasting under
each scenario? 
If

the wind power is control variable,  how it can be
determined since we cannot control weather condition? 
 
Best,
Wenlei
 

  
From: bounce-120537672-71172...@list.cornell.edu
[mailto:bounce-120537672-71172...@list.cornell.edu]
On Behalf Of Ray Zimmerman
Sent: Friday, June 03, 2016 9:29 AM
To: MATPOWER discussion forum  <matpowe...@list.cornell.edu>
Subject: Re: MOST example
  

 
MOST requires a good MILP solver for UC
  problems. I believe that only the very latest versions of
  intlingprog (of the Optimization Toolbox) are up for the
  task. If you don’t have the latest version of Matlab (and
  even if you do), I would strongly recommend using Gurobi
  or CPLEX (free for academics) if possible.

   


  So, I suspect the issue may be that
you do not have the latest version of intlinprog. Type mpver to display
the versions of all of the MATPOWER related tools
installed.
  
 
  
  
   Ray

   


   
  

  
On Jun 2, 2016, at 9:07 PM,
  Bai, Wenlei <wenlei_...@baylor.edu>

  wrote:
  
   
  

  Dear Ray
Thanks for releasing the latest matpower6.1
version which includes plenty of new useful
tools.
I was trying to run the sample codes in
Section 2.3.1 of MOST manual. However it
feedback me errors.
   

Re: MOST example

[Carlos E Murillo-Sanchez]

  
  
Because modeling as a dispatchable (up
  to Pmax) generator allows the optimization to curtail the wind
  intake for security reasons.  Of course, if the wind is considered
  must-take, you can always set Pmin=Pmax .  Modeling this way gives
  you more options.
  
  carlos.
  
  
  Bai, Wenlei wrote:


  
  
  
  
Thanks
Carlos. I see. That makes sense. But why not always
maximizing the wind power and model it as negative PQ bus?

 
Wenlei
 

  
From:
bounce-120538094-71172...@list.cornell.edu
[mailto:bounce-120538094-71172...@list.cornell.edu]
On Behalf Of Carlos E Murillo-Sanchez
Sent: Friday, June 03, 2016 11:29 AM
To: MATPOWER discussion forum
<matpowe...@list.cornell.edu>
Subject: Re: MOST example
  

 

  For each time period, there can be
several wind scenarios. The idea is to capture the
variability of wind, given a forecast, using those plausible
wind realizations.  In each scenario, the Pmax value of the
wind generator varies to indicate the availability of wind
for that particular scenario.  The optimization then will
decide on whether to push the Pg of the wind turbine all the
way to that Pmax or somewhere in between if there is a need
to curtail some of the wind generation.

Carlos.


Bai, Wenlei wrote:


  Thanks
  Ray, I’ll try to get CPLEX.
  Another
  question about the wind power integration, do you model
  wind power injection as a control variable to be solved
  after optimization,
  or
  you model wind power injection as negative load on PQ bus
  since wind power can be known by forecasting under each
  scenario?

  If
  the wind power is control variable,  how it can be
  determined since we cannot control weather condition?

   
  Best,
  Wenlei
   
  

  From:
  bounce-120537672-71172...@list.cornell.edu
  [mailto:bounce-120537672-71172...@list.cornell.edu]
  On Behalf Of Ray Zimmerman
  Sent: Friday, June 03, 2016 9:29 AM
  To: MATPOWER discussion forum 
<matpowe...@list.cornell.edu>
  Subject: Re: MOST example

  
   
  MOST requires a good MILP solver for UC
problems. I believe that only the very latest versions of
intlingprog (of the Optimization Toolbox) are up for the
task. If you don’t have the latest version of Matlab (and
even if you do), I would strongly recommend using Gurobi or
CPLEX (free for academics) if possible.
  
 
  
  
So, I suspect the issue may be that you
  do not have the latest version of intlinprog. Type
  mpver to display
  the versions of all of the MATPOWER related tools
  installed.

   


     Ray
  
 
  
  
 

  

  On Jun 2, 2016, at 9:07 PM,
Bai, Wenlei <wenlei_...@baylor.edu>
wrote:

 

  
Dear Ray
  Thanks for releasing the latest matpower6.1
  version which includes plenty of new useful
  tools.
  I was trying to run the sample codes in
  Section 2.3.1 of MOST manual. However it
  feedback me errors.
  I've attached it, could you take a look?
  
  Much appreciation
  Wenlei
  
  
  
  

  

 
  

  

 
  


  

Re: MOST example

[Carlos E Murillo-Sanchez]

  
  
For each time period, there can be
  several wind scenarios. The idea is to capture the variability of
  wind, given a forecast, using those plausible wind realizations. 
  In each scenario, the Pmax value of the wind generator varies to
  indicate the availability of wind for that particular scenario. 
  The optimization then will decide on whether to push the Pg of the
  wind turbine all the way to that Pmax or somewhere in between if
  there is a need to curtail some of the wind generation.
  
  Carlos.
  
  
  Bai, Wenlei wrote:


  
  
  
  
Thanks
Ray, I’ll try to get CPLEX.
Another
question about the wind power integration, do you model wind
power injection as a control variable to be solved after
optimization,
or
you model wind power injection as negative load on PQ bus
since wind power can be known by forecasting under each
scenario?

If
the wind power is control variable,  how it can be
determined since we cannot control weather condition?

 
Best,
Wenlei
 

  
From:
bounce-120537672-71172...@list.cornell.edu
[mailto:bounce-120537672-71172...@list.cornell.edu]
On Behalf Of Ray Zimmerman
Sent: Friday, June 03, 2016 9:29 AM
To: MATPOWER discussion forum

Subject: Re: MOST example
  

 
MOST requires a good MILP solver for UC
  problems. I believe that only the very latest versions of
  intlingprog (of the Optimization Toolbox) are up for the task.
  If you don’t have the latest version of Matlab (and even if
  you do), I would strongly recommend using Gurobi or CPLEX
  (free for academics) if possible.

   


  So, I suspect the issue may be that you
do not have the latest version of intlinprog. Type
mpver to display
the versions of all of the MATPOWER related tools installed.
  
 
  
  
   Ray

   


   
  

  
On Jun 2, 2016, at 9:07 PM,
  Bai, Wenlei 
  wrote:
  
   
  

  Dear Ray
Thanks for releasing the latest matpower6.1
version which includes plenty of new useful
tools.
I was trying to run the sample codes in Section
2.3.1 of MOST manual. However it feedback me
errors.
I've attached it, could you take a look?

Much appreciation
Wenlei




  

  
   

  

  


  

Re: penalty

[Carlos E Murillo-Sanchez]

Dear Mounika:

We need to understand the nature of your question.   It seems as if you 
might be trying to force a two-stage decision problem onto the framework 
of a single-stage one.  Hence Ray's answer.  Please ellucidate.


carlos.

Mounika Vanjarapu wrote:

sir
   can we pose penalties for the customers who don't curtail the load 
using matpower.

Re: Running bpmpd

[Carlos E Murillo-Sanchez]

Dear Malcolm:

It is very likely that you are running 64 bit Matlab. Unfortunately, 
compiling BPMPD for 64 bit architectures requires changing code all over 
the place, and we have not devoted time to such endeavour.   If you have 
MatlabR2010a or earlier in your unix/mac machine you can invoke the 32 
bit version with the command


: matlab -maci 

If you are running on windows, you might have the 32 bit version 
somewhere in the Program Files-x86 folder.


Carlos.

Malcolm Barnacle wrote:

Dear Carlos E. Murillo-Sanchez,



I am trying to use the bpmpd solver for a dcopf problem. I have unzipped the 
downloaded mex interface file and placed the *.m and the bp.mexw32 in a 
location on my matlab path, however, when trying to implement the solver within 
my code I get the following error:



Attempt to execute SCRIPT bp as a function (relating to bp.m)



I also get this error when executing test5.m



Do I need to compile the interface (using the instructions provided)? Or is 
this just an issue with the version of matpower i'm using (i'm using Matpower 
4.0)?



Also, I extracted the bpmpd package (from the bpmpd homepage) to my C: drive 
and placed the files from the src directory into this file.



Best Regards

Malcolm Barnacle

Re: Convergence Issue for Distribution Network Power Flow Analysis

[Carlos E Murillo-Sanchez]

  
  
Hi;
  
  You have used the TAP column of the branch table to indicate two
  transformers with a 55:1 ratio, and then you used the LV
  impedances, I think, still in PU with a base voltage of 22KV; they
  are pretty large.  The TAP column should be used to specify small
  variations about 1.0 for true tap-changing transformers.  All
  branch impedances should be specified using a single pu system.  
  I believe that the following is what you are actually trying to
  run:
  
  define_constants;
  mpc = loadcase('caseSG');
  mpc.branch(3:end, BR_R:BR_X) = mpc.branch(3:end, BR_R:BR_X) /
  55^2;
  mpc.branch(3:4, TAP) = 0;
  runpf(mpc);
  
  #ZHANG TIAN# wrote:


  
  
  
  
Dear All,
 
I am using Matpower for a
distribution network power flow analysis.

 
The data I used are taken
from a real network, and the network is working fine using
PowerWorld simulator. Basically, it is a radial network with
14 buses. Bus 1 is the connection point to the main grid,
which I modelled it as a slack bus (type 3).
 
However, when converting the
model into a Matpower case, I can only get a failure
notification “Did NOT converge (0.01 seconds)”.
 
Does anyone have any idea
about what might be the problem? Or what are the options for
me to debug?
 
I attached my case data in
this email for your reference.
 
Thank you all very much.
 
Best regards,
Tian

 

  


  

Re: AW: Solved case does not converge in zero iterations

[Carlos E Murillo-Sanchez]

  
  

  
  Dear Dominic:
  
  The PF solver takes the generator voltage setpoint from the gen(:,
  VG), thus changing the voltage values set by the OPF at generator
  buses.  Try
  
  resultsOPF=runopf(mpc)
  %calculate opf
  mpc.gen=resultsOPF.gen
  %update mpc with optimal P,V and angle values
  mpc.bus=resultsOPF.bus
  mpc.gen(:, VG) = mpc.bus(mpc.gen(:, GEN_BUS),
VM);
resultsPF=runpf(mpc)
  

  
  Regards,

  carlos.

   
  
  Hewes, Dominic wrote:


  
  
  
  
Hi
Uriel,
 
Thanks
for your quick response. I understand that the opf varies
the PV bus voltages (and other variables) in order to
achieve an optimal solution. However, if I take the results
of the opf (i.e the optimal generator P, V and bus V,Angle
etc) and use these to run a pf (which as you say fixes these
variables and does not allow them to change) then why should
I get different results in comparison to the opf results?
 
Maybe
my method description could be clearer. If I first run an
opf, and then update my original mpc struct with the
voltages, angles and powers from the opf results, and then
run a pf, surely I should get the same results as were
output by the opf? ie:
 
resultsOPF=runopf(mpc)
%calculate opf
 
mpc.gen=resultsOPF.gen
%update mpc with optimal P,V and angle values
mpc.bus=resultsOPF.bus
 
resultsPF=runpf(mpc)  
%run pf to calculate power flows given by the optimal P,V
and angle values
 
Does
this make any sense?
 
Again,
thanks for the response.
 
Regards,
 
Dominic
 
 
 

  
Von: bounce-118751957-69321...@list.cornell.edu
[mailto:bounce-118751957-69321...@list.cornell.edu]
Im Auftrag von Uriel Fernando Sandoval
Gesendet: Mittwoch, 28. Januar 2015 20:02
An: MATPOWER discussion forum
Betreff: Re: Solved case does not converge in
zero iterations
  

 
Hello Dominic,

   


  Probably you are confusing what is the
objective of each routine:


   


  On one hand opf tries to minimize the
production cost subject to voltage constraints : Vmin= V
= Vmax (for all buses, even PV buses) and other network
constraints, therefore, opf does not fix the terminal
voltage of the generators. 


   


  On the other hand pf solves and obtain an
equilibrium point that satisfy power balance equations, but,
in this case pf fixes the terminal voltage the generators
(PV buses)  Vk == Vref.


   


  IMHO that is the reason why your are
experiencing those differences.


   


   


  Best,


   


  Uriel


   


   
  

  
El 28/01/2015, a las 10:42, Hewes,
  Dominic dominic.he...@tum.de
  escribió:
  
   
  

  Dear
  Matpower Community,


   


  I
  am observing a strange problem whereby the results
  from a successful 'runopf()' do not seem to
  present a solved power flow case. I want to verify
  the power flow solution from an OPF by running a
  PF with the OPF results as the mpc struct.
  Firstly, the 'runpf()' converges in 1 iteration,
  whereas i would expect a solved case to converge
  in 0 iterations- am i mistaken here? Secondly,
  when i use the 'compare_case()' command to compare
  the OPF results with the resulting PF results, I
  see that there are large differences between the
  solutions. My code is as follows:
  

Re: Forcing PG,QG to zero in the slack bus

[Carlos E Murillo-Sanchez]

  
  
You should have no trouble; the slack
  generator will play the role of the "outside world".  The only
  difference with respect to reality would be if the MV network's
  load can actually affect the voltage at this bus. On the other
  hand, many such transformers actually have taps and attempt to do
  local regulation, so having the voltage magnitude specified
  (fixed) in this bus is probably close enough to reality.
  
  Regards,
  
  Carlos.
  
  Marco Barbetta wrote:


  Yes, the station is the only point of connection
between the two networks. 
My doubt was conceptual: does this generator represent
  correctly the flows of P and Q from the HV to the MV netwoks
  (or from MV to HV if Pg and Qg are negatives)? 
I agree that this is a model, but in my mind the fact that
  this generator doesn't exist in reality and at the same time
  represents my output is giving me some "conceputal" troubles.
  
  
  Thanks for your reply,
  
  
  Marco Barbetta 

  
  
2014-11-28 20:34 GMT+01:00 Carlos E
  Murillo-Sanchez ce.murillosanc...@gmail.com:
  If there
is only one point of connection from the MV network to the
HV one, why can't you model this particular bus as a
reference bus with a generator that can have both positive
and negative Pg?  Just set Pmin to something negative and
Pmax to some positive value.

Carlos.

  

Marco Barbetta wrote:

  Dear collegues,
  
  i have a problem with the slack bus. I discovered by
  myself that in MatPower a slack bus MUST have a
  generator in it, otherwise the algorithm looks for the
  next PV bus in order to set it as the reference bus.
  
  Well, in my case (as i specified in http://www.mail-archive.com/matpower-l%40cornell.edu/msg03745.html)
  i necessarily must set the slack bus in a bus without
  generation (primary station), while all other buses
  have to be set as PQ buses because i need to analyze
  voltage magnitude over time, so i need to let them
  free to change.
  
  I thought that imposing PG and QG = 0 over time (k =
  1:96, every 15 minutes) could resolve the problem:
  
  mpc.gen(:,PG) = p_gen(:,k);  where p_gen(1,k)
  = 0 always
  mpc.gen(:,QG) = q_gen(:,k);  where q_gen(1,k)
  = 0 always
  
  but analyzing the PF results i noted that the
  generator in the slack bus (that in the reality
  doesn't exists) has great values of PG and QG injected
  in every hour.
  
  Any idea about to how resolve this problem? I can't
  change the reference bus because i need to analyze the
  profile of power (P and Q) requested from the primary
  station (150/20 kV), looking for hours of power flow's
  inversion (from MV to HV network).
  
  Thanks to all,
  
  Marco Barbetta



  

  


  


  

Re: OPF convergence issue: resolving voltage constraint violations by optimizing generator dispatch

[Carlos E Murillo-Sanchez]

  
  
Isabel:
  
  Try creating a small band of acceptable voltage limits at the
  generator bus 
  say   VMIN =  Vcenter - epsilon = V = Vcenter + epsilon =
  VMAX,   then start slowly
  moving Vcenter from the initial optimization problem's solution
  towards the value that
  you want to set, and solve it for each case and look out for
  changes in the magnitude of the
  Lagrange multipliers everywhere; this might give you an idea about
  what is going wrong.
  
  carlos.
  
  
  Isabel Duque wrote:


  
  
Hello,
 
I’m using the Matpower
OPF in order to optimize the
dispatch of generators in a distribution network in case of
voltage constraint
violations.  The OPF is able to find a solution for my
initial
optimization problem.
However, as soon as I
try to set the voltage limits on
the bus of one of my generators to a certain value
(different from the acceptable
voltage range at the other buses) the OPF does not converge
anymore.  I’ve
tried not setting a specific value, but leaving some degree
of freedom for the
voltage at said generator bus, but the OPF still doesn’t
converge.
I’m trying to do the
“voltage setting” at the
generator bus in the mpc.bus file for maximum- and minimum
voltage magnitude:
maximum voltage magnitude = minimum voltage magnitude.
 
Does anyone have an
idea what could be the source of
this problem?
 
Best regards,
Isabel
  


  

Re: Load Voltages

[Carlos E Murillo-Sanchez]

[ref pv, pq] = bustypes(bus, gen)   ( or [ref pv, pq] = 
bustypes(results.bus, results.gen)   )


and then

results.bus(pq, VM)

carlos.


Kusi, Samuel A wrote:

Is there any way in MatPower to call out just the load voltages?

results.bus(:, VM) calls all buss voltages. Is there any code that can be used 
to output only load voltages?

Please advise

Re: matrix singular to working precision - error in AC powerflow

[Carlos E Murillo-Sanchez]

  
  
It seems to me that you have an
  instance of a data file which is aimed at detailed modeling of all
  of the system's elements. This kind of data is useful for
  graphical representation, but it poses a major problem: it
  assigns different bus numbers to elements that are actually at the
  same electrical point, such as a busbar in a substation. Then
  people put very small values for the series reactance and
  resistance connecting these "busbars". This has profound numeric
  consequences for the resulting Ybus matrix, which is trying to
  deal with two voltages which are in fact a single one.
  
  The only solution is to locate the instances of such bus
  disaggregation in the network data and collapse them into a single
  bus.
  
  People use network data for different purposes: graphical
  representation, equipment status representation, power flow. What
  is desirable for one purpose (i.e., detailed equipment description
  for substation breaker status visualization for example) can be
  troublesome for another purpose (load flow computation).
  
  carlos.
  
  Simon Schneider wrote:


  
  
  Dear Dr. Zimmerman, dear list
  
  When I encounter the error
  
  "Warning: Matrix is singular to working precision "
In newtonpf at 109: dx = - (J \ F)
  
  in a regular AC Powerflow, what is, in your experience, most
likely the cause?
  
  What I did:
  I'm trying to model a big grid (~4500 buses) out of real
data, so most likely I made a mistake while translating the data
to the casefile format?!
  
  Some things that caught my attention:
  
  - The Casefile.branch(:,'X') column contains values from
5e-006 to15 - Maybe that's to much of a span?
  
  - (J \ F) contains some"Inf" and"NaN" entries - should that
be the case?
  
  - there are a lot of different voltage levels in the grid
(mostly because of the respective generators and their base
voltage) - maybe the system is to complex?
  
  The same error occurs in DC PF and OPF as well by the way.
  
  
  I'm thankful for any useful input.
  Best regards
  Simon
  
  
  


  

Re: conductor resistance and power rating (MVA)

[Carlos E Murillo-Sanchez]

Dear Jiashen:

The model used in Matpower is the standard pi one-line equivalent of a 
three phase transmission line, with quantities in per-unit. This is 
constructed from a base voltage equal to sqrt(3) times the phase voltage 
and a base power equal to three times the per-phase power.  With this 
choice of base quantities, the base impedance is equal to the per-phase 
impedance. This is covered in most power systems analysis textbooks.


carlos.

Jiashen Teh wrote:

Dear Dr Ray,

Before asking my question, allow me to put us on the same level of 
understanding.
If I am not mistaken, each transmission line in reality is actually 
consists of 3 conductors connected in parallel.


Hence, these are my 2 questions based on the above assumption:

The resistance values in Matpower are
(a) the total resistance of 3 conductors connected in parallel?
or
(b)  the resistance for only one of the three conductors?


The line ratings in Matpower are
(a) the total rating for 3 conductors connected in parallel?
or
(b) the rating for only one of the three conductors?


Yours sincerely,

Jiashen Teh
PhD Student
Electrical Energy  Power Systems Group, School of Electrical  
Electronic Engineering
Ferranti Building (B18), The University of Manchester, M13 9PL, United 
Kingdom

Tel: +44 (0) 161 306 2263; Mobile: +44 (0) 792 322 4864

Re: Can MATPOWER do Security constrained OPF computation?

[Carlos E Murillo-Sanchez]

One possible way, using system replication to build an augmented system
with coupling constraints among the different islands, is what we
originally employed a few years ago for this:

http://www.sciencedirect.com/science/article/pii/S0167923613001152


linhomeperson wrote:
 Dear MATPOWER users,
 Can MATPOWER perform security constrained OPF computation? If yes, how
 can I add the security constraints?
 Thanks,
 Best Regards,
 Lin

Re: Ideally coupled bus bars

[Carlos E Murillo-Sanchez]

Mr. Acker:

The mathematical problem that is solved behind the scenes is simply 
singular in light of such modeling detail.  Any robust solver would 
actually look for such occurences in the data and collapse the busbars 
into a single one, and then, as a post-solution-processing strategy, 
split the results.  MATPOWER does not do such things yet automatically, 
in part because there are assumptions about such situations that the 
current system data model is not able to represent, and there is no 
industry standard about it either.


Hendrik Acker wrote:


Hi Mr. Zimmerman,

I am wondering how I can represent ideally coupled busbars in 
MATPOWER. In the UCTE Format they are represented by a branch with 
zero impedance (R=0; X=0; B=0) but I cannot implement such a branch in 
Matpower because the Matrix will become singular.


Do you have an idea how to work around this problem?

Best regards

M.sc. Hendrik Acker

*^

Technische Universität Kaiserslautern

Fachbereich Elektrotechnik und Informationstechnik

Lehrstuhl für Energiesysteme und Energiemanagement

Erwin-Schrödinger-Straße

67663 Kaiserslautern

Tel.: +49 (0)631 / 205 - 3037

Fax: +49 (0)631 / 205 - 2168

Mail: ac...@eit.uni-kl.de mailto:haes...@eit.uni-kl.de

Re: Branch limit and bus voltage violation

[Carlos E Murillo-Sanchez]

  
  
As well as adding coordination costs in
  separation and coordination optimization schemes :-) .
  
  Ray Zimmerman wrote:


  
  The basekV column of the bus matrix has no effect on the
solution.
  
  
  I am not aware of any real cost associated with reactive
generation for typical power plants. This feature was
implemented to allow the OPF to be used to clear markets where
there were non-zero offers for reactive generation.
  
  
  



-- 
Ray Zimmerman
Senior Research Associate
419A Warren Hall, Cornell University, Ithaca,
  NY 14853
phone: (607) 255-9645

  
  
  

  
  
  
On May 8, 2013, at 1:39 PM, spyros gian sp.g...@hotmail.com
  wrote:


  
Dear Dr Zimmerman,
  
  
  Does the 'basekV' column in the mpc.bus matrix play
any role in the solution that matpower produces, or is
it only for presentation ?
  So for example, 10 buses have 138kV and 5 others have
233kV as basekV. 
  
  
  Secondly, as it is possible to set in the objective
function the $/MVARh cost of generating Q, I would like
to ask about the realism of such a thing.
  In reality, is there any such thing as cost of
generating a MVAR ? 
  As far as I know, the fuel cost is always in terms of
$/MWh.
  
  
  Thank you
  

  From: r...@cornell.edu
  Subject: Re: Branch limit and bus voltage violation
  Date: Tue, 7 May 2013 12:09:25 -0400
  To: matpowe...@list.cornell.edu
  
  MATPOWER does not include any functions to do this
  automatically, but it is trivial with a few lines of
  Matlab code using 'find' with a condition that
  compares the actual MVA flows to RATE_A and actual bus
  voltages with VMIN/VMAX.
  
  
  

  
  
  -- 
  Ray Zimmerman
  Senior Research Associate
  419A Warren Hall, Cornell
University, Ithaca, NY 14853
  phone: (607) 255-9645
  



  



  On May 5, 2013, at 1:30 PM, Umer Ali Alsedeeq
Ibrahim uibra...@km.com.qa
wrote:
  
  

  
 

  
 
  

  Dear Dr Zimmerman,
  
  
  
  I am doing research related to power
  security. I am simulating a
  contingency by setting the branch
  status to 0. But I want to know the
  matpower can print out all the
  branches that have cross the limit and
  the buses voltage which are violated
  after running power flow
  
  
  Thank you
  
  
  
  
  
  
  
  
  
  
  
  
  
  

  
From: Ray
  

Re: Ideally coupled busbars

[Carlos E Murillo-Sanchez]

  
  
Unfortunately, this problem is of an
  intrinsic nature. If it is an OPF that you are running, you might
  try using additional linear constraints to equate the two bus bars
  magnitudes and angles, and hope that the underlying linear algebra
  algorithms will deal with the singular constraint matrix
  appropriately. But I would suggest instead to write two different
  special-purpose functions: one taking the data of the original
  system and collapsing the two busbars into a single one, then run
  whatever you want on it, and another function taking the results
  and splitting the bus bars again. MATPOWER does not detect such
  issues in the data, but if it were to do so, this process would
  probably be part of the pre-processing and post-processing of the
  data (in the same way that it does renumbering of bus bars and so
  on).
  
  carlos.
  
  
  Hendrik Acker wrote:


  
  
  
  
Hi everyone, dear Mr. Zimmerman

Im having problems with
implementing ideally coupled bus bars.
In the UCTE Format 2 bus
bars are coupled with an branch which has R=0 X=0 and B=0.
Matpower however cannot work with this as the Matrix
singular. If I put R=0 and X small I get really weird high
flows of P=XXX^6 MW.
What can I do to couple
2 busbars? (Except replacing them by only 1 node-point)

Best regards

M.sc.
Hendrik Acker

*
Technische
Universitt Kaiserslautern
Fachbereich
Elektrotechnik und Informationstechnik
Lehrstuhl
fr Energiesysteme und Energiemanagement
Erwin-Schrdinger-Strae
67663
Kaiserslautern
Tel.: +49
(0)631 / 205 - 3037
Fax:
+49 (0)631 / 205 - 2168
Mail:
  ac...@eit.uni-kl.de

  


  

Re: load flow problem

[Carlos E Murillo-Sanchez]

Ahmad:

If baseMVA is 100, then Bs in pu should be 0.19 .

carlos.

ahmad rezaee wrote:

Dear
Dr Zimmerman and all friends

  
I

have written one load flow code with Gauss-Sidel and one with Newton-Raphson.
Both of them lead to the same results. For validating my codes I compared the
results with matpower results. I compared the results in IEEE 14, 30 and 57 test
systems.  In all cases the angles of
voltages and real power of lines are roughly the same with Matpower, but the 
voltage
amplitudes and reactive power of lines are different. I thought much to find
the problem. Mostly I skeptical about inputting Bs  (shunt suceptances in 
busses). In Matpower Bs
is defined as :  “ shunt suceptance (MVAR
injected at V=1 pu). For inputting  Bs in
my code I have done followings: (19 is the data for Bs in 14 bus test system). 
the simple formulation for computing Bs in Pu is attached.


So,
in my load flow code I have put Bs=0.0524 pu, is it correct? You think which
part of my load flow code can be wrong and why my results are not the same with
Matpower?
  
  
Your

cooperation is highly appreciated
Regards
Ahmad

Re: reactive power cost calculation in AC OPF

[Carlos E Murillo-Sanchez]

Santiago:

You can use a piecewise linear cost model with two segments, with vertex 
points

at (-Qnegmax, Qnegprice*Qnegmax), (0,0), (Qposmax, Qposprice*Qposmax)  .

Santiago Torres wrote:

Dear Ray and Matpower friends

I want to use the reactive power cost of AC optimal power flow.   I
understand that modeling a cuadratic cost function I could
  get always positive costs, for reactive power generation.  But, I am
using that in a different way.  I am modeling linear costs (Qg x
reactive Costs) and I want always to have positive costs, for both
inductive power and capacitive power generation. Therefore in that
case, Qg must be always positive when I calculate the costs. May be
there is a way to do that getting inside the code... I think it could
be a simple matter to put some abs command where  is located the cost
calculation part can you give me some advice on how to do that??

Any help is apreciated.

regards,

Santiago

Re: 回复：Modelling passive / non controlled loads in matpower

[Carlos E Murillo-Sanchez]

You can specify bus shunt conductances and capacitive susceptances in 
the GS and BS columns of the bus matrix as MW and Mvars at nominal 
voltage. And yes, the assumption that loads are modeled as PQ quantities 
is standard in the load flow problem. Using a different model for loads 
is a non-standard modification.


kongzizh...@vip.sina.com wrote:

Hi SdT,
The load model for the standard power flow problem is based on bus 
classification: load bus is regard as PQ bus or in other words, the load model 
is constant power load. It's definitely true that no absolute real constant 
power load with wild variation of voltage exists (also nearly true for constant 
impedance load). However, for a real system, from the static point of view, 
power restoring dynamic and voltage regulating will finally keep the voltage 
near the rate value and the load power fitting the demand. So if you just want 
to know the long term power flow at a normal operating point, bus 
classification may not be a bad assumption. Of course, that assumption is not 
proper for precise dynamic simulation or the research on voltage sensitive 
phenomena. In all, whether a model is proper depends on your purpose.
In MATPOWER, you can model the constant inductance load as shunt compactor. Beyond that, 
I think you have to change the code. The simplest improvement may be to add a column for 
shunt resistance in bus data and slightly change the makeYbus function, then 
you can have constant impedance load. Further, you need add new bus type and write code 
for them from modeling to Jacobian matrix generation, or give up bus classification and 
use some general form for solving nonlinear equations.

Shiyang Li
李诗旸
ECpE, Iowa State University

 原始邮件 -
发件人：Sala de Tareas saladetar...@gmail.com
收件人：matpowe...@cornell.edu
主题：Modelling passive / non controlled loads in matpower
日期：2012年10月23日 17点20分

hi there,

if yuo set up a load with 50kW in matpower it will always get those 50kW, no 
matter how low the voltage has gone. this is an evidence, that matpower uses 
controlled / active loads. the impedance of the load is regulated in a way, 
that always the asked power is converted.


my question to you, since not all loads in reality are active, is if there is a 
possibility in matpower to make analysises with passive / not controlled loads? 
so less power when there is less voltage?


thank you in advance,SdT
来自新浪邮箱手机网页版

Re: AC power low analysis does not converge with EU power grid model

[Carlos E Murillo-Sanchez]

Dear Bela:

Running MINOPF on the system, it seems that both active and reactive 
balances are hard to fulfill in bus 706.


Carlos.

Bela Genge wrote:

Dear all,

I am having some problems running an AC power flow with the attached 
case system. This is an approximate EU Power Grid model that was 
generated from the IEEE/CF format available here: 
http://www.see.ed.ac.uk/~jbialek/Europe_load_flow/
The problem is that the 'runpf' function always gives a Did not 
converge result. A DC power flow analysis converges, but I was not 
able to do an AC analysis. I also tried different algorithms available 
for 'runpf', but with the same result.

Any help would be highly appreciated.

Thank you!

Best regards,
Bela

Re: Photovoltaic Generators modelling

[Carlos E Murillo-Sanchez]

Richard:

One easy way to minimize losses using the opf solver is to assign to all 
generators the same linear fuel cost.  If all sources have the same 
cost, then the optimizer will try to minimize losses.  However, you have 
to provide sensible VMIN, VMAX limits for all buses in the bus table, or 
the optimizer will simply try to raise voltages as much as possible.


Richard Ngonga wrote:

Carlos,

Thank you once more for your help. My objective is to solve an optimum 
power flow and I want to obtain an optimal voltage profile and 
minimise dissipation losses. I have modelled the Photovoltaic 
generators to inject active(Pmax=0.032MV)  reactive power and tested 
the network for convergency using pf before proceeding to the opf 
model. The network converged when I modelled the buses containing the 
photovoltaic generators as either slack bus or PQ bus but does not 
converge when I model the buses as PV. Would the situation change if I 
test the model using opf? I have one traditional generator modelled as 
a HV infinite source.


 Date: Sat, 1 Sep 2012 22:32:51 -0400
 From: ce.murillosanc...@gmail.com
 To: matpower-l@list.cornell.edu
 Subject: Re: Photovoltaic Generators modelling

 Richard:

 Are you sure that you want to specify the power injections of the
 photovoltaic generators as zero in a power flow?

 The trapezoidal model for (P,Q) feasibility is intended for use in an
 optimal power flow setting, not a power flow setting. If you have all
 generators with Pg = 0 then you may not have enough generation to meet
 the demand. Do you have additional, traditional generators?

 In a power flow, the reactive dispatches are found such that the 
voltage

 at the bus is at the specified Vg. In an optimal power flow, the
 reactive dispatches are modulated to obtain an optimal voltage profile.

 Which is it that you want to achieve? Do you want to solve a power flow
 or an optimal power flow?

 Richard Ngonga wrote:
  Hi ,
 
  I have modelled 20 photovoltaic generators in a 100 bus radial
  distribution network with the parameters shown below(in the generator
  field). The problem I am having is that when I model the nodes with
  the Photovoltaic generators as PV buses the AC Newton Raphson 
loadflow

  does not coverge, but when I model the same nodes as swing
  buses(option 3) the network converges. My aim is to model
  the photovoltaic generators as var controllers, is there a way this
  can be done in Matpower?
 
  Pg=0
  Qg=0
  Pmin = 0
  Pmax = 0
  Qmax = 0.01563
  Qmin = -0.01563
  mBase=100
  Pc1 = 0
  Qc1min = 0
  Qc1max = 0
  Pc2 = 0.032
  Qc2min = -0.01563
  Qc2max = 0.01563
 
  Richard Ngonga
 
 
   Date: Thu, 30 Aug 2012 21:36:52 -0400
   Subject: Re: Photovoltaic Generators modelling
   From: ce.murillosanc...@gmail.com
   To: matpower-l@list.cornell.edu
  
   Assuming that you want to specify a reactive dispatch capability
   within the .9 power factor cone that we talked about earlier, and
   assuming Pmin = 0 and Pmax = 1MW, then at Pmax the reactive dispatch
   could be in [-0.4843, 0.4843] MVAr. Then, the following parameters
   define that cone for Matpower:
  
   Pmin = 0
   Pmax = 0
   Qmax = 0.4843
   Qmin = -0.4843
   Pc1 = 0
   Qc1min = 0
   Qc1max = 0
   Pc2 = 1
   Qc2min = -0.4843
   Qc2max = 0.4843
  
  
  
  
   On Thu, Aug 30, 2012 at 4:56 PM, Richard Ngonga
  rich_...@hotmail.com wrote:
   
Hi Carlos,
   
Do I have to model photovoltaic generators in matpower like diesel
generators? My aim is to model photovoltaic inverters as 
dispatchable
reactive power sources using Matpower's trapezidal modeling of 
the

  (P,Q)
feasible region. What is the best way to model them in matpower?
   
Regards
   
Richard
   
Date: Mon, 20 Aug 2012 12:23:10 -0400
From: ce.murillosanc...@gmail.com
To: matpower-l@list.cornell.edu
Subject: Re: PV Generators and Transformer modelling
   
So, if the reactive dispatch of your generators is 
constrained to be
within a 0.95 power factor, then you can use MATPOWER's 
trapezoidal

modeling of the (P,Q) feasible region. as opposed to simple bound
constraints on P and Q
for a generator. In your case, if Pmin reaches down to 0, then
  you have
more of a cone instead of a trapezoid.
This is best explained using a picture; see manual for details.
   
carlos.
   
Richard Ngonga wrote:
 Thanks for that, I mean photo voltaic. I am modelling PV 
generators
 that are able to dispatch reactive power(i.e operating at 
-0.95 to

 0.95 power factor).


  Date: Mon, 20 Aug 2012 01:34:09 -0400
  From: ce.murillosanc...@gmail.com
  To: matpower-l@list.cornell.edu
  Subject: Re: PV Generators and Transformer modelling
 
  Um, an unfortunate crisscross with acronyms... by PV
  generators do you
  mean power-voltage as in classical power flow problem
  parlance or do
 you
  rather mean photo voltaic?
 
  Richard Ngonga wrote:
  
 

Re: line Capacity for IEEE 56 bus

[Carlos E Murillo-Sanchez]

  
  
Hi;
  
  Unfortunately, the original data does not include those
  parameters.
  
  A while ago, based on information about base transmission line
  voltage, standard conductor sizes, and information about whether
  certain lines were single or double circuit, a colleague, Claudio
  Zapata,  made some educated guesses about the possible ratings of
  the original IEEE 118 bus system.  Perhaps you could try to do
  this as well.
  
  Kukuh Widarsono wrote:


  
dear all


Hi...


I need data line Capacity for IEEE 56
  bus test data.
may be, can you help me to get it.


thank you very much.




kukuh widarsono
 
  

  

  


  

Re: p-opf in Matpower

[Carlos E Murillo-Sanchez]

Iman:  two methods are compared in this paper.  The 2-point estimate 
tries to capture moments of the distribution using just two 
_deterministic_ OPFs.  The cumulant method assumes linear propagation 
(i.e., based on a sensitivity analysis of the KKT conditions) of the 
pdfs of the quantities deemed random.  This assumes that the projected 
restrictions continue to fulfill some power flow.  In other words, the 
projected distributions fulfill linearized power flow deviations about a 
base case solution, but not the true nonlinear power flow.


The nonlinear power flow is a deterministic problem.  It does not make 
sense to gather physical insight from problems posed in terms of 
fulfillment of nonlinear constraints in an expected sense.


I think that we are still stuck with having to deal with distributions 
through collections of samples, for the nonlinear power flow case.


iman wrote:

Dear All,

I came across this paper *Probabilistic Optimal Power Flow 
Applications to Electricity Markets *by Gregor , Antony Schellenberg 
and, William Rosehart

showing that probabilistic optimal power flow is done in Matpower.
Does anybody know how you can implement it in Matpower?
Probablistic optimal power flow is used to deal with variant nature of 
generators such as wind.


Thanks
Iman

Re: p-opf in Matpower

[Carlos E Murillo-Sanchez]

I think that this is actually a good review of the issues involved in 
attempting a true probabilistic power flow:


http://ieeexplore.ieee.org/xpl/login.jsp?tp=arnumber=4523658url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F4511470%2F4523365%2F04523658.pdf%3Farnumber%3D4523658

iman wrote:

Dear All,

I came across this paper *Probabilistic Optimal Power Flow 
Applications to Electricity Markets *by Gregor , Antony Schellenberg 
and, William Rosehart

showing that probabilistic optimal power flow is done in Matpower.
Does anybody know how you can implement it in Matpower?
Probablistic optimal power flow is used to deal with variant nature of 
generators such as wind.


Thanks
Iman

Re: Initial guess for the power flow

[Carlos E Murillo-Sanchez]

Hi;

There are diagrams for the ieee 30 bus system and the 118 bus system 
around, may also for others.

I will send you these two in a separate mail.

carlos.

Shri wrote:




On Aug 20, 2012, at 11:11 AM, Carlos E Murillo-Sanchez 
ce.murillosanc...@gmail.com wrote:


Power networks are usually almost planar, with a few exceptions in which lines 
do cross each other without connection.  The obvious place to connect a network 
to another is in peripheral nodes, just a few of them should be common.  But if 
you don not have the geographical location of nodes this can be hard to do.  On 
the other hand, it might be possible that the person who put the data together 
listed the buses and lines in some kind of systematic manner and it might 
perhaps be possible to figure out a planar map of the system.

I am using test cases provided with the MatPower distribution. How easy or 
tough would it be to get a planar map of your test cases? Is the bus and the 
line data listed in a systematic manner?

Thanks,
Shri

carlos.


Shri wrote:

On Aug 15, 2012, at 9:03 PM, Carlos E Murillo-Sanchez wrote:


I can envision that this method of randomly connecting two systems might easily 
create unsolvable systems, with wild angular differences even if solvable.  
That is not how transmission networks are designed.

Thanks for your comments Carlos. Any tips on how to go about connecting test 
cases in an engineered way rather than just naively putting in random lines?

If anyone has larger test cases ( 3375 buses) (not neccessarily MatPower 
format) and willing to share it, I would really love that :)

Thanks,
Shri

Shri wrote:

Hi,
 I am trying to create a bigger test case  by duplicating a MatPower test case 
(= 2383 buses) multiple times. To have connectivity between each of the bigger 
areas, I've added randomly chosen tie lines. However, I am not able to get power 
flow to converge.
 Monitoring the residual norm shows that Newton convergence is linear in the 
first few steps and then it diverges. I suspect that this might be due to the 
initial guess given to Newton. My premise is based on observing that if a flat 
start is chosen for some (or all?) of the MatPower test cases (= 2383 buses), 
Newton doesn't converge and has a similar divergence pattern.

I was wondering whether the bus(:,VM:VA), which is part of the initial 
guess to Newton, data was computed using some algorithm or provided by the test 
case data provider.

Thanks and appreciate your help as always!
Shri

Re: Matpower Repository

[Carlos E Murillo-Sanchez]

Hi;

I am not sure that I completely follow your second question. With 
regards to the first one, we really have just the ones that are 
distributed with MATPOWER, plus some others that we use in research and 
which may contain propietary data.


Your second question...   if the solvers find a solution, by definition 
it must be feasible...  is your question rather how do I know if there 
is a feasible solution?  There is no simple answer; sometimes relaxing 
the restrictions of a problem allows the solvers to converge and by 
tightening the restrictions back slowly you may get information about 
which constraints are the ones that cannot be met.  But in general, 
answering the question of feasibility is not easy.


There is a little function in the MINOPF distribution that is used to 
precondition a case to provide a better starting point for MINOPF; it is 
called sqppf and it tries to minimize the sum of squares of opf 
constraint violations; it prints info about which constraints register 
the highest violations at every step; it will try to give you back a 
power flow solution that is OPF-feasible, so MINOPF can start from there 
to get to the optimal solution.


Carlos.

iman wrote:

Dear all,

Firstly,Is there any repository for Matpower cases, so I can download 
them?

Secondly,how feasibility of optimal solution of cases could be checked?

Thanks for your help in advanced.
Iman

Re: Question about Nominal_PD and Pload

[Carlos E Murillo-Sanchez]

Let me see if I get this rightt:

1) You define real power dispatches of non-slack generators in a test 
case, perhaps also change the amount of load, and then

2) you run a power flow, ostensibly with runpf. But then,
3) you find that the dispatch values that you had defined in step (1) 
for generators other than the slack have been changed by runpf.


It should not happen normally.  The only mechanism for this to happen is 
if a) you have ENFORCE_Q_LIMS set to 1 (default is 0), and b) The slack 
generator happens to hit a Q limit, in which case the the slack bus is 
treated as a PQ bus with Qg set to the limit, and then the next PV 
generator is treated as the slack bus, which might cause this generator 
to have a slightly different Pg dispatch than what you originally 
specified.  Could this be what you are seeing?


Carlos.

Hanie Sedghi wrote:

I think I should explain the problem more briefly.
The thing is that when I input some load to a grid in MATPOWER, the 
final value of power injections at buses are not exactly equal to the 
initial values I assigned them.
I now know this happens in a real grid due to the branch data (line 
and/or transformer impedance data), and other loads in the system (if 
any) that can consume power at each bus when running power flow.
So my question is, is it ok to get this result if I run DC power flow 
in MATPOWER? and I am wondering why this happens.

I just want to justify the results.

Thank you so much,
Hanie

On Fri, Aug 17, 2012 at 9:51 AM, Hanie Sedghi honey.sed...@gmail.com 
mailto:honey.sed...@gmail.com wrote:


Hello sir,

Hope you are doing great.

For my research, I need to feed the grid with independent demands
and follow the outputs. I solve for DC power flow
For changing the demand I use

mpc = loadcase('case9');
define_constants;
Nominal_PD =[0;0;13;21.97;0;0;0;0;52.42;0] %something random

So I expect that Pload in MATPOWER's output be the same as my
given Nominal_PD
which is not always true.
for example I have used case 9 with above Nominal_PD, which is
less than sum of Nominal generations for bus 2,3 (that is 163, 85
respectively)
now Pload=[-3.68;1.83 ;20.53 ;33.52;4.44;3.55 ;4.92
; -0.56;44.83;-3.02]

or even when Nominal_PD is such that sum of demand exceeds the
generation in 2,3 (and slack bus compensates for the rest) I have
the same problem that Pload is not equal to Nominal_PD (I assign
this value randomly)

It seems like the grid satisfies demand partially for some nodes
and induces some gen/demand at nodes when there is no demand(when
I run DC power flow)
So I was wondering what is going on here. Is it what in fact
happens in the grid or I am missing an assumption in MATPOWER or
is it something else?

I would truly appreciate your response.

Best Regards,
Hanie

Re: Question about Nominal_PD and Pload

[Carlos E Murillo-Sanchez]

Hanie, I do not understand how this could be possible.  I think that we 
should move the discussion offline and when we have a resolution to this 
riddle we will post it back for others to see.  Please email me 
privately at carlos_muri...@ieee.org and describe in detail the steps 
that you are taking; include scripts/functions if necessary.  But what 
you are describing should not happen.


Carlos.

Hanie Sedghi wrote:

Dear Carlos,

Thank you so much for your consideration,

Actually No.
I am not changing the generators. PD_Nominal as I understand it is the 
demand at each bus.

There is a generator part in the case file that I do not change.
What I am saying is that I am setting the power demand at each bus and 
then run the DCpower flow. afterwards, the values of injected demand 
or Pload(as stated in output) are not exactly the same as the initial 
demand but in a range of it.
So my question is what is MATPOWER doing for solving the DC power flow 
that causes this.


It would be of great help to me if you answer this.
All the best,
Hanie

On Tue, Aug 21, 2012 at 2:46 PM, Carlos E Murillo-Sanchez 
ce.murillosanc...@gmail.com mailto:ce.murillosanc...@gmail.com wrote:


Let me see if I get this rightt:

1) You define real power dispatches of non-slack generators in a
test case, perhaps also change the amount of load, and then
2) you run a power flow, ostensibly with runpf. But then,
3) you find that the dispatch values that you had defined in step
(1) for generators other than the slack have been changed by runpf.

It should not happen normally.  The only mechanism for this to
happen is if a) you have ENFORCE_Q_LIMS set to 1 (default is 0),
and b) The slack generator happens to hit a Q limit, in which case
the the slack bus is treated as a PQ bus with Qg set to the limit,
and then the next PV generator is treated as the slack bus, which
might cause this generator to have a slightly different Pg
dispatch than what you originally specified.  Could this be what
you are seeing?

Carlos.

Hanie Sedghi wrote:

I think I should explain the problem more briefly.
The thing is that when I input some load to a grid in
MATPOWER, the final value of power injections at buses are not
exactly equal to the initial values I assigned them.
I now know this happens in a real grid due to the branch data
(line and/or transformer impedance data), and other loads in
the system (if any) that can consume power at each bus when
running power flow.
So my question is, is it ok to get this result if I run DC
power flow in MATPOWER? and I am wondering why this happens.
I just want to justify the results.

Thank you so much,
Hanie

On Fri, Aug 17, 2012 at 9:51 AM, Hanie Sedghi
honey.sed...@gmail.com mailto:honey.sed...@gmail.com
mailto:honey.sed...@gmail.com
mailto:honey.sed...@gmail.com wrote:

Hello sir,

Hope you are doing great.

For my research, I need to feed the grid with independent
demands
and follow the outputs. I solve for DC power flow
For changing the demand I use

mpc = loadcase('case9');
define_constants;
Nominal_PD =[0;0;13;21.97;0;0;0;0;52.42;0] %something random

So I expect that Pload in MATPOWER's output be the same as my
given Nominal_PD
which is not always true.
for example I have used case 9 with above Nominal_PD, which is
less than sum of Nominal generations for bus 2,3 (that is
163, 85
respectively)
now Pload=[-3.68;1.83 ;20.53 ;33.52;4.44;3.55 ;4.92
; -0.56;44.83;-3.02]

or even when Nominal_PD is such that sum of demand exceeds the
generation in 2,3 (and slack bus compensates for the rest)
I have
the same problem that Pload is not equal to Nominal_PD (I
assign
this value randomly)

It seems like the grid satisfies demand partially for some
nodes
and induces some gen/demand at nodes when there is no
demand(when
I run DC power flow)
So I was wondering what is going on here. Is it what in fact
happens in the grid or I am missing an assumption in
MATPOWER or
is it something else?

I would truly appreciate your response.

Best Regards,
Hanie

Re: Initial guess for the power flow

[Carlos E Murillo-Sanchez]

Power networks are usually almost planar, with a few exceptions in which 
lines do cross each other without connection.  The obvious place to 
connect a network to another is in peripheral nodes, just a few of them 
should be common.  But if you don not have the geographical location of 
nodes this can be hard to do.  On the other hand, it might be possible 
that the person who put the data together listed the buses and lines in 
some kind of systematic manner and it might perhaps be possible to 
figure out a planar map of the system.


carlos.


Shri wrote:

On Aug 15, 2012, at 9:03 PM, Carlos E Murillo-Sanchez wrote:


I can envision that this method of randomly connecting two systems might easily 
create unsolvable systems, with wild angular differences even if solvable.  
That is not how transmission networks are designed.

Thanks for your comments Carlos. Any tips on how to go about connecting test 
cases in an engineered way rather than just naively putting in random lines?

If anyone has larger test cases ( 3375 buses) (not neccessarily MatPower 
format) and willing to share it, I would really love that :)

Thanks,
Shri

Shri wrote:

Hi,
 I am trying to create a bigger test case  by duplicating a MatPower test case 
(= 2383 buses) multiple times. To have connectivity between each of the bigger 
areas, I've added randomly chosen tie lines. However, I am not able to get power 
flow to converge.
 Monitoring the residual norm shows that Newton convergence is linear in the 
first few steps and then it diverges. I suspect that this might be due to the 
initial guess given to Newton. My premise is based on observing that if a flat 
start is chosen for some (or all?) of the MatPower test cases (= 2383 buses), 
Newton doesn't converge and has a similar divergence pattern.

I was wondering whether the bus(:,VM:VA), which is part of the initial 
guess to Newton, data was computed using some algorithm or provided by the test 
case data provider.

Thanks and appreciate your help as always!
Shri

Re: PV Generators and Transformer modelling

[Carlos E Murillo-Sanchez]

So, if the reactive dispatch of your generators is constrained to be 
within a 0.95 power factor, then you can use MATPOWER's trapezoidal 
modeling of the (P,Q) feasible region. as opposed to simple bound 
constraints on P and Q
for a generator. In your case, if Pmin reaches down to 0, then you have 
more of a cone instead of a trapezoid.

This is best explained using a picture; see manual for details.

carlos.

Richard Ngonga wrote:
Thanks for that, I mean photo voltaic. I am modelling PV generators 
that are able to dispatch reactive power(i.e operating at -0.95 to 
0.95 power factor).



 Date: Mon, 20 Aug 2012 01:34:09 -0400
 From: ce.murillosanc...@gmail.com
 To: matpower-l@list.cornell.edu
 Subject: Re: PV Generators and Transformer modelling

 Um, an unfortunate crisscross with acronyms... by PV generators do you
 mean power-voltage as in classical power flow problem parlance or do 
you

 rather mean photo voltaic?

 Richard Ngonga wrote:
 
  Hi there,
 
  I am working on a thesis on reactive power control on a distributed
  network with transformers and PV generators. Can I model the PVs as
  generators on a PV bus or should I model them as capacitors on a PQ
  bus? I'm also having problems modelling transformers from a 20KV
  network to a 0.4KV network; when I use the transformer ration 50 I 
get
  very large power flows and losses. The transformer data is: Sn 
400KVA,

  Usc=10%, Uprm/Usec=20/0.4(KV) and Usec set=1.05.
 
  Regards

Re: Unbalance loads on low voltage grid, how simulate

[Carlos E Murillo-Sanchez]

Hi Rui;

Unfortunately MATPOWER uses one-line equivalent flows, so it cannot do 
unbalanced three-phase analysis.


carlos.

Rui Ferreira wrote:


Dear Sirs,

I built a small network to represent a branch of low voltage grid, I 
have a transformer 400 kVA 15kV/400V and downstream I have the LV 
network, I simulated some scenarios with and without micro generation, 
but always as a tri-phase system, in other words, I consider tri-phase 
loads and three-phase micro-generators, so at this moment I want 
simulate the same grid (case) but with monophase loads and 
micro-generators to see the differences on the three phases due the 
unbalance loads and generators.

It is possible do this simulation on matpower?

Sorry my bad English.

Best regards,
Rui Ferreira

Re: PV Generators and Transformer modelling

[Carlos E Murillo-Sanchez]

Um, an unfortunate crisscross with acronyms... by PV generators do you 
mean power-voltage as in classical power flow problem parlance or do you 
rather mean photo voltaic?


Richard Ngonga wrote:


 Hi there,

I am working on a thesis on reactive power control on a distributed 
network with transformers and PV generators. Can I model the PVs as 
generators on a PV bus or should I model them as capacitors on a PQ 
bus? I'm also having problems modelling transformers from a 20KV 
network to a 0.4KV network; when I use the transformer ration 50 I get 
very large power flows and losses. The transformer data is: Sn 400KVA, 
Usc=10%, Uprm/Usec=20/0.4(KV) and Usec set=1.05.


Regards

Re: Initial guess for the power flow

[Carlos E Murillo-Sanchez]

I can envision that this method of randomly connecting two systems might 
easily create unsolvable systems, with wild angular differences even if 
solvable.  That is not how transmission networks are designed.


Shri wrote:

Hi,
 I am trying to create a bigger test case  by duplicating a MatPower test case 
(= 2383 buses) multiple times. To have connectivity between each of the bigger 
areas, I've added randomly chosen tie lines. However, I am not able to get power 
flow to converge.
 Monitoring the residual norm shows that Newton convergence is linear in the 
first few steps and then it diverges. I suspect that this might be due to the 
initial guess given to Newton. My premise is based on observing that if a flat 
start is chosen for some (or all?) of the MatPower test cases (= 2383 buses), 
Newton doesn't converge and has a similar divergence pattern.

I was wondering whether the bus(:,VM:VA), which is part of the initial 
guess to Newton, data was computed using some algorithm or provided by the test 
case data provider.

Thanks and appreciate your help as always!
Shri

Re: probabilistic power flow

[Carlos E Murillo-Sanchez]

Iman:

The power flow is a deterministic problem, because you cannot have PF 
variables obey Kirchhoff's laws in a valid probabilistic manner.  
However, you can have probability-weighted deterministic power flow 
scenarios representing some distribution, and depending on what kind of 
things you want to be able to say, it might be a way to approach the 
problem.


carlos.

iman wrote:


Dear All,


As you know probabilistic power flow is one of the ways for overcoming 
uncertainties in networks. These days Wind Turbines and photovoltaic 
systems, introduce additional power fluctuations into the system .I am 
sure the Matpower has the capability of not only doing deterministic 
power flow but also probabilistic but I couldn’t find anywhere in 
manual how that is implemented.


Any of you guys have  encountered this problem?

Do I need to add an extra code?


Thank you


Best regards
Iman

Re: slack bus issue

[Carlos E Murillo-Sanchez]

If the angles change from the value in the data tables after you run 
runpf(), then it just means that the initial data is not a steady state 
solution to the AC power flow, and therefore such data is meaningless. 
There is no before this shift has happened.


carlos.

Hanie Sedghi wrote:

Dear sir,

I am doing some research and for that I need the value of voltage 
angles at different buses. when I use runpf() as you know, the angles 
are kind of shifted as slack bus angle is 0 and the others are shifted 
to that value.

But I need the values of angles before this shift has happened.
Which part of the code I need to manipulate to get there?

I would truly appreciate your consideration,
Best,
Hanie

Re: sampling

[Carlos E Murillo-Sanchez]

There is a rather flexible utility in matpower for scaling loads.  Type
 help scale_load

at the matlab prompt for help on how to use it.  Otherwise, if you just 
want to modify inflexible demand,

you could do something like

mpc = loadcase('case118');
define_constants;
Nominal_PD = mpc.bus(:,  PD);
Nominal_QD = mpc.bus(:, QG):
for factor = 0.8:0.01:1.20
  mpc.bus(:, PD) = factor * Nominal_PD;
  mpc.bus(:, QD) = factor * Nominal_QD;
  results = runpf(mpc);
  % now insert code here to do whatever you want to do with the results
  your code
  more code...
end

This scales inflexible demand in the system by a factor from 80% of 
nominal to 120% of nominal in 1% increments and runs a power flow; you 
could run also an optimal power flow using runopf()  instead.  The load 
is scaled maintaining a constant power factor.





Hanie Sedghi wrote:

Dear Sir,

I would like to have different voltage angle values at different times 
for a structure. Let's say I want to have the same structure as case9, 
but I want to know what are the values at different times. It is like 
simulating a grid and taking samples at different times. For that I 
think I need different demands. Then I checked the case file and 
thought I need to put random Pg's in gen matrix. Am I right? Shall I 
generate random values in [Pmin,Pmax] interval?
I have another question, in case9, for bus 1, Pg=0 while Pmin=10. Is 
it correct? Can Pg be less than Pmin? In that case,what do we mean by 
Pmin?


I would truly appreciate your help.

Best,
Hanie

Re: sampling

[Carlos E Murillo-Sanchez]

Oops, that fourth line should be


   Nominal_QD = mpc.bus(:, QD);


Carlos E Murillo-Sanchez wrote:

There is a rather flexible utility in matpower for scaling loads.  Type
 help scale_load

at the matlab prompt for help on how to use it.  Otherwise, if you 
just want to modify inflexible demand,

you could do something like

mpc = loadcase('case118');
define_constants;
Nominal_PD = mpc.bus(:,  PD);
Nominal_QD = mpc.bus(:, QG):
for factor = 0.8:0.01:1.20
  mpc.bus(:, PD) = factor * Nominal_PD;
  mpc.bus(:, QD) = factor * Nominal_QD;
  results = runpf(mpc);
  % now insert code here to do whatever you want to do with the results
  your code
  more code...
end

This scales inflexible demand in the system by a factor from 80% of 
nominal to 120% of nominal in 1% increments and runs a power flow; you 
could run also an optimal power flow using runopf()  instead.  The 
load is scaled maintaining a constant power factor.





Hanie Sedghi wrote:

Dear Sir,

I would like to have different voltage angle values at different 
times for a structure. Let's say I want to have the same structure as 
case9, but I want to know what are the values at different times. It 
is like simulating a grid and taking samples at different times. For 
that I think I need different demands. Then I checked the case file 
and thought I need to put random Pg's in gen matrix. Am I right? 
Shall I generate random values in [Pmin,Pmax] interval?
I have another question, in case9, for bus 1, Pg=0 while Pmin=10. Is 
it correct? Can Pg be less than Pmin? In that case,what do we mean by 
Pmin?


I would truly appreciate your help.

Best,
Hanie

Re: AW: Transformer modelling

[Carlos E Murillo-Sanchez]

André:

The ratio that is to be entered is a tap ratio for transformers that 
have variable tap ratio capability, not a turns ratio;  Tap ratios are 
usually close to unity, say within [0.95, 1.05] .  Turn ratios are done 
away with in per unit modeling.  And phase shifting transformers (a 
rather expensive and relatively unusual piece of equipment) rarely 
achieve more than 30 degrees of phase shift.  150 degrees is not 
sensible at all, and in fact in a typical network it would mean dynamic 
instability almost surely.


carlos.

Lemke, André wrote:

Dear Dr V. Ravikumar Pandi,
First of all thank you for the help.
The branch from node 1 to 2 is a transformer. I've enteredthe ratio 
10kV / 0,4 kV = 24 and the phase angle of 150 degreesinto the first 
branch.

At this point I can find no error.
What struck me when comparing with the case file case300.m that my 
ratio is significantly larger. (25 to 1.0435) Could this be a problem? 
Am experienced in this area yet not so.

For comments or tips, I am grateful.


*Von:* bounce-37988428-24829...@list.cornell.edu 
[mailto:bounce-37988428-24829...@list.cornell.edu] *Im Auftrag von 
*RAVIKUMAR V

*Gesendet:* Donnerstag, 1. September 2011 08:36
*An:* MATPOWER discussion forum
*Betreff:* Re: Transformer modelling

Hi Andre,
The off-nominal tap ratio for a tap changing transformer and angle of phase 
shifting transformer should be given in branch matrix.
Kindly go through the previous discussion about the transformer 
modelling from the ratings given in

http://www.mail-archive.com/matpower-l@list.cornell.edu/msg01426.html .


On Wed, Aug 31, 2011 at 5:39 PM, Lemke, André 
andre.le...@umsicht.fraunhofer.de 
mailto:andre.le...@umsicht.fraunhofer.de wrote:


Dear Mr. Zimmerman,

I have problems to integrate a transformer in my attached example.
Matpower doesn't converge.
I've probably made a mistake in the translation of physical
quantities into p.u. quantities?
The calculation without an transformer succeeds properly with
correct results which I've checked with a similar program.

For an answer I would be very grateful.

Sincerely,

André Lemke

Netz02.m



-
WITH REGARDS,

Dr V. Ravikumar Pandi,
Post Doctoral Fellow,
Masdar Institute, Abu Dhabi,
United Arab Emirates - 54224.
-
HAVE A NICE DAY
-

Re: Linear Shift Factors

[Carlos E Murillo-Sanchez]

Hello;

An optimal power flow, when confronted with an incremental load change,
dictates a distributed 
slack-taking rule that maintains optimality conditions.

"The proportion is fixed for an incremental load change in any bus" -
yes, if the costs are linear.
If the costs are adequately smooth, the proportion changes smoothly,
though. If the costs are piecewise linear,
the proportion can change abruptly, as it can also change if new
constraints become "active".

An (I think) interesting analysis of OPF sensitivity can be found in
the appendix of

 http://e3rg.pserc.cornell.edu/node/50

carlos.


z qin wrote:
Dear Mr.Zimmerman:
  
Thank you very much. Yes, I am using the same slack when I say "works
for DC PF". 
  
In DC OPF, there are generator capacity constraints and transmission
line constraints. Before any constraint being reached, the proportion
is fixed for an incremental load change in any bus. However, the
proportion keeps changing as one and more constraints are reached. In
this case, is it possible to predict the flow changes among all
branches for an incremental load change? Can we resort to the original
equations to get an analytic solution? 
  
Thanks a lot.
  
Jerry 
  
  On Wed, Mar 2, 2011 at 8:18 PM, Ray
Zimmerman r...@cornell.edu wrote:
  The
PTDF shows how the power flows change based on load changes, given a
specific slack distribution. When you say that it "works for DC PF", I
assume you mean that you can use it to predict the new flows you get
when you run a new DC PF. That's because you probably are using the
same slack bus for both. If you think about how a DC OPF redispatches
for an incremental load change, the "slack" is taken up by the units
that are on the margin. I'm not sure how to compute what the proportion
is, but if you knew that proportion you could use it to specify the
slack distribution for computing the appropriate PTDF.

--
Ray Zimmerman
Senior Research Associate
211 Warren Hall, Cornell University, Ithaca, NY 14853
phone: (607) 255-9645





On Mar 2, 2011, at 5:27 PM, z qin wrote:

 Hello,

 It seems that the linear shift factors (PTDF matrix) only works
for DC PF, but not for DC OPF. Is there a corresponding matrix for DC
OPF? I am wondering how the power flows on all the branches change if
one bus's power demand changes. Any suggestions? Thanks a lot.

 Jerry





  
  
  
  
  
-- 

  
Zhengrui (Jerry) Qin
  
Computer Science
College of William and Mary
Williamsburg, VA 23185
  

Re: bpmpd mex question

[Carlos E Murillo-Sanchez]

Are you running 32 or 64 bit Matlab? The mex file is 32 bit and
can only run under 32 bit Matlab.

Berk Kapicioglu wrote:
Dear colleagues,
  
  
  I would like to use bpmpd. I found it while searching for a
state-of-the-art QP solver that is super fast and can deal with sparse
matrices when interfaced through matlab.
  
  
  I followed the instructions onhttp://www.pserc.cornell.edu/bpmpd/.
I also downloaded the bpmpd.dll throughhttp://www.sztaki.hu/~meszaros/bpmpd/
  
  
  The problem is, the file bp.m has no code in it. I do not
understand how I can call bpmpd... When I try calling test5.m, it also
fails since it cannot call the bp function...
  
  
  Does anyone have any advise about this? I would greatly
appreciate it!!
  
  
  Thank you in advance,
  Berk Kapicioglu
  
  
  PS: The version I downloaded is the mac binary with bp.mexmaci
and version number2.21.1d.