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] 
> <mailto:[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] <mailto:[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

Reply via email to