feat: add function to create data frame for gen_build_costs

[danielolsen]

Purpose

Create data frame to populate the gen_build_costs.csv file. Closes #3

What is the code doing

Within const.py: we add constants for assumed Pmins by generation type, and assumed generation build costs. The assumed Pmins by generation type are copied from the current logic of REISE.jl, which allows us to obtain identical results without needing to use a Scenario object which has been run by REISE.jl (since the original script made use of the linearized points, which come from running REISE.jl).

Within grid_to_switch.py:

• We add a linearize_gencost function, which performs the same logic as what is done by REISE.jl, returning both the cost_at_minimum_power and the single_segment_slope. We only make use of cost_at_minimum_power for now, but we will need single_segment_slope for #1.
• We add logic to the build_gen_build_costs function, emulating the functionality from the original script. The output of this function is one consolidated data frame, with a number of rows equal to N * P, where N = 1 + the number of investment years, and P is the length of the plant data frame. Following the original script, the first P rows are indexed by f"g{i}", where i is each generator ID, for the year 2019 (hard-coded). ~Then, the next P rows are indexed the same as f"g{i}{j}", where j is the zero-based index of the investment year. Note: I think this current logic can cause index collisions for plant data frames whose index spans more than one order of magnitude, since generator ID 1 in the first investment year (indexed as 0) will collide with generator ID 10 in the year 2019 (no suffix). If so, then we probably did not run into this for the Western grid we had been using in the initial script, but will certainly run into this issue for grids containing the Eastern interconnect, and we may want to switch to something like f"g{i}_{j}" to avoid this issue.~ EDIT: I mis-read the original code, this is not the case. The first P rows are as described, and the next P rows are indexed as f"g{i}i". So the i suffix is literally the string "i". These indices repeat, with different entries in the build_year column, so there are duplicate entries for the GENERATION_PROJECT columns but no duplicate entries for the combination of GENERATION_PROJECT and build_year.

Time to review

15-30 minutes. We are probably getting to the point where we want to start manually testing with real grid objects.

[rouille]

Is that a big deal to change the indexing scheme to avoid collision? What implication would that have on switch. @YifanLi86 can you comment on that?

[YifanLi86]

Is that a big deal to change the indexing scheme to avoid collision? What implication would that have on switch. @YifanLi86 can you comment on that?

Just talked to Daniel, should be fine for now. In the future we might need to make it more robust for multi-stage investment data though.

[danielolsen]

Is that a big deal to change the indexing scheme to avoid collision? What implication would that have on switch. @YifanLi86 can you comment on that?

Just talked to Daniel, should be fine for now. In the future we might need to make it more robust for multi-stage investment data though.

Fixed.