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