-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release 2.0.1 #106
Merged
Release 2.0.1 #106
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… --save-expression[s] flag to allow saving of expressions (or params, undocumented)
…CH_JOB_ID environment variable.
…ave-expression(s), --suffix(es) or --scenario(s)
It is sometimes necessary to reload models to run new post_solve code, e.g., if new outputs are defined after time-consuming models have already been run. Previously, --reload-prior-solution just reloaded the model and dumped the user into an interactive prompt, with no easy way to run module code. This commit changes the behavior of --reload-prior-solution, so that it now acts like an exact alternative to re-running the model, i.e., if the user specifies --reload-prior-solution, we reload the solution, then run the normal post-solve code, and don't drop to an interactive prompt unless they also specify --interact. Since this behavior is now central to the use of the model rather than a quasi-reporting behavior, this commit also moves save_results() back from switch_model.reporting to switch_model.solve. This commit also adds a --no-save-solution flag to disable automatic solution- saving, which is helpful for models that will be solved repeatedly and don't need to be reloaded.
This gives an explicit test of whether the list-argument parsing bug still applies to the current version of Python, and disables the warning if not needed. This also documents the bug better so future developers can remove the warning when no longer needed.
Pyomo 5.1.1 (and probably other versions) is very slow to load prior solutions because it does a full-component search for each component name as it assigns the data. This creates a delay that is quadratic in model size, so reloading solutions takes longer than solving the model from scratch. This code monkey-patches a few lines (!) of pyomo.core.base.PyomoModel.ModelSolutions.add_solution to use Pyomo's built-in caching system for component names. This makes --load-prior-solution fast enough to use for practical work. This is a pretty extreme approach, but there doesn't seem to be another way short of writing our own model-reload code. TODO: create a pull request for Pyomo to do this
The hawaii.ev_advanced module constructs ChargeEVs as a weighted sum of several possible charging profiles. If this is squared and added to the smoothing objective, it makes the model non-positive-definite, so cplex won't solve it. This code instead smoothes a helper variable ChargeEVsVar that is bound to ChargeEVs. This commit also refactors the smoothing code to make it a little DRYer.
- rename gen_cap.txt to gen_cap.tab and sort rows if requested - calculate spinning reserves from EVs correctly in the hawaii.ev_advanced module - turn off the must-run requirement in hawaii.kalaeloa when RPS or EV share is above 75% - drop support for nominal-dollar fuel price forecasts in hawaii.scenario_data - add --no-post-solve option - improve description of prior solution file
hawaii.smooth_dispatch previously smoothed the hourly dispatch profile for slack elements (storage, demand response, EVs) by minimizing the sum of the squares of the hourly values of these elements. This requires a quadratic solver and is difficult to setup with hawaii.ev_advanced, which defines EV charging as a convex combination of other decision variables. With this commit, we instead switch to minimizing the hour- to-hour variation of these variables (actually the total upward variation over the study period), which is linear, faster to solve, and works about as well.
This also adds ad-hoc technologies to production_by_technology.tsv.
…5.6 compatibility
…" if the upgrade runs twice.
This set is useful for assets with lifetimes longer than the study, but that assumption is generally poor practice. It is better to use explicit lifetimes. So this component is not widely useful.
I've added a CHANGELOG.txt that gives a more readable version of the changes. Since the code has mostly been running well for months and all tests pass, I will now merge it to master and publish as 2.0.1. |
…support correctly.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This includes a number of minor fixes -- please see the commit log. All tests pass, and most of the code has been running successfully for 6 months or more.