The OPF tests include such an example.
See, for example, the code starting at line 228 in t_opf_default.m
<https://github.com/MATPOWER/matpower/blob/a6a489c3d3a83f5c65fc7e0a5dc5306eb7cc6ac0/lib/t/t_opf_default.m#L228>.
Ray
> On Apr 25, 2019, at 11:45 AM, Jubeyer Rahman <[email protected]> wrote:
>
> Hi,
>
> Just a query, can you point me any example code that demonstrates the whole
> direct specification of extended OPF formulation described in section 7.1?
>
> Regards,
> Jubeyer
>
>
>
> On Thu, Apr 25, 2019 at 10:50 AM Ray Zimmerman <[email protected]
> <mailto:[email protected]>> wrote:
> 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]
>> <mailto:[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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
