blue-marble / gridpath Goto Github PK
View Code? Open in Web Editor NEWA versatile simulation and optimization platform for power-system planning and operations.
Home Page: https://www.gridpath.io
License: Apache License 2.0
A versatile simulation and optimization platform for power-system planning and operations.
Home Page: https://www.gridpath.io
License: Apache License 2.0
Current ramp rate limits are in units of "fraction of capacity per hour", with a minimum of zero and a maximum of 1 (Pyomo PercentFraction). There are 2 problems with this approach:
If we change ramp rate limit units to "fraction of capacity per minute", users won't under-input the ramp rates since most units can't ramp their full capacity within a minute. Assuming that units who can ramp their full capacity within a minute won't ever be ramp constrained, we could keep the PercentFraction constraint for the inputs. If we don't want that, we should not limit the inputs to 1 and allow inputs larger than 1 (at which point we might as well keep the units in fraction per hour).
Whatever ramp rate unit we choose, the checks that happen when skipping ramp constraints should not assume hourly timesteps and properly address the ramp rate units.
We need to figure out how to write the appropriate directory and file structure for horizon and stage subproblems from the database.
Currently, operational types that are assumed not to provide reserves have no constraints on their reserve provision in the operational_type's module. However, if a user provides a reserve sharing zone for any of these type of resources, the model will create a decision variable for that type of reserve, and the variable will be totally unconstrained.
This currently applies to the following operational types:
There are a few options to solve this:
According to Morales-Espana et al. (2013), the min up/down constraint for unit commitment is only applied to [UT, T], where UT is the min up/down time, and T is the horizon length (e.g. 24 hours). This means you can skip the constraint for the first UT-1 hours.
We should investigate whether this also applies to the capacity commit module, where we have linear capacity commitment rather than binary commitment, and adjust the constraint
if needed. See PR #42 for discussion.
Medium Priority
Low Priority
Currently the units are MW, which makes it the hydro operational type incompatible with new build resources. It also doesn't allow for a proper evaluation of when to skip ramp rates, since the pmin as fraction of capacity is not determined until model the model is solved (capacity is an expression).
These issues are easily solved by changing all hydro input units to "fraction of operational capacity".
We should implement functionality to save and load solutions (e.g. in order to access solution elements that were not exported without having to re-run the scenario).
That makes more sense as an 'entry point' and the scripts can then be added to setup.py.
The current test cases in the 'gridpath/examples' folder contain combinations of continuous commit and new build generators, which shouldn't be combined because it creates non-linear problems and messes up the fuel burn calculations.
We need to modify the examples such that new build resources are not of the continuous/binary commit type, while making sure that there are still other non-new build resources of the continuous/binary commit type (to make sure these are still covered in the test examples).
Ramp rate limit units are in 'fraction per minute' and default to 1, i.e. the unit can ramp its full capacity in 1 minute. If you were to do sub 1-minute modeling (e.g. 1-second timesteps), this default ramp rate limit could become binding, which is not the expected behavior (limit shouldn't bind if not specified).
We need to adjust the constraints so that they are skipped at the default input value, regardless of the timepoint duration.
E.g. storage reserves effect on state of charge, thermal reserves effect on emissions (and costs?), hydro reserves effect on budget
The order order of 'temporal' IDs in the table definitions and SQL statements is inconsistent and needs to be standardized.
Fix ramp constraints of operational module to take reserve-provision into account.
When you are providing downward reserves in the previous timepoint, and/or upward reserves in the current timepoint should reduce the amount of upward ramping you can do between timepoint setpoints. E.g. if you're going from 50 MW in t-1 to 100 MW at t, but you were also provding 10 MW reg down in t-1 and 10 MW reg up in t, your unit must at least be able to ramp up 70 MW between timepoints.
Likewise, if you are providing upward reserves in the previous timepoint, and/or downward reserves in the current timepoint sould reduce the amount of downward ramping you can do between timepoint setpoints. E.g. if you're going from 100 MW in t-1 to 50 MW at t, but you were also provding 10 MW reg up in t-1 and 10 MW reg down in t, your unit must at least be able to ramp down 70 MW between timepoints.
This is an issue for the following operational types:
The following operational types will also have this issue, but will be rewritten anyway:
The following operational type will have this issue once we add ramp rate constraints to it:
Heat rate curves with arbitrary number of piecewise linear (?) segments.
Current implementation is fairly ad-hoc and could use clean up.
Standardize naming conventions for variables
tonnes
to describe carbon emissions (which are in metric tonnes) and avoid confusion with short tons.Code Style
Doc Strings
fuel_burn
, variable_om
, carbon_emissions
, and recs
are all "per timepoint" and not per hour and should be multiplied by the number of hours in the timepoint to get the actual amount ("power" vs. "energy" issue). This could also be clarified by changing the variable name. See #461.Results Formatting
Re-factoring repetitive code
Other
conn
seems most clear to me; db
could be the name of the db or the connection, or the path).imports_results_into_database
in import_scenario_results.py
, process_results.py
, spin_on_database_lock
.determine_xxx
function to read in inputs, but we often call that function many times (instead of calling it once and assigning it to a variable).See also #6
The capacity commit module has some non-conventional ways to break out the startup ramps and the operational ramps. Those are experimental and haven't been tested as thoroughly as they should.
It would be good to have the option to skip the non-linear example problems and maybe all example problems.
Currently, we're assuming the database is in the 'db' folder and called 'io.db' -- we need to allow the user to specify a different location and database name.
Storage will sometimes charge and discharge at the same time to appear as load, so that, for example, it appears that RPS energy is being delivered to load (in the simple case where a MWh RPS target is specified), even though it's really just losses.
Also check other tables for incorrect directionality of foreign keys.
The current minimum up time and minimum down constraints in the capacity_commit operational module do not properly take into account how varying timepoint durations will change what timepoints should be included in the relevant_tmps when creating the constraint.
Rather than a for-loop based on the current timepoint's duration, the constraint should evaluate the elapsed time as you go back to previous timepoints, until you hit the minimum uip or down time.
This will also be an issue for the min up and down time constraints for the binary_commit and continuous commit generators.
We need to figure out how to write the appropriate directory and file structure for horizon and stage subproblems from the database. We also need to think about additional functionality on linking stages and horizons (e.g. look-ahead days, spin-up days. etc.). Also think about how to allocate hydro/fuel budgets to horizons (can be simple average or something more sophisticated).
PR #78 seems to have caused issues with importing modules now that the scripts that do the imports are within the gridpath module. I get the following error:
Traceback (most recent call last):
File "run_scenario.py", line 22, in <module>
from gridpath.auxiliary.auxiliary import Logging
ModuleNotFoundError: No module named 'gridpath'
If I remove gridpath from the import statements in run_scenario.py I get the following error:
ERROR! Module temporal.operations.timepoints not found.
.
So it seems little more complicated than simply removing gridpath from all the import statements.
Ramp Rates:
Minup / Mindown:
Startup / Shutdown:
Database export functions
find a way to avoid having to type stdout_original = sys.stdout
all the time in run_scenario.py
In theory these type of generators should be able to provide reserves. If a generator is not able to do this, you can simply not provide a reserve zone.
Make sure to include reserve provision into ramp rates (see #30).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.