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