Add an interface for the user to define expansion candidates besides what's in the input Grid

[danielolsen]

🚀

• Is your feature request essential for your project?

Not necessarily essential for v0.1, since that seems to be able to continue under the assumption that we can restrict ourselves to expanding existing generators/transmission lines (@YifanLi86 please correct me if I'm wrong), but will be required once we want to enable Switch to choose new generators, new branches, new storage etc.

Describe the workflow you want to enable

I wish I could provide tables for expansion candidates (generators, branches, storage), distinct from the existing grid. This information could be passed to the main user-facing function described in #62, which will further pass it to the grid_to_switch function which writes the Switch input CSVs. For hypothetical variable generators, we will need to grab a profile from an existing generator, so this information will probably need to flow through to the profiles_to_switch function as well.

Describe your proposed implementation

The user can pass a table for each of:

• generation expansion candidates
• transmission expansion candidates (AC & DC)
• storage expansion candidates

These tables need not have all of the columns of the existing tables within the Grid object, since the columns that would get interpreted by Matpower or REISE.jl are not needed, but we need all of the information required to instantiate a 'final' Grid from the Switch solution.

It would be nice if the user could also say that no expansion is allowed for one or all of these, or that expansion should only consider existing ones.

For transmission, as far as I can tell, it does not appear that we can set a limit for how much each branch can be expanded.

[danielolsen]

Looking at the example files for specifying storage build candidates (https://github.com/switch-model/switch/tree/master/examples/storage/inputs), it seems that we will need to add at least:

• A gen_storage_efficiency column to the generation_projects_info.csv file, with a value between 0 and 1 for storage devices and a "." for all non-storage generators.
• A gen_storage_energy_overnight_cost column to the gen_build_costs.csv file, with a value ($/MWh?) for each storage device and a "." for all non-storage generators. This will be in addition to the existing gen_overnight_cost column which I think specified storage on a per-MW basis.

There may be more information that we need to give to Switch as well, @YifanLi86 would probably know more.

We can pull the storage efficiency from the Grid object that is given to the prepare_inputs function, but we will need to define values for the per-MW and per-MWh costs of storage.

It's unclear how we can specify the energy capacity for existing storage.

[YifanLi86]

@danielolsen Almost there, you already got most of the key information it needs. For gen_storage_energy_overnight_cost, it is in $/MWh. I would use this one instead of the $/MW cost as seems like storage is usually priced by energy in market than Max Power.

For existing storage, as a simplification, I would just multiply the Max Power by the hour duration to get energy capacity.

For storage expansion candidate's naming, I use "12345s", and it can be assigned to any load_zone exists in grid object.

One more thing to specify is the fuel for storage as "Electricity" and assign to all storage. It is not a real fuel and not going to bring in additional energy, but still all uses power absorbing from the grid. Also, you need to add a new gen_tech for all storages, like "battery", "battery storage", etc.

Efficiency is optional and default to 1. There are some other optional properties in gen_projects_info.csv, below is what I would suggest to use:

gen_storage_max_cycles_per_year: use "200"
gen_store_to_release_ratio: use "1"
gen_storage_energy_to_power_ratio: use "."

[danielolsen]

For gen_storage_energy_overnight_cost, it is in $/MWh. I would use this one instead of the $/MW cost as seems like storage is usually priced by energy in market than Max Power.

We can populate either one, or both. Either the user needs to provide this information (the same for all storage devices? different for each storage device?) or we need to have hard-coded default values.

There are some other optional properties in gen_projects_info.csv, below is what I would suggest to use:

gen_storage_max_cycles_per_year: use "200"
gen_store_to_release_ratio: use "1"
gen_storage_energy_to_power_ratio: use "."

What is the meaning of the gen_store_to_release_ratio value? If all storage devices have no information for the gen_storage_energy_to_power_ratio parameter (I think that's what "." does), then do we need to include this column?

[YifanLi86]

For gen_storage_energy_overnight_cost, it is in $/MWh. I would use this one instead of the $/MW cost as seems like storage is usually priced by energy in market than Max Power.

We can populate either one, or both. Either the user needs to provide this information (the same for all storage devices? different for each storage device?) or we need to have hard-coded default values.

I would only populate one of the two, but not both at the same time. We can definitely hard code for now, the value I am using now is 213000. Pretty much NREL 2020 ATB.

There are some other optional properties in gen_projects_info.csv, below is what I would suggest to use:
gen_storage_max_cycles_per_year: use "200"
gen_store_to_release_ratio: use "1"
gen_storage_energy_to_power_ratio: use "."

What is the meaning of the gen_store_to_release_ratio value? If all storage devices have no information for the gen_storage_energy_to_power_ratio parameter (I think that's what "." does), then do we need to include this column?

it defines the ratio between max charging speed and discharging (generation) max power. So for example you have 5MW storage as max output, defining this ratio as 0.8 will only allow it to charge at max rate of 4MW.

gen_storage_energy_to_power_ratio is essentially the duration of storage. Putting an "." will make it a decision variable to be optimized, which is what I suggest to do now, but in the next step we may want to test putting different values there, so better to keep this column available when you build the wrapper.

[danielolsen]

What are the defaults for gen_storage_max_cycles_per_year, gen_store_to_release_ratio, and gen_storage_energy_to_power_ratio? If we are not specifying anything different, then there is no need to put these into the input files.

[YifanLi86]

".", "1", ".". I would be ok to leave these out for now. As I said, these are optional, just would like to give you the complete information about storage modeling in SWITCH and share what I've been doing so far.

[danielolsen]

So the information that we want the user to supply for storage candidates is:

• bus (zone) ID

And the hard-coded values that we will use to populate non-default Switch values are:

• gen_storage_max_cycles_per_year: 200
• gen_storage_energy_overnight_cost: 213000
• fuel: "Electricity"
• tech: "Battery"

Anything I'm missing?

[YifanLi86]

So the information that we want the user to supply for storage candidates is:

• bus (zone) ID

And the hard-coded values that we will use to populate non-default Switch values are:

• gen_storage_max_cycles_per_year: 200
• gen_storage_energy_overnight_cost: 213000
• fuel: "Electricity"
• tech: "Battery"

Anything I'm missing?

Yes, this should be all that the user need to supply.

[danielolsen]

For storage candidates, do we also want to fill in any information in the gen_capacity_limit_mw file, or should we leave this as "." (unconstrained)?

[danielolsen]

One way we could convey the information on candidates is as part of a change table dictionary, where adding a plant with a certain capacity represents that a plant can be added at that location, with up to that capacity. We could do the same with added storage and added branches (although it's unclear whether Switch can be told not to build more than X MW of new transmission at any given location). The ChangeTable methods have the convenience that they can automatically perform error checking and fill in un-specified default values automatically.