Add Storage to Model

[Ethan-Russell]

No description provided.

[sallyrobson]

We should look for some updated costs of energy storage, and possibly multiple durations of energy storage including some longer duration storage. There are new techs being developed for longer duration storage so maybe check in on what is realistic.

[sallyrobson]

Currently we use hydrogen for long duration storage, is that the only thing that we use hydrogen for? Should we be grouping that in storage more in the results?

[sallyrobson]

We plan to represent PS (RPS/CES) as a percentage of energy served (not target load). When we figure out how to represent batteries we should revisit this. We may want to only have the net battery load be part of that instead of the full energy to charge.

constraint would be on percent requirement * (target load - curtailment + DAC load + net battery load)

[Ethan-Russell]

For storage, we can potentially model storage as only adjusting pserv. When charging, it increases pserv (acting as a load). Then when discharging, it would decrease pserv (decreasing the load).

[Ethan-Russell]

For now, I'm starting with diurnal storage.

First, I want to resolve the following:

• Add Line Losses #92
• Change demand/demanded load to target load #91

[Ethan-Russell]

Required fields for Diurnal storage:

This is something necessary for each device.

• storage_duration - storage capacity, in number of hours to fully discharge. Come up with better name??
• storage_duration_charge - (optional)
• pcap0 - starting discharge capacity, in MW
• storage_efficiency - round-trip efficiency
• fom
• vom
• capex
• bus_idx
• hour_groupby - the hours column to group by - day, for example
• hour_duration - the hours column specifying the duration, in hours, spent at each time interval
• hour_order - the hours table column specifying the order of each time interval. This might not be necessary, if the hours are already in order.

Variables Introduced

• pcap_stor[1:nstor, 1:nyear] - the discharge rate
• pcharge_stor[1:nstor, 1:nyear, 1:nhour], between 0 and pcap_stor ( maybe change this limit if different charge duration)
• pdischarg_stor[1:nstor, 1:nyear, 1:nhour], between 0 and pcap_stor

Constraints Introduced

• Constrain the sum of echarge - edischarge to be zero across the interval - i.e. same starting and ending charge
• Constrain that the net charge at each hour of the day is bounded by the maximum charge (above and below). The net charge at each hour of the day is she sum of echarge - edischarge from the first hour of the day until the current one.

Objective Function

• add fom * pcap_stor to objective
• add capex_obj * pcap_stor to objective
• add vom * pcharge (or pdischarge? or both?) to the objective - check ATB to see how they specify VOM

Expressions

• add/subtract pcharge / storage_efficiency to/from the appropriate expression. See Add Line Losses #92
• add/subtract pdischarge to/from the appropriate expression. See Add Line Losses #92

Implementation Details

• Does it make sense to add diurnal storage to the generator table? Then just handle it specially? Or does it make sense for it to be in a Modification? Or just a separate file? I think there is some duplicated stuff, like vom/fom/capex, that could be easily handled in the gen table. It could also make results processing easier (albeit a bit misleading?) if batteries are in the generation table. If we have them separate, that allows for custom results for batteries. We could do seasonal charging shapes, etc.
• Do we want diurnal storage and longer duration storage to be modeled in a similar way? It would be great to have as little duplicate work as possible. I.e. do we want to carefully specify how to give different intervals for storage profiles? The tricky thing with long duration storage is that, if the charge duration is less than the total time period we are modeling, then the storage intervals must be sequential, which is not necessarily feasible with the way we have historically calculated our representative hours.

Results

• Do we care about daily diurnal profiles?
  • Maybe eventually, but not required. Make sure we have information saved so we could calculate it.
• Charging, in MWh
• Discharging, in MWh
• Net energy loss by storage devices. Charging Loss (this could get added to results)
• Anything else?

[Ethan-Russell]

Sally and I decided it would be best to have batteries in their own separate table, so that we have more flexibility to define them in ways that wouldn't work well with the generator table.

[Ethan-Russell]

Finished in #112