CPF bug when cpf_corrector failes on first iteration

2017-08-08 Thread Elis Nycander
Hi,

I have found a small bug in the CPF function. Suppose the base case power
flow converges but the very first corrector step fails. Then the following
happens

1. cpf loop sets *cont_steps = 0 *and terminates with break
2. callback function is called with *k=0 *and thus executes initialization
instead of final callback loop
3. *cpf_results *is now missing the field *V *(and all other fields which
are supposed to be set in final callback loop)
4. missing *cpf_results.V *causes error on line 610 in runcpf:
n = size(cpf_results.V, 2);

So the reason for this error is that the first parameter taken by the
callback functions has two different functions. It is both
1. An indicator what stage the cpf is in, i.e. initialization stage,
continuation stage, or final stage
2. A counter for the number of iterations which has been run
So the possibility of being in the final stage (because the corrector did
not converge) in the very first iteration creates problems.

I have attached an example where this happens. It is a modified version of
case4gs.

Regards,
Elis Nycander


example.mat
Description: Binary data


mwe.m
Description: application/vnd.wolfram.mathematica.package


Re: Regarding assigning initial values for load flow analysis in NR method in runpf() function

2017-08-08 Thread Jose Luis Marín
Hi Sayandev,

As you know, iterative methods need an initial guess.  But this is the
user's *choice*: you can use a flat start as you mention, or any other
information you may have (for instance, from previously solved cases that
are similar to the one at hand---as it happens when solving N-1 contingency
analysis cases).  MATPOWER cannot make this choice for you; so it will just
take the values of bus(:,[VM VA]) present in the input file as the initial
guess (except for VM in PV buses, where the value is replaced by the
regulation voltage VG of the corresponding generators).

So, if you want to test a "flat start", you have to explicitly set the
values of VM and VA before you call runpf().  By the way, setting the VM to
the swing's Vref is (arguably) slightly better than setting them to 1.  In
any case, note that "flat start" is by no means a guaranteed way to obtain
the correct solution (or a solution at all).

-- 
Jose L. Marin
Grupo AIA



2017-08-08 10:11 GMT+02:00 Sayandev Ghosh :

> Beg your pardon the missing snippet from the previous mail is as follows:
>
>
> %% initial state
>
> %V0= ones(size(bus, 1), 1);%% flat start
>
> V0  = bus(:, VM) .* exp(sqrt(-1) * pi/180 * bus(:, VA))
>
> vcb = ones(size(V0));   %% create mask of voltage-controlled
> buses
>
> vcb(pq) = 0;%% exclude PQ buses
>
> k = find(vcb(gbus));%% in-service gens at v-c buses
>
> V0(gbus(k)) = gen(on(k), VG) ./ abs(V0(gbus(k))).* V0(gbus(k));
>
>
> *SAYANDEV GHOSH*
> Assistant Professor
> Electrical Engineering Department
> Chaibasa Engineering College, Chaibasa, Jharkhand
> Mob. No. - 7292880077 / 9748509620
>
> On Tue, Aug 8, 2017 at 1:31 PM, Sayandev Ghosh 
> wrote:
>
>> Hello,
>> I am Sayandev Ghosh, presently teaching power system in an undergraduate
>> engineering college. I have done my M.Tech on Energy Science from Jadavpur
>> University. I have been using MATPOWER for load flow analysis of till 118
>> bus by Newton Raphson method. While doing that I am not able to understand
>> the following area:-
>>
>>
>>  In the runpf() function while using Newton Raphson method  the initial
>> values of voltage magnitude and voltage angle have been assigned by the
>> following lines (line 177 - 183):
>>
>>   [image: Inline image 2]
>> I am having a bit problem in understanding this section. Why are we
>> considering the final values of Voltage magnitude and Voltage angle as the
>> initial guess? In the case files for eg. 'case57' the Vm and Va are
>> probably the final voltage magnitudes and voltage angles.
>>
>> Shouldn't it be like assigning all the voltage magnitudes of PQ bus as 1.0
>> pu and voltage angles of all PV and PQ bus as 0 degree for a flat start.
>>
>> Depending on the answer of this question I would like to convey my other
>> doubts/questions.
>>
>> Thanks in advance.
>>
>>
>>
>> *SAYANDEV GHOSH*
>> Assistant Professor
>> Electrical Engineering Department
>> Chaibasa Engineering College, Chaibasa, Jharkhand
>>
>
>


Re: Regarding assigning initial values for load flow analysis in NR method in runpf() function

2017-08-08 Thread Sayandev Ghosh
Beg your pardon the missing snippet from the previous mail is as follows:


%% initial state

%V0= ones(size(bus, 1), 1);%% flat start

V0  = bus(:, VM) .* exp(sqrt(-1) * pi/180 * bus(:, VA))

vcb = ones(size(V0));   %% create mask of voltage-controlled
buses

vcb(pq) = 0;%% exclude PQ buses

k = find(vcb(gbus));%% in-service gens at v-c buses

