Capacity planning ct scaling output #143
Conversation
|
Is this PR ready to review, or is this branch still a work-in-progress? |
|
I expect there will be feedback from @BainanXia to address before it is ready... |
|
After taking a closer look of the code, I found it is right in its current form give the fact that |
|
I didn't include the final change table step: because that step is straightforward to do already. Another consideration for leaving it out is that we'll likely be changing the overall change table schema. |
|
@BainanXia Feel free to suggest a better way to create the |
|
I don't think the final step is as straightforward as you think. Targets are defined by state (anywhere from 1 to N zones), while generators in the change table are specified by zone_id or by plant_id. A test case that tests |
|
As @danielolsen mentioned, before we run an integration test on this to compare the change tables generated by the two approaches, we should add some simple unit tests on the function |
|
I think you could get a meaningful test case of change table output by taking an Eastern grid and aggregating together all plants by type/zone into one single plant, so that you have sufficient complexity (primarily around the zone to state mapping: some states have 1 zone, some states have multiple zones with all different names, some states have multiple zones where one zone matches the state name) without an excessive amount of input data. EDIT: or you could get even simpler by doing the above and dropping all states besides Florida, North Carolina, and Maine. Those three states cover the three cases I mentioned above, which I think is all of the edge cases we want to be sure of. |
|
We can potentially use the approach Daniel suggested above using real grid data, and also, I just worked out a simple integration test here building on the previous capacity planning tests: |
|
Here are the summed generator capacities for the six zones which are required to handle the three cases I mentioned above. Each capacity sum can be aggregated into a single generator in a MockGrid, I believe we will only need the 'Pmax' and 'zone_id' columns. For a change table output that can integrate with the rest of our process, the calculated scaling factors for the Maine TargetManager need to be applied to that state's one zone, the scaling factors for North Carolina TargetManager need to applied to those two zones, the scaling factors for Florida TargetManager need to be applied to those three zones. See |
|
If this is now ready to go, could you please rebase onto |
dmuldrew
force-pushed
the
capacity_planning_ct_output
branch
from
9a1ad70 to
1060345
Compare
|
Trying the new function using the objects we've been using to set up Eastern scenarios seems to fail: |
|
The docstring is missing from |
|
@danielolsen This is an assertion to verify to that all resources within the capacity planning target object exist within the base grid. I suppose if we need to have resources in future scenario grids that are not present in the base grid, it will have to be removed or replaced... Right now we have the ability to specify resources not in the grid if they are present in |
|
The script from my previous comment now runs, but the outputs are still not compatible with the way our change table specifies scaling. Scaling has to be specified by zone_id or plant_id, not by a string for the name of the state (which may be made up of several zones). |
|
The last step is accomplished in the notebook using: I think we should keep this step, otherwise, there would be a scenario object dependency within the capacity planning framework, which I'd like to avoid. |
|
You can instant Kate a ChangeTable objet, Gill the table with the methods defined in the object. All of this without the mention to the Scenario object. |
|
I took a closer look at the I don't see any update to any notebooks as part of this PR, so I'm not seeing how you are able to generate a change table that will work the way we need it to. I am not asking you to apply the change table as part of this feature, just to demonstrate somehow that the change table that is generated is compatible with the input required by the change table method. |
|
Here's the dictionary that I get when running my code pasted above (which mimics what we are doing now for Eastern runs): I see a few issues:
When I try to apply this ct to a new scenario, |
|
So it sounds like we only need to output scaling factors for the |
|
Any changes to the scaling of generators besides @dmuldrew could you please run an integration test to demonstrate that this now works as expected? It does not need to be anything fancy, just copying/pasting from a terminal to show success will be enough. |
|
If the change table output of capacity scaling framework only contains wind and solar, we will have to go through the same procedure as previously we did using target capacity excel sheet to load target capacities for other generators, which make it meaningless. I was expecting the change table output here to be a complete one that covers all the scalings coming from the target capacities. After running this, we just need to add other entries to the change table when creating next scenario. |
|
@BainanXia I see your point. That brings up two questions:
|
|
I updated the capacity planning demo notebook: |
|
New natural gas generators have been added since scenario 394 (see #118), which is why you are calculating a scaling factor when you use that scenario as a base. Currently in both our 2016 runs and our 2020 runs, we turn off some subset of generators in our grid to reflect that some of them either a) have retired or b) have not yet been installed, so I don't think we can compare total capacities between two grids to get the scaling factors we want for non-renewable types. Doing this automatically would (I think) require adding extra info to the plant table (operating/retirement year), adding another parameter to the algorithm (simulation year), and passing capacity targets to this process (which we can do). There's another problem with the change table output in the last post: it has ERCOT zones for Texas. That's why it's not adding properly in the demo notebook. |
|
My notes from our sync-up today:
If something here is unclear, wrong, or incomplete, please let me know. |
|
One more thing to be aware of: the 'base' scenario may have fewer generators than exist in a new unscaled grid in |
I have similar comments in my draft box when I saw your comment popped up ;) |
dmuldrew
force-pushed
the
capacity_planning_ct_output
branch
from
bdaf464 to
8362280
Compare
|
The results of the change table validation of new method of generating the change table using the new Summarizing, all scaling factors generating by the new method are in also in the scaling factors generated by the old method. However, there appears to be a minor bug in the old method that attempts to scale some states with no resource capacity and more than one loadzone down to zero. I think it has to do the initialization of sum_state_ca = 0
if area in state2loadzone:
for loadzone in state2loadzone[area]:
if loadzone in sum_by_type_zone and colname_map[gen_type] in sum_by_type_zone[loadzone]:
sum_state_ca += sum_by_type_zone[loadzone][colname_map[gen_type]]
for loadzone in state2loadzone[area]:
if loadzone in sum_by_type_zone and colname_map[gen_type] in sum_by_type_zone[loadzone]:
scale_factor[colname_map[gen_type]][loadzone] = (row[gen_type],sum_state_ca)
else:
if colname_map[gen_type] in sum_by_type_zone[area]:
sum_state_ca = sum_by_type_zone[area][colname_map[gen_type]]
scale_factor[colname_map[gen_type]][area] = (row[gen_type],sum_state_ca)This later is corrected by the change table object validation. The new method has no such issue, and the change table object has no complaints about the generated scaling factors. |
|
@dmuldrew Whenever there is non-zero target capacity designed for a zero existing capacity resource, we consider something is wrong and needs to be notified, which is not a bug, even in the new framework, we should be aware of that (we could add dummy 1MW generators later to fix it). Another case you mentioned, if the existing capacity is zero and the target capacity is also zero, this will be considered as a normal situation, not 'attempting to scale multiple loadzones down to zero'. It certainly can be handled in a different way, as in the new framework, they are identified to be 'no scale', which is fine. Thanks for the validation. I've read through the notebook and find the change table outputs comparison is convincible. I think @danielolsen should also give a pass before we can close this. |
|
I think it's validated enough to merge in, since these new functions are an optional output for our workflow, we can still do some additional comparisons with new scenarios before we rely solely this new output. |
|
Thank you for the notebook, the creation of a change table with zone scaling factors appears to be working very well. Could you please rebase onto
|
dmuldrew
force-pushed
the
capacity_planning_ct_output
branch
from
2b227fd to
33e7d48
Compare
|
@danielolsen I think this is part of what you're looking for? |
dmuldrew
force-pushed
the
capacity_planning_ct_output
branch
from
33e7d48 to
dda0f73
Compare
|
@dmuldrew yes, the change table output is handling things properly when it needs to scale generators by type/zone, but not when it needs to scale by type & plant_id. In Scenario 403 we specifically turn off individual generators, to represent retirements between 2016 and 2020. We want the change table we generate to also do the same thing. |
|
@dmuldrew Let me explain the main concern that @danielolsen brings up here. Let's call the grid we got from the loaded scenario, However, there is an issue here, the Furthermore, the change table operations are independent with each other, which implies we should turn off those generators that we found in the |
|
Seems like in this case you can just pass in whatever reference grid you want to scale from as one of the optional inputs of the new functions. |
|
The reference grid is associated with the 'base' scenario, so we do not need another input from the user side. Passing the base scenario and the list of targets is enough information for all calculations. |
Purpose
This PR adds a function to output capacity scaling factors with respect to the base grid capacities. In addition, a
GridInfoclass is created which contains grid-specific code now inherited by theScenarioInfoclass.What is the code doing?
There are two new functions:
Outputs a dataframe of region capacities
output_capacities_table(self, base_grid)
Creates a change table from the capacities dataframe with optional external input
create_scale_factor_table(self, base_grid, gen_capacity=None)
Where to look
powersimdata/design/clean_capacity_scaling.py
powersimdata/design/tests/test_change_table_output.py
powersimdata/design/scenario_info.py
Time estimate
60 min