Add Time Representation(s)

[Ethan-Russell]

Let's think carefully about different types of time representations. As a primer, here are some of the things that change in E4ST vs Haiku:

Attribute	E4ST Time Blocks	Haiku Yearly	Haiku Time Blocks
Policies	No	Yes	No (but could if we wanted to)
Availability Factor	Yes	No	Yes
Fuel Cost	No	Yes	Yes (by season)
Capacity	No	Yes	No
Generation	Yes	Yes	Yes
Generator Costs	No	Yes	No
Value of Lost Load	No	No (we don’t represent this at all, but could represent it annually if we needed to)	No (we don’t represent this at all, but could represent it across time blocks if we wanted to)
Demanded Load	Yes	Yes	Yes

[Ethan-Russell]

So we will need some way of breaking up hours in potentially different ways for different things. In general, we may want to break things down within a sim on a yearly basis in addition to having representative hours. MATLAB E4ST assumes that it will only ever run a single year.

Time scale

We want to be able to support a wide range of time scales. It would be awesome to support multi-year sims where each year has representative time blocks. Some key differences in the way we handle time in MATLAB E4ST vs the rewrite:

• Policies are either on or off for a single simulation, since simulations are run yearly. In the future, we'd need to have the possibility of running multiple years in a single simulation (without iteration).

So we may need two time indices for many of our variables.

variable	indices
pg	[gen_idx, year_idx, hour_idx]
pcap	[gen_idx, year_idx]
pl	[bus_idx, year_idx, hour_idx]
$\theta$	[bus_idx, year_idx, hour_idx]

One tricky thing here will be configurable data access. Depending on the configuration, we may wish to have some variables that are constant across years or representative hours.

For our time representation, I would propose that we keep track of the following:

• representative hours - a vector summing to 8760 containing the number of hours spent in each representative hour
• years - a vector containing the years we are running in the current sim. This would be separate from iteration years (or iteration year sets)

Sequential Hours

How would we handle sets of sequential hours? i.e. days?

[Ethan-Russell]

Information Access

Certain pieces of information may need to vary in different ways:

• No temporal variation
• Annually only (i.e. whether or not a policy is in effect for a year, social cost of carbon, etc)
• Hourly only (availability factor)
• Annually and hourly (same hourly variations each year but scale per year)
• Annually and hourly (different hourly variations each year)

Generator-specific information may need filters for the information too, as well as defaults for cases not covered.

• Location/region of the generator
• Generator type and subtype
• Age of the generator - between a min and max age

We need a good interface for specifying this information and a good interface for retrieving it once specified.

Availability Factor Examples:

• Set the availability factor of solar generation by region by representative hour
• Scale the availability factor of a specific solar subtype by generator age to model panel degradation
• Set the availability factor of all nuclear generators to be 0.9

How do we (quickly) retrieve the availability factor of a specific generator at a specific time and year, without necessarily pre-calculating all fields for all generators at every time/year?

[Ethan-Russell]

An important question in terms of how we represent data:

In the case of a multi-year simulation, do we foresee needing to change the shape of hourly load or availability factor profiles? Or can we keep the same load / availability factor shape between years, and potentially scale it between years?

[sallyrobson]

The only scenario I can think of where load shape would change would be a successful demand response program lowering peak demand. I imagine that this would endogenously change load so I don't think it would impact how we input data initially but might be something that updates with the year.

For availability factor, things like wind and solar do theoretically change between years but I think they are generally close enough and that it doesn't need to change. And since it is reduced to the representative hours anyways I don't think it has the level of detail that would change.

I can't see a particular need for the shape of those things to change and so I don't think it's worth too much trouble to include that ability. But probably worth asking Dan too

[sallyrobson]

Discussion 11/18:

Changing load and AF shape between years?

• Availability for generators does go down over time. But can likely be delt with as a scalar by year.
• Price responsive load: would be a decision variable.
• Electric vehicle charging will likely change over years. Could split up EV and other load. Or can adjust load shape over the years to close match the EV charging load.

In order to keep EV load shape able to change over years, it is worth being able to change load shape over time. Having the same underlying data structure for load and AF is probably easiest.

Another note: There can be more than one wind farm at each node, each of which has a different set of availability factors. This is fine is AF is per generator not bus.

Different set of representative hours in different years?

• Potentially useful but not worth the trouble that it causes.
• More likely that rep hours would change for a specific project but not years.

Second stage where every hour of year is simulated without any entry and exit of generators.

• Part of the offshore wind project
• Could be not all hours but more, (maybe like DERCAM: 3 whole days for each month)
• Then identifies the most challenging/interesting hours and chooses those for the analysis.
• Good for tech with consecutive hours, energy storage.

One downside of the model currently is that the load between buses is always proportional in the regions they are sorted into (nerc subregions or states). This might be more of an issue if we have more representative hours. Could be hard to get that data, but could possibly estimate.

[Ethan-Russell]

This has been implemented