The A matrix of (6.38) in the MATPOWER 7.0b1 User’s Manual will have to include 
the coefficients for all variables, both Pg and z.

   Ray

> On Apr 22, 2019, at 10:06 PM, Jubeyer Rahman <[email protected]> wrote:
> 
> 
> Hi,
> 
> Thanks a lot for your reply. 
> 
> Are you referring to Ar matrix ( The A matrix multiplied with Pg here) from 
> the reserve formulation (since this is a subtraction with the variable z)?
> 
> So, If I want to implement anything like, Pg-z*factor= Po; where Po is the 
> dispatch in pre-contingency case how should I do it?
> 
> The way I am thinking to do is, I will run the pre-contingency case, preserve 
> the 'Pg' data, and pass it as the 'Pmin' for the redistpatch period. Then I 
> will add the z variable with the OPF structure.
> 
>  I apologize I could not come up with a proper formulation as I am not quite 
> sure what I am thinking is correct or not.
> 
> Regards,
> Jubeyer
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Tue, Apr 16, 2019 at 9:01 AM Ray Zimmerman <[email protected] 
> <mailto:[email protected]>> wrote:
> Add a single constraint of the form …
> 
> A * Pg - z  = 0
> 
> … where A is a row vector, Pg is the vector of generation and z is a new 
> scalar variable representing the total amount of the resdispatch.
> 
>    Ray
> 
> 
>> On Apr 9, 2019, at 5:56 PM, Jubeyer Rahman <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> And for redispatch case as you have mentioned , if I want the generators 
>> redispatch in a certain way (make them produce power like Pg+some 
>> factor*some variable), how should I do that?
>> 
>> On Tue, Apr 9, 2019 at 4:56 PM Jubeyer Rahman <[email protected] 
>> <mailto:[email protected]>> wrote:
>> I am really sorry that I haven't been able to make it more clear. However, I 
>> will come up with a clear formulation later on.
>> 
>> Actually, I have already formualted that and am getting some value for R. 
>> But I am not quite sure whether I have been able to get the cost formulation 
>> correct.
>> 
>> So, for now , can you only tell me, that if I do get some value for R, which 
>> is supposed to come from some certain generator's, how can I make that 
>> calculated as a total power generation Pg+R from the gencost information and 
>> not from the reserve cost. 
>> 
>> On Tue, Apr 9, 2019 at 4:50 PM Ray Zimmerman <[email protected] 
>> <mailto:[email protected]>> wrote:
>> I’m afraid I still don’t understand the problem you intend to solve. The 
>> formulation you provided is completely equivalent to the standard OPF with 
>> some additional variables and constraints that have no effect ultimately 
>> (since r_i = 0 is feasible).
>> 
>> It sounds like you want to apply some kind of constraint to Pg to restrict 
>> redispatches from some initial dispatch or something, but the formulation 
>> you provided does not accomplish that.
>> 
>> So, it seems like the first step would be to get the problem formulation 
>> clear and correct, then we can help if you have questions about the 
>> implementation.
>> 
>>     Ray
>> 
>> 
>>> On Apr 9, 2019, at 4:33 PM, Jubeyer Rahman <[email protected] 
>>> <mailto:[email protected]>> wrote:
>>> 
>>> Yes, I don't want the objective function to be affected in that way. The 
>>> reason of formulating that way is if I don't have all the generators active 
>>> in my system (in case  I loose one generator for example, I want the rest 
>>> of the generator's to respond in a certain way).
>>> 
>>> On Tue, Apr 9, 2019 at 4:30 PM Ray Zimmerman <[email protected] 
>>> <mailto:[email protected]>> wrote:
>>> I think there must be something missing. Because the addition of these 
>>> variables and constraints will not affect the OPF solution at all. It will 
>>> be the same as the standard OPF formulation with no reserves. That is, the 
>>> original solution will still be both optimal (since there is no change to 
>>> the objective function in (6.34)) and feasible (since r_i = 0 is feasible 
>>> and imposes no additional restrictions on the problem).
>>> 
>>> Your formulation as stated includes no reason for r_i to be non-zero.
>>> 
>>>    Ray
>>> 
>>> 
>>> 
>>>> On Apr 9, 2019, at 3:33 PM, Jubeyer Rahman <[email protected] 
>>>> <mailto:[email protected]>> wrote:
>>>> 
>>>> Ok. Here they go:
>>>> 
>>>> similar to 7.2
>>>> 
>>>> 0<=r_i<=Pmax
>>>> 
>>>> for 7.3: Since I don't want the cost to be calculated separately, I don't 
>>>> need anything here (reserves from generators should be calculated as the 
>>>> total power generation cost, no separate cost for generator)
>>>> 
>>>> for 7.4
>>>> pg^i+x*r_i<=pg^i,max
>>>> 
>>>> x is given as parameters here.
>>>> 
>>>> for 7.5; since I don't have zonal requirement I don't have anything for 
>>>> that.
>>>> 
>>>> Let me know if you need anything for more clarification.
>>>> 
>>>> 
>>>> 
>>>> On Tue, Apr 9, 2019 at 3:13 PM Ray Zimmerman <[email protected] 
>>>> <mailto:[email protected]>> wrote:
>>>> Ok, so you are attempting to modify the existing fixed reserves 
>>>> implementation to something with a similar, but not identical structure. I 
>>>> think I need to fully understand the formulation. Can you provide the 
>>>> equivalent of equations (7.2)–(7.5) for your problem so I can see exactly 
>>>> where the differences are?
>>>> 
>>>>    Ray
>>>> 
>>>> 
>>>>> On Apr 9, 2019, at 11:43 AM, Jubeyer Rahman <[email protected] 
>>>>> <mailto:[email protected]>> wrote:
>>>>> 
>>>>> Ok. Thanks a lot for your reply.
>>>>> 
>>>>>  What I am trying to implement is something like this 'Pg+x*R', where 
>>>>> 'Pg' is real power generation, x is a collection of factors (parameters) 
>>>>> usually fraction number ranging between 0 and 1, and R will be a variable 
>>>>> for reserves. Usually the minimum value for R is 0 and maximum value is 
>>>>> equal to the 'Pmax' for each generator asked to provide reserves. What I 
>>>>> also want is that the reserve cost to be ignored ,rather the cost of 
>>>>> total power generation 'Pg+x*R'  should be calculated from the generator 
>>>>> cost information and not from the reserve costs ( I have tried that by 
>>>>> making all the reserve costs zero). In addition to these I have no zonal 
>>>>> reserve requirement ( I have made the constraint deactivated and deleted 
>>>>> the second row of the mpc.reserves.zones, deactivated mpc.reserves.req 
>>>>> and also deactivated where  'req' has been implemented). 
>>>>> 
>>>>> 
>>>>> Can you suggest how can how I do it? or do you have any comments on the 
>>>>> process I am already following?
>>>>> 
>>>>> Just to illustrate more on the reserve cost modification:
>>>>> 
>>>>> For example, I have 'Pg' from  a particular generator  (generator 1) 5 
>>>>> MW, now after implementing the reserve , it is supplying another 1 MW 
>>>>> from its capacity (it's Pmax is 10 MW). Now what I want is that this 
>>>>> (5+1)=6 MW generation cost to be calculated by using the polynomial cost 
>>>>> information from the mpc.gencost section. 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Tue, Apr 9, 2019 at 10:38 AM Ray Zimmerman <[email protected] 
>>>>> <mailto:[email protected]>> wrote:
>>>>> I think it might help me to have a high-level view of what you are trying 
>>>>> to accomplish. If you are simply trying to *use* the already implemented 
>>>>> fixed reserve capability, you shouldn’t need to even concern yourself at 
>>>>> all with the implementation (i.e. the Ar matrix and the various callback 
>>>>> functions, etc.). In that case, all you need is to understand the inputs 
>>>>> in Table 7-5. If, on the other hand, you are modifying the implementation 
>>>>> to do something other than what is currently implemented, then I need to 
>>>>> understand what that is.
>>>>> 
>>>>> In what is already implemented, the generation cost is simply the cost of 
>>>>> Pg. There is a separate cost of R that is added as a user cost. See 
>>>>> (7.3). So the cost coefficients of R are provided in mpc.reserves.cost 
>>>>> (see Table 7-5).
>>>>> 
>>>>>     Ray
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Apr 8, 2019, at 2:39 PM, Jubeyer Rahman <[email protected] 
>>>>>> <mailto:[email protected]>> wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I have another few questions regarding the addition of the fixed zonal 
>>>>>> reserves. So, far I understand, after adding the reserves, the real 
>>>>>> power output of the generator will be added with reserve amount, so in 
>>>>>> the part of the objective function where real power cost is being 
>>>>>> calculated, which power is fed into as for calculation is it the 'Pg' 
>>>>>> part of 'Pg+R' or is it the total 'Pg'? 
>>>>>> 
>>>>>> If I want to implement a reation like 'Pg+x*R' , where x is a collection 
>>>>>> of parameters (n-by-1) , which place can I feed into these parameters? I 
>>>>>> am assuming, this should be the second column of the Ar matrix. Is that 
>>>>>> correct?
>>>>>> 
>>>>>> Regards
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Fri, Apr 5, 2019 at 10:53 AM Jubeyer Rahman <[email protected] 
>>>>>> <mailto:[email protected]>> wrote:
>>>>>> Please ignore the last email, I have figured this out. Every column in 
>>>>>> the first row corresponds the generators supposed to participate in the 
>>>>>> reserve provision , that's why they are made one.
>>>>>> 
>>>>>> On Wed, Apr 3, 2019 at 5:27 PM Jubeyer Rahman <[email protected] 
>>>>>> <mailto:[email protected]>> wrote:
>>>>>> Are you talking about the columns in the second row?
>>>>>> 
>>>>>> On Mon, Apr 1, 2019 at 5:21 PM Ray Zimmerman <[email protected] 
>>>>>> <mailto:[email protected]>> wrote:
>>>>>> The only thing you need to do is make sure the corresponding column in 
>>>>>> mpc.reserves.zones is all zeros.
>>>>>> 
>>>>>>    Ray
>>>>>> 
>>>>>>> On Apr 1, 2019, at 10:31 AM, Jubeyer Rahman <[email protected] 
>>>>>>> <mailto:[email protected]>> wrote:
>>>>>>> 
>>>>>>> Ok, I got your point and realized my mistake in understanding the zone 
>>>>>>> handling section. So, if I want some of the generator's choosing not to 
>>>>>>> provide ramp, should just setting the element of Identity matrix's 
>>>>>>> corresponding rows of first column of Ar be Ok? or I may need to change 
>>>>>>> something else as well?
>>>>>>> 
>>>>>>> On Mon, Apr 1, 2019 at 9:45 AM Ray Zimmerman <[email protected] 
>>>>>>> <mailto:[email protected]>> wrote:
>>>>>>> Regarding your first question, as described by (7.2) in the User’s 
>>>>>>> Manual, the reserve for a given generator is bounded above by both any 
>>>>>>> limit provided in mpc.reserves.qty (r_i^{max}) and by any physical ramp 
>>>>>>> rate (∆_i) given in mpc.gen(:, RAMP_10). It just so happens that the 
>>>>>>> example in t_case30_userfcn does not specify any physical ramp rates, 
>>>>>>> but the code still needs to handle cases which *do* provide physical 
>>>>>>> ramp limits.
>>>>>>> 
>>>>>>> I’m not sure why you say only two generators are supposed to take part 
>>>>>>> in the reserve provision. In t_case30_userfcn there are two reserve 
>>>>>>> zones defined, but all 6 generators are able to participate in 
>>>>>>> providing the required reserves.
>>>>>>> 
>>>>>>> You may want to review carefully the formulation in (7.2)–(7.5) and 
>>>>>>> Table 7-2.
>>>>>>> 
>>>>>>>    Ray
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On Mar 29, 2019, at 4:06 PM, Jubeyer Rahman <[email protected] 
>>>>>>>> <mailto:[email protected]>> wrote:
>>>>>>>> 
>>>>>>>> Referring to the 'userfcn_reserves_formulation', there is a line which 
>>>>>>>> is finding the value of k, which seems to be zero since none of the 
>>>>>>>> data in  'Ramp_10' column  in t_case_30_userfcn is all zeros. so I 
>>>>>>>> don't see any point of using the line 
>>>>>>>> 
>>>>>>>> Rmax(k)=mpc.gen(k,Ramp_10), can you explain why the code is written 
>>>>>>>> that way.
>>>>>>>> 
>>>>>>>> From my understanding only two generators are supposed to take part in 
>>>>>>>> the reserve provision, but the while putting the value for Rmax and 
>>>>>>>> Rmin, the code is considering all of them, which looks kind of 
>>>>>>>> unreasonable to me. Can you please explain this section as well?
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Jubeyer
>>>>>>>> 
>>>>>>>> On Fri, Mar 29, 2019 at 12:43 PM Ray Zimmerman <[email protected] 
>>>>>>>> <mailto:[email protected]>> wrote:
>>>>>>>> That is correct. All of the callbacks are technically optional. 
>>>>>>>> Typically you need the formulation callback to implement the actual 
>>>>>>>> problem modifications, and possibly ext2int and int2ext if you need to 
>>>>>>>> do some handling of input and output data, respectively. The printpf 
>>>>>>>> and savecase callbacks are only needed if you want to add things to 
>>>>>>>> the standard pretty-printed output or saved case data.
>>>>>>>> 
>>>>>>>>     Ray
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Mar 29, 2019, at 12:15 PM, Jubeyer Rahman <[email protected] 
>>>>>>>>> <mailto:[email protected]>> wrote:
>>>>>>>>> 
>>>>>>>>> Just how important it is to include printpf and savecase callback 
>>>>>>>>> during the extension of OPF, if I don't really need anything printed 
>>>>>>>>> out right after I call the power flow? Will it be still possible to 
>>>>>>>>> extract information from the 'results' when I say 
>>>>>>>>> results=runopf(mycase)?
>>>>>>>>> 
>>>>>>>>> To my understanding, after runopf being called, 'results' struct will 
>>>>>>>>> be returned and can be accessed by writing some command like 
>>>>>>>>> results.gen(:,2), etc. Let me know if I am thinking correctly or not?
>>>>>>>>> 
>>>>>>>>> On Fri, Mar 29, 2019 at 9:53 AM Jubeyer Rahman <[email protected] 
>>>>>>>>> <mailto:[email protected]>> wrote:
>>>>>>>>> Thank you very much.
>>>>>>>>> 
>>>>>>>>> On Fri, Mar 29, 2019 at 8:43 AM Ray Zimmerman <[email protected] 
>>>>>>>>> <mailto:[email protected]>> wrote:
>>>>>>>>> Are you attempting to use the provided extension for fixed reserves, 
>>>>>>>>> or are you attempting to write your own extension?
>>>>>>>>> 
>>>>>>>>> If it’s the former, the full implementation is included in 
>>>>>>>>> toggle_reserves() 
>>>>>>>>> <http://www.pserc.cornell.edu/matpower/docs/ref/matpower6.0/toggle_reserves.html>.
>>>>>>>>>  Simply load your case file, use toggle_reserves() to enable the 
>>>>>>>>> callbacks, then run the OPF (or just call runopf_w_res() 
>>>>>>>>> <http://www.pserc.cornell.edu/matpower/docs/ref/matpower6.0/runopf_w_res.html>,
>>>>>>>>>  which does these 3 steps automatically for you).
>>>>>>>>> 
>>>>>>>>> If you are attempting to write your own extension, I suggest making a 
>>>>>>>>> copy of toggle_reserves.m and rename it and all of the functions in 
>>>>>>>>> it and use it as a template for your own extension.
>>>>>>>>> 
>>>>>>>>>    Ray
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Mar 28, 2019, at 12:40 PM, Jubeyer Rahman <[email protected] 
>>>>>>>>>> <mailto:[email protected]>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hi,
>>>>>>>>>> 
>>>>>>>>>> Recently I was digging through the extending OPF chapter of Matpower 
>>>>>>>>>> manual, but I don't quite catch the process. Regarding the example 
>>>>>>>>>> given there on 'Fixed zonal reserves' what I understand from my 
>>>>>>>>>> reading is, it is required to write down a call back function for 
>>>>>>>>>> formulation along with some call of callback functions. I have 
>>>>>>>>>> followed every steps mentioned there but could not make the code run 
>>>>>>>>>> (I am using version 6.0). I am adding my code snippet here for 
>>>>>>>>>> better conveying.
>>>>>>>>>> 
>>>>>>>>>> %%%
>>>>>>>>>> mpc=loadcase('case30.m');
>>>>>>>>>> mpopt = mpoption('out.all', 0, 'verbose', 0);
>>>>>>>>>> mpc=add_usefcn(mpc,'formulation',@userfcn_reserves_formulation);
>>>>>>>>>> mpc=ext2int(mpc,mpopt);
>>>>>>>>>> results=runopf(mpc);
>>>>>>>>>> results=int2ext;
>>>>>>>>>> 
>>>>>>>>>> %%%%
>>>>>>>>>> Error message:
>>>>>>>>>> Access to an object's fields is only permitted within its methods.
>>>>>>>>>> 
>>>>>>>>>> I have added the mpc.reserve data(cost, req, zones) posted in 
>>>>>>>>>> 't_case30_userfcns.m' file.
>>>>>>>>>> I have written the userfcn_reserves_formulation in a different 
>>>>>>>>>> script , but  it is not working.
>>>>>>>>>> I didn't write the add_var and add_constraint explicitly since the 
>>>>>>>>>> add_userfcn callback function already contains those.
>>>>>>>>>> 
>>>>>>>>>> Can you tell me what I am missing?
>>>>>>>>>> 
>>>>>>>>>> Regards,
>>>>>>>>>> Jubeyer
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

Reply via email to