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]> 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]> 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]> 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]> wrote:
>>
>>> Are you talking about the columns in the second row?
>>>
>>> On Mon, Apr 1, 2019 at 5:21 PM Ray Zimmerman <[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]> 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]> 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]>
>>>>> 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]>
>>>>> 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]>
>>>>>> 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]>
>>>>>> wrote:
>>>>>>
>>>>>>> Thank you very much.
>>>>>>>
>>>>>>> On Fri, Mar 29, 2019 at 8:43 AM Ray Zimmerman <[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]>
>>>>>>>> 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