V0(gbus(k)) = gen(on(k), VG) ./ abs(V0(gbus(k))).* V0(gbus(k));


*SAYANDEV GHOSH*
Assistant Professor
Electrical Engineering Department
Chaibasa Engineering College, Chaibasa, Jharkhand
Mob. No. - 7292880077 / 9748509620

On Tue, Aug 8, 2017 at 1:31 PM, Sayandev Ghosh  wrote:

> Hello,
> I am Sayandev Ghosh, presently teaching power system in an undergraduate
> engineering college. I have done my M.Tech on Energy Science from Jadavpur
> University. I have been using MATPOWER for load flow analysis of till 118
> bus by Newton Raphson method. While doing that I am not able to understand
> the following area:-
>
>
>  In the runpf() function while using Newton Raphson method  the initial
> values of voltage magnitude and voltage angle have been assigned by the
> following lines (line 177 - 183):
>
>   [image: Inline image 2]
> I am having a bit problem in understanding this section. Why are we
> considering the final values of Voltage magnitude and Voltage angle as the
> initial guess? In the case files for eg. 'case57' the Vm and Va are
> probably the final voltage magnitudes and voltage angles.
>
> Shouldn't it be like assigning all the voltage magnitudes of PQ bus as 1.0
> pu and voltage angles of all PV and PQ bus as 0 degree for a flat start.
>
> Depending on the answer of this question I would like to convey my other
> doubts/questions.
>
> Thanks in advance.
>
>
>
> *SAYANDEV GHOSH*
> Assistant Professor
> Electrical Engineering Department
> Chaibasa Engineering College, Chaibasa, Jharkhand
>


Regarding assigning initial values for load flow analysis in NR method in runpf() function

2017-08-08 Thread Sayandev Ghosh
Hello,
I am Sayandev Ghosh, presently teaching power system in an undergraduate
engineering college. I have done my M.Tech on Energy Science from Jadavpur
University. I have been using MATPOWER for load flow analysis of till 118
bus by Newton Raphson method. While doing that I am not able to understand
the following area:-


 In the runpf() function while using Newton Raphson method  the initial
values of voltage magnitude and voltage angle have been assigned by the
following lines (line 177 - 183):

  [image: Inline image 2]
I am having a bit problem in understanding this section. Why are we
considering the final values of Voltage magnitude and Voltage angle as the
initial guess? In the case files for eg. 'case57' the Vm and Va are
probably the final voltage magnitudes and voltage angles.

Shouldn't it be like assigning all the voltage magnitudes of PQ bus as 1.0
pu and voltage angles of all PV and PQ bus as 0 degree for a flat start.

Depending on the answer of this question I would like to convey my other
doubts/questions.

Thanks in advance.



*SAYANDEV GHOSH*
Assistant Professor
Electrical Engineering Department
Chaibasa Engineering College, Chaibasa, Jharkhand



Re: DCOPF not converging for large system

2017-08-08 Thread prem panigrahi
Dear all
   I am facing problem in DCOPF. I need help. In my power grid model i 
have fixed the capacity of transmission line in RATE A column by 110% of 
initial power flow. Then increase the load by a factor (1.01) and run the 
dcopf. But matpower showing infeasible model due to which it is not converging. 
I am not able to understand the problem. Here load and generation is also well 
balanced. Now which parameter constraint to converging of my test case. I stuck 
here for a long time, so please help me



The result shown below is after increasing the load by 1.01.


MATPOWER Version 6.0, 16-Dec-2016 -- DC Optimal Power Flow
Gurobi Version 7.0.2 -- automatic LP solver
Optimize a model with 19515 rows, 4968 columns and 47500 nonzeros
Coefficient statistics:
  Matrix range [2e-03, 9e+05]
  Objective range  [1e+02, 2e+02]
  Bounds range [5e-03, 1e+02]
  RHS range[3e-17, 4e+02]

Concurrent LP optimizer: dual simplex and barrier
Showing barrier log only...

Presolve removed 2 rows and 17 columns
Presolve time: 0.06s

Solved with dual simplex
Solved in 0 iterations and 0.07 seconds
Infeasible model

>  Did NOT converge (0.17 seconds)  <





Checking connectivity ... single fully connected network
Elapsed time is 0.051284 seconds.

Full
   System
Number of:   --
  buses  3989
  loads  2227
on   2227
off -
fixed2227
dispatchable-
  on-
  off   -
  generators  979
on979
off -
  shunt elements  247
  branches   8096
on   8096
off -
ties (off)  -

Load
  active (MW)
dispatched  85879.4
  fixed 85879.4
  dispatchable  -
nominal 85879.4
  on85879.4
  off   -
  fixed 85879.4
  dispatchable  -
on  -
off -
  reactive (MVAr)
dispatched  23668.6
  fixed 23668.6
  dispatchable  -
nominal 23668.6
  on23668.6
  off   -
  fixed 23668.6
  dispatchable  -
on  -
off -

Generation
  active (MW)
