Change units of ramp rate limits #34

gerritdm · 2019-05-28T20:45:34Z

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:

Even when the ramp rate is 1, i.e. the unit can ramp its full capacity in an hour, the ramp rate could still be limiting when you are looking at timesteps of less than an hour (e.g. 5 minutes). However, most ramp rate constraints are skipped when the ramp rate limit is 1, which could lead to infeasible ramps when modeling subhourly timesteps.
When users convert their ramp rates from MW/min to fraction/hour, they will likely input "1" if the ramp rate allows for full ramping within the hour, even if it could do much more than that (e.g. a 100 MW unit which can ramp 10 MW/min, would be able to ramp 6 times its capacity in an hour, but users will likely just input 1). Also, because of the current PercentFraction constraint, users wouldn't even be able to input a number larger than 1.

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.

Update the dispatchable_binary_commit operational type to provide a fully-featured production cost modeling functionality with: - binary commitment decisions (on/off, startup, shutdown) - minimum and miximum output levels based on the commitment and the minimum stable level - minimum up time constraints - minimum down time constraints - ramp rate limits (during operations and during startup/shutdown) - upward and downward reserves The formulation is based on "Tight and compact MILP formulation for the thermal unit commitment problem (Morales-Espana et al. 2013)". We also add functionality to export results to the database. While this has been tested locally, there is currently no unittest that tests these new features Closes: #37 See also: #30, #34, #36

Ramp rate limits used to be in fraction/hour, and default to 1. If they were equal to 1, the constraints would be skipped. This causes a problem for modeling subhourly timesteps, where being able to ramp the full capacity within an hour might still lead to binding ramp rate limits. Also, users wouldn't be able to input ramp rate fractions above 1, even though some units can ramp their full capacity within much less than an hour. This commit addresses these issues by: - changing the units of ramp rate limits from fraction/hour to fraction/minute - updating the conditions for when ramp constraints are skipped. - standardizing how ramp rates are adjusted for timepoint duration (this was not accounted for properly everywhere). The ramp rate constraints will be skipped if you can ramp the project's full operational capacity range within the timepoint duration. For hydro operational types (curtailable and non_curtailable), we assume the operational range is [0, 1] whereas for the other operational types, it is [min_stable_level, 1]. Ideally we should take into account the min_stable_level for hydro too, but we would need to change the format of the hydro_conventional_horizon_params inputs to fractions rather than absolute MW (see #48). Another possible improvement is to better handle defaults and adjust the constraints so that they are skipped at the default input value (i.e. no inputs provided), regardless of the timepoint duration. Right now there could still be issues when you are modeling sub-minute timesteps and the model defaults to a "1-per-minute" ramp rate limit (see #46). Note that the objective function for the test cases changes slightly, even though the decision variables are the same within multiple figures of precision. This is due to the very high cost of overgeneration, where even a difference in 0.000001 MW in overgeneration can cause a significant difference in the objective function Closes: #34

Update the dispatchable_binary_commit operational type to provide a fully-featured production cost modeling functionality with: - binary commitment decisions (on/off, startup, shutdown) - minimum and miximum output levels based on the commitment and the minimum stable level - minimum up time constraints - minimum down time constraints - ramp rate limits (during operations and during startup/shutdown) - upward and downward reserves The formulation is based on "Tight and compact MILP formulation for the thermal unit commitment problem (Morales-Espana et al. 2013)". We also add functionality to export results to the database. While this has been tested locally, there is currently no unittest that tests these new features Closes: #37 See also: #30, #34, #36

Update the dispatchable_binary_commit and dispatchable_continuous_commit operational type to provide fully-featured production cost modeling functionality with: - binary commitment decisions (on/off, startup, shutdown) - minimum and miximum output levels based on the commitment and the minimum stable level - minimum up time constraints (note: this constraint shares the function that determines the relevant timepoints with the capacity_commit operational type - minimum down time constraints (note: this constraint shares the function that determines the relevant timepoints with the capacity_commit operational type - ramp rate limits (during operations and during startup/shutdown) - upward and downward reserves - database import/export functions and database schemas The formulation is based on "Tight and compact MILP formulation for the thermal unit commitment problem (Morales-Espana et al. 2013)". The continuous commit formulation is exactly the same as the binary commit formulation, except with the commit, start, and stop binary variables relaxed from binary to continuous [0,1]. While this has been tested locally, there is currently no unittest that tests the binary_commit operational type (and the examples that include continuous_commit operational types only test simplified examples without ramp rate limits or minimum up/down times). Closes: #37 See also: #30, #34, #36

gerritdm added the type: enhancement improvements to existing functionality label May 29, 2019

gerritdm mentioned this issue May 29, 2019

20190528 34 ramp rate units gdm #35

Merged

gerritdm added the type: bug bugs and errors label May 29, 2019

This was referenced May 29, 2019

Flesh out binary and continuous commit modules #37

Closed

Add ramp rate limits to no_commit generators #38

Closed

gerritdm closed this as completed in #35 Jun 12, 2019

gerritdm mentioned this issue Jan 9, 2020

Startup and shutdown ramp rates should be adjusted in irp port script #300

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Change units of ramp rate limits #34

Change units of ramp rate limits #34

gerritdm commented May 28, 2019

Change units of ramp rate limits #34

Change units of ramp rate limits #34

Comments

gerritdm commented May 28, 2019