bar generation stack plot

[BainanXia]

Pull Request doc

Purpose

Integrate another plot function from NREL seam study visualizations, which addresses #258: generation stack bar plot with any number of scenarios side by side. This might be helpful during the training session.

What the code is doing

• Implement plot function plot_bar_generation_stack.
• Add demo notebook for the new plot function.
• Add tests for input validations of the new plot function.

Testing

Tests for input validations are added in postreise/plot/tests/test_plot_bar_generation_stack.py
The plot function calls existing functions in analyze module for calculations.

Where to look

/postreise/plot/plot_bar_generation_stack.py
/postreise/plot/tests/test_plot_bar_generation_stack.py
/postreise/plot/demo/plot_bar_generation_stack_demo.ipynb

Usage Example/Visuals

Demos can be found in the demo notebook.

Time estimate

15 min.

[rouille]

Are we going to compare scenarios using different grid model? If yes, we could move the above lines (starting where we create an instance of ModelImmutables) in the for loop on the scenario to get the each scenario grid model pre-defined type2color, etc.

[BainanXia]

Good point. We can definitely compare scenarios created by different models for this figure. Will do so.

[BainanXia]

@rouille Actually, this might cause implicit conflicts as well. For example, we have two scenarios created by usa_tamu and hifld model respectively. They have different default colors for 'wind' resource. If we put two such scenarios in a list to show the generation stack bars side by side, the colors are going to be overwritten by the model of the last scenario in the list.

[BainanXia]

Given mi here is just for loading default color dicts, I suggest to keep it in its current form, i.e. always pick the default colors for the model of the first scenario in the list. We can still have scenarios with different models side by side using the default color scheme defined by the first scenario (the user can overwrite them all by these keyword arguments) as long as they have same areas which won't break area_to_loadzone as you mentioned below, otherwise, an "invalid area" error will be raised.

[rouille]

I guess that it will break here if we have scenarios that have different grid model since an area might be defined in one grid model but not in another, e.g, Bay Area is a load zone in usa_tamu but not in hifld.

[BainanXia]

I guess that it will break here if we have scenarios that have different grid model since an area might be defined in one grid model but not in another, e.g, Bay Area is a load zone in usa_tamu but not in hifld.

Yeah, I think it should be fine to break here by printing out "invalid area" from area_to_loadzone function to let the user know a specific area is not available for a particular grid_model?

[rouille]

Very nice. Thanks.