Thank you so much for your answers, will follow this approach. Carlos Ferrandon
El jue., 14 feb. 2019 a las 16:42, Ray Zimmerman (<[email protected]>) escribió: > 1. When using CT_REL it should be scaling the original PMAX value > specified for the wind generator. I suspect you want CT_REP. In that case, > you should never see the wind dispatched greater than the specified value, > but it could be less (wind curtailed) if that is more economical for some > reason. The easiest way to make your wind non-dispatchable is to simply > specify a load profile that represents the net load (load – wind) at each > bus and eliminate the wind as explicit generators. > > 3. If you mean the objective function *f* displayed by most_summary(), > then it is precisely that … the value of the entire objective as defined in > equation (4.6) in the MOST User’s Manual > <http://www.pserc.cornell.edu/matpower/docs/MOST-manual-1.0.1.pdf>. If > you want the cost for each time step you will have to compute it manually > from the commitment schedule and the dispatches. For example, in the > deterministic case without reserves, you can find the cost of energy in > period *t* using something like … > > mpc_t = mdo.flow(t).mpc; > cost_t = totcost(mpc_t.gencost, mpc_t.gen(:, PG)); > > Ray > > > On Feb 12, 2019, at 1:27 PM, Carlos Ferrandon Cervantes < > [email protected]> wrote: > > 1. Yes, the wind power output for certain bus is not the same at each > hourly time step compared to the original wind profile. I have tried > testing different scenarios and it does not follow the wind profile > previously specified in none of them. For example, for peak load it is even > violating the PMAX specified for the wind generation. The limit specified > in "wind.gen" is 713 and in some time steps is going well beyond that > value. Does it have something to do with the "chgtype" setting of the wind > profile? right now is on "CT_REL"; and according to the manual of Matpower > that means to "scale old value by factor in CT NEWVAL column". What is that > "old value"? the one from the original wind profile? I have tried using > "CT_REP" also but the wind generation is reduced, and definitely not > following the wind profile. Is there anyway to make that wind profile > non-dispatchable generation? > > 2. Perfect! thank you for this one! > > 3. Sorry for including another one, but the value of the cost function > shown at the end of the simulation is the cost of the whole 24 hours > optimisation? if so, how could I get the cost for each time step? > > Thank you so much!, > > Carlos > > El mar., 12 feb. 2019 a las 15:59, Ray Zimmerman (<[email protected]>) > escribió: > >> 1. I’m not sure I understand what you mean by “wind power input is moving >> freely”. Normally, the wind power output is dispatched by MOST. If the cost >> of the wind generation is sufficiently low, and the network supports it, >> the wind units will typically be dispatched at their PMAX values as >> specified by the wind profile. What exactly are you seeing? >> >> 2. Certainly. All of the output data is stored in the mdo returned by >> most(). In particular, see Tables 5-10 and 5-13 in the MOST User’s Manual >> <http://www.pserc.cornell.edu/matpower/docs/MOST-manual-1.0.1.pdf>. You >> can find the UC status for generator *i* in period *t* in >> mdo.UC.CommitSched(i, >> t) and the dispatch in mdo.flow(t, j, k).mpc.gen(i, PG). >> >> Ray >> >> >> On Feb 11, 2019, at 10:27 AM, Carlos Ferrandon Cervantes < >> [email protected]> wrote: >> >> Hello Doctors: >> >> >> I am running a unit commitment simulation for the 24 bus reliability test >> system, for a time horizon of 24 hours with an hourly time step. >> >> Problem 1: The wind power input from time series data is not following >> the specified pattern. To fix this, I've tried following the "most_ex6_uc" >> example in MOST. I've added the wind data as in the example >> "ex_wind_profile_uc". I am certain that in the "wind.xgd_table.data" file >> the wind power input is marked with the number 2 for a "CommitKey" value. >> I've removed the wind input from the mpc data, specifically on "mpc.gen", >> "mpc.gencost" and "mpc.reserves", since only using "add_wind" and >> "get_profiles" is enough; according to the example. >> >> Nevertheless, I realise that the wind power input is moving freely >> through each one of the time steps, whereas in the "most_ex6_uc" example >> this is not the case. I would like my case to follow the hourly wind >> pattern during 24hrs just like in the example. >> >> I will be very helpful if you could explain to me why this is happening >> and how to solve it. >> >> Problem 2: Is it possible to use the final output data of UC? Save it and >> use it next with different constraints added to a second UC problem? I am >> interested in saving the data of certain power output of some units after >> the simulation is performed. I would like to know how would you approach >> this. >> >> As always, thank you very much in advance, your input has been widely >> helpful, >> >> best wishes, >> >> -- >> Carlos Ferrandon >> >> >> > > -- > Carlos Ferrandon > > > -- Carlos Ferrandon
