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