chore: merge develop into master for v0.5 release

[danielolsen]

Pull Request doc

Purpose

There have been several breaking changes to the PostREISE API (not to mention many new features), so we should probably increment the version accordingly. Closes #298.

Proposed release notes

Closed issues

• Recalibrate US map of emission using bars (Recalibrate US map of emission using bars #186)
• Refactor shortfall figure (Refactor shortfall figure #235)
• Scatter plot of capacity vs capacity factor (Scatter plot of capacity vs capacity factor #236)
• Integrate heatmap figure (Integrate heatmap figure #237)
• Integrate power flow snapshot figure (Integrate power flow snapshot figure #238)
• Clean up (Clean up #239)
• Scatter plot of capacity vs curtailment (Scatter plot of capacity vs curtailment #244)
• Scatter plot of cost curve slopes vs capacity (Scatter plot of cost curve slopes vs capacity #246)
• Generation stacked bar chart (Generation stacked bar chart #258)
• MatplotlibDeprecationWarning: The 's' parameter of annotate() has been renamed 'text' since Matplotlib 3.3 (MatplotlibDeprecationWarning: The 's' parameter of annotate() has been renamed 'text' since Matplotlib 3.3 #259)
• Bar plot of total capacity, actual generation and minimum generation per zone (Bar plot of total capacity, actual generation and minimum generation per zone #263)
• Bar plot of total capacity, actual generation and available energy per zone (Bar plot of total capacity, actual generation and available energy per zone #264)
• Transmission upgrades visualization refactor (Transmission upgrades visualization refactor  #267)
• Storage line and fill can be misaligned in plot_generation_time_series_stack (Storage line and fill can be misaligned in plot_generation_time_series_stack #275)
• Documentation including plots should be reproducible (Documentation including plots should be reproducible #280)
• Refactor plot_renewable_capacity_map (Refactor plot_renewable_capacity_map #281)
• Add scatter plot of capacity vs capacity factor to tutorial (Add scatter plot of capacity vs capacity factor to tutorial #282)
• Add scatter plot of capacity vs cost curve slope to tutorial (Add scatter plot of capacity vs cost curve slope to tutorial #285)
• Add scatter plot of capacity vs curtailment to tutorial (Add scatter plot of capacity vs curtailment to tutorial #287)
• Add utilization map to tutorial (Add utilization map to tutorial #290)
• Rename plot_upgrades_map to plot_transmission_upgrades mapsion upgrade (Rename plot_upgrades_map to plot_transmission_upgrades mapsion upgrade  #293)
• Refactor states plotting (Refactor states plotting #305)

Merged pull requests (features)

• Retire analyze_pg and multi folder (Retire analyze_pg and multi folder #243) (@BainanXia)
• feat: add heatmap plot (feat: add heatmap plot #245) (@danielolsen)
• scatter plot capacity vs capacity factor (scatter plot capacity vs capacity factor #251) (@BainanXia)
• Create dockerfile (Create dockerfile #252) (@dmuldrew)
• scatter capacity vs curtailment (scatter capacity vs curtailment #256) (@BainanXia)
• scatter capacity vs cost curve slope (scatter capacity vs cost curve slope #261) (@BainanXia)
• bar generation stack plot (bar generation stack plot #262) (@BainanXia)
• README, tutorial and code improvement (README, tutorial and code improvement #265) (@rouille)
• feat: improve flexibility of utilization, risk, and bind maps (feat: improve flexibility of utilization, risk, and bind maps #266) (@danielolsen)
• refactor: move cost calculation function to separate module (refactor: move cost calculation function to separate module #269) (@danielolsen)
• refactor: add flexibility to plot_upgrades_map (refactor: add flexibility to plot_upgrades_map #271) (@danielolsen)
• bar generation max vs actual vs min (bar generation max vs actual vs min #292) (@BainanXia)
• bar renewable max vs profile vs actual (bar renewable max vs profile vs actual #295) (@BainanXia)
• refactor: rewrite map_plant_capacity function for flexibility (refactor: rewrite map_plant_capacity function for flexibility #300) (@danielolsen)
• refactor: improve the flexibility of the transmission upgrades map (refactor: improve the flexibility of the transmission upgrades map #301) (@danielolsen)
• Refactor states plotting (Refactor states plotting #306) (@rouille)

Merged pull requests (fixes, etc.)

• docs: fix link to function in docstring (docs: fix link to function in docstring #248) (@rouille)
• Update dependencies (Update dependencies #249) (@jon-hagg)
• ci: add pep8-naming check to flake8 (ci: add pep8-naming check to flake8 #250) (@jon-hagg)
• docs: fix link to functions in docstrings (docs: fix link to functions in docstrings #254) (@rouille)
• ci: build and push docker image (ci: build and push docker image #257) (@jon-hagg)
• fix: install ipywidgets for tqdm progress bar (@jon-hagg)
• chore: change file permission (chore: change file permission #268) (@rouille)
• chore: add data CSVs to package_data (chore: add data CSVs to package_data #270) (@danielolsen)
• chore: remove seaborn from requirements (chore: remove seaborn from requirements #272) (@danielolsen)
• chore: create bug report issue template (@273) (@rouille)
• ci: add workflow_dispatch trigger to docker build (ci: add workflow_dispatch trigger to docker build #274) (@jon-hagg)
• generation stack plot bug fix (@276) (@BainanXia)
• ci: add coverage report to pytest (ci: add coverage report to pytest #278) (@jon-hagg)
• Add scatter plot of capacity vs capacity factor to tutorial (Add scatter plot of capacity vs capacity factor to tutorial #283) (@rouille)
• chore: create feature request issue template (chore: create feature request issue template #284) (@rouille)
• Add scatter plot of capacity vs cost curve slope to tutorial (Add scatter plot of capacity vs cost curve slope to tutorial #286) (@rouille)
• Add scatter plot of capacity vs curtailment to tutorial (Add scatter plot of capacity vs curtailment to tutorial #288) (@rouille)
• Add utilization map to tutorial (Add utilization map to tutorial #291) (@rouille)
• Rename plot_upgrades_map to plot_transmission_upgrades map (Rename plot_upgrades_map to plot_transmission_upgrades map #294) (@rouille)
• Add logo and badges to README (Add logo and badges to README #296) (@rouille)
• Update dependencies (Update dependencies #297) (@jon-hagg)
• fix: correct bug where get_dcline_differences fails for DC lines connected to new buses (fix: correct bug where get_dcline_differences fails for DC lines connected to new buses #299) (@danielolsen)
• refactor: move code snippets to files (refactor: move code snippets to files #302) (@jon-hagg)
• Update dependencies (Update dependencies #303) (@jon-hagg)
• Simplify process to generate plotting documentation (Simplify process to generate plotting documentation #307) (@jon-hagg)
• chore: bump version number to v0.5.0 (chore: bump version number to v0.5.0 #309) (@danielolsen)
• refactor: replace function definitions with imports from powersimdata (refactor: replace function definitions with imports from powersimdata #310) (@danielolsen)
• Update dependencies (Update dependencies #311) (@jon-hagg)
• Upload coverage report (Upload coverage report #312) (@jon-hagg)
• chore: fix yaml and add badge (chore: fix yaml and add badge #313) (@jon-hagg)
• docs: clarify PowerSimData dependency (docs: clarify PowerSimData dependency #314) (@rouille)
• Fix import statements (Fix import statements #315) (@rouille)
• Update dependencies (Update dependencies #316) (@jon-hagg)
• Update packaging and docker related workflows (Update packaging and docker related workflows #317) (@jon-hagg)

Time estimate

5 minutes. We probably want to wait on this until we merge #306 and #307 (maybe more refactoring as well?), but we can at least get the ball rolling.

[danielolsen]

Once Breakthrough-Energy/PowerSimData#514 is merged, how can we specify in the requirements that we require PowerSimData >= 0.4.3?

[jenhagg]

Once Breakthrough-Energy/PowerSimData#514 is merged, how can we specify in the requirements that we require PowerSimData >= 0.4.3?

Closest think I can think of would be to use the github url as we do in switchwrapper, since develop branch will satisfy the requirement.

[danielolsen]

Once Breakthrough-Energy/PowerSimData#514 is merged, how can we specify in the requirements that we require PowerSimData >= 0.4.3?

Closest think I can think of would be to use the github url as we do in switchwrapper, since develop branch will satisfy the requirement.

develop should satisfy the requirement, but we don't need the user to pull the latest PowerSimData every time they want to use PostREISE. Can we specify a particular release in the github URL?

[jenhagg]

Once Breakthrough-Energy/PowerSimData#514 is merged, how can we specify in the requirements that we require PowerSimData >= 0.4.3?

Closest think I can think of would be to use the github url as we do in switchwrapper, since develop branch will satisfy the requirement.

develop should satisfy the requirement, but we don't need the user to pull the latest PowerSimData every time they want to use PostREISE. Can we specify a particular release in the github URL?

Yeah we could specify the git tag, which would be equivalent to powersimdata==0.4.3. If we want >=0.4.3 then using develop or master would work. Actually if we only merge to master on releases, that should be equivalent to how it would work if we had the package on PyPI.

[danielolsen]

Actually if we only merge to master on releases, that should be equivalent to how it would work if we had the package on PyPI.

I think we want ~=0.4.3, right? Since we may decide to make breaking changes for PowerSimData 0.5.

[jenhagg]

I think we want ~=0.4.3, right? Since we may decide to make breaking changes for PowerSimData 0.5.

That would be ideal. In that case, I guess we could have a stable branch where we exclude patch changes, and have all versioned releases in master. Not sure if it would be easier to just publish to PyPI.

[BainanXia]

I think we want ~=0.4.3, right? Since we may decide to make breaking changes for PowerSimData 0.5.

That would be ideal. In that case, I guess we could have a stable branch where we exclude patch changes, and have all versioned releases in master. Not sure if it would be easier to just publish to PyPI.

I'm new to package versioning. I could understand if we have all versioned releases in master, it is equivalent to publish to PyPI. But what do you mean by "having a stable branch where we exclude patch changes"?

[jenhagg]

I'm new to package versioning. I could understand if we have all versioned releases in master, it is equivalent to publish to PyPI. But what do you mean by "having a stable branch where we exclude patch changes"?

I was thinking of semver patches, but misspoke - those should be backward compatible. What I meant to say is stable would exclude breaking changes. In any case, this is a temporary solution, since pip can't really do all the version handling without a package server (e.g. PyPI, not sure of other options).

[danielolsen]

With #317 getting merged in, I don't think there are any more blockers to this release. I've updated the proposed release notes with the last two months' PRs & issues. Any remaining objections to merging #309 and this PR?

[jenhagg]

With #317 getting merged in, I don't think there are any more blockers to this release. I've updated the proposed release notes with the last two months' PRs & issues. Any remaining objections to merging #309 and this PR?

None from me.

[kasparm]

Looks good.
Thank you.