SWITCH storage module

[Evan Li]

Dear SWITCH developer,

I am a research scientist in Breakthrough Energy, currently we are using SWITCH to evaluate storage expansion, and I got a question about timepoints and time series: so how does SWITCH determine the chronological order of timestamps? Is it purely based on timepoint_id? If that is the case, seems like some of the SOC does not lining up with charging and discharging amount as I observed...and how does it deal with the "ts_scale_to_period" and "ts_duration"? Is the "timestamp" data being used anywhere here? Much appreciate on any guidance about this!

Regards,

Yifan 

[Matthias Fripp]

Hi Yifan,

This is a good question. Switch inherits its behavior from Pyomo, which uses the order that the timepoints appear in the input files. So TIMEPOINTS are in the same order as the rows in timepoints.csv. The set of timepoints in each timeseries (TPS_IN_TS) also uses this same order.

One important point is that we don't treat each timeseries as being linked to the next one. Instead, when doing the storage modeling, we treat the last timepoint of each timeseries as being linked back to the first timepoint of the same timeseries. This way, we can use independent samples of weather (typically one timeseries for each sample day), but still model realistically the usage of storage, demand response, unit commitment, etc. over the course of each day. Another way to think about this is that we model each day as if it were an infinite sequence of the same kind of day. Or equivalently, we require storage, unit commitment, etc., to come back to the same point at the end of each day as they were at the start. This is somewhat conservative, because sometimes there might only be one or two bad days in a row, and you could afford to run storage down a little bit from one day to the next. If you really need to model that behavior, you'd need to use multi-day timesamples. But then it gets hard to use enough samples to cover the full range of conditions you might see.

ts_scale_to_period is a weight assigned to each timeseries (e.g., sample day). You can think of it as identifying how many times you typically expect that type of day to repeat during the investment period (the investment period is the interval between one investment decision and the next, typically about 5 years). The ts_scale_to_period weight is multiplied by all the costs that occur during that timeseries, to get an appropriate total cost for the whole investment period. Sometimes people use stratified sampling, where they pick every n'th day of the year, and then ts_scale_to_period would be n * period_length_years. But these days I usually pick some days that represent typical conditions, and give them a big weight, then I pick other days that represent more unusual, difficult conditions, and give them a small weight. (I use k-means clustering to automate this.)

Each timepoint in a timeseries must have the same duration. This duration is shown in ts_duration_of_tp (in hours). It is nice to have timepoints every hour on each sample day (timeseries), in which case, ts_duration_of_tp would be 1. But for difficult models, it is sometimes necessary to have timesteps every 2 or 3 hours, in which case ts_duration_of_tp would be 2 or 3. Operational decisions are made for each timepoint, and most of them are expressed as flow rates (MW or maybe MMBtu per hour). Then those rates are multiplied by ts_duration_of_tp to get total amount of energy produced or consumed during that timepoint. ts_duration_of_tp is also used to keep track of minimum up and down time and startup costs for unit commitment.

The timestamp is not used anywhere. It is intended as a human-readable version of the timepoint ID, so sometimes it is reported instead of the timepoint value. But I don't think we've been 100% consistent about that. There may be some efficiency to be gained by using an integer for the timepoint ID and a date/time string for the timestamp.

I hope that covers it. Let me know if anything was unclear or if you have more questions.

Matthias

----
Matthias Fripp
Assoc. Prof. of Electrical Engineering
Univ. of Hawaii, Manoa
mfr...@hawaii.edu

--
You received this message because you are subscribed to the Google Groups "Switch Model" group.
To unsubscribe from this group and stop receiving emails from it, send an email to switch-model...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/switch-model/283b14c5-8431-4908-83bc-607a88e30c14n%40googlegroups.com.

[Evan Li]

It seems like I chose the wrong reply option and not sure if my earlier message got sent successfully....thank you very much Prof. Fripp for the detailed explanation, it makes perfect sense and is a great design to treat time points in a timeseries cyclically, so if I understand it correctly, different time series are treated independently without chronological linkage, i.e., memoryless in terms of operation. Maybe one quick follow up is that for storage SOC, what will SWITCH set their initial status? Looks like many of starts with 0, but there do have some invested storage comes with non-zero SoC at timepoint 1 time series 1....

Thanks & Regards,

Yifan