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