MATPOWER/most

Changing length of each period in MOST

StefanoUnipd opened this issue · 6 comments

I know that Most is designed to solve dispatching problems in the daily electricity market, however my goal is to use it for an analysis over several years.
Other people have had a similar idea and I have read their posts in this forum. However, I was wondering if, instead of increasing the number of periods analyzed, there was the possibility of changing the duration of each period.
The duration of each period should be defined in the file: md_init.m, and particularly in the line: md = struct('Delta_T',1).
It would be possible, with a line of code like: mdi.Delta_T = number of hours changing the lenght of each period?

rdzman commented

Yes. That is exactly how to change the length of the period. I would not modify the md_init.m file, since it just initializes the data structure with a default value.

I recommend setting mdi.Delta_T to your desired value after calling loadmd() and before calling most().

I understand, however one thing is not clear to me: by increasing the number of hours that make up a period, how does the f objective change?
That I have: mdi.Delta_T = 1 or mdi.Delta_T = 1000 I always get the same f objective and I don't think it's correct if the units of measurement of f objective are $.
I set mdi.Delta_T here:

mdi = loadmd(mpc, nt, xgd, [], [], profiles);
mdi.Delta_T = 1000;
mdo = most(mdi,mpopt);
most_summary(mdo)
rdzman commented

Hmmm ... I'll have to check into this. The units should be $, so it definitely should change with mdi.Delta_T. But, I'm sure different values of mdi.Delta_T definitely received minimal if any testing.

If you find out anything, let me know, Professor. Anyway, thank you for the super quick answers you always gave me.

rdzman commented

Well, this does look like a bug to me.

In searching through the code, it looks like the Delta_T affects some ramping constraints and some strorage constraints and costs, but not the other cost terms, such as generation, redispatch, reserves, etc.

If I am correct, it means that all costs that are intended to be specified in $/hr or $/MWh are actually used as if they were $/period and $/MW-period. So the work-around would be to scale the values of the parameters by the number of hours per period.

Perfect! Thank you very much Mr. Zimmerman.