Add ability to scale gencost from change table

[danielolsen]

Purpose

Add ability to scale gencost from change table. Closes #142.

What the code is doing

• In change_table.py:
  • adding a new method _add_plant_entries() to add generator transformations to the change table. This is largely a copy/paste of the existing scale_plant_capacity, with one new added parameter that determines the top-level key that the plant_id and zone_name sub-dicts will live in. I also changed the behavior for bad info to be to re-raise the Exception after clearing the change table entry, rather than just printing the error & returning None; I think this will prevent users from overlooking these errors.
  • refactoring scale_plant_capacity to use this new method.
  • adding a new method scale_plant_cost() that also uses this method, with the difference that the keys that are added are e.g. "coal_cost" rather than "coal".
• In transform_grid.py:
  • we rename the existing _scale_gencost() to _scale_gencost_by_capacity() to emphasize that this is being done as a subroutine of _scale_gen(), since this is done to preserve the shape of the cost curve when we simulate adding new capacity by scaling up existing generators, and
  • we add a new _scale_gencost() method which scales all cost coefficients equally.
• In test_transform_grid.py: adding tests that these methods work as expected.

Time estimate

30 minutes. Not much is actually changed, and most new code is copy/pasted from existing code.

There's one somewhat-related issue I found in the rest of the test_transform_grid.py code: if the TransformGrid init and get_grid() fails in one test, then it may cause unrelated tests to fail, since the ChangeTable will not get cleared. Maybe other ways too. To demonstrate, try running the tests with a raise Exception as the first line of TransformGrid._scale_gencost(): it will break unrelated tests.

I think we can fix this by moving all code that touches ct into the try:/finally: blocks, or alternatively by just using a deepcopy within each individual test. Probably other ways too. We could address this here or in a separate PR.

[danielolsen]

I generalized the way we add plant_id- & zone_id-specified info to the change table, so that we can re-use the same code for scaling capacities as we do for scaling costs (and we will use the same for scaling Pmins). I think this is ready to review.

[danielolsen]

The daniel/scale_pmin branch is also waiting in the wings for when we get this merged.

[rouille]

Let me know what you want to do for the tests. the patch you propose can be done here or in a following PR. I went through the code and it looks good.

[BainanXia]

Should we prevent users from trying to scale a zero cost resource here such as wind, solar, hydro, etc, or simply put down some warnings?

[rouille]

Good point

[danielolsen]

Will these resources be zero-cost forever? With production tax credits, they may actually be bidding negative prices.

[rouille]

Do we have cost curves for renewable generators with zero coefficients in gencost?

[danielolsen]

Yes, they have 0 for c0, c1, c2

[BainanXia]

If they are getting a $10/MWh subsidy, then I think their 'true' cost is -10 $/MWh.

But they may not want to expose this subsidy in the market.

[danielolsen]

Aha, private subsidies, now we are getting strategic!

[danielolsen]

Coming back to this: I think there are other places in the code where we've baked in the idea that renewables are always zero cost. E.g. in transform_grid.py: if gen_type in self.thermal_gen_types:, we are implicitly assuming that non-'thermal' generators have zero c0 and c2 at the very least, and so there is no need to adjust those cost curve parameters. I like the idea of either making this assumption explicit (e.g. adding a set of 'zero_cost_resources' somewhere) or to stop assuming it altogether.

But, in my own self-interest, I would like to say that this is outside of the scope of this PR.

[rouille]

I see. Does it need to be handled here?

[rouille]

If we decide to set renewables to zero cost, a good place to define the zero_cost_resources would be in powersimdata/network/usa_tamu/constants/plants.py

[danielolsen]

Let me know what you want to do for the tests. the patch you propose can be done here or in a following PR. I went through the code and it looks good.

The comments here don't seem too tough to address, I would advocate for merging this and then fixing the tests in a follow-up.

[rouille]

Looks good. I have created an issue (#332) to address the equivocalness of zero cost for renewable generators

[BainanXia]

Looks good to me ;)