Hi, Sorry to bring this into discussion again, since I am failing to do what I want. If I have nothing to worry about zones, and want some of the generator's participate to provide reserve and some of them not . What is the way of doing it?
Based on my understanding, I need to change the entry of the Ar matrix, make all the rows of the 2nd column zero which actually correspond to the generators, not supposed to participate in providing reserves. Let me know what you think? For doing this, are the ext2int and int2ext callbacks necessary or not? Regards, Jubeyer 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 >>>>> >>>>> >>>>> >>> >> >