dispatched  86451.8
max capacity   213706.7
  on   213706.7
  off   -
min capacity   -72665.3
  on   -72665.3
  off   -
  reactive (MVAr)
dispatched  24069.5
max capacity69809.7
  on69809.7
  off   -
min capacity   -50352.2
  on   -50352.2
  off   -

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

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
  ref bus numbers3292



From: bounce-121637002-78651...@list.cornell.edu 
 on behalf of Ray Zimmerman 

Sent: Monday, July 3, 2017 9:33:26 PM
To: MATPOWER discussion forum
Subject: Re: DCOPF not converging for large system

If you have a solved AC power flow, that’s a good start. Normally, the first 
step I try when faced with an OPF that won’t converge is to eliminate the 
branch flow limits by setting the RATE_A column of the branch matrix to zero 
(or by increasing the values by some factor). In your case, you can check which 
flows in the power flow solution exceed their limits and only relax those to 
begin with.

If I were you, I would relax any branch, voltage and generator limits as 
required to make the power flow solution you have feasible for the AC OPF 
problem. It should solve. If it does, then you can begin to eliminate those 
relaxations to find the source of the infeasibility.

   Ray


On Jun 23, 2017, at 10:55 AM, Mort D. Webster 
> wrote:


Dear Matpower Folks:

I have larger network that is a solved load flow case from an ISO.

The AC power flow converges fine, but neither AC nor DC OPF solve.

I supplied my own estimated generator costs, and perturbed them so that none 
are identical.

I get the following error:


>> mpc = iso2015sum

mpc =

 version: '2'
 baseMVA: 100
 bus: [7108x13 double]

Re: load2disp command

2017-08-08 Thread prem panigrahi
Dear all

   I am facing problem in DCOPF. I need help. In my power grid model i 
have fixed the capacity of transmission line in RATE A column by 110% of 
initial power flow. Then increase the load by a factor (1.01) and run the 
dcopf. But matpower showing infeasible model due to which it is not converging. 
I am not able to understand the problem. Here load and generation is also well 
balanced. Now which parameter constraint to converging of my test case. I stuck 
here for a long time, so please help me




The result shown below is after increasing the load by 1.01.


MATPOWER Version 6.0, 16-Dec-2016 -- DC Optimal Power Flow
Gurobi Version 7.0.2 -- automatic LP solver
Optimize a model with 19515 rows, 4968 columns and 47500 nonzeros
Coefficient statistics:
  Matrix range [2e-03, 9e+05]
  Objective range  [1e+02, 2e+02]
  Bounds range [5e-03, 1e+02]
  RHS range[3e-17, 4e+02]

Concurrent LP optimizer: dual simplex and barrier
Showing barrier log only...

Presolve removed 2 rows and 17 columns
Presolve time: 0.06s

Solved with dual simplex
Solved in 0 iterations and 0.07 seconds
Infeasible model

>  Did NOT converge (0.17 seconds)  <




Checking connectivity ... single fully connected network
Elapsed time is 0.051284 seconds.

Full
   System
Number of:   --
  buses  3989
  loads  2227
on   2227
off -
fixed2227
dispatchable-
  on-
  off   -
  generators  979
on979
off -
  shunt elements  247
  branches   8096
on   8096
off -
ties (off)  -

Load
  active (MW)
dispatched  85879.4
  fixed 85879.4
  dispatchable  -
nominal 85879.4
  on85879.4
  off   -
  fixed 85879.4
  dispatchable  -
on  -
off -
  reactive (MVAr)
dispatched  23668.6
  fixed 23668.6
  dispatchable  -
nominal 23668.6
  on23668.6
  off   -
  fixed 23668.6
  dispatchable  -
on  -
off -

Generation
  active (MW)
dispatched  86451.8
max capacity   213706.7
  on   213706.7
  off   -
min capacity   -72665.3
  on   -72665.3
  off   -
  reactive (MVAr)
dispatched  24069.5
max capacity69809.7
  on69809.7
  off   -
min capacity   -50352.2
  on   -50352.2
  off   -

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

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
  ref bus numbers3292






From: bounce-121661719-78651...@list.cornell.edu 
 on behalf of Ray Zimmerman 

Sent: Monday, July 17, 2017 8:05:10 PM
To: MATPOWER discussion forum
Subject: Re: load2disp command

Did you check the help for the function (e.g. 
load2disp
 in the online function reference)?

idx is simply a vector of bus indexes, in your case it should be simply be 
equal to 2 (a 1 x 1 vector).

   Ray




On Jul 17, 2017, at 2:29 AM, Akash Tyagi 
> wrote:

Hello everyone,
I am using load2disp command and I understand everything in that command except 
the input index.
Suppose I want to convert the fixed load to dispatchable load at bus 2 only.
I tried by using the following command-
clc
clear
close all;
define_constants;
mpc0=loadcase(case5a);
idx1=mpc0.bus([2,3],PD);
mpc1=load2disp(mpc0,'Akash',idx1);
It is not working?
Thanks in advance