10. GridPath Functionality - Advanced¶
This section contains the advanced documentation that is automatically generated from the documentation within each GridPath module.
10.1. Core Functionality¶
This chapter describes GridPath’s basic functionality if no optional features are included.
10.1.1. Temporal Setup¶
gridpath.temporal¶
The gridpath.temporal package describes the optimization problem’s temporal span and resolution.
Temporal units include:
Timepoints: the finest resolution over which operational decisions are made (e.g. an hour). Commitment and dispatch decisions are made for each timepoint, with some constraints applied across timepoint (e.g. ramp constraints.)
Horizons: Each timepoint belongs to a ‘horizon’ (e.g. a day), which describes which timepoints are linked together, with some operational constraints enforced over the ‘horizon,’ e.g. hydro budgets or storage energy balance.
Periods: each timepoint and horizon belong to a ‘period’ (e.g. an year), which describes when decisions to build or retire infrastructure can be made.
gridpath.temporal.operations¶
The gridpath.temporal.operations package contains the timepoints and horizons modules that describe the operational resolution of the model.
gridpath.temporal.operations.timepoints¶
Refer Timepoints.
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
The following Pyomo model components are defined in this module:
Sets
TMPS
Within:PositiveIntegers
The list of timepoints being modeled; timepoints are ordered and must be non-negative integers.
MONTHS
Within:PositiveIntegers
The list of months (1-12).
Required Input Params
hrs_in_tmp
Defined over:TMPS
Within:NonNegativeReals
The number of hours in each timepoint (can be a fraction). For example, a 15-minute timepoint will have 0.25 hours per timepoint whereas a 4-hour timepoint will have 4 hours per timepoint. This parameter is used by other modules to track energy (e.g. storage state of charge) and when evaluation ramp rates. Timepoints do not need to have the same
hrs_in_tmp
value, i.e. one of them can represent a 5-minute segment and another a 24-hour segment.tmp_weight
Defined over:TMPS
Within:NonNegativeReals
This parameter accounts for the number of other similar ‘timepoints’ that are not explicitly included in the optimization, but that the included timepoint represents in the objective function. For example, we could include one day from the month to represent the entire month, in which case the timepoint_weight for each timepoint on that day will be the number of the days in the respective month.
prev_stage_tmp_map
Defined over:TMPS
Within:NonNegativeIntegers
The associated timepoint in the previous stage (if there is any) for each timepoint. This is used to pass commitment decisions from one stage to the next. E.g. if the real-time stage has 15-minute timepoints , and the hour-ahead stage had hourly timepoints, all 4 real-time timepoints within an hour will point to the same hourly timepoint in the previous hour-ahead stage to its commitment decision.
month
Defined over:TMPS
Within:MONTHS
The month that each timepoint belongs to. This is used to determine fuel costs during that timepoint, among others.
gridpath.temporal.operations.horizons¶
Refer Balancing Types and Horizons.
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
The following Pyomo model components are defined in this module:
Sets
BLN_TYPE_HRZS
Two dimensional set of balancing types and their associated horizons. Balancing types are strings, e.g. year, month, week, day, whereas horizons must be non-negative integers.
TMPS_BY_BLN_TYPE_HRZ
Defined over:BLN_TYPE_HRZS
Ordered, indexed set that describes the the horizons associated with each balancing type. The timepoins within a horizon-balancing type are ordered.
Derived Sets
BLN_TYPES
The list of all balancing types.
HRZS_BY_BLN_TYPE
Defined over:BLN_TYPES
Ordered, indexed set that describes the horizons associated with each balancing type. The horizons within a balancing type are ordered.
TMPS_BLN_TYPES
Two-dimensional set of all timepoints along with the balancing types each timepoint belongs to.
Required Input Params
horizon
Defined over:TMPS x BLN_TYPES
Describes the horizon that each timeoint belongs to for a given balancing type. Depending on the balancing type, timepoints can be grouped in different horizons.
boundary
Defined over:BLN_TYPE_HRZS
Within:['circular', 'linear']
The boundary for each horizon. If the boundary is ‘circular,’ then the last timepoint of the horizon is treated as the ‘previous’ timepoint for the first timepoint of the horizon (e.g. for ramping constraints or tracking storage state of charge).
Derived Input Params
first_hrz_tmp
Defined over:BLN_TYPE_HRZS
Derived parameter describing the first timepoint in each horizon for a given balancing type. Note: this relies on
TMPS_BY_BLN_TYPE_HRZ
being an ordered (indexed) set.last_hrz_tmp
Defined over:BLN_TYPE_HRZS
Derived parameter describing the last timepoint in each horizon for a given balancing type. Note: this relies on
TMPS_BY_BLN_TYPE_HRZ
being an ordered (indexed) set.prev_tmp
Defined over:TMPS x BLN_TYPES
Within: :code: m.TMPS | {None}Derived parameter describing the previous timepoint for each timepoint in each balancing type; depends on whether horizon is circular or linear and relies on having ordered
TIMEPOINTS
.next_tmp
Defined over:TMPS x BLN_TYPES
Within: :code: m.TMPS | {None}Derived parameter describing the next timepoint for each timepoint in each balancing type; depends on whether horizon is circular or linear and relies on having ordered
TIMEPOINTS
.
gridpath.temporal.investment¶
The gridpath.temporal.investment package contains the periods module that describe the investment resolution of the model.
gridpath.temporal.investment.periods¶
Refer Periods.
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
The following Pyomo model components are defined in this module:
Sets
PERIODS
Within:PositiveIntegers
The list of all periods being modeled. Periods must be non-negative integers and the set is ordered.
Derived Sets
TMPS_IN_PRD
Defined over:PERIODS
Indexed set that describes the timepoints that occur in each period.
NOT_FIRST_PRDS
Within:PERIODS
The list of periods excluding the first period. Relies on periods being ordered.
Required Input Params
discount_factor
Defined over:PERIODS
Within:NonNegativeReals
Determines the relative objective function weight of investment and operational decisions made in each period (i.e. future costs can be weighted less).
hours_in_period_timepoints
Defined over:PERIODS
Within:[8760, 8766, 8784]
The number of hours in the timepoints representing a period (across all scenario subproblems, within a stage, excluding spinup/lookahead. Note that to ensure consistent weighting of period-level and timepoint-level costs, this derived parameter must have a value of the number of hours in a year. This is automatically calculated from the temporal_scenario_id structure if using the database and an error will be thrown if the timepoint param inputs do not summ up to one of the allowed values. Within GridPath, this parameter is used to adjust the capacity-related costs incurred within a subproblem if a subproblem is shorter than the period.
period_start_year
Defined over:PERIODS
Within:NonNegativeReals
The first ‘year’ in a period, e.g. if this is 2030, the period is assumed to begin at 2030-01-01 00:00. Note that non-integer values are allowed, so you could have 2030.25 for a period that starts on 2030-04-01, for example. Having periods shorter (or longer) than a year is largely untested, so be extra careful if attempting to use this functionality, as it could be buggy.
period_end_year
Defined over:PERIODS
Within:NonNegativeReals
The last ‘year’ in a period. This is exclusive following typical Python convention, i.e. if it is 2040, the period is assumed to go through 2039-12-01 23:59. Note that non-integer values are allowed, so you could have 2030.50 for a period that goes through 2030-06-30, for example. Having periods shorter (or longer) than a year is largely untested, so be extra careful if attempting to use this functionality, as it could be buggy.
period
Defined over:TMPS
Within:PERIODS
Specifies the associated period for each timepoint.
Derived Input Params
number_years_represented
Defined over:PERIODS
Within:NonNegativeReals
Accounts for the number of years that the periods is meant to represent. Investment cost inputs in GridPath are annualized, so they are multiplied by this parameter in the objective function. The parameter is derived based on the period_start_year and period_end_year parameters.
first_period
Within:PERIODS
The first period in the model. Relies on the PERIODS set being ordered.
prev_period
Defined over:NOT_FIRST_PRDS
Within:PERIODS
Determines the previous period for each period other than the first period, which doesn’t have a previous period.
hours_in_subproblem_period
Defined over:PERIODS
Within:NonNegativeReals
The number of hours in each period for the current subproblem, taking into account the timepoints in each period-subproblem, the number of hours in each timepoint, and their associated timepoint weights. In capacity expansion mode with one subproblem, this should simply be equal to
hours_in_period_timepoints
. In production simulation mode with multiple subproblems within 1 period, this number is compared tohours_in_period_timepoints
and used to adjust the reported “per-period” costs. For instance, when running daily subproblems the fixed cost in each day should be only 1/365 of the annualized fixed cost.
10.1.2. Geographic Setup¶
The gridpath.geography package describes the optimization problem’s geographic span and resolution.
gridpath.geography.load_zones¶
The gridpath.geography.load_zones module describes the geographic unit at which load is met. Here, we also define whether violations (overgeneration and unserved energy) are allowed and what the violation costs are.
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
- Parameters:
m – the Pyomo abstract model object we are adding components to
d – the dynamic inputs class object; not used here
The module adds the LOAD_ZONES set to the model formulation as well as vairous parameters associated with load balance penalties and limits.
10.1.3. Projects¶
gridpath.project.__init__¶
The ‘project’ package contains modules to describe the available capacity and operational characteristics of generation, storage, and demand-side infrastructure ‘projects’ in the optimization problem.
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
Sets
PROJECTS
The list of all projects considered in the optimization problem.
Input Params
load_zone
Defined over:PROJECTS
Within:LOAD_ZONES
This param describes which load zone’s load-balance constraint each project contributes to.
capacity_type
Defined over:PROJECTS
Within:["dr_new", "gen_new_bin", "gen_new_lin",
"gen_ret_bin", "gen_ret_lin", "gen_spec", "stor_new_bin",
"stor_new_lin", "stor_spec", "fuel_prod_spec", "fuel_prod_new
"energy_spec", "energy_new_lin"]
This param describes each project’s capacity type, which determines how the available capacity of the project is defined (depending on the type, it could be a fixed for each period or a decision variable).
operational_type
Defined over:PROJECTS
Within:["dr", "gen_always_on", "gen_commit_bin",
"gen_commit_cap", "gen_commit_lin", "gen_hydro",
"gen_hydro_must_take", "gen_must_run", "gen_simple",
"gen_var", "gen_var_must_take", "stor", "fuel_prod", "dac",
"flex_load"]
This param describes each project’s operational type, which determines how the project operates, e.g. whether it is fuel-based dispatchable generator, a baseload project, a variable generation project, a storage project, etc.
availability_type
Defined over:PROJECTS
Within:["binary", "continuous", "exogenous"]
This param describes each project’s availability type, which determines how the project availability is determined (exogenously or endogenously).
balancing_type_project
Defined over:PROJECTS
Within:BLN_TYPES
This param describes each project’s balancing type, which determines how timepoints are grouped in horizons for that project. See
horizons
module for more info.technology
Defined over:PROJECTS
Within:Any
Default:unspecified
The technology for each project, which is only used for aggregation purposes in the results.
Project Capacity¶
gridpath.project.capacity¶
This package contains modules to describe the available capacity and the capacity-associated costs of generation, storage, and demand-side infrastructure ‘projects’ in the optimization problem.
gridpath.project.capacity.capacity¶
This is a project-level module that adds to the formulation components that describe the capacity of projects that are available to the optimization for each period. For example, the capacity can be a fixed number or an expression with variables depending on the project’s capacity_type. The project capacity can then be used to constrain operations, contribute to reliability constraints, etc.
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
First, we iterate over all required capacity_types modules (this is the set of distinct project capacity types in the list of projects specified by the user) and add the components specific to the respective capacity_type module. We do this by calling the add_model_components method of the capacity_type module if the method exists.
Then, the following Pyomo model components are defined in this module:
Sets
PRJ_OPR_PRDS
Within:PROJECTS x PERIODS
Two-dimensional set that defines all project-period combinations when a project can be operational (i.e. either has specified capacity or can be build). This set is created by joining sets added by the capacity_type modules (which is done before loading this module), as how operational periods are determined differs by capacity type.
OPR_PRDS_BY_PRJ
Defined over:PROJECTS
Indexed set that describes the possible operational periods for each project.
PRJ_OPR_TMPS
Two-dimensional set that defines all project-timepoint combinations when a project can be operational.
OPR_PRJS_IN_TMP
Defined over:TMPS
Indexed set that describes all projects that could be operational in each timepoint.
Expressions
Capacity_MW
Defined over:PRJ_OPR_PRDS
Defines the project capacity in each period (in which the project can exist) in the model. The exact formulation of the expression depends on the project’s capacity_type. For each project, we call its capacity_type module’s capacity_rule method in order to formulate the expression. E.g. a project of the gen_spec capacity_type will have a have a pre-specified capacity whereas a project of the gen_new_lin capacity_type will have a model variable (or sum of variables) as its Capacity_MW.
Energy_Storage_Capacity_MWh
Defined over:PRJ_OPR_PRDS
Defines the project’s energy capacity in each period (in which the project can exist). The exact formulation of the expression depends on the project’s capacity_type. For each project, we call its capacity_type module’s energy_stor_capacity_rule method in order to formulate the expression.
gridpath.project.capacity.costs¶
The gridpath.project.capacity.costs module is a project-level module that adds to the formulation components that describe the capacity-related costs of projects (e.g. investment capital costs and fixed O&M costs).
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
The following Pyomo model components are defined in this module:
Expressions
Capacity_Cost_in_Period
Defined Over:PRJ_OPR_PRDS
This expression describe each project’s capacity-related costs for each operational period, based on its capacity_type. For the purpose, call the capacity_cost_rule method from the respective capacity-type module. If the subproblem is less than a full year (e.g. in production- cost mode with 365 daily subproblems), the costs are scaled down proportionally.
gridpath.project.capacity.capacity_types¶
The gridpath.project.capacity.capacity_types package contains modules to describe the various ways in which project capacity can be treated in the optimization problem, e.g. as specified, available to be built, available to be retired, etc.
gridpath.project.capacity.capacity_types.gen_spec¶
The following Pyomo model components are defined in this module:
Sets |
---|
GEN_SPEC_OPR_PRDS Two-dimensional set of project-period combinations that describes the
project capacity available in a given period. This set is added to the
list of sets to join to get the final |
Required Input Params |
---|
gen_spec_capacity_mw Defined over:
GEN_SPEC_OPR_PRDS Within:
NonNegativeReals The project’s specified capacity (in MW) in each operational period. |
gen_spec_fixed_cost_per_mw_yr Defined over:
GEN_SPEC_OPR_PRDS Within:
NonNegativeReals The project’s fixed cost (in $ per MW-yr.) in each operational period. This cost will be added to the objective function but will not affect optimization decisions. |
gridpath.project.capacity.capacity_types.gen_new_lin¶
The following Pyomo model components are defined in this module:
Sets |
---|
GEN_NEW_LIN_VNTS A two-dimensional set of project-vintage combinations to describe the periods in time when project capacity can be built in the optimization. |
Required Input Params |
---|
gen_new_lin_operational_lifetime_yrs_by_vintage Defined over:
GEN_NEW_LIN_VNTS Within:
NonNegativeReals The project’s lifetime, i.e. how long project capacity of a particular vintage remains operational. |
gen_new_lin_fixed_cost_per_mw_yr Defined over:
GEN_NEW_LIN_VNTS Within:
NonNegativeReals The project’s fixed O&M cost incurred in each year in which the project is operational. |
gen_new_lin_financial_lifetime_yrs_by_vintage Defined over:
GEN_NEW_LIN_VNTS Within:
NonNegativeReals The project’s financial lifetime, i.e. how long project capacity of a particular incurs annualized capital costs. |
gen_new_lin_annualized_real_cost_per_mw_yr Defined over:
GEN_NEW_LIN_VNTS Within:
NonNegativeReals The project’s cost to build new capacity in annualized real dollars in per MW. |
Note
The cost input to the model is an annualized cost per unit capacity. This annualized cost is incurred in each period of the study (and multiplied by the number of years the period represents) for the duration of the project’s “financial” lifetime. It is up to the user to ensure that the variousl lifetime and cost parameters are consistent with one another and with the period length (projects are operational and incur capital costs only if the operational and financial lifetimes last through the end of a period respectively.
Derived Sets |
---|
OPR_PRDS_BY_GEN_NEW_LIN_VINTAGE Defined over:
GEN_NEW_LIN_VNTS Indexed set that describes the operational periods for each possible
project-vintage combination, based on the
|
GEN_NEW_LIN_OPR_PRDS Two-dimensional set that includes the periods when project capacity of
any vintage could be operational if built. This set is added to the
list of sets to join to get the final |
GEN_NEW_LIN_VNTS_OPR_IN_PERIOD Defined over:
PERIODS Indexed set that describes the project-vintages that could be
operational in each period based on the
|
FIN_PRDS_BY_GEN_NEW_LIN_VINTAGE Defined over:
GEN_NEW_LIN_VNTS Indexed set that describes the financial periods for each possible
project-vintage combination, based on the
|
GEN_NEW_LIN_FIN_PRDS Two-dimensional set that includes the periods when project capacity of
any vintage could be incurring costs if built. This set is added to
the list of sets to join to get the final |
GEN_NEW_LIN_VNTS_FIN_IN_PERIOD Defined over:
PERIODS Indexed set that describes the project-vintages that could be incurring
costs in each period based on the
|
Variables |
---|
GenNewLin_Build_MW Defined over:
GEN_NEW_LIN_VNTS Within:
NonNegativeReals Determines how much capacity of each possible vintage is built at each gen_new_lin project. |
Expressions |
---|
GenNewLin_Capacity_MW Defined over:
GEN_NEW_LIN_OPR_PRDS Within:
NonNegativeReals The capacity of a new-build generator in a given operational period is equal to the sum of all capacity-build of vintages operational in that period. |
Constraints |
---|
GenNewLin_Min_Cum_Build_Constraint Defined over:
GEN_NEW_LIN_VNTS_W_MIN_CONSTRAINT Ensures that certain amount of capacity is built by a certain period,
based on |
GenNewLin_Max_Cum_Build_Constraint Defined over:
GEN_NEW_LIN_VNTS_W_MAX_CONSTRAINT Limits the amount of capacity built by a certain period, based on
|
gridpath.project.capacity.capacity_types.gen_new_bin¶
The following Pyomo model components are defined in this module:
Sets |
---|
GEN_NEW_BIN Two-dimensional set of project-vintage combinations to describe all possible project-vintage combinations for projects with a cumulative minimum build capacity specified. |
GEN_NEW_BIN_VNTS A two-dimensional set of project-vintage combinations to describe the periods in time when project capacity can be built in the optimization. |
Required Input Params |
---|
gen_new_bin_operational_lifetime_yrs_by_vintage Defined over:
GEN_NEW_BIN_VNTS Within:
NonNegativeReals The project’s lifetime, i.e. how long project capacity of a particular vintage remains operational. |
gen_new_bin_fixed_cost_per_mw_yr Defined over:
GEN_NEW_BIN_VNTS Within:
NonNegativeReals The project’s fixed O&M cost incurred in each year in which the project is operational. |
gen_new_bin_financial_lifetime_yrs_by_vintage Defined over:
GEN_NEW_BIN_VNTS Within:
NonNegativeReals The project’s financial lifetime, i.e. how long project capacity of a particular incurs annualized capital costs. |
gen_new_bin_annualized_real_cost_per_mw_yr Defined over:
GEN_NEW_BIN_VNTS Within:
NonNegativeReals The project’s cost to build new capacity in annualized real dollars per MW. |
gen_new_bin_build_size_mw Defined over:
GEN_NEW_BIN Within:
NonNegativeReals The project’s specified build size in MW. The model can only build the project in this pre-specified size. |
Note
The cost input to the model is an annualized cost per unit capacity. This annualized cost is incurred in each period of the study (and multiplied by the number of years the period represents) for the duration of the project’s “financial” lifetime. It is up to the user to ensure that the variousl lifetime and cost parameters are consistent with one another and with the period length (projects are operational and incur capital costs only if the operational and financial lifetimes last through the end of a period respectively.
Derived Sets |
---|
OPR_PRDS_BY_GEN_NEW_BIN_VINTAGE Defined over:
GEN_NEW_BIN_VNTS Indexed set that describes the operational periods for each possible
project-vintage combination, based on the
|
GEN_NEW_BIN_OPR_PRDS Two-dimensional set that includes the periods when project capacity of
any vintage could be operational if built. This set is added to the
list of sets to join to get the final |
GEN_NEW_BIN_VNTS_OPR_IN_PERIOD Defined over:
PERIODS Indexed set that describes the project-vintages that could be
operational in each period based on the
|
GEN_NEW_BIN_FIN_PRDS Two-dimensional set that includes the periods when project capacity of
any vintage could be incurring annual capital costs if built. This
set is added to the list of sets to join to get the final
|
Variables |
---|
GenNewBin_Build Defined over:
GEN_NEW_BIN_VNTS Within:
Binary Binary build decision for each project-vintage combination (1=build). |
Constraints |
---|
GenNewBin_Only_Build_Once_Constraint Defined over:
GEN_NEW_BIN_OPR_PRDS Once a project is built, it cannot be built again in another vintage until its lifetime is expired. |
gridpath.project.capacity.capacity_types.gen_ret_lin¶
The following Pyomo model components are defined in this module:
Sets |
---|
GEN_RET_LIN The list of projects of the |
GEN_RET_LIN_OPR_PRDS Two-dimensional set of project-period combinations that helps describe
the project capacity available in a given period. This set is added to
the list of sets to join to get the final |
OPR_PRDS_BY_GEN_RET_LIN Indexed set that describes the operational periods for each
|
Required Input Params |
---|
gen_ret_lin_capacity_mw Defined over:
GEN_RET_LIN_OPR_PRDS Within:
NonNegativeReals The project’s specified capacity (in MW) in each operational period if no capacity is retired. |
gen_ret_lin_fixed_cost_per_mw_yr Defined over:
GEN_RET_LIN_OPR_PRDS Within:
NonNegativeReals The project’s fixed cost (in $ per MW-yr.) in each operational period. This cost can be avoided by retiring the generation project. |
Variables |
---|
GenRetLin_Retire_MW Defined over:
GEN_RET_LIN_OPR_PRDS The amount of capacity (in MW) to be retired for each project in each
operational period. Has to be larger than zero and smaller than
|
Constraints |
---|
GenRetLin_Retire_Forever_Constraint Defined over:
GEN_RET_LIN_OPR_PRDS Total capacity after retirement must be less than or equal what is was in the previous period. This ensures retirement decisions cannot be undone. |
gridpath.project.capacity.capacity_types.gen_ret_bin¶
The following Pyomo model components are defined in this module:
Sets |
---|
GEN_RET_BIN The list of projects of the |
GEN_RET_BIN_OPR_PRDS Two-dimensional set of project-period combinations that helps describe
the project capacity available in a given period. This set is added to
the list of sets to join to get the final |
OPR_PRDS_BY_GEN_RET_BIN Indexed set that describes the operational periods for each
|
Required Input Params |
---|
gen_ret_bin_capacity_mw Defined over:
GEN_RET_BIN_OPR_PRDS Within:
NonNegativeReals The project’s specified capacity (in MW) in each operational period if no capacity is retired. |
gen_ret_bin_fixed_cost_per_mw_yr Defined over:
GEN_RET_BIN_OPR_PRDS Within:
NonNegativeReals The project’s fixed cost (in $ per MW-yr.) in each operational period. This cost can be avoided by retiring the generation project. |
Variables |
---|
GenRetBin_Retire Defined over:
GEN_RET_BIN_OPR_PRDS Binary decision variable that specifies whether the project is to be retired in a given operational period or not (1 = retire). When retired, no capacity will be available in that period and all following periods, and any fixed costs will no longer be incurred. |
Constraints |
---|
GenRetBin_Retire_Forever_Constraint Defined over:
GEN_RET_BIN_OPR_PRDS The binary decision variable has to be less than or equal to the binary decision variable in the previous period. This will prevent capacity from coming back online after it has been retired. |
gridpath.project.capacity.capacity_types.stor_spec¶
The following Pyomo model components are defined in this module:
Sets |
---|
STOR_SPEC_OPR_PRDS Two-dimensional set of project-period combinations that helps describe
the project capacity available in a given period. This set is added to
the list of sets to join to get the final |
Required Input Params |
---|
stor_spec_power_capacity_mw Defined over:
STOR_SPEC_OPR_PRDS Within:
NonNegativeReals The storage project’s specified power capacity (in MW) in each operational period. |
stor_spec_energy_capacity_mwh Defined over:
STOR_SPEC_OPR_PRDS Within:
NonNegativeReals The storage project’s specified energy capacity (in MWh) in each operational period. |
stor_spec_fixed_cost_per_mw_yr Defined over:
STOR_SPEC_OPR_PRDS Within:
NonNegativeReals The storage project’s fixed cost for the power components (in $ per MW-yr.) in each operational period. This cost will be added to the objective function but will not affect optimization decisions. |
stor_spec_fixed_cost_per_stor_mwh_yr Defined over:
STOR_SPEC_OPR_PRDS Within:
NonNegativeReals The storage project’s fixed cost for the energy components (in $ per MWh-yr.) in each operational period. This cost will be added to the objective function but will not affect optimization decisions. |
gridpath.project.capacity.capacity_types.stor_new_lin¶
The following Pyomo model components are defined in this module:
Sets |
---|
STOR_NEW_LIN The list of projects of capacity type |
STOR_NEW_LIN_VNTS A two-dimensional set of project-vintage combinations to describe the periods in time when storage capacity/energy can be built in the optimization. |
STOR_NEW_LIN_VNTS_W_MIN_CAPACITY_CONSTRAINT Two-dimensional set of project-vintage combinations to describe all possible project-vintage combinations for projects with a cumulative minimum build capacity specified. |
STOR_NEW_LIN_VNTS_W_MIN_ENERGY_CONSTRAINT Two-dimensional set of project-vintage combinations to describe all possible project-vintage combinations for projects with a cumulative minimum build energy specified. |
STOR_NEW_LIN_VNTS_W_MAX_CAPACITY_CONSTRAINT Two-dimensional set of project-vintage combinations to describe all possible project-vintage combinations for projects with a cumulative maximum build capacity specified. |
STOR_NEW_LIN_VNTS_W_MAX_ENERGY_CONSTRAINT Two-dimensional set of project-vintage combinations to describe all possible project-vintage combinations for projects with a cumulative maximum build energy specified. |
Required Input Params |
---|
stor_new_lin_min_duration_hrs Defined over:
STOR_NEW_LIN Within:
NonNegativeReals The project’s minimum duration, i.e. ratio of MWh of energy capacity by MW of power capacity, in hours. |
stor_new_lin_max_duration_hrs Defined over:
STOR_NEW_LIN Within:
NonNegativeReals The project’s maximum duration, i.e. ratio of MWh of energy capacity by MW of power capacity, in hours. |
stor_new_lin_operational_lifetime_yrs Defined over:
STOR_NEW_LIN_VNTS Within:
NonNegativeReals The project’s lifetime, i.e. how long project capacity/energy of a particular vintage remains operational. |
stor_new_lin_fixed_cost_per_mw_yr Defined over:
STOR_NEW_LIN_VNTS Within:
NonNegativeReals The project’s power capacity fixed O&M cost incurred in each year in which the project is operational. |
stor_new_lin_fixed_cost_per_stor_mwh_yr Defined over:
STOR_NEW_LIN_VNTS Within:
NonNegativeReals The project’s energy capacity fixed O&M cost incurred in each year in which the project is operational. |
stor_new_lin_financial_lifetime_yrs_by_vintage Defined over:
STOR_NEW_LIN_VNTS Within:
NonNegativeReals The project’s financial lifetime, i.e. how long project capacity of a particular vintage incurs annualized capital costs. |
stor_new_lin_annualized_real_cost_per_mw_yr Defined over:
STOR_NEW_LIN_VNTS Within:
NonNegativeReals The project’s cost to build new power capacity in annualized real dollars in per MW. |
stor_new_lin_annualized_real_cost_per_stor_mwh_yr Defined over:
STOR_NEW_LIN_VNTS Within:
NonNegativeReals The project’s cost to build new energy capacity in annualized real dollars in per MW. |
Note
The cost input to the model is an annualized cost per unit capacity. This annualized cost is incurred in each period of the study (and multiplied by the number of years the period represents) for the duration of the project’s “financial” lifetime. It is up to the user to ensure that the variousl lifetime and cost parameters are consistent with one another and with the period length (projects are operational and incur capital costs only if the operational and financial lifetimes last through the end of a period respectively.
Derived Sets |
---|
OPR_PRDS_BY_STOR_NEW_LIN_VINTAGE Defined over:
STOR_NEW_LIN_VNTS Indexed set that describes the operational periods for each possible
project-vintage combination, based on the
|
STOR_NEW_LIN_OPR_PRDS Two-dimensional set that includes the periods when project capacity of
any vintage could be operational if built. This set is added to the
list of sets to join to get the final |
STOR_NEW_LIN_VNTS_OPR_IN_PRD Defined over:
PERIODS Indexed set that describes the project-vintages that could be
operational in each period based on the
|
Variables |
---|
StorNewLin_Build_MW Defined over:
STOR_NEW_LIN_VNTS Within:
NonNegativeReals Determines how much power capacity (in MW) of each possible vintage is built at each stor_new_lin project. |
StorNewLin_Build_MWh Defined over:
STOR_NEW_LIN_VNTS Within:
NonNegativeReals Determines how much energy capacity (in MWh) of each possible vintage
is built at each stor_new_lin project. Note that this is independent
from |
Expressions |
---|
StorNewLin_Power_Capacity_MW Defined over:
STOR_NEW_LIN_OPR_PRDS Within:
NonNegativeReals The power capacity of a new storage project (in MW) in a given operational period is equal to the sum of all capacity-build of vintages operational in that period. |
StorNewLin_Energy_Storage_Capacity_MWh Defined over:
STOR_NEW_LIN_OPR_PRDS Within:
NonNegativeReals The energy capacity of a new storage project (in MWh) in a given operational period is equal to the sum of all energy-build of vintages operational in that period. |
Constraints |
---|
StorNewLin_Min_Duration_Constraint Defined over:
STOR_NEW_LIN_OPR_PRDS Ensures that the storage duration is above a pre-specified requirement when building the project, preventing situations when energy capacity is built first with power capacity only following in a subsequent vintage. |
StorNewLin_Max_Duration_Constraint Defined over:
STOR_NEW_LIN_OPR_PRDS Ensures that the storage duration in each operational period is above a pre-specified requirement. |
gridpath.project.capacity.capacity_types.stor_new_bin¶
The following Pyomo model components are defined in this module:
Sets |
---|
STOR_NEW_BIN The list of projects of capacity type |
STOR_NEW_BIN_VNTS A two-dimensional set of project-vintage combinations to describe the periods in time when storage capacity/energy can be built in the optimization. |
Required Input Params |
---|
stor_new_bin_operational_lifetime_yrs Defined over:
STOR_NEW_BIN_VNTS Within:
NonNegativeReals The project’s lifetime, i.e. how long project capacity/energy of a particular vintage remains operational. |
stor_new_bin_fixed_cost_per_mw_yr Defined over:
STOR_NEW_BIN_VNTS Within:
NonNegativeReals The project’s power capacity fixed O&M cost incurred in each year in which the project is operational. |
stor_new_bin_fixed_cost_per_stor_mwh_yr Defined over:
STOR_NEW_BIN_VNTS Within:
NonNegativeReals The project’s energy capacity fixed O&M cost incurred in each year in which the project is operational. |
stor_new_bin_financial_lifetime_yrs_by_vintage Defined over:
STOR_NEW_BIN_VNTS Within:
NonNegativeReals The project’s financial lifetime, i.e. how long project capacity of a particular vintage incurs annualized capital costs. |
stor_new_bin_annualized_real_cost_per_mw_yr Defined over:
STOR_NEW_BIN_VNTS Within:
NonNegativeReals The project’s cost to build new power capacity in annualized real dollars in per MW. |
stor_new_bin_annualized_real_cost_per_stor_mwh_yr Defined over:
STOR_NEW_BIN_VNTS Within:
NonNegativeReals The project’s cost to build new energy capacity in annualized real dollars in per MW. |
stor_new_bin_build_size_mw Defined over:
STOR_NEW_BIN Within:
NonNegativeReals The project’s specified power capacity build size in MW. The model can only build the project in this pre-specified size. |
stor_new_bin_build_size_mwh Defined over:
STOR_NEW_BIN Within:
NonNegativeReals The project’s specified energy capacity build size in MWh. The model can only build the project in this pre-specified size. |
Note
The cost input to the model is an annualized cost per unit capacity. This annualized cost is incurred in each period of the study (and multiplied by the number of years the period represents) for the duration of the project’s “financial” lifetime. It is up to the user to ensure that the variousl lifetime and cost parameters are consistent with one another and with the period length (projects are operational and incur capital costs only if the operational and financial lifetimes last through the end of a period respectively.
Derived Sets |
---|
OPR_PRDS_BY_STOR_NEW_BIN_VINTAGE Defined over:
STOR_NEW_BIN_VNTS Indexed set that describes the operational periods for each possible
project-vintage combination, based on the
|
STOR_NEW_BIN_OPR_PRDS Two-dimensional set that includes the periods when project capacity of
any vintage could be operational if built. This set is added to the
list of sets to join to get the final |
STOR_NEW_BIN_VNTS_OPR_IN_PRD Defined over:
PERIODS Indexed set that describes the project-vintages that could be
operational in each period based on the
|
FIN_PRDS_BY_STOR_NEW_BIN_VINTAGE Defined over:
STOR_NEW_BIN_VNTS Indexed set that describes the financial periods for each possible
project-vintage combination, based on the
|
STOR_NEW_BIN_FIN_PRDS Two-dimensional set that includes the periods when project capacity of
any vintage could be incurring costs if built. This set is added to
the list of sets to join to get the final |
Variables |
---|
StorNewBin_Build Defined over:
STOR_NEW_BIN_VNTS Within:
Binary Binary build decision for each project-vintage combination (1=build). |
Constraints |
---|
StorNewBin_Only_Build_Once_Constraint Defined over:
STOR_NEW_BIN_OPR_PRDS Once a project is built, it cannot be built again in another vintage until its lifetime is expired. |
gridpath.project.capacity.capacity_types.gen_stor_hyb_spec¶
The following Pyomo model components are defined in this module:
Sets |
---|
GEN_STOR_HYB_SPEC_OPR_PRDS Two-dimensional set of project-period combinations that describes the
project capacity available in a given period. This set is added to the
list of sets to join to get the final |
Required Input Params |
---|
gen_stor_hyb_spec_capacity_mw Defined over:
GEN_STOR_HYB_SPEC_OPR_PRDS Within:
NonNegativeReals The project’s specified capacity (in MW) in each operational period. This is the grid-facing capacity, which can be different from the sizing of the internal generation and storage components of the hybrid project. |
gen_stor_hyb_spec_hyb_gen_capacity_mw Defined over:
GEN_STOR_HYB_SPEC_OPR_PRDS Within:
NonNegativeReals The specified capacity (in MW) of the project’s generator component in each operational period. |
gen_stor_hyb_spec_hyb_stor_capacity_mw Defined over:
GEN_STOR_HYB_SPEC_OPR_PRDS Within:
NonNegativeReals The specified capacity (in MW) of the project’s storage component in each operational period. |
gen_stor_hyb_spec_capacity_mwh Defined over:
GEN_STOR_HYB_SPEC_OPR_PRDS Within:
NonNegativeReals The specified energy capacity (in MWh) of the project’s storage component in each operational period. |
gen_stor_hyb_spec_fixed_cost_per_mw_yr Defined over:
GEN_STOR_HYB_SPEC_OPR_PRDS Within:
NonNegativeReals The project’s fixed cost (in $ per MW-yr.) in each operational period. This cost will be added to the objective function but will not affect optimization decisions. Costs for the generator, storage, and energy capacity components can be added separately. |
gen_stor_hyb_spec_hyb_gen_fixed_cost_per_mw_yr Defined over:
GEN_STOR_HYB_SPEC_OPR_PRDS Within:
NonNegativeReals The project’s fixed cost for its generator component (in $ per MW-yr.) in each operational period. This cost will be added to the objective function but will not affect optimization decisions. |
gen_stor_hyb_spec_hyb_stor_fixed_cost_per_mw_yr Defined over:
GEN_STOR_HYB_SPEC_OPR_PRDS Within:
NonNegativeReals The project’s fixed cost for its storage power component (in $ per MW-yr.) in each operational period. This cost will be added to the objective function but will not affect optimization decisions. |
gen_stor_hyb_spec_fixed_cost_per_stor_mwh_yr Defined over:
GEN_STOR_HYB_SPEC_OPR_PRDS Within:
NonNegativeReals The project’s fixed cost for its storage energy component (in $ per MWh-yr.) in each operational period. This cost will be added to the objective function but will not affect optimization decisions. |
gridpath.project.capacity.capacity_types.dr_new¶
The following Pyomo model components are defined in this module:
Sets |
---|
DR_NEW The list of |
DR_NEW_OPR_PRDS Two-dimensional set of all |
DR_NEW_FIN_PRDS Two-dimensional set of all |
DR_NEW_PTS Two-dimensional set of all |
Required Input Params |
---|
dr_new_min_duration Defined over:
DR_NEW Within:
NonNegativeReals The project’s duration in hours, i.e. how many hours the load can be shifted. |
dr_new_min_cumulative_new_build_mwh Defined over:
DR_NEW_OPR_PRDS Within:
NonNegativeReals The minimum cumulative amount of shiftable load capacity (in MWh) that must be built for a project by a certain period. |
dr_new_max_cumulative_new_build_mwh Defined over:
DR_NEW_OPR_PRDS Within:
NonNegativeReals The maximum cumulative amount of shiftable load capacity (in MWh) that must be built for a project by a certain period. |
dr_new_supply_curve_slope Defined over:
DR_NEW_PTS Within:
NonNegativeReals The project’s slope for each point (section) in the piecewise linear supply cost curve, in $ per MWh. |
dr_new_supply_curve_intercept Defined over:
DR_NEW_PTS Within:
NonNegativeReals The project’s intercept for each point (section) in the piecewise linear supply cost curve, in $. |
Variables |
---|
DRNew_Build_MWh Defined over:
DR_NEW_OPR_PRDS Within:
NonNegativeReals Determines how much shiftable load capacity (in MWh) is built in each operational period. |
DRNew_Cost Defined over:
DR_NEW_OPR_PRDS Within:
NonNegativeReals The cost of new shiftable load capacity in each operational period. |
Expressions |
---|
DRNew_Energy_Storage_Capacity_MWh Defined over:
DR_NEW_OPR_PRDS Within:
NonNegativeReals The project’s total energy capacity (in MWh) in each operational period is the sum of the new-built energy capacity in all of the previous periods. |
DRNew_Power_Capacity_MW Defined over:
DR_NEW_OPR_PRDS Within:
NonNegativeReals The project’s total power capacity (in MW) in each operational period is equal to the total energy capacity in that period, divided by the project’s minimum duraiton (in hours). |
Constraints |
---|
DRNew_Cost_Constraint Defined over:
DR_NEW_PTS*PERIODS Ensures that the project’s cost in each operational period is larger than the calculated piecewise linear cost in each segment. Only one segment will bind at a time. |
Project Availability¶
gridpath.project.availability.availability¶
gridpath.project.availability.availability_types.exogenous¶
The following Pyomo model components are defined in this module:
Sets |
---|
AVL_EXOG The set of projects of the |
AVL_EXOG_OPR_TMPS Two-dimensional set with projects of the |
Optional Input Params |
---|
avl_exog_cap_derate_independent Defined over:
AVL_EXOG_OPR_TMPS Within:
NonNegativeReals Default:
1 The pre-specified availability derate (e.g. for maintenance/planned outages) that does not depend on weather. Defaults to 1 if not specified. Availaibility can also be more than 1. |
avl_exog_cap_derate_weather Defined over:
AVL_EXOG_OPR_TMPS Within:
NonNegativeReals Default:
1 The pre-specified availability derate (e.g. for maintenance/planned outages) that depends on weather. Defaults to 1 if not specified. Availaibility can also be more than 1. |
gridpath.project.availability.availability_types.binary¶
The following Pyomo model components are defined in this module:
Sets |
---|
AVL_BIN The set of projects of the |
AVL_BIN_OPR_PRDS Two-dimensional set with projects of the |
AVL_BIN_OPR_TMPS Two-dimensional set with projects of the |
Required Input Params |
---|
avl_bin_unavl_hrs_per_prd Defined over:
AVL_BIN Within:
NonNegativeReals The number of hours the project must be unavailable per period. |
avl_bin_unavl_hrs_per_prd_req_exact Defined over:
AVL_BIN Within:
Boolean Require exactly the number of hours the project must be unavailable per period. If set to 0, the constraint is soft. |
avl_bin_min_unavl_hrs_per_event Defined over:
AVL_BIN Within:
NonNegativeReals The minimum number of hours an unavailability event should last for. |
avl_bin_min_avl_hrs_between_events Defined over:
AVL_BIN Within:
NonNegativeReals The minimum number of hours a project should be available between unavailability events. |
Variables |
---|
AvlBin_Unavailable Defined over:
AVL_BIN_OPR_TMPS Within:
Binary Binary decision variable that specifies whether the project is unavailable or not in each operational timepoint (1=unavailable). |
AvlBin_Start_Unavailability Defined over:
AVL_BIN_OPR_TMPS Within:
Binary Binary decision variable that designates the start of an unavailability event (when the project goes from available to unavailable. |
AvlBin_Stop_Unavailability Defined over:
AVL_BIN_OPR_TMPS Within:
Binary Binary decision variable that designates the end of an unavailability event (when the project goes from unavailable to available. |
Constraints |
---|
AvlBin_Tot_Sched_Unavl_per_Prd_Constraint Defined over:
AVL_BIN_OPR_PRDS The project must be unavailable for |
AvlBin_Unavl_Start_and_Stop_Constraint Defined over:
AVL_BIN_OPR_TMPS Link the three binary variables in each timepoint such that
|
AvlBin_Min_Event_Duration_Constraint Defined over:
AVL_BIN_OPR_TMPS The duration of each unavailability event should be larger than or
equal to |
AvlBin_Min_Time_Between_Events_Constraint Defined over:
AVL_BIN_OPR_TMPS The time between unavailability events should be larger than or equal
to |
gridpath.project.availability.availability_types.continuous¶
The following Pyomo model components are defined in this module:
Sets |
---|
AVL_CONT The set of projects of the |
AVL_CONT_OPR_PRDS Two-dimensional set with projects of the |
AVL_CONT_OPR_TMPS Two-dimensional set with projects of the |
Required Input Params |
---|
avl_cont_unavl_hrs_per_prd Defined over:
AVL_CONT Within:
NonNegativeReals The number of hours the project must be unavailable per period. |
avl_cont_unavl_hrs_per_prd_req_exact Defined over:
AVL_BIN Within:
Boolean Require exactly the number of hours the project must be unavailable per period. If set to 0, the constraint is soft. |
avl_cont_min_unavl_hrs_per_event Defined over:
AVL_CONT Within:
NonNegativeReals The minimum number of hours an unavailability event should last for. |
avl_cont_min_avl_hrs_between_events Defined over:
AVL_CONT Within:
NonNegativeReals The minimum number of hours a project should be available between unavailability events. |
Variables |
---|
AvlCont_Unavailable Defined over:
AVL_CONT_OPR_TMPS Within:
PercentFraction Continuous decision variable that specifies whteher the project is unavailable or not in each operational timepoint (1=unavailable). |
AvlCont_Start_Unavailability Defined over:
AVL_CONT_OPR_TMPS Within:
PercentFraction Continuous decision variable that designates the start of an unavailability event (when the project goes from available to unavailable. |
AvlCont_Stop_Unavailability Defined over:
AVL_CONT_OPR_TMPS Within:
PercentFraction Continuous decision variable that designates the end of an unavailability event (when the project goes from unavailable to available. |
Constraints |
---|
AvlCont_Tot_Sched_Unavl_per_Prd_Constraint Defined over:
AVL_CONT_OPR_PRDS The project must be unavailable for |
AvlCont_Unavl_Start_and_Stop_Constraint Defined over:
AVL_CONT_OPR_TMPS Link the three continuous variables in each timepoint such that
|
AvlCont_Min_Event_Duration_Constraint Defined over:
AVL_CONT_OPR_TMPS The duration of each unavailability event should be larger than or
equal to |
AvlCont_Min_Time_Between_Events_Constraint Defined over:
AVL_CONT_OPR_TMPS The time between unavailability events should be larger than or equal
to |
Project Operations¶
gridpath.project.operations¶
The gridpath.project.operations package contains modules to describe the operational capabilities, constraints, and costs of generation, storage, and demand-side infrastructure ‘projects’ in the optimization problem.
In this package, we also create the project fuel burn and cost components to be passed downstream for aggregation into the system-level constraints and the objective function.
In the __init__ module of the package, we specify fuel burn and cost parameters for each project. The project’s operational type uses these parameters to determine the projects will incur fuel burn and cost in each operational timepoint. All parameters are optional, i.e. each type can be used without fuel or variable cost for example. Conversely, the user needs to ensure that the specified functionality makes sense for the project’s operational type, e.g. even if startup costs are specified for a gen_var project, that operational type uses the default method for startup costs, which returns 0, as variable generators do not have the concept of startup (see the documentation in operational_types.__init__ for the defaults and in each individual operational type module). When incompatible parameters are specified for an operational type, GridPath will flag a validation error and throw a warning (but not an error) at runtime.
gridpath.project.operations.power¶
The gridpath.project.capacity.capacity module is a project-level module that adds to the formulation components that describe the amount of power that a project is providing in each study timepoint.
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
The following Pyomo model components are defined in this module:
Expressions
Power_Provision_MW
Defined over:PRJ_OPR_TMPS
Defines the power a project is producing in each of its operational timepoints. The exact formulation of the expression depends on the project’s operational_type. For each project, we call its capacity_type module’s power_provision_rule method in order to formulate the expression. E.g. a project of the gen_must_run operational_type will be producing power equal to its capacity while a dispatchable project will have a variable in its power provision expression. This expression will then be used by other modules.
gridpath.project.operations.costs¶
The gridpath.project.operations.costs module is a project-level module that adds to the formulation components that describe the operations-related costs of projects (e.g. variable O&M costs, fuel costs, startup and shutdown costs).
For the purpose, this module calls the respective method from the operational type modules.
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
The following Pyomo model components are defined in this module:
Sets
VAR_OM_COST_SIMPLE_PRJ_OPR_TMPS
Within:PRJ_OPR_TMPS
The two-dimensional set of projects for which a simple variable O&M cost is specified and their operational timepoints.
VAR_OM_COST_CURVE_PRJS_OPR_TMPS_SGMS
The three-dimensional set of projects for which a VOM cost curve is specified along with the VOM curve segments and the project operational timepoints.
VAR_OM_COST_CURVE_PRJS_OPR_TMPS
Within:PRJ_OPR_TMPS
The two-dimensional set of projects for which a VOM cost curve is specified along with their operational timepoints.
VAR_OM_COST_ALL_PRJS_OPR_TMPS
Within:PRJ_OPR_TMPS
The two-dimensional set of projects for which either or both a simple VOM or a VOM curve is specified along with their operational timepoints.
STARTUP_COST_PRJ_OPR_TMPS
Within:PRJ_OPR_TMPS
The two-dimensional set of projects for which a startup cost is specified along with their operational timepoints.
SHUTDOWN_COST_PRJ_OPR_TMPS
Within:PRJ_OPR_TMPS
The two-dimensional set of projects for which a shutdown cost curve is specified along with their operational timepoints.
VIOL_ALL_PRJ_OPR_TMPS
Within:PRJ_OPR_TMPS
The two-dimensional set of projects for which an operational constraint can be violated along with their operational timepoints.
CURTAILMENT_COST_PRJ_OPR_TMPS
Within:PRJ_OPR_TMPS
The two-dimensional set of projects for which an curtailment costs are incurred along with their operational timepoints.
Variables
Variable_OM_Curve_Cost
Defined over:VAR_OM_COST_CURVE_PRJS_OPR_TMPS
Within:NonNegativeReals
Variable cost in each operational timepoint of projects with a VOM cost curve.
Constraints
Variable_OM_Curve_Constraint
Defined over:VAR_OM_COST_CURVE_PRJS_OPR_TMPS_SGMS
Determines variable cost from the project in each timepoint based on its VOM curve.
Expressions
Variable_OM_Cost
Defined over:VAR_OM_COST_ALL_PRJS_OPR_TMPS
This is the variable cost incurred in each operational timepoints for projects for which either a simple VOM or a VOM curve is specified. If both are specified, the two are additive. We obtain the simple VOM by calling the variable_om_cost_rule method of a project’s operational_type module. We obtain the VOM curve cost by calling the variable_om_cost_by_ll_rule method of a project’s operational type, using that to create the Variable_OM_Curve_Constraint on the Variable_OM_Curve_Cost variable, and the using the variable in this expression.
Fuel_Cost
Defined over:FUEL_PRJ_OPR_TMPS
This expression defines the fuel cost of a project in all of its operational timepoints by summing across fuel burn by fuel times each fuel’s price.
Startup_Cost
Defined over:STARTUP_COST_PRJ_OPR_TMPS
This expression defines the startup cost of a project in all of its operational timepoints. We obtain the expression by calling the startup_cost_rule method of a project’s operational_type module.
Shutdown_Cost
Defined over:SHUTDOWN_COST_PRJ_OPR_TMPS
This expression defines the shutdown cost of a project in all of its operational timepoints. We obtain the expression by calling the shutdown_cost_rule method of a project’s operational_type module.
Operational_Violation_Cost
Defined over:VIOL_ALL_PRJ_OPR_TMPS
This expression defines the operational constraint violation cost of a project in all of its operational timepoints. We obtain the expression by calling the operational_violation_cost_rule method of a project’s operational_type module.
Curtailment_Cost
Defined over:CURTAILMENT_COST_PRJ_OPR_TMPS
This expression defines the curtailment cost of a project in all of its operational timepoints. We obtain the expression by calling the curtailment_cost_rule method of a project’s operational_type module.
gridpath.project.operations.carbon_emissions¶
Carbon emissions from each carbonaceous project.
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
The following Pyomo model components are defined in this module:
Expressions
Project_Carbon_Emissions
Defined over:FUEL_PRJ_OPR_TMPS
The project’s carbon emissions for each timepoint in which the project could be operational. Note that this is an emissions RATE (per hour) and should be multiplied by the timepoint duration and timepoint weight to get the total emissions amount during that timepoint.
gridpath.project.operations.carbon_tax¶
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
The following Pyomo model components are defined in this module:
Sets
CARBON_TAX_PRJS
Within:PROJECTS
Two set of carbonaceous projects we need to track for the carbon tax.
Required Input Params
carbon_tax_zone
Defined over:CARBON_TAX_PRJS
Within:CARBON_TAX_ZONES
This param describes the carbon tax zone for each carbon tax project.
carbon_tax_allowance
Defined over:CARBON_TAX_PRJS
, FUEL_GROUPS, PERIODSWithin:NonNegativeReals
This param describes the carbon tax allowance for each carbon tax project and fuel group.
carbon_tax_allowance_average_heat_rate
Defined over:CARBON_TAX_PRJS
, PERIODSWithin:PositiveReals
This param describes the average heat rate for each carbon tax project used to calculate the carbon tax allowance.
Derived Sets
CARBON_TAX_PRJS_BY_CARBON_TAX_ZONE
Defined over:CARBON_TAX_ZONES
Within:CARBON_TAX_PRJS
Indexed set that describes the list of carbonaceous projects for each carbon tax zone.
CARBON_TAX_PRJ_OPR_TMPS
Within:PRJ_OPR_TMPS
Two-dimensional set that defines all project-timepoint combinations when a carbon tax project can be operational.
CARBON_TAX_PRJ_OPR_PRDS
Within:PRJ_OPR_PRDS
Two-dimensional set that defines all project-period combinations when a carbon tax project can be operational.
CARBON_TAX_PRJ_FUEL_GROUP_OPR_TMPS
Two-dimensional set that defines all project-fuel_group-timepoint combinations when a carbon tax project can be operational.
CARBON_TAX_PRJ_FUEL_GROUP_OPR_PRDS
Two-dimensional set that defines all project-fuel_group-period combinations when a carbon tax project can be operational.
gridpath.project.operations.fuel_burn¶
This module keeps track of fuel burn for each project. Fuel burn consists of both operational fuel burn for power production, and startup fuel burn (if applicable).
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
The following Pyomo model components are defined in this module:
Sets
FUEL_PRJ_OPR_TMPS
Within:PRJ_OPR_TMPS
The two-dimensional set of projects for which a fuel is specified and their operational timepoints.
HR_CURVE_PRJS_OPR_TMPS_SGMS
The three-dimensional set of projects for which a heat rate curve is specified along with the heat rate curve segments and the project operational timepoints.
HR_CURVE_PRJS_OPR_TMPS
Within:PRJ_OPR_TMPS
The two-dimensional set of projects for which a heat rate curve is specified along with their operational timepoints.
STARTUP_FUEL_PRJ_OPR_TMPS
Within:FUEL_PRJ_OPR_TMPS
The two-dimensional set of projects for which startup fuel burn is specified and their operational timepoints.
Variables
HR_Curve_Prj_Fuel_Burn
Defined over:HR_CURVE_PRJS_OPR_TMPS
Within:NonNegativeReals
Fuel burn in each operational timepoint of projects with a heat rate curve.
Project_Opr_Fuel_Burn_by_Fuel
Defined over:FUEL_PRJS_FUEL_OPR_TMPS
Within:NonNegativeReals
Fuel burn by fuel in each operational timepoint of each fuel project.
Project_Startup_Fuel_Burn_by_Fuel
Defined over:FUEL_PRJS_FUEL_OPR_TMPS
Within:NonNegativeReals
Startup fuel burn by fuel in each operational timepoint of each startup fuel project.
Expressions
Operations_Fuel_Burn_MMBtu
Within:PRJ_OPR_TMPS
This expression describes each project’s operational fuel consumption (in MMBtu) in all operational timepoints. We obtain it by calling the fuel_burn_rule method in the relevant operational_type. This does not include fuel burn for startups, which has a separate expression.
Startup_Fuel_Burn_MMBtu
Within:PRJ_OPR_TMPS
This expression describes each project’s startup fuel consumption (in MMBtu) in all operational timepoints. We obtain it by calling the startup_fuel_burn_rule method in the relevant operational_type. Only operational types with commitment variables can have startup fuel burn (for others it will always return zero).
Total_Fuel_Burn_by_Fuel_MMBtu
Within:PRJ_OPR_TMPS
Total fuel burn is the sum of operational fuel burn for power production and startup fuel burn (by fuel).
Constraints
HR_Curve_Prj_Fuel_Burn_Constraint
Defined over:HR_CURVE_PRJS_OPR_TMPS_SGMS
Determines fuel burn from the project in each timepoint based on its heat rate curve.
Fuel_Blending_Opr_Fuel_Burn_Constraint
Defined over:FUEL_PRJ_OPR_TMPS
The sum of operations fuel burn across all fuels should equal the total operations fuel burn.
Fuel_Blending_Startup_Fuel_Burn_Constraint
Defined over:STARTUP_FUEL_PRJ_OPR_TMPS
The sum of startup fuel burn across all fuels should equal the total operations fuel burn.
gridpath.project.operations.cycle_select¶
The gridpath.project.operations.cycle_select module is a project-level module that adds to the formulation components that describe cycle selection constraints, i.e. mutually exclusive syncing of projects. An example might be a plant that can be operated in either simple cycle or combined cycle mode. This plant would be described by multiple projects with mutually exclusive Sync variables, i.e. only one of the projects can be synced at any time.
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
The tables below list the Pyomo model components defined in the ‘gen_commit_bin’ module followed below by the respective components defined in the ‘gen_commit_lin” module.
Sets
GEN_W_CYCLE_SELECT
Within:GEN_COMMIT_BINLIN
Projects that have “cycle select” constraints.
GEN_CYCLE_SELECT_BY_GEN
Defined over:GEN_W_CYCLE_SELECT
Within:GEN_COMMIT_BINLIN
Indexed set that describes each project’s list of “cycle select” – projects that cannot be ‘synced’ when this project is synced, e.g. when choosing simple-cycle vs. combined cycle operational model.
GEN_W_GEN_CYCLE_SELECT_OPR_TMPS
Three-dimensional set with generators of the respective operational type, their “cycle select” projects, and their their operational timepoints. Note that projects that don’t have “cycle select” projects are not included in this set.
Constraints
Gen_Commit_BinLin_Select_Cycle_Constraint
Defined over:GEN_W_GEN_CYCLE_SELECT_OPR_TMPS
This generator can only be synced if the “cycle select” generator is not synced (the sum of the Sync variables of the two must be less than or equal to 1.
gridpath.project.operations.supplemental_firing¶
The gridpath.project.operations.cycle_select module is a project-level module that adds to the formulation components that describe cycle selection constraints, i.e. mutually exclusive syncing of projects. An example might be a plant that can be operated in either simple cycle or combined cycle mode. This plant would be described by multiple projects with mutually exclusive Sync variables, i.e. only one of the projects can be synced at any time.
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
The tables below list the Pyomo model components defined in the ‘gen_commit_bin’ module followed below by the respective components defined in the ‘gen_commit_lin” module.
Sets
GEN_W_SUPPLEMENTAL_FIRING
Within:GEN_COMMIT_BINLIN
Projects that have “cycle select” constraints.
GEN_SUPPLEMENTAL_FIRING_BY_GEN
Defined over:GEN_W_SUPPLEMENTAL_FIRING
Within:GEN_COMMIT_BINLIN
Indexed set that describes each project’s list of “cycle select” – projects that cannot be ‘synced’ when this project is synced, e.g. when choosing simple-cycle vs. combined cycle operational model.
GEN_W_GEN_SUPPLEMENTAL_FIRING_OPR_TMPS
Three-dimensional set with generators of the respective operational type, their “supplemental firing” projects, and their their operational timepoints. Note that projects that don’t have “supplemental firing” projects are not included in this set.
Constraints
Gen_Commit_BinLin_Select_Cycle_Constraint
Defined over:GEN_W_GEN_SUPPLEMENTAL_FIRING_OPR_TMPS
This generator can only be synced if the “cycle select” generator is not synced (the sum of the Sync variables of the two must be less than or equal to 1.
gridpath.project.operations.energy_target_contributions¶
Get RECs for each project
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
The following Pyomo model components are defined in this module:
Sets
ENERGY_TARGET_PRJS
Within:PROJECTS
The set of all energy-target-eligible projects.
ENERGY_TARGET_PRJ_OPR_TMPS
Two-dimensional set that defines all project-timepoint combinations when an energy-target-elgible project can be operational.
ENERGY_TARGET_PRJS_BY_ENERGY_TARGET_ZONE
Defined over:ENERGY_TARGET_ZONES
Within:ENERGY_TARGET_PRJS
Indexed set that describes the energy-target projects for each energy-target zone.
Input Params
energy_target_zone
Defined over:ENERGY_TARGET_PRJS
Within:ENERGY_TARGET_ZONES
This param describes the energy-target zone for each energy-target project.
Expressions
Scheduled_Energy_Target_Energy_MW
Defined over:ENERGY_TARGET_PRJ_OPR_TMPS
Describes how many RECs (in MW) are scheduled for each energy-target-eligible project in each timepoint.
Scheduled_Curtailment_MW
Defined over:ENERGY_TARGET_PRJ_OPR_TMPS
Describes the amount of scheduled curtailment (in MW) for each energy-target-eligible project in each timepoint.
Subhourly_Energy_Target_Energy_MW
Defined over:ENERGY_TARGET_PRJ_OPR_TMPS
Describes how many RECs (in MW) are delivered subhourly for each energy-target-eligible project in each timepoint. Subhourly energy-target energy delivery can occur due to sub-hourly upward reserve dispatch (e.g. reg-up).
Subhourly_Curtailment_MW
Defined over:ENERGY_TARGET_PRJ_OPR_TMPS
Describes the amount of subhourly curtailment (in MW) for each energy-target-eligible project in each timepoint. Subhourly curtailment can occur due to sub-hourly downward reserve dispatch (e.g. reg-down).
gridpath.project.operations.performance_standard¶
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
The following Pyomo model components are defined in this module:
Sets
PERFORMANCE_STANDARD_PRJS_PERFORMANCE_STANDARD_ZONES
Within:m.PROJECTS * m.PERFORMANCE_STANDARD_ZONES
set of projects we need to track for the performance standard. Two-dimensional set of performance standard projects and the performance standard zones they contribute to. Projects can contribute to multiple performance standard zones.
Derived Sets
PERFORMANCE_STANDARD_PRJS
Within:PROJECTS
Two set of performance standard projects we need to track for the performance standard.
PERFORMANCE_STANDARD_PRJS_BY_PERFORMANCE_STANDARD_ZONE
Defined over:PERFORMANCE_STANDARD_ZONES
Within:PERFORMANCE_STANDARD_PRJS
Indexed set that describes the list of performance standard projects for each performance standard zone.
PERFORMANCE_STANDARD_OPR_TMPS
Within:PRJ_OPR_TMPS
Two-dimensional set that defines all project-timepoint combinations when a performance standard project can be operational.
PERFORMANCE_STANDARD_OPR_PRDS
Within:PRJ_OPR_PRDS
Two-dimensional set that defines all project-period combinations when a performance standard project can be operational.
gridpath.project.operations.cap_factor_limits¶
The gridpath.project.operations.cap_factor_limits module is a project-level module that adds to the formulation components that limit the minimum and maximum cap factor of a project over a horizon.
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
The tables below list the Pyomo model components defined in the ‘gen_commit_bin’ module followed below by the respective components defined in the ‘gen_commit_lin” module.
Sets
CAP_FACTOR_LIMIT_PRJ_BT_HRZ
Within:PROJECTS*BLN_TYPE_HRZS
Three-dimensional set with the project, horizon balancing type, and horizon over which cap factor limits should be enforced.
Input Params
min_cap_factor
Defined over:CAP_FACTOR_LIMIT_PRJ_BT_HRZ
Within:Reals
Default:Negative_Infinity
The project’s minimum cap factor for this horizon balancing type and horizon. It can be negative to allow us to limit storage (which is a net load over the course of the horizon due to losses.
max_cap_factor
Defined over:CAP_FACTOR_LIMIT_PRJ_BT_HRZ
Within:Reals
Default:Infinity
The project’s maximum cap factor for this horizon balancing type and horizon. It can be negative to allow us to limit storage (which is a net load over the course of the horizon due to losses.
Constraints
Min_Cap_Factor_Constraint
Defined over:CAP_FACTOR_LIMIT_PRJ_BT_HRZ
Energy output from this project over this balancing type and horizon must equal or exceed the minimum capacity factor multiplied by the maximum possible output over this balancing type and horizon.
Max_Cap_Factor_Constraint
Defined over:CAP_FACTOR_LIMIT_PRJ_BT_HRZ
Energy output from this project over this balancing type and horizon must be less than or equal to the maximum capacity factor multiplied by the maximum possible output over this balancing type and horizon.
gridpath.project.operations.tuning_costs¶
Operational tuning costs that prevent erratic dispatch in case of degeneracy. Tuning costs can be applied to hydro up and down ramps (gen_hydro and gen_hydro_must_take operational types) and to storage up-ramps ( stor operational type) in order to force smoother dispatch.
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
The following Pyomo model components are defined in this module:
Input Params
ramp_tuning_cost_per_mw
Default:0
The tuning cost for ramping in $ per MW of ramp. The cost is the same for upward and downward ramping.
Variables
Ramp_Up_Tuning_Cost
Defined over:PRJ_OPR_TMPS
Within:NonNegativeReals
This variable represents the total upward ramping tuning cost for each project in each operational timepoint.
Ramp_Up_Tuning_Cost
Defined over:PRJ_OPR_TMPS
Within:NonNegativeReals
This variable represents the total downwward ramping tuning cost for each project in each operational timepoint.
Expressions
Ramp_Expression
Defined over:PRJ_OPR_TMPS
This expression pulls the ramping expression from the appropriate operational type module. It represents the difference in power output (in MW) between 2 timepoints; i.e. a positive number means upward ramp and a negative number means downward ramp. For simplicity, we only look at the difference in power setpoints, i.e. ignore the effect of providing any reserves.
Constraints
Ramp_Up_Tuning_Cost_Constraint
Defined over:PRJ_OPR_TMPS
Sets the upward ramping tuning cost to be equal to the ramp expression times the tuning cost (for the appropriate operational types only).
Ramp_Down_Tuning_Cost_Constraint
Defined over:PRJ_OPR_TMPS
Sets the downward ramping tuning cost to be equal to the ramp expression times the tuning cost (for the appropriate operational types only).
gridpath.project.capacity.operational_types.gen_simple¶
The following Pyomo model components are defined in this module:
Sets |
---|
GEN_SIMPLE The set of generators of the |
GEN_SIMPLE_OPR_TMPS Two-dimensional set with generators of the |
GEN_SIMPLE_LINKED_TMPS Two-dimensional set with generators of the |
Optional Input Params |
---|
gen_simple_ramp_up_when_on_rate Defined over:
GEN_SIMPLE Within:
PercentFraction Default:
1 The project’s upward ramp rate limit during operations, defined as a fraction of its capacity per minute. |
gen_simple_ramp_down_when_on_rate Defined over:
GEN_SIMPLE Within:
PercentFraction Default:
1 The project’s downward ramp rate limit during operations, defined as a fraction of its capacity per minute. |
Linked Input Params |
---|
gen_simple_linked_power Defined over:
GEN_SIMPLE_LINKED_TMPS Within:
NonNegativeReals The project’s power provision in the linked timepoints. |
gen_simple_linked_upwards_reserves Defined over:
GEN_SIMPLE_LINKED_TMPS Within:
NonNegativeReals The project’s upward reserve provision in the linked timepoints. |
gen_simple_linked_downwards_reserves Defined over:
GEN_SIMPLE_LINKED_TMPS Within:
NonNegativeReals The project’s downward reserve provision in the linked timepoints. |
Variables |
---|
GenSimple_Provide_Power_MW Defined over:
GEN_SIMPLE_OPR_TMPS Within:
NonNegativeReals Power provision in MW from this project in each timepoint in which the project is operational (capacity exists and the project is available). |
Constraints |
---|
Power |
GenSimple_Max_Power_Constraint Defined over:
GEN_SIMPLE_OPR_TMPS Limits the power plus upward reserves to the available capacity. |
GenSimple_Min_Power_Constraint Defined over:
GEN_SIMPLE_OPR_TMPS Power provision minus downward reserves should exceed the minimum stable level for the project. |
Ramps |
GenSimple_Ramp_Up_Constraint Defined over:
GEN_SIMPLE_OPR_TMPS Limits the allowed project upward ramp based on the
|
GenSimple_Ramp_Down_Constraint Defined over:
GEN_SIMPLE_OPR_TMPS Limits the allowed project downward ramp based on the
|
gridpath.project.capacity.operational_types.gen_must_run¶
The following Pyomo model components are defined in this module:
Sets |
---|
GEN_MUST_RUN The set of generators of the |
GEN_MUST_RUN_OPR_TMPS Two-dimensional set with generators of the |
Optional Input Params |
---|
gen_must_run_aux_consumption_frac_capacity Defined over:
GEN_MUST_RUN Within:
PercentFraction Default:
0 Auxiliary consumption as a fraction of capacity. This would be incurred all timepoints when capacity is available. |
Constraints |
---|
GenMustRun_No_Upward_Reserves_Constraint Defined over:
GEN_MUST_RUN_OPR_TMPS Must-run projects cannot provide upward reserves. |
GenMustRun_No_Downward_Reserves_Constraint Defined over:
GEN_MUST_RUN_OPR_TMPS Must-run projects cannot provide downward reserves. |
gridpath.project.capacity.operational_types.gen_always_on¶
The following Pyomo model components are defined in this module:
Sets |
---|
GEN_ALWAYS_ON The set of generators of the |
GEN_ALWAYS_ON_OPR_TMPS Two-dimensional set with generators of the |
GEN_ALWAYS_ON_LINKED_TMPS Two-dimensional set with generators of the |
Required Input Params |
---|
gen_always_on_unit_size_mw Defined over:
GEN_ALWAYS_ON Within:
NonNegativeReals The MW size of a unit in this project (projects of the
|
gen_always_on_min_stable_level_fraction Defined over:
GEN_ALWAYS_ON Within:
PercentFraction The minimum stable level of this project as a fraction of its capacity. This can also be interpreted as the minimum stable level of a unit within this project (as the project itself can represent multiple units with similar characteristics. |
Optional Input Params |
---|
gen_always_on_ramp_up_when_on_rate Defined over:
GEN_ALWAYS_ON Within:
PercentFraction Default:
1 The project’s upward ramp rate limit during operations, defined as a fraction of its capacity per minute. |
gen_always_on_ramp_down_when_on_rate Defined over:
GEN_ALWAYS_ON Within:
PercentFraction Default:
1 The project’s downward ramp rate limit during operations, defined as a fraction of its capacity per minute. |
gen_always_on_aux_consumption_frac_capacity Defined over:
GEN_ALWAYS_ON Within:
PercentFraction Default:
0 Auxiliary consumption as a fraction of capacity. This would be incurred in all timepoints when capacity is available. |
gen_always_on_aux_consumption_frac_power Defined over:
GEN_ALWAYS_ON Within:
PercentFraction Default:
0 Auxiliary consumption as a fraction of gross power output. |
Linked Input Params |
---|
gen_always_on_linked_power Defined over:
GEN_ALWAYS_ON_LINKED_TMPS Within:
NonNegativeReals The project’s power provision in the linked timepoints. |
gen_always_on_linked_upwards_reserves Defined over:
GEN_ALWAYS_ON_LINKED_TMPS Within:
NonNegativeReals The project’s upward reserve provision in the linked timepoints. |
gen_always_on_linked_downwards_reserves Defined over:
GEN_ALWAYS_ON_LINKED_TMPS Within:
NonNegativeReals The project’s downward reserve provision in the linked timepoints. |
Variables |
---|
GenAlwaysOn_Gross_Power_MW Defined over:
GEN_ALWAYS_ON_OPR_TMPS Within:
NonNegativeReals Power provision in MW from this project in each timepoint in which the project is operational (capacity exists and the project is available). |
Expressions |
---|
GenAlwaysOn_Auxiliary_Consumption_MW Defined over:
GEN_ALWAYS_ON_OPR_TMPS The project’s auxiliary consumption (power consumed on-site and not sent to the grid) in each timepoint. |
Constraints |
---|
Power |
GenAlwaysOn_Max_Power_Constraint Defined over:
GEN_ALWAYS_ON_OPR_TMPS Limits the power plus upward reserves to the available capacity. |
GenAlwaysOn_Min_Power_Constraint Defined over:
GEN_ALWAYS_ON_OPR_TMPS Power provision minus downward reserves should exceed the minimum stable level for the project. |
Ramps |
GenAlwaysOn_Ramp_Up_Constraint Defined over:
GEN_ALWAYS_ON_OPR_TMPS Limits the allowed project upward ramp based on the
|
GenAlwaysOn_Ramp_Down_Constraint Defined over:
GEN_ALWAYS_ON_OPR_TMPS Limits the allowed project downward ramp based on the
|
gridpath.project.capacity.operational_types.gen_commit_bin¶
See the formulation documentation in the gen_commit_unit_common.add_model_components().
gridpath.project.capacity.operational_types.gen_commit_lin¶
See the formulation documentation in the gen_commit_unit_common.add_model_components().
gridpath.project.capacity.operational_types.gen_commit_unit_common¶
The tables below list the Pyomo model components defined in the ‘gen_commit_bin’ module followed below by the respective components defined in the ‘gen_commit_lin” module.
Sets |
---|
GEN_COMMIT_BIN GEN_COMMIT_LIN The set of generators of the |
GEN_COMMIT_BIN_STARTUP_BY_ST_PRJS within:
GEN_COMMIT_BIN GEN_COMMIT_LIN_STARTUP_BY_ST_PRJS within:
GEN_COMMIT_LIN The set of generators of the |
GEN_COMMIT_BIN_STARTUP_BY_ST_PRJS_TYPES GEN_COMMIT_LIN_STARTUP_BY_ST_PRJS_TYPES Two-dimensional set of generators of the respective operational type
and their startup types (if the project is in
|
GEN_COMMIT_BIN_OPR_TMPS GEN_COMMIT_LIN_OPR_TMPS Two-dimensional set with generators of the respective operational type and their operational timepoints. |
GEN_COMMIT_BIN_OPR_TMPS_STR_TYPES GEN_COMMIT_LIN_OPR_TMPS_STR_TYPES Three-dimensional set with generators of the respective operational
type, their operational timepoints, and their startup types (if the
project is in |
GEN_COMMIT_BIN_STR_TYPES_BY_PRJ Defined over:
GEN_COMMIT_BIN GEN_COMMIT_LIN_STR_TYPES_BY_PRJ Defined over:
GEN_COMMIT_LIN Indexed set that describes the startup types for each project of the respective operational type. |
GEN_COMMIT_BIN_LINKED_TMPS GEN_COMMIT_LIN_LINKED_TMPS Two-dimensional set with generators of the respective operational type and their linked timepoints. |
Required Input Params |
---|
gen_commit_bin_min_stable_level_fraction Defined over:
GEN_COMMIT_BIN Within:
PercentFraction gen_commit_lin_min_stable_level_fraction Defined over:
GEN_COMMIT_LIN Within:
PercentFraction The minimum stable level of this project as a fraction of its capacity. |
Optional Input Params |
---|
gen_commit_bin_ramp_up_when_on_rate Defined over:
GEN_COMMIT_BIN Within:
PercentFraction Default:
1 gen_commit_lin_ramp_up_when_on_rate Defined over:
GEN_COMMIT_LIN Within:
PercentFraction Default:
1 The project’s upward ramp rate limit during operations, defined as a fraction of its capacity per minute. |
gen_commit_bin_ramp_down_when_on_rate Defined over:
GEN_COMMIT_BIN Within:
PercentFraction Default:
1 gen_commit_lin_ramp_down_when_on_rate Defined over:
GEN_COMMIT_LIN Within:
PercentFraction Default:
1 The project’s downward ramp rate limit during operations, defined as a fraction of its capacity per minute. |
gen_commit_bin_startup_plus_ramp_up_rate_by_st Defined over:
GEN_COMMIT_BIN_STARTUP_BY_ST_PRJS_TYPES Within:
PercentFraction Default:
1 gen_commit_lin_startup_plus_ramp_up_rate_by_st Defined over:
GEN_COMMIT_LIN_STARTUP_BY_ST_PRJS_TYPES Within:
PercentFraction Default:
1 The project’s upward ramp rate limit during startup for a given startup type, defined as a fraction of its capacity per minute. If, after adjusting for timepoint duration, this is smaller than the minimum stable level, the project will have a startup trajectory across multiple timepoints. |
gen_commit_bin_shutdown_plus_ramp_down_rate Defined over:
GEN_COMMIT_BIN Within:
PercentFraction Default:
1 gen_commit_lin_shutdown_plus_ramp_down_rate Defined over:
GEN_COMMIT_LIN Within:
PercentFraction Default:
1 The project’s downward ramp rate limit during startup, defined as a fraction of its capacity per minute. If, after adjusting for timepoint duration, this is smaller than the minimum stable level, the project will have a shutdown trajectory across multiple timepoitns. |
gen_commit_bin_min_up_time_hours Defined over:
GEN_COMMIT_BIN Within:
NonNegativeReals Default:
0 gen_commit_lin_min_up_time_hours Defined over:
GEN_COMMIT_LIN Within:
NonNegativeReals Default:
0 The project’s minimum up time in hours. |
gen_commit_bin_min_down_time_hours Defined over:
GEN_COMMIT_BIN Within:
NonNegativeReals Default:
0 gen_commit_lin_min_down_time_hours Defined over:
GEN_COMMIT_LIN Within:
NonNegativeReals Default:
0 The project’s minimum down time in hours. |
gen_commit_bin_aux_consumption_frac_capacity Defined over:
GEN_COMMIT_BIN Within:
PercentFraction Default:
0 gen_commit_lin_aux_consumption_frac_capacity Defined over:
GEN_COMMIT_LIN Within:
PercentFraction Default:
0 Auxiliary consumption as a fraction of committed capacity. |
gen_commit_bin_aux_consumption_frac_power Defined over:
GEN_COMMIT_BIN Within:
PercentFraction Default:
0 gen_commit_lin_aux_consumption_frac_power Defined over:
GEN_COMMIT_LIN Within:
PercentFraction Default:
0 Auxiliary consumption as a fraction of gross power output. |
gen_commit_bin_down_time_cutoff_hours Defined over:
GEN_COMMIT_BIN_STARTUP_BY_ST_PRJS_TYPES Within:
NonNegativeReals gen_commit_lin_down_time_cutoff_hours Defined over:
GEN_COMMIT_LIN_STARTUP_BY_ST_PRJS_TYPES Within:
NonNegativeReals The project’s minimum down time cutoff to activate a given startup type. If the unit has been down for more hours than this cutoff, the relevant startup type will be activated. E.g. if a unit has 2 startup types (hot and cold) with respective cutoffs of 4 hours and 8 hours, it means that startup type 1 (the hot start) will be activated if the unit starts after a down time between 4-8 hours, and startup type 2 (the cold start) will be activated if the unit starts after a down time of over 8 hours. The cutoff for the hottest start must match the unit’s minimum down time. If the unit is fast-start without a minimum down time, the user should input zero (rather than NULL) |
gen_commit_bin_partial_availability_threshold Defined over:
GEN_COMMIT_BIN Within:
PercentFraction Default:
0.01 gen_commit_lin_partial_availability_threshold Defined over:
GEN_COMMIT_LIN Within:
PercentFraction Default:
0.01 The project’s availability threshold below which it cannot be committed/synced. Defaults to 0.01, i.e., the commit and sync variables will be set to zero any time availability is 0.01 or less (for gen_commit_bin; the gen_commit_lin variables are still continuous), but can be 1 otherwise. Make sure to set this to a positive fraction to ensure you approximate partial availability but avoid the issue where the optimization can set the sync variables to 1 even when the project is unavailable, thus avoiding startup costs. |
Derived Params |
---|
gen_commit_bin_allow_ramp_up_violation Defined over:
GEN_COMMIT_BIN Within:
Boolean gen_commit_lin_allow_ramp_up_violation Defined over:
GEN_COMMIT_LIN Within:
Boolean Determines whether the ramp up constraint can be violated. It is 1 if a ramp_up_violation_penalty is specified for the project. |
gen_commit_bin_allow_ramp_down_violation Defined over:
GEN_COMMIT_BIN Within:
Boolean gen_commit_lin_allow_ramp_down_violation Defined over:
GEN_COMMIT_LIN Within:
Boolean Determines whether the ramp down constraint can be violated. It is 1 if a ramp_down_violation_penalty is specified for the project. |
gen_commit_bin_allow_min_up_time_violation Defined over:
GEN_COMMIT_BIN Within:
Boolean gen_commit_lin_allow_min_up_time_violation Defined over:
GEN_COMMIT_LIN Within:
Boolean Determines whether the min up time constraint can be violated. It is 1 if a min_up_time_violation_penalty is specified for the project. |
gen_commit_bin_allow_min_down_time_violation Defined over:
GEN_COMMIT_BIN Within:
Boolean gen_commit_lin_allow_min_down_time_violation Defined over:
GEN_COMMIT_LIN Within:
Boolean Determines whether the min down time constraint can be violated. It is 1 if a min_down_time_violation_penalty is specified for the project. |
Variables |
---|
GenCommitBin_Commit Within:
Binary Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Commit Within:
PercentFraction Defined over:
GEN_COMMIT_LIN_OPR_TMPS In gen_commit_bin, a binary variable which represents the commitment decision in each operational timepoint. It is one if the unit is committed and zero otherwise (including during a startup and shutdown trajectory). In gen_commit_lin, this variable can take on non-binary values between zero and 1 (i.e. partial commitment of the unit is allowed). |
GenCommitBin_Startup Within:
Binary Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Startup Within:
PercentFraction Defined over:
GEN_COMMIT_LIN_OPR_TMPS Binary variable which is one if the unit starts up and zero otherwise. A startup is defined as changing commitment from zero to one. Note: this variable is zero throughout a startup trajectory! In gen_commit_lin, this variable can take on non-binary values between zero and 1. |
GenCommitBin_Startup_Type Within:
Binary Defined over:
GEN_COMMIT_BIN_OPR_TMPS_STR_TYPES GenCommitLin_Startup_Type Within:
PercentFraction Defined over:
GEN_COMMIT_LIN_OPR_TMPS_STR_TYPES Binary variable which is one if the unit starts up for the given startup type and zero otherwise. A startup is defined as changing commitment from zero to one, whereas the startup type indicates the hotness/coldness of the start. Note: this variable is zero throughout a startup trajectory! In gen_commit_lin, this variable can take on non-binary values between zero and 1. |
GenCommitBin_Shutdown Within:
Binary Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Shutdown Within:
PercentFraction Defined over:
GEN_COMMIT_LIN_OPR_TMPS Binary variable which is one if the unit shuts down and zero otherwise. A shutdown is defined as changing commitment from one to zero. Note: this variable is zero throughout a shutdown trajectory! In gen_commit_lin, this variable can take on non-binary values between zero and 1. |
GenCommitBin_Synced Within:
Binary Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Synced Within:
PercentFraction Defined over:
GEN_COMMIT_LIN_OPR_TMPS Binary variable which is one if the project is providing any power ( either because it is committed or because it is in a startup or shutdown trajectory), and zero otherwise. In gen_commit_lin, this variable can take on non-binary values between zero and 1. |
GenCommitBin_Provide_Power_Above_Pmin_MW Within:
NonNegativeReals Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Provide_Power_Above_Pmin_MW Within:
NonNegativeReals Defined over:
GEN_COMMIT_LIN_OPR_TMPS Power provision above the minimum stable level in MW from this project in each timepoint in which the project is committed. |
GenCommitBin_Provide_Power_Startup_By_ST_MW Within:
NonNegativeReals Defined over:
GEN_COMMIT_BIN_OPR_TMPS_STR_TYPES GenCommitLin_Provide_Power_Startup_By_ST_MW Within:
NonNegativeReals Defined over:
GEN_COMMIT_LIN_OPR_TMPS_STR_TYPES Power provision during startup in each timepoint in which the project is starting up, for each startup type (zero if project is committed or not starting up). |
GenCommitBin_Provide_Power_Shutdown_MW Within:
NonNegativeReals Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Provide_Power_Shutdown_MW Within:
NonNegativeReals Defined over:
GEN_COMMIT_LIN_OPR_TMPS Power provision during shutdown in each timepoint in which the project is shutting down (zero if project is committed or not shutting down). |
GenCommitBin_Ramp_Up_Violation_MW Within:
NonNegativeReals Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Ramp_Up_Violation_MW Within:
NonNegativeReals Defined over:
GEN_COMMIT_LIN_OPR_TMPS Violation of the project’s ramp up constraint in each operational timepoint. |
GenCommitBin_Ramp_Down_Violation_MW Within:
NonNegativeReals Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Ramp_Down_Violation_MW Within:
NonNegativeReals Defined over:
GEN_COMMIT_LIN_OPR_TMPS Violation of the project’s ramp down constraint in each operational timepoint. |
GenCommitBin_Min_Up_Time_Violation Within:
NonNegativeReals Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Min_Up_Time_Violation Within:
NonNegativeReals Defined over:
GEN_COMMIT_LIN_OPR_TMPS Violation of the project’s min up time constraint in each operational timepoint. |
GenCommitBin_Min_Down_Time_Violation Within:
NonNegativeReals Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Min_Down_Time_Violation Within:
NonNegativeReals Defined over:
GEN_COMMIT_LIN_OPR_TMPS Violation of the project’s min down time constraint in each operational timepoint. |
Expressions |
---|
GenCommitBin_Pmax_MW Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Pmax_MW Defined over:
GEN_COMMIT_LIN_OPR_TMPS The project’s maximum power output (in MW) if the unit was committed. Depends on the project’s availability and capacity in the timepoint. |
GenCommitBin_Pmin_MW Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Pmin_MW Defined over:
GEN_COMMIT_LIN_OPR_TMPS The project’s minimum power output (in MW) if the unit was committed. Depends on the project’s availability and capacity in the timepoint, and the minimum stable level. |
GenCommitBin_Provide_Power_Startup_MW Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Provide_Power_Startup_MW Defined over:
GEN_COMMIT_LIN_OPR_TMPS Power provision during startup in each timepoint in which the project is starting up (zero if project is committed or not starting up). |
GenCommitBin_Provide_Power_MW Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Provide_Power_MW Defined over:
GEN_COMMIT_LIN_OPR_TMPS The project’s total power output (in MW) in each operational timepoint, including power from a startup or shutdown trajectory. If modeling auxiliary consumption, this is the gross power output. |
GenCommitBin_Ramp_Up_Rate_MW_Per_Tmp Defined over:
GEN_COMMIT_BIN_OPR_TMPS The project’s upward ramp-able capacity (in MW) in each operational
timepoint. Depends on the |
GenCommitBin_Ramp_Down_Rate_MW_Per_Tmp Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Ramp_Up_Rate_MW_Per_Tmp Defined over:
GEN_COMMIT_LIN_OPR_TMPS The project’s downward ramp-able capacity (in MW) in each operationa
timepoint. Depends on the |
GenCommitBin_Startup_Ramp_Rate_By_ST_MW_Per_Tmp Defined over:
GEN_COMMIT_BIN_OPR_TMPS_STR_TYPES GenCommitLin_Startup_Ramp_Rate_By_ST_MW_Per_Tmp Defined over:
GEN_COMMIT_LIN_OPR_TMPS_STR_TYPES The project’s upward ramp-able capacity (in MW) during startup in each
operational timepoint. Depends on the
|
GenCommitBin_Shutdown_Ramp_Rate_MW_Per_Tmp Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Shutdown_Ramp_Rate_MW_Per_Tmp Defined over:
GEN_COMMIT_LIN_OPR_TMPS The project’s downward ramp-able capacity (in MW) during shutdown in
each operational timepoint. Depends on the
|
GenCommitBin_Active_Startup_Type Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Active_Startup_Type Defined over:
GEN_COMMIT_LIN_OPR_TMPS The project’s active startup type in each operational timepoint, described as an integer. If no startup type is active (the project is not starting up in this timepoint), this expression returns zero. |
GenCommitBin_Upwards_Reserves_MW Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Upwards_Reserves_MW Defined over:
GEN_COMMIT_LIN_OPR_TMPS The project’s total upward reserves offered (in MW) in each timepoint. |
GenCommitBin_Downwards_Reserves_MW Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Downwards_Reserves_MW Defined over:
GEN_COMMIT_LIN_OPR_TMPS The project’s total downward reserves offered (in MW) in each timepoint. |
GenCommitBin_Auxiliary_Consumption_MW Defined over:
GEN_COMMIT_BIN_OPR_TMPS The project’s auxiliary consumption (power consumed on-site and not sent to the grid) in each timepoint. |
Constraints |
---|
Commitment |
GenCommitBin_Binary_Logic_Constraint Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Binary_Logic_Constraint Defined over:
GEN_COMMIT_LIN_OPR_TMPS Defines the relationship between the binary commitment, startup, and shutdown variables. When the commitment changes from zero to one, the startup variable is one, when it changes from one to zero, the shutdown variable is one. |
GenCommitBin_Synced_Constraint Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Synced_Constraint Defined over:
GEN_COMMIT_LIN_OPR_TMPS Sets the GenCommitBin_Synced variable to one if the project is providing any power (either because it is committed or because it is in a startup or shutdown trajectory), and zero otherwise. |
Power |
GenCommitBin_Max_Power_Constraint Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Max_Power_Constraint Defined over:
GEN_COMMIT_LIN_OPR_TMPS Limits the power plus upward reserves to the available capacity. |
GenCommitBin_Min_Power_Constraint Defined over:
GEN_COMMIT_BIN_OPR_TMPS Power provision minus downward reserves should exceed the minimum stable level for the project. |
Minimum Up and Down Time |
GenCommitBin_Min_Up_Time_Constraint Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Min_Up_Time_Constraint Defined over:
GEN_COMMIT_LIN_OPR_TMPS Requires that when the project is started, it stays on for at least
|
GenCommitBin_Min_Down_Time_Constraint Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Min_Down_Time_Constraint Defined over:
GEN_COMMIT_LIN_OPR_TMPS Requires that when the project is shut down, it stays off for at least
|
Ramps |
GenCommitBin_Ramp_Up_Constraint Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Ramp_Up_Constraint Defined over:
GEN_COMMIT_LIN_OPR_TMPS Limits the allowed project upward ramp during operations based on the
|
GenCommitBin_Ramp_Down_Constraint Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Ramp_Down_Constraint Defined over:
GEN_COMMIT_LIN_OPR_TMPS Limits the allowed project downward ramp during operations based on the
|
Startup Power |
GenCommitBin_Unique_Startup_Type_Constraint Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Unique_Startup_Type_Constraint Defined over:
GEN_COMMIT_LIN_OPR_TMPS Ensures that only one startup type can be active at the same time. |
GenCommitBin_Active_Startup_Type_Constraint Defined over:
GEN_COMMIT_BIN_OPR_TMPS_STR_TYPES GenCommitLin_Active_Startup_Type_Constraint Defined over:
GEN_COMMIT_LIN_OPR_TMPS_STR_TYPES Ensures that a startup type can only be active if the unit has been down for the appropriate interval. |
GenCommitBin_Max_Startup_Power_Constraint Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Max_Startup_Power_Constraint Defined over:
GEN_COMMIT_LIN_OPR_TMPS Limits startup power to zero when the project is committed and to the minimum stable level when it is not committed. |
GenCommitBin_Ramp_During_Startup_By_ST_Constraint Defined over:
GEN_COMMIT_BIN_OPR_TMPS_STR_TYPES GenCommitLin_Ramp_During_Startup_By_ST_Constraint Defined over:
GEN_COMMIT_LIN_OPR_TMPS_STR_TYPES Limits the allowed project upward startup power ramp based on the
|
GenCommitBin_Increasing_Startup_Power_By_ST_Constraint Defined over:
GEN_COMMIT_BIN_OPR_TMPS_STR_TYPES GenCommitLin_Increasing_Startup_Power_By_ST_Constraint Defined over:
GEN_COMMIT_LIN_OPR_TMPS_STR_TYPES Requires that the startup power always increases, except for the
startup timepoint (when |
GenCommitBin_Power_During_Startup_By_ST_Constraint Defined over:
GEN_COMMIT_BIN_OPR_TMPS_STR_TYPES GenCommitLin_Power_During_Startup_By_ST_Constraint Defined over:
GEN_COMMIT_LIN_OPR_TMPS_STR_TYPES Limits the difference between the power provision in the startup
timepoint and the startup power in the previous timepoint based on the
|
Shutdown Power |
GenCommitBin_Max_Shutdown_Power_Constraint Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Max_Shutdown_Power_Constraint Defined over:
GEN_COMMIT_LIN_OPR_TMPS Limits shutdown power to zero when the project is committed and to the minimum stable level when it is not committed. |
GenCommitBin_Ramp_During_Shutdown_Constraint Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Ramp_During_Shutdown_Constraint Defined over:
GEN_COMMIT_LIN_OPR_TMPS Limits the allowed project downward shutdown power ramp based on the
|
GenCommitBin_Decreasing_Shutdown_Power_Constraint Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Decreasing_Shutdown_Power_Constraint Defined over:
GEN_COMMIT_LIN_OPR_TMPS Requires that the shutdown power always decreases, except for the
shutdown timepoint (when |
GenCommitBin_Power_During_Shutdown_Constraint Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_Power_During_Shutdown_Constraint Defined over:
GEN_COMMIT_LIN_OPR_TMPS Limits the difference between the power provision in the shutdown
timepoint and the shutdown power in the next timepoint based on the
|
GenCommitBin_No_Sync_When_Unavailable_Constraint Defined over:
GEN_COMMIT_BIN_OPR_TMPS GenCommitLin_No_Sync_When_Unavailable_Constraint Defined over:
GEN_COMMIT_LIN_OPR_TMPS A project cannot be synced (committed or providing startup/shutdown power) when unavailable (<1% available). |
GenCommitBin_No_Commit_When_Unavailable_Constraint Defined over:
GEN_COMMIT_BIN_OPR_TMPS Forces the binary commitment to 0 when the project is unavailable (<1% available). |
gridpath.project.capacity.operational_types.gen_commit_cap¶
The following Pyomo model components are defined in this module:
Sets |
---|
GEN_COMMIT_CAP The set of generators of the gen_commit_cap operational type |
GEN_COMMIT_CAP_OPR_TMPS Two-dimensional set with generators of the |
GEN_COMMIT_CAP_LINKED_TMPS Two-dimensional set with generators of the |
Required Input Params |
---|
gen_commit_cap_unit_size_mw Defined over:
GEN_COMMIT_CAP Within:
NonNegativeReals The MW size of a unit in this project (projects of the
|
gen_commit_cap_min_stable_level_fraction Defined over:
GEN_COMMIT_CAP Within:
NonNegativeReals The minimum stable level of this project as a fraction of its capacity. This can also be interpreted as the minimum stable level of a unit within this project (as the project itself can represent multiple units with similar characteristics. |
Optional Input Params |
---|
gen_commit_cap_startup_plus_ramp_up_rate Defined over:
GEN_COMMIT_CAP Within:
PercentFraction Default:
1 The project’s ramp rate when starting up as percent of project capacity per minute (defaults to 1 if not specified). |
gen_commit_cap_shutdown_plus_ramp_down_rate Defined over:
GEN_COMMIT_CAP Within:
PercentFraction Default:
1 The project’s ramp rate when shutting down as percent of project capacity per minute (defaults to 1 if not specified). |
gen_commit_cap_ramp_up_when_on_rate Defined over:
GEN_COMMIT_CAP Within:
PercentFraction Default:
1 The project’s upward ramp rate limit during operations, defined as a fraction of its capacity per minute. |
gen_commit_cap_ramp_down_when_on_rate Defined over:
GEN_COMMIT_CAP Within:
PercentFraction Default:
1 The project’s downward ramp rate limit during operations, defined as a fraction of its capacity per minute. |
gen_commit_cap_min_up_time_hours Defined over:
GEN_COMMIT_CAP Within:
PercentFraction Default:
1 The project’s minimum up time in hours. |
gen_commit_cap_min_down_time_hours Defined over:
GEN_COMMIT_CAP Within:
PercentFraction Default:
1 The project’s minimum down time in hours. |
gen_commit_cap_aux_consumption_frac_capacity Defined over:
GEN_COMMIT_CAP Within:
PercentFraction Default:
0 Auxiliary consumption as a fraction of committed capacity. |
gen_commit_cap_aux_consumption_frac_power Defined over:
GEN_COMMIT_CAP Within:
PercentFraction Default:
0 Auxiliary consumption as a fraction of gross power output. |
Linked Input Params |
---|
gen_commit_cap_linked_commit_capacity Defined over:
GEN_COMMIT_CAP_LINKED_TMPS Within:
NonNegativeReals The project’s committed capacity in the linked timepoints. |
gen_commit_cap_linked_power Defined over:
GEN_COMMIT_CAP_LINKED_TMPS Within:
NonNegativeReals The project’s power provision in the linked timepoints. |
gen_commit_cap_linked_upwards_reserves Defined over:
GEN_COMMIT_CAP_LINKED_TMPS Within:
NonNegativeReals The project’s upward reserve provision in the linked timepoints. |
gen_commit_cap_linked_downwards_reserves Defined over:
GEN_COMMIT_CAP_LINKED_TMPS Within:
NonNegativeReals The project’s downward reserve provision in the linked timepoints. |
gen_commit_cap_linked_startup Defined over:
GEN_COMMIT_CAP_LINKED_TMPS Within:
NonNegativeReals The project’s startup in the linked timepoints. |
gen_commit_cap_linked_shutdown Defined over:
GEN_COMMIT_CAP_LINKED_TMPS Within:
NonNegativeReals The project’s shutdown in the linked timepoints. |
Variables |
---|
GenCommitCap_Provide_Power_MW Within:
NonNegativeReals Defined over:
GEN_COMMIT_CAP_OPR_TMPS Power provision in MW from this project in each timepoint in which the project is operational (capacity exists and the project is available). If modeling auxiliary consumption, this is the gross power output. |
Commit_Capacity_MW Within:
NonNegativeReals Defined over:
GEN_COMMIT_CAP_OPR_TMPS A continuous variable that represents the commitment state of the (i.e. of the units represented by this project). |
GenCommitCap_Fuel_Burn_MMBTU Within:
NonNegativeReals Defined over:
GEN_COMMIT_CAP_OPR_TMPS Fuel burn by this project in each operational timepoint. |
Ramp_Up_Startup_MW Within:
Reals Defined over:
GEN_COMMIT_CAP_OPR_TMPS The upward ramp of the project when capacity is started up. |
Ramp_Down_Startup_MW Within:
Reals Defined over:
GEN_COMMIT_CAP_OPR_TMPS The downward ramp of the project when capacity is shutting down. |
Ramp_Up_When_On_MW Within:
Reals Defined over:
GEN_COMMIT_CAP_OPR_TMPS The upward ramp of the project when capacity on. |
Ramp_Down_When_On_MW Within:
Reals Defined over:
GEN_COMMIT_CAP_OPR_TMPS The downward ramp of the project when capacity is on. |
GenCommitCap_Startup_MW Within:
NonNegativeReals Defined over:
GEN_COMMIT_CAP_OPR_TMPS The amount of capacity started up (in MW). |
GenCommitCap_Shutdown_MW Within:
NonNegativeReals Defined over:
GEN_COMMIT_CAP_OPR_TMPS The amount of capacity shut down (in MW). |
Expressions |
---|
GenCommitCap_Auxiliary_Consumption_MW Defined over:
GEN_COMMIT_CAP_OPR_TMPS The project’s auxiliary consumption (power consumed on-site and not sent to the grid) in each timepoint. |
Constraints |
---|
Commitment and Power |
Commit_Capacity_Constraint Defined over:
GEN_COMMIT_CAP_OPR_TMPS Limits committed capacity to the available capacity. |
GenCommitCap_Max_Power_Constraint Defined over:
GEN_COMMIT_CAP_OPR_TMPS Limits the power plus upward reserves to the committed capacity. |
GenCommitCap_Min_Power_Constraint Defined over:
GEN_COMMIT_CAP_OPR_TMPS Limits the power provision minus downward reserves to the minimum stable level for the project. |
Ramps |
Ramp_Up_Off_to_On_Constraint Defined over:
GEN_COMMIT_CAP_OPR_TMPS Limits the allowed project upward ramp when turning capacity on based
on the |
Ramp_Up_When_On_Constraint Defined over:
GEN_COMMIT_CAP_OPR_TMPS Limits the allowed project upward ramp when capacity is on based on
the |
Ramp_Up_When_On_Headroom_Constraint Defined over:
GEN_COMMIT_CAP_OPR_TMPS Limits the allowed project upward ramp based on the headroom available in the previous timepoint. |
GenCommitCap_Ramp_Up_Constraint Defined over:
GEN_COMMIT_CAP_OPR_TMPS Limits the allowed project upward ramp (regardless of commitment state). |
Ramp_Down_On_to_Off_Constraint Defined over:
GEN_COMMIT_CAP_OPR_TMPS Limits the allowed project downward ramp when turning capacity on based
on the |
Ramp_Down_When_On_Constraint Defined over:
GEN_COMMIT_CAP_OPR_TMPS Limits the allowed project downward ramp when capacity is on based on
the |
Ramp_Down_When_On_Headroom_Constraint Defined over:
GEN_COMMIT_CAP_OPR_TMPS Limits the allowed project downward ramp based on the headroom available in the current timepoint. |
GenCommitCap_Ramp_Down_Constraint Defined over:
GEN_COMMIT_CAP_OPR_TMPS Limits the allowed project downward ramp (regardless of commitment state). |
Minimum Up and Down Time |
GenCommitCap_Startup_Constraint Defined over:
GEN_COMMIT_CAP_OPR_TMPS Limits the capacity started up to the difference in commitment between the current and previous timepoint. |
GenCommitCap_Shutdown_Constraint Defined over:
GEN_COMMIT_CAP_OPR_TMPS Limits the capacity shut down to the difference in commitment between the current and previous timepoint. |
GenCommitCap_Min_Up_Time_Constraint Defined over:
GEN_COMMIT_CAP_OPR_TMPS Requires that when units within this project are started, they stay on
for at least |
GenCommitCap_Min_Down_Time_Constraint Defined over:
GEN_COMMIT_CAP_OPR_TMPS Requires that when units within this project are stopped, they stay off
for at least |
gridpath.project.capacity.operational_types.gen_hydro¶
The following Pyomo model components are defined in this module:
Optional Input Params |
---|
gen_hydro_ramp_up_when_on_rate Defined over:
GEN_HYDRO Within:
PercentFraction Default:
1 The project’s upward ramp rate limit during operations, defined as a fraction of its capacity per minute. |
gen_hydro_ramp_down_when_on_rate Defined over:
GEN_HYDRO Within:
PercentFraction Default:
1 The project’s downward ramp rate limit during operations, defined as a fraction of its capacity per minute. |
gen_hydro_aux_consumption_frac_capacity Defined over:
GEN_HYDRO Within:
PercentFraction Default:
0 Auxiliary consumption as a fraction of capacity. This would be incurred in all timepoints when capacity is available. |
gen_hydro_aux_consumption_frac_power Defined over:
GEN_HYDRO Within:
PercentFraction Default:
0 Auxiliary consumption as a fraction of gross power output. |
Linked Input Params |
---|
gen_hydro_linked_power Defined over:
GEN_HYDRO_LINKED_TMPS Within:
Reals The project’s power provision in the linked timepoints. |
gen_hydro_linked_curtailment Defined over:
GEN_HYDRO_LINKED_TMPS Within:
NonNegativeReals The project’s curtailment in the linked timepoints. |
gen_hydro_linked_upwards_reserves Defined over:
GEN_HYDRO_LINKED_TMPS Within:
NonNegativeReals The project’s upward reserve provision in the linked timepoints. |
gen_hydro_linked_downwards_reserves Defined over:
GEN_HYDRO_LINKED_TMPS Within:
NonNegativeReals The project’s downward reserve provision in the linked timepoints. |
Variables |
---|
GenHydro_Gross_Power_MW Defined over:
GEN_HYDRO_OPR_TMPS Within:
Reals Gross power in MW from this project in each timepoint in which the project is operational (capacity exists and the project is available). We’ll subtract curtailment and auxiliary consumption from this for load balance purposes. |
GenHydro_Curtail_MW Defined over:
GEN_HYDRO_OPR_TMPS Within:
NonNegativeReals Curtailment in MW from this project in each timepoint in which the project is operational (capacity exists and the project is available). |
Expressions |
---|
GenHydro_Auxiliary_Consumption_MW Defined over:
GEN_HYDRO_OPR_TMPS The project’s auxiliary consumption (power consumed on-site and not sent to the grid) in each timepoint. |
gridpath.project.capacity.operational_types.gen_hydro_must_take¶
The following Pyomo model components are defined in this module:
Optional Input Params |
---|
gen_hydro_must_take_ramp_up_when_on_rate Defined over:
GEN_HYDRO_MUST_TAKE Within:
PercentFraction Default:
1 The project’s upward ramp rate limit during operations, defined as a fraction of its capacity per minute. |
gen_hydro_must_take_ramp_down_when_on_rate Defined over:
GEN_HYDRO_MUST_TAKE Within:
PercentFraction Default:
1 The project’s downward ramp rate limit during operations, defined as a fraction of its capacity per minute. |
gen_hydro_must_take_aux_consumption_frac_capacity Defined over:
GEN_HYDRO_MUST_TAKE Within:
PercentFraction Default:
0 Auxiliary consumption as a fraction of capacity. This would be incurred in all timepoints when capacity is available. |
gen_hydro_must_take_aux_consumption_frac_power Defined over:
GEN_HYDRO_MUST_TAKE Within:
PercentFraction Default:
0 Auxiliary consumption as a fraction of gross power output. |
Linked Input Params |
---|
gen_hydro_must_take_linked_power Defined over:
GEN_HYDRO_MUST_TAKE_LINKED_TMPS Within:
Reals The project’s power provision in the linked timepoints. |
gen_hydro_must_take_linked_upwards_reserves Defined over:
GEN_HYDRO_MUST_TAKE_LINKED_TMPS Within:
NonNegativeReals The project’s upward reserve provision in the linked timepoints. |
gen_hydro_must_take_linked_downwards_reserves Defined over:
GEN_HYDRO_MUST_TAKE_LINKED_TMPS Within:
NonNegativeReals The project’s downward reserve provision in the linked timepoints. |
Variables |
---|
GenHydroMustTake_Gross_Power_MW Defined over:
GEN_HYDRO_MUST_TAKE_OPR_TMPS Within:
Reals Power provision in MW from this project in each timepoint in which the project is operational (capacity exists and the project is available). |
Expressions |
---|
GenHydroMustTake_Auxiliary_Consumption_MW Defined over:
GEN_HYDRO_MUST_TAKE_OPR_TMPS The project’s auxiliary consumption (power consumed on-site and not sent to the grid) in each timepoint. |
gridpath.project.capacity.operational_types.gen_var¶
The following Pyomo model components are defined in this module:
Sets |
---|
GEN_VAR The set of generators of the |
GEN_VAR_OPR_TMPS Two-dimensional set with generators of the |
Required Input Params |
---|
gen_var_cap_factor Defined over:
GEN_VAR Within:
Reals The project’s power output in each operational timepoint as a fraction of its available capacity (i.e. the capacity factor). |
Variables |
---|
GenVar_Provide_Power_MW Defined over:
GEN_VAR_OPR_TMPS Within:
NonNegativeReals Power provision in MW from this project in each timepoint in which the project is operational (capacity exists and the project is available). |
GenVar_Scheduled_Curtailment_MW Defined over:
GEN_VAR_OPR_TMPS Within:
NonNegativeReals Curtailed power in MW from this project in each timepoint in which the project is operational (capacity exists and the project is available). This will be the available power minus what was actually provided. |
Expressions |
---|
GenVar_Subhourly_Curtailment_MW Defined over:
GEN_VAR_OPR_TMPS Sub-hourly curtailment (in MW) from providing downward reserves. |
GenVar_Subhourly_Energy_Delivered_MW Defined over:
GEN_VAR_OPR_TMPS Sub-hourly energy delivered (in MW) from providing upward reserves. |
GenVar_Total_Curtailment_MW Defined over:
GEN_VAR_OPR_TMPS Scheduled curtailment (in MW) plus an upward adjustment for additional curtailment when providing downward reserves, and a downward adjustment adjustment for a reduction in curtailment when providing upward reserves, to account for sub-hourly dispatch when providing reserves. |
Constraints |
---|
Power |
GenVar_Max_Power_Constraint Defined over:
GEN_VAR_OPR_TMPS Limits the power plus scheduled curtailment in each timepoint to equal
the available power.
|
GenVar_Max_Upward_Reserves_Constraint Defined over:
GEN_VAR_OPR_TMPS Upward reserves cannot exceed curtailment. |
GenVar_Max_Downward_Reserves_Constraint Defined over:
GEN_VAR_OPR_TMPS Downward reserves cannot exceed power provision when the capacity factor is non-negative (power is non-negative); otherwise they are set to zero. |
gridpath.project.capacity.operational_types.gen_var_must_take¶
The following Pyomo model components are defined in this module:
Sets |
---|
GEN_VAR_MUST_TAKE The set of generators of the |
GEN_VAR_MUST_TAKE_OPR_TMPS Two-dimensional set with generators of the |
Required Input Params |
---|
gen_var_must_take_cap_factor Defined over:
GEN_VAR_MUST_TAKE Within:
Reals The project’s power output in each operational timepoint as a fraction of its available capacity (i.e. the capacity factor). |
Constraints |
---|
GenVarMustTake_No_Upward_Reserves_Constraint Defined over:
GEN_VAR_MUST_TAKE_OPR_TMPS Variable must-take generator projects cannot provide upward reserves. |
GenVarMustTake_No_Downward_Reserves_Constraint Defined over:
GEN_VAR_MUST_TAKE_OPR_TMPS Variable must-take generator projects cannot provide downward reserves. |
gridpath.project.capacity.operational_types.stor¶
The following Pyomo model components are defined in this module:
Sets |
---|
STOR The set of projects of the |
STOR_OPR_TMPS Two-dimensional set with projects of the |
STOR_LINKED_TMPS Two-dimensional set with generators of the |
Required Input Params |
---|
stor_charging_efficiency Defined over:
STOR Within:
PercentFraction The storage project’s charging efficiency (1 = 100% efficient). |
stor_discharging_efficiency Defined over:
STOR Within:
PercentFraction The storage project’s discharging efficiency (1 = 100% efficient). |
Optional Input Params |
---|
stor_storage_efficiency Defined over:
STOR Within:
PercentFraction Default:
1 The storage project’s storage efficiency (1 = 100% efficient). |
stor_losses_factor_in_energy_target Within:
PercentFraction Default:
1 The fraction of storage losses that count against the energy target. |
stor_losses_factor_curtailment Within:
PercentFraction Default:
1 The fraction of storage losses that count against curtailment. |
stor_charging_capacity_multiplier Defined over:
STOR Within:
NonNegativeReals Default:
1.0 The storage project’s charging capacity multiplier to be used if the charging capacity is different from the nameplate capacity. |
stor_discharging_capacity_multiplier Defined over:
STOR Within:
NonNegativeReals Default:
1.0 The storage project’s discharging capacity multiplier to be used if the discharging capacity is different from the nameplate capacity. |
stor_exogenous_starting_state_of_charge Defined over:
STOR_EXOG_SOC_TMPS Within:
NonNegativeReals The storage project’s exogenously specified starting state of charge. If not specified, the state of charge is endogenously determined by the optimization subject to the rest of the constraints. |
Linked Input Params |
---|
stor_linked_starting_energy_in_storage Defined over:
STOR_LINKED_TMPS Within:
NonNegativeReals The project’s starting energy in storage in the linked timepoints. |
stor_linked_discharge Defined over:
STOR_LINKED_TMPS Within:
NonNegativeReals The project’s dicharging in the linked timepoints. |
stor_linked_charge Defined over:
STOR_LINKED_TMPS Within:
NonNegativeReals The project’s charging in the linked timepoints. |
Variables |
---|
Stor_Charge_MW Defined over:
STOR_OPR_TMPS Within:
NonNegativeReals Charging power in MW from this project in each timepoint in which the project is operational (capacity exists and the project is available). |
Stor_Discharge_MW Defined over:
STOR_OPR_TMPS Within:
NonNegativeReals
|
Stor_Starting_Energy_in_Storage_MWh Defined over:
STOR_OPR_TMPS Within:
NonNegativeReals The state of charge of the storage project at the start of each timepoint, in MWh of energy stored. |
Constraints |
---|
Power and Stage of Charge |
Stor_Max_Charge_Constraint Defined over:
STOR_OPR_TMPS Limits the project’s charging power to the available capacity. |
Stor_Max_Discharge_Constraint Defined over:
STOR_OPR_TMPS Limits the project’s discharging power to the available capacity. |
Stor_Energy_Tracking_Constraint Defined over:
STOR_OPR_TMPS Tracks the amount of energy stored in each timepoint based on the previous timepoint’s energy stored and the charge and discharge decisions. |
Stor_Max_Energy_in_Storage_Constraint Defined over:
STOR_OPR_TMPS Limits the project’s total energy stored to the available energy capacity. |
Reserves |
Stor_Max_Headroom_Power_Constraint Defined over:
STOR_OPR_TMPS Limits the project’s upward reserves based on available headroom. Going from charging to non-charging also counts as headroom, doubling the maximum amount of potential headroom. |
Stor_Max_Footroom_Power_Constraint Defined over:
STOR_OPR_TMPS Limits the project’s downward reserves based on available footroom. Going from non-charging to charging also counts as footroom, doubling the maximum amount of potential footroom. |
Stor_Max_Headroom_Energy_Constraint Defined over:
STOR_OPR_TMPS Can’t provide more upward reserves (times sustained duration required) than available energy in storage in that timepoint. |
Stor_Max_Footroom_Energy_Constraint Defined over:
STOR_OPR_TMPS Can’t provide more downard reserves (times sustained duration required) than available capacity to store energy in that timepoint. |
gridpath.project.capacity.operational_types.gen_var_stor_hyb¶
The following Pyomo model components are defined in this module:
Sets |
---|
GEN_VAR_STOR_HYB The set of generators of the |
GEN_VAR_STOR_HYB_OPR_TMPS Two-dimensional set with generators of the |
Required Input Params |
---|
gen_var_stor_hyb_cap_factor Defined over:
GEN_VAR_STOR_HYB Within:
NonNegativeReals The project’s power output in each operational timepoint as a fraction of its available capacity (i.e. the capacity factor). |
gen_var_stor_hyb_charging_efficiency Defined over:
GEN_VAR_STOR_HYB Within:
PercentFraction The project’s storage component charging efficiency (1 = 100% efficient). |
gen_var_stor_hyb_discharging_efficiency Defined over:
GEN_VAR_STOR_HYB Within:
PercentFraction The project’s storage component discharging efficiency (1 = 100% efficient). |
Variables |
---|
GenVarStorHyb_Provide_Power_MW Defined over:
GEN_VAR_STOR_HYB_OPR_TMPS Within:
NonNegativeReals Power provision in MW from this project in each timepoint in which the project is operational (capacity exists and the project is available). This can come either directly from the variable resource via the the generator component or from the storage component. |
GenVarStorHyb_Charge_MW Defined over:
GEN_VAR_STOR_HYB_OPR_TMPS Within:
NonNegativeReals Charging power in MW from this project in each timepoint in which the project is operational (capacity exists and the project is available). This operational type can only charge from the variable resource, not from the grid. |
GenVarStorHyb_Discharge_MW Defined over:
GEN_VAR_STOR_HYB_OPR_TMPS Within:
NonNegativeReals Discharging power in MW from this project in each timepoint in which the project is operational (capacity exists and the project is available). |
GenVarStorHyb_Starting_Energy_in_Storage_MWh Defined over:
GEN_VAR_STOR_HYB_OPR_TMPS Within:
NonNegativeReals The state of charge of the project’s storage component at the start of each timepoint, in MWh of energy stored. |
Expressions |
---|
GenVarStorHyb_Available_Power_MW Defined over:
GEN_VAR_STOR_HYB_OPR_TMPS The available power from the variable resource. |
GenVarStorHyb_Scheduled_Curtailment_MW Defined over:
GEN_VAR_STOR_HYB_OPR_TMPS The available power minus what was actually provided (in MW). |
GenVarStorHyb_Subtimepoint_Curtailment_MW Defined over:
GEN_VAR_STOR_HYB_OPR_TMPS Curtailment resulting from provision of downward reserves. |
GenVarStorHyb_Total_Curtailment_MW Defined over:
GEN_VAR_STOR_HYB_OPR_TMPS Scheduled curtailment (in MW) plus an upward adjustment for additional curtailment when providing downward reserves, and a downward adjustment adjustment for a reduction in curtailment when providing upward reserves, to account for sub-hourly dispatch when providing reserves. |
GenVarStorHyb_Subtimepoint_Energy_Delivered_MW Defined over:
GEN_VAR_STOR_HYB_OPR_TMPS Delivered energy resulting from provision of upward reserves. |
Constraints |
---|
GenVarStorHyb_Max_Power_Constraint Defined over:
GEN_VAR_STOR_HYB_OPR_TMPS The project’s power and upward reserves cannot exceed the available capacity. |
GenVarStorHyb_Max_Available_Power_Constraint Defined over:
GEN_VAR_STOR_HYB_OPR_TMPS Limits the power plus upward reserves in each timepoint based on the
product of |
GenVarStorHyb_Min_Power_Constraint Defined over:
GEN_VAR_STOR_HYB_OPR_TMPS Power provision minus downward reserves should be greater than or equal to zero. We are assuming that the hybrid storage cannot charge from the grid (so power provision cannot go negative). |
GenVarStorHyb_Max_Charge_Constraint Defined over:
GEN_VAR_STOR_HYB_OPR_TMPS Storage charging power can’t exceed available storage component capacity. |
GenVarStorHyb_Max_Discharge_Constraint Defined over:
GEN_VAR_STOR_HYB_OPR_TMPS Storage discharging power can’t exceed available storage component capacity. |
GenVarStorHyb_Energy_Tracking_Constraint Defined over:
GEN_VAR_STOR_HYB_OPR_TMPS The energy stored in each timepoint is equal to the energy stored in the previous timepoint minus any discharged power (adjusted for discharging efficiency and timepoint duration) plus any charged power (adjusted for charging efficiency and timepoint duration). |
GenVarStorHyb_Max_Energy_in_Storage_Constraint Defined over:
GEN_VAR_STOR_HYB_OPR_TMPS The amount of energy stored in each operational timepoint cannot exceed the available energy capacity. |
GenVarStorHyb_Max_Headroom_Energy_Constraint Defined over:
GEN_VAR_STOR_HYB_OPR_TMPS The project cannot provide more upward reserves (reserve provision times sustained duration required) than the available energy (from resource and from storage) after accounting for power provision. Said differently, we must have enough energy available to remain at the new set point (for the full duration of the timepoint). |
gridpath.project.capacity.operational_types.dr¶
The following Pyomo model components are defined in this module:
Sets |
---|
DR The set of projects of the |
DR_OPR_TMPS Two-dimensional set with projects of the |
DR_OPR_HRZS Two-dimensional set with projects of the |
Variables |
---|
DR_Shift_Up_MW Defined over:
DR_OPR_TMPS Within:
NonNegativeReals Load added (in MW) in each operational timepoint. |
DR_Shift_Down_MW Defined over:
DR_OPR_TMPS Within:
NonNegativeReals Load removed (in MW) in each operational timepoint. |
Constraints |
---|
DR_Max_Shift_Up_Constraint Defined over:
DR_OPR_TMPS Limits the added load to the available power capacity. |
DR_Max_Shift_Down_Constraint Defined over:
DR_OPR_TMPS Limits the removed load to the available power capacity. |
DR_Energy_Balance_Constraint Defined over:
DR_OPR_HRZS Ensures no energy losses or gains when shifting load within the horizon. |
DR_Energy_Budget_Constraint Defined˚ over:
DR_OPR_HRZS Total energy that can be shifted on each horizon should be less than or equal to budget. |
gridpath.project.capacity.operational_types.dac¶
The following Pyomo model components are defined in this module:
Sets |
---|
DAC The set of generators of the |
DAC_OPR_TMPS Two-dimensional set with projects of the |
Variables |
---|
DAC_Consume_Power_MW Defined over:
DAC_OPR_TMPS Within:
NonNegativeReals Power consumption in MW from this project in each timepoint in which the project is operational (capacity exists and the project is available). |
Constraints |
---|
Power |
DAC_Max_Power_Constraint Defined over:
DAC_OPR_TMPS Limits the power consumption to the available capacity. |
10.1.4. Load Balance¶
gridpath.system.load_balance.static_load_requirement¶
This module adds the main load-balance consumption component, the static load requirement to the load-balance constraint.
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
- Parameters:
m – the Pyomo abstract model object we are adding the components to
d – the DynamicComponents class object we are adding components to
Here, we add profiles for the various load components that must be defined for each load zone z and timepoint tmp. These profiles are summed into the LZ_Load_in_Tmp expression, which in turn is added to the dynamic load-balance consumption components that will go into the load balance constraint in the load_balance module (i.e. the constraint’s RHS).
The following Pyomo model components are defined in this module:
Sets
LOAD_ZONE_LOAD_CMPNTS_ALL
Two-dimensional set of all load_zone-load_components.
LOAD_ZONE_TMP_LOAD_CMPNTS_ALL
Three-dimensional set of all load_zone-timepoint-load_components.
LOAD_ZONE_TMP_LOAD_CMPNTS_W_DEFINED_LOAD
Three-dimensional set of load_zone-timepoint-load_component for which load will be defined.
Required Input Params
component_static_load_mw_w_tmp_value
Defined over:LOAD_ZONE_TMP_LOAD_CMPNTS_W_DEFINED_LOAD
Within:NonNegativeReals
Load level for load_zone, timepoint, and load_component.
Optional Input Params
load_level_default
Defined over:LOAD_ZONE_LOAD_CMPNTS
Within:NonNegativeReals
Default:"undefined"
Default value for load level if it is not defined for via the timepoint inputs; if not defined, this parameter itself defaults to infinity. If it ends up defaulting to infinity, a ValueError is raised.
Derived Params
component_static_load_mw
Defined over:LOAD_ZONE_TMP_LOAD_CMPNTS_ALL
Within:NonNegativeReals
Will either be set to component_static_load_mw_w_tmp_value or to load_level_default. One or the other is required; if both are specified a ValueError will be thrown.
Expressions
LZ_Load_in_Tmp
Defined over:LOAD_ZONES, TMPS
The total load (sum of all load components) for this load zone and timepoint.
gridpath.system.load_balance.aggregate_project_power¶
This module, aggregates the power production by all operational projects to create a load-balance production component, and adds it to the load-balance constraint.
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
- Parameters:
m – the Pyomo abstract model object we are adding the components to
d – the DynamicComponents class object we are adding components to
Here, we add the Power_Production_in_Zone_MW expression – an aggregation of power production by all operational projects in each load zone z and timepoint tmp –and add it to the dynamic load-balance production components that will go into the load balance constraint in the load_balance module (i.e. the constraint’s lhs).
\(Power\_Production\_in\_Zone\_MW_{z, tmp} = \sum_{r^z\in OR_{tmp}}{Power\_Provision\_MW_{r, tmp}}\)
gridpath.system.load_balance.load_balance¶
Refer Load Balance.
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
- Parameters:
m – the Pyomo abstract model object we are adding the components to
d – the DynamicComponents class object we are adding components to
Here we add, the overgeneration and unserved-energy per unit costs are declared here as well as the overgeneration and unserved-energy variables.
We also get all other production and consumption components and add them to the lhs and rhs of the load-balance constraint respectively. With the minimum set of features, the load-balance constraint will be formulated like this:
\(Power\_Production\_in\_Zone\_MW_{z, tmp} + Unserved\_Energy\_MW_{ z, tmp} = static\_load\_requirement_{z, tmp} + Overgeneration\_MW_{z, tmp}\)
10.1.5. Objective Function¶
The gridpath.objective package creates the objective function from dynamic model components added by other modules.
Project-level costs are added in the projects subpackage.
Project-level costs are added in the system subpackage.
gridpath.objective.project.aggregate_capacity_costs¶
This module aggregates all project capacity costs and adds them to the objective function.
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
- Parameters:
m – the Pyomo abstract model object we are adding the components to
d – the DynamicComponents class object we are adding components to
Here, we sum up all capacity-related costs and add them to the objective-function dynamic components.
\(Total\_Capacity\_Costs = \sum_{(r, p)\in {RP}}{Capacity\_Cost\_in\_Period_{r, p} \times discount\_factor_p \times number\_years\_represented_p}\)
gridpath.objective.project.aggregate_operational_costs¶
This module aggregates all project operational costs and adds them to the objective function.
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
- Parameters:
m – the Pyomo abstract model object we are adding the components to
d – the DynamicComponents class object we are adding components to
Here, we sum up all operational costs. Operational costs include variable O&M costs, fuel costs, startup costs, and shutdown costs.
\(Total\_Variable\_OM\_Cost = \sum_{(r, tmp)\in {RT}}{Variable\_OM\_Cost_{r, tmp} \times number\_of\_hours\_in\_timepoint_{tmp} \times horizon\_weight_{h^{tmp}} \times number\_years\_represented_{p^{tmp}} \times discount\_factor_{p^{tmp}}}\)
\(Total\_Fuel\_Cost = \sum_{(r, tmp)\in {RT}}{Fuel\_Cost_{r, tmp} \times number\_of\_hours\_in\_timepoint_{tmp} \times horizon\_weight_{h^{tmp}} \times number\_years\_represented_{p^{tmp}} \times discount\_factor_{p^{tmp}}}\)
gridpath.objective.system.aggregate_load_balance_penalties¶
This module adds load-balance penalty costs to the objective function. Penalties can be applied on unserved energy, overgeneration, and the maximum unserved load experienced in the study period (the latter is only indexed by load zone and is not weighted by any timepoint- or period-level parameters).
Note
Unserved_Energy_MW, unserved_energy_penalty_per_mwh, Overgeneration_MW, overgeneration_penalty_per_mw, and max_unserved_load_penalty_per_mw are declared in system/load_balance/load_balance.py
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
- Parameters:
m – the Pyomo abstract model object we are adding components to
d – the DynamicComponents class object we will get components from
Here, we aggregate total unserved-energy and overgeneration costs as well as any penalties on max unserved load by load zone, and add them as a dynamic component to the objective function.
gridpath.objective.max_npv¶
Refer Objective Function.
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
- Parameters:
m – the Pyomo abstract model object we are adding components to
d – the DynamicComponents class object we will get components from
At this point, all relevant modules should have added cost components to d.total_cost_components. We sum them all up here. With the minimum set of functionality, the objective function will be as follows:
\(minimize:\)
\(Total\_Capacity\_Costs + Total\_Variable\_OM\_Cost + Total\_Fuel\_Cost + Total\_Load\_Balance\_Penalty\_Costs\)
10.2. Advanced Functionality¶
This section describes GridPath’s advanced functionality that can be included by selecting optional features.
10.2.1. Multi-Stage¶
This module exports the commitment variables that must be fixed in the next stage and imports the commitment variables that were fixed in the previous stage.
- add_model_components(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
The following Pyomo model components are defined in this module:
Sets
FNL_COMMIT_PRJS
The set of generators for which the current stage or any of the previous stages is the final commitment stage.
FXD_COMMIT_PRJS
The set of generators that have already had their commitment fixed in a prior commitment stage.
FNL_COMMIT_PRJS_OPR_TMPS
Two-dimensional set of all final commitment projects and their operational timepoints.
FXD_COMMIT_PRJS_OPR_TMPS
Two-dimensional set of all fixed commitment projects and their operational timepoints.
Input Params
fixed_commitment
Defined over:FXD_COMMIT_PRJ_OPR_TMPS
This param describes the fixed commitment from the prior commitment stage for each fixed commitment project and their operational timepoints.
Expressions
Commitment
Defined over:FNL_COMMIT_PRJ_OPR_TMPS
Describes the commitment for all final commitment projects and their operational timepoints. For the
gen_commit_cap
operational type, it describes the committed capacity in MW whereas for thegen_commit_lin
andgen_commit_bin
operational types it describes the binary commitment variable. This expression will be exported so that the next stage’s optimization can read it in through thefixed_commitment
param and fix the commitment to this value.
- export_pass_through_inputs(scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage, m)[source]¶
This function exports the commitment for all final commitment projects, i.e. projects for which the current stage or any of the previous stages is the final commitment stage.
- Parameters:
scenario_directory –
subproblem –
stage –
m –
- Returns:
- fix_variables(m, d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage)[source]¶
This function fixes the commitment of all fixed commitment projects by running the
fix_commitment
function in the appropriate operational module.- Parameters:
m –
d –
scenario_directory –
subproblem –
stage –
- Returns:
10.2.2. Transmission¶
gridpath.transmission¶
The gridpath.transmission package adds transmission-line-level components to the model formulation.
gridpath.transmission.capacity.capacity_types¶
The gridpath.transmission.capacity.capacity_types package contains modules to describe the various ways in which transmission-line capacity can be treated in the optimization problem, e.g. as specified, available to be built, available to be retired, etc.
gridpath.transmission.capacity.capacity_types.tx_spec¶
The following Pyomo model components are defined in this module:
Sets |
---|
TX_SPEC_OPR_PRDS Two-dimensional set of transmission line-period combinations that
helps describe the transmission capacity available in a given period.
This set is added to the list of sets to join to get the final
|
Required Input Params |
---|
tx_spec_min_cap_mw Defined over:
TX_SPEC_OPR_PRDS Within:
Reals The transmission line’s specified minimum flow capacity (in MW) in each operational period. A negative number designates flow in the opposite direction of the defined line flow direction. |
tx_spec_max_cap_mw Defined over:
TX_SPEC_OPR_PRDS Within:
Reals The transmission line’s specified maximum flow capacity (in MW) in each operational period. A negative number designates flow in the opposite direction of the defined line flow direction. |
Optional Input Params |
---|
tx_spec_fixed_cost_per_mw_yr Defined over:
TX_SPEC_OPR_PRDS Within:
NonNegativeReals Default:
0 Fixed cost to be incurred in each operational period. Multiplied by the average of the absolute values of the min and max line capacity. |
gridpath.transmission.capacity.capacity_types.tx_new_lin¶
The following Pyomo model components are defined in this module:
Sets |
---|
TX_NEW_LIN_VNTS A two-dimensional set of line-vintage combinations to help describe the periods in time when transmission line capacity can be built in the optimization. |
TX_NEW_LIN_VNTS_W_MIN_CONSTRAINT Two-dimensional set of transmission-vintage combinations to describe all possible transmission-vintage combinations for transmission lines with a cumulative minimum build capacity specified. |
TX_NEW_LIN_VNTS_W_MAX_CONSTRAINT Two-dimensional set of transmission-vintage combinations to describe all possible transmission-vintage combinations for transmission lines with a cumulative maximum build capacity specified. |
Required Input Params |
---|
tx_new_lin_operational_lifetime_yrs_by_vintage Defined over:
TX_NEW_LIN_VNTS Within:
NonNegativeReals The transmission line’s operational lifetime, i.e. how long line capacity of a particular vintage remains operational. |
tx_new_lin_financial_lifetime_yrs_by_vintage Defined over:
TX_NEW_LIN_VNTS Within:
NonNegativeReals The transmission line’s financial lifetime, i.e. how long payments are made if new capacity is built. |
tx_new_lin_annualized_real_cost_per_mw_yr Defined over:
TX_NEW_LIN_VNTS Within:
NonNegativeReals The transmission line’s cost to build new capacity in annualized real dollars per MW. |
Note
The cost input to the model is an annualized cost per unit
capacity. This annualized cost is incurred in each period of the study
(and multiplied by the number of years the period represents) for
the duration of the line’s lifetime. It is up to the user to
ensure that the tx_new_lin_financial_lifetime_yrs_by_vintage
and
tx_new_lin_annualized_real_cost_per_mw_yr
parameters are
consistent.
Optional Input Params |
---|
tx_new_lin_fixed_cost_per_mw_yr Defined over:
TX_NEW_LIN_VNTS Within:
NonNegativeReals Default:
0 The transmission line’s fixed cost to be paid in each operational period in real dollars per unit capacity of that vintage. |
tx_new_lin_min_cumulative_new_build_mw Defined over:
TX_NEW_LIN_VNTS Within:
NonNegativeReals The minimum cumulative amount of capacity (in MW) that must be built for a transmission line by a certain period. |
tx_new_lin_max_cumulative_new_build_mw Defined over:
TX_NEW_LIN_VNTS Within:
NonNegativeReals The maximum cumulative amount of capacity (in MW) that must be built for a transmission line by a certain period. |
Derived Sets |
---|
OPR_PRDS_BY_TX_NEW_LIN_VINTAGE Defined over:
TX_NEW_LIN_VNTS Indexed set that describes the operational periods for each possible
transmission line-vintage combination, based on the
|
TX_NEW_LIN_OPR_PRDS Two-dimensional set that includes the periods when transmission
capacity of any vintage could be operational if built. This set is
added to the list of sets to join to get the final
|
TX_NEW_LIN_VNTS_OPR_IN_PRD Defined over:
PERIODS Indexed set that describes the transmission line-vintages that could
be operational in each period based on the
|
FIN_PRDS_BY_TX_NEW_LIN_VINTAGE Defined over:
TX_NEW_LIN_VNTS Indexed set that describes the financial periods for each possible
line-vintage combination, based on the
|
TX_NEW_LIN_FIN_PRDS Two-dimensional set that includes the periods when line capacity of
any vintage could be incurring costs if built. This set is added to
the list of sets to join to get the final |
TX_NEW_LIN_VNTS_FIN_IN_PRD Defined over:
PERIODS Indexed set that describes the line-vintages that could be incurring
costs in each period based on the
|
Variables |
---|
TxNewLin_Build_MW Defined over:
TX_NEW_LIN_VNTS Within:
NonNegativeReals Determines how much transmission capacity of each possible vintage is
built at each |
Expressions |
---|
TxNewLin_Capacity_MW Defined over:
TX_NEW_LIN_OPR_PRDS Within:
NonNegativeReals The transmission capacity of a line in a given operational period is equal to the sum of all capacity-build of vintages operational in that period. |
Constraints |
---|
TxNewLin_Min_Cum_Build_Constraint Defined over:
TX_NEW_LIN_VNTS_W_MIN_CONSTRAINT Ensures that certain amount of capacity is built by a certain period,
based on |
TxNewLin_Max_Cum_Build_Constraint Defined over:
TX_NEW_LIN_VNTS_W_MAX_CONSTRAINT Limits the amount of capacity built by a certain period, based on
|
gridpath.transmission.capacity.capacity¶
This is a line-level module that adds to the formulation components that describe the capacity of transmission lines that are available to the optimization for each period. The capacity can be a fixed number or an expression with variables depending on the line’s capacity_type. The project capacity can then be used to constrain operations, contribute to reliability constraints, etc. The module also adds transmission costs which again depend on the line’s capacity_type.
gridpath.transmission.operations.operational_types¶
The gridpath.transmission.operations.operational_types package contains modules to describe the various ways in which transmission-line operations are constrained in optimization problem, e.g. as a simple transport model, or DC OPF.
gridpath.transmission.operations.operational_types.tx_simple¶
The following Pyomo model components are defined in this module:
Sets |
---|
TX_SIMPLE The set of transmission lines of the |
TX_SIMPLE_OPR_TMPS Two-dimensional set with transmission lines of the |
Params |
---|
tx_simple_loss_factor Defined over:
TX_SIMPLE Within:
PercentFraction Default:
0 The fraction of power that is lost when transmitted over this line. |
Variables |
---|
TxSimple_Transmit_Power_MW Defined over:
TX_SIMPLE_OPR_TMPS Within:
Reals The transmission line’s power flow in each timepoint in which the line is operational. Negative power means the power flow goes in the opposite direction of the line’s defined direction. |
TxSimple_Losses_LZ_From_MW Defined over:
TX_SIMPLE_OPR_TMPS Within:
NonNegativeReals Losses on the transmission line in each timepoint, which we’ll account for in the “from” origin load zone’s load balance, i.e. losses incurred when power is flowing to the “from” zone. |
TxSimple_Losses_LZ_To_MW Defined over:
TX_SIMPLE_OPR_TMPS Within:
NonNegativeReals Losses on the transmission line in each timepoint, which we’ll account for in the “to” origin load zone’s load balance, i.e. losses incurred when power is flowing to the “to” zone. |
Constraints |
---|
TxSimple_Min_Transmit_Constraint Defined over:
TX_SIMPLE_OPR_TMPS Transmitted power should exceed the transmission line’s minimum power flow for in every operational timepoint. |
TxSimple_Max_Transmit_Constraint Defined over:
TX_SIMPLE_OPR_TMPS Transmitted power cannot exceed the transmission line’s maximum power flow in every operational timepoint. |
TxSimple_Losses_LZ_From_Constraint Defined over:
TX_SIMPLE_OPR_TMPS Losses to be accounted for in the “from” load zone’s load balance are 0 when power flow on the line is positive (power flowing from the “from” to the “to” load zone) and must be greater than or equal to the flow times the loss factor otherwise (power flowing to the “from” load zone). |
TxSimple_Losses_LZ_To_Constraint Defined over:
TX_SIMPLE_OPR_TMPS Losses to be accounted for in the “to” load zone’s load balance are 0 when power flow on the line is negative (power flowing from the “to” to the “from” load zone) and must be greater than or equal to the flow times the loss factor otherwise (power flowing to the “to” load zone). |
TxSimple_Max_Losses_From_Constraint Defined over:
TX_SIMPLE_OPR_TMPS Losses cannot exceed the maximum transmission flow capacity times the loss factor in each operational timepoint. Provides upper bound on losses. |
TxSimple_Max_Losses_To_Constraint Defined over:
TX_SIMPLE_OPR_TMPS Losses cannot exceed the maximum transmission flow capacity times the loss factor in each operational timepoint. Provides upper bound on losses. |
gridpath.transmission.operations.operational_types.tx_dcopf¶
The following Pyomo model components are defined in this module:
Sets |
---|
TX_DCOPF The set of transmission lines of the |
TX_DCOPF_OPR_TMPS Two-dimensional set with transmission lines of the |
Derived Sets |
---|
PRDS_CYCLES_ZONES Three-dimensional set describing the combination of periods, cycles, and zones/nodes. A cycle is a “basic cycle” in the network as defined in graph theory. This is the key set on which most other sets are derived. |
PRDS_CYCLES Two-dimensional set with the period and cycle_id of the independent cycles of the network graph (the network can change between periods). |
CYCLES_OPR_TMPS Two-dimensional set with of cycle IDs and operational timepoints. KVL constraint is indexed by this set. |
ZONES_IN_PRD_CYCLE Defined over:
PRDS_CYCLES Indexed set of ordered zones/nodes by period-cycle. Helper set, not directly used in constraints/param indices. |
PRDS_CYCLES_TX_DCOPF Three-dimensional set of periods, cycle_ids, and transmission lines in
that period-cycle. This set is used to determine the set
|
TX_DCOPF_IN_PRD_CYCLE Defined over:
PRDS_CYCLES Indexed set of transmission lines in each period-cycle. This set is used in the KVL constraint when summing up the values. |
Required Params |
---|
tx_dcopf_reactance_ohms Defined over:
TX_DCOPF The series reactance in Ohms for each |
Derived Params |
---|
tx_dcopf_cycle_direction Defined over:
PRDS_CYCLES_TX_DCOPF The value of the cycle incidence matrix for each period-cycle-tx_line. |
Variables |
---|
TxDcopf_Transmit_Power_MW Defined over:
TX_DCOPF_OPR_TMPS Within:
Reals The transmission line’s power flow in each timepoint in which the line is operational. Negative power means the power flow goes in the opposite direction of the line’s defined direction. |
Constraints |
---|
TxDcopf_Min_Transmit_Constraint Defined over:
TX_DCOPF_OPR_TMPS Transmitted power should exceed the transmission line’s minimum power flow for in every operational timepoint. |
TxDcopf_Max_Transmit_Constraint Defined over:
TX_DCOPF_OPR_TMPS Transmitted power cannot exceed the transmission line’s maximum power flow in every operational timepoint. |
TxDcopf_Kirchhoff_Voltage_Law_Constraint Defined over:
CYCLES_OPR_TMPS The sum of all potential difference across branches around all cycles in the network must be zero. Using DC OPF assumptions, this can be expressed in terms of the cycle incidence matrix and line reactance. |
gridpath.transmission.operations.operations¶
This is a line-level module that adds to the formulation components that describe the amount of power flowing on each line.
gridpath.system.load_balance.aggregate_transmission_power¶
This module aggregates the net power flow in/out of a load zone on all transmission lines connected to the load zone to create a load-balance production component, and adds it to the load-balance constraint.
Transmission Hurdle Rates¶
If the transmission hurdle rates feature is enabled, the following modules are also included:
gridpath.transmission.operations.hurdle_costs¶
This is a Tx-line-level module that adds to the formulation components that describe the operations-related costs of transmission lines, namely hurdle rate costs. Hurdle rate costs are currently applied on power sent across the transmission line.
gridpath.objective.transmission.aggregate_hurdle_costs¶
This module aggregates transmission-line-timepoint-level operational costs for use in the objective function.
10.2.3. Operating Reserves¶
GridPath can model operating reserve requirements and provision. Reserves currently modeled (none, any, or all can be selected, as they are additive in the model) include regulation up and down, spinning reserves, load-following up and down, and frequency response.
The treatment of operating reserves is standardized. It requires defining the reserve balancing areas with their associated parameters and setting the reserve requirements by balancing area and timepoint; we must also assign a balancing area to each project that can provide the reserve; the model then takes care of creating the appropriate project-level reserve-provision variables, aggregates the provision of reserves, and ensures that total provision of the reserve and the reserve requirement are balanced (or that penalties are applied if not).
Modules from each reserve feature call on standardized methods included in other GridPath modules. The standard methods are included in the following modules:
gridpath.project.operations.reserves.reserve_provision¶
- generic_record_dynamic_components(d, scenario_directory, weather_iteration, hydro_iteration, availability_iteration, subproblem, stage, headroom_or_footroom_dict, ba_column_name, reserve_provision_variable_name, reserve_provision_derate_param_name, reserve_to_energy_adjustment_param_name, reserve_balancing_area_param_name)[source]¶
- Parameters:
d – the DynamicComponents class we’ll be populating
scenario_directory – the base scenario directory
stage – the horizon subproblem, not used here
stage – the stage subproblem, not used here
headroom_or_footroom_dict – the headroom or footroom dictionary with projects as keys and list of headroom or footroom variables, respectively, as values; the keys are populated in the determine_dynamic_inputs method of gridpath.project.__init__
ba_column_name – the name of the column that determines the reserve balancing area for the projects in the projects.tab input file
reserve_provision_variable_name – the variable name for this reserve type
reserve_provision_derate_param_name – the reserve-provision derate paramater name for this reserve type
reserve_to_energy_adjustment_param_name – the reserve-to-energy-adjustment parameter name for this reserve type
reserve_balancing_area_param_name – the project-level balancing area parameter name for this reserve type
This method populates the following ‘dynamic components’:
headroom_variables or footroom_variables
reserve_variable_derate_params
reserve_to_energy_adjustment_params
The headroom_variables and footroom_variables components are populated based on the data in the projects.tab input file.
When this method is called, the module calling it will specify whether the respective reserve variable name should be added to the headroom or footroom dictionaries. The reserve module will also specify what the name is of the column in projects.tab where the project’s balancing area for the respective reserve is specified, the ba_column_name. For projects for which a balancing area is specified (as opposed to having a ‘.’ value indicating no balancing area), the respective reserve-provision variable name (the reserve_provision_variable_name specified by the reserve module calling this method) will be added to the project’s list of headroom/footroom variables. These lists will then be passed to the ‘add_model_components’ method of the operational-modules and used to build the appropriate operational constraints for each project, usually named the ‘max power rule’ (power + upward reserves must be less than or equal to online capacity) and ‘min power rule’ (power - downward reserves must be greater than or equal to the minimum stable level) in the operational-type modules.
Advanced GridPath functionality includes the ability to put a more stringent constraint on reserve-provision than the available headroom/footroom by de-rating how much of the available project headroom/footroom can be used for a certain reserve-type in the respective constraints in the operational_type modules. The reserve_variable_derate_params dynamic component dictionary is populated here; it has the project-level reserve provision variable as key and the derate param for the respective reserve variable as value.
Note
Currently, these de-rates are only used in the variable operational type and we need to add them to other operational types.
Advanced GridPath functionality also includes the ability to account for the energy effects of reserve-provision. For example, when providing regulation-up during a timepoint, projects will occasionally be called upon, so they will produce extra energy above what was schedule for the timepont. Similarly, if they are providing load-following down, they will occasionally be called upon to reduce their output, so will produce less energy than ‘scheduled’ for the timepoint. To account for this, the simplest treatment is to multiply the reserve-provision variables by a parameter and include that ‘energy’ in other constraints. We create a dictionary of the reserve-provision variables and the adjustment parameter name for each reserve-type requested by the user.
Note
Currently, these adjustments are only used in the variable operational type and we need to add them to other operational types.
10.2.4. Reliability¶
GridPath currently includes the ability to require that a planning reserve requirement be met. Projects can contribute toward the reserve requirement via a simple fraction of their installed capacity or an “ELCC surface” that takes into account declining marginal contributions and/or portfolio effects with other projects. GridPath can also account for “deliverability,” i.e., lower capacity contributions due to transmission limits.
gridpath.project.reliability.prm.prm_simple¶
Simplest PRM contribution where each PRM project contributes a fraction of its installed capacity. Note that projects contributing through the ELCC surface can also simultaneous contribute a simple fraction of their capacity (the fraction defaults to 0 if not specified).
gridpath.project.reliability.prm.elcc_surface¶
Contributions to ELCC surface
gridpath.system.reliability.prm.elcc_surface¶
Total ELCC of projects on ELCC surface
10.2.5. Policy¶
GridPath includes the ability to model certain policies, e.g. a renewable portfolio standard requiring that a certain percentage of demand be met with renewable resources, and a carbon cap, requiring that total emissions be below a certain level.
gridpath.system.policy.carbon_cap¶
gridpath.system.policy.carbon_tax¶
gridpath.system.policy.energy_targets.horizon_energy_target¶
Simplest implementation with a MWh target by balancing type horizon.
gridpath.system.policy.fuel_burn_limits.fuel_burn_limits¶
Fuel burn limit for each fuel and fuel burn balancing area.
gridpath.system.policy.performance_standard.performance_standard¶
Performance standard for each performance_standard zone
10.2.6. Markets¶
GridPath can model market participation of a project or a set of projects. A price stream is required and projects are assumed to be price-takers. The market volume can be constrained. In multi-stage modeling, the transactions from the previous stages can be fixed in the following stages.