9. GridPath Functionality - Advanced¶

This section contains the advanced documentation that is automatically generated from the documentation within each GridPath module.

9.1. Core Functionality¶

This chapter describes GridPath’s basic functionality if no optional features are included.

9.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¶

Timepoints are the finest resolution over which operational decisions are made (e.g. an hour). Generator commitment and dispatch decisions are made for each timepoint, with some constraints applied across timepoints (e.g. ramp constraints.) Most commonly, a timepoint is an hour, but the resolution is flexible: a timepoint could also be a 15-minute, 5-minute, 1-minute, or 4-hour segment. Different timepoint durations can also be mixed, e.g. some can be 5-minute segments and some can be hours.

Timepoints can also be assigned weights in order to represent other timepoints that are not modeled explicitly (e.g. use a 24-hour period per month to represent the whole month using the number of days in that month for the weight of each of the 24 timepoints). Note that all costs incurred at the timepoint level are multiplied by the period-level number_years_represented and discount_factor parameters in the objective function. At the period level we use annualized capacity costs (and multiply those by the number of years in a period), so we must also annualize operational costs incurred at the timepoint level. In other words, we must use the timepoint weights (along with the hours-in-timepoint parameter) to calculate the timepoint-level cost incurred over a year. The sum of timepoint_weight*hours_in_timepoint over all timepoints in a period must therefore equal the number of hours in a year (8760, 8766, or 8784). This will then get multiplied by the number of years in a period and period discount rate to get the total operational costs.

For example, if you are representing a 10-year period with a single day at a 24-hour timepoint resolution, the timepoint weight for each of the 24 timepoints would need to be 365. Timepoint-level costs will be multiplied by 10 automatically to account for the length of the period. If you are representing a 1-year period with a single day at a 24-hour resolution, the timepoint weight would still be 365, and timepoint-level costs will get multiplied by 1 automatically to account for the length of the period. If you are representing a 0.25-year period with a single day at a 24-hour resolution, the timepoint weight would still be 365.

To support multi-stage production simulation timepoints can also be assigned a mapping to the previous stage (e.g. timepoints 1-12 in the 5-minute real-time stage map to timepoint 1 in the hour-ahead stage) and a flag whether the timepoint is part of a spinup or lookahead segment.

Timepoints that are part of a spinup or lookahead segment are included in the optimization but are generally discarded when calculating result metrics such as annual emissions, energy, or cost.

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¶

GridPath organizes timepoints into balancing types and horizons that describe how timepoints are grouped together when making operational decisions, with some operational constraints enforced over the horizon for each balancing type, e.g. hydro budgets or storage energy balance. As a simple example, in the case of modeling a full year with 8760 timepoints, we could have three balancing types: a day, a month, and a year; there would then be 365 horizons of the balancing type ‘day,’ 12 horizons of the balancing type ‘month,’ and 1 horizon of the balancing type ‘year.’ Within each balancing types, horizons are modeled as independent from each other for operational purposes (i.e operational decisions made on one horizon do not affect those made on another horizon). Generator and storage resources in GridPath are also assigned balancing types: a hydro plant of the balancing type ‘day’ would have to meet an energy budget constraint on each of the 365 ‘day’ horizons whereas one of the balancing type ‘year’ would only have a single energy budget constraint grouping all 8760 timepoints.

Each horizon has boundary condition that can be ‘circular,’ ‘linear,’ or ‘linked.’ With the ‘circular’ approach, the last timepoint of the horizon is considered the previous timepoint for the first timepoint of the horizon (for the purposes of functionality such as ramp constraints or tracking storage state of charge). If the boundary is ‘linear,’ then we ignore constraints relating to the previous timepoint in the first timepoint of a horizon. If the boundary is ‘linked,’ then we use the last timepoint of the previous horizon as the previous timepoint for the first timepoint of a horizon (this can only be done when running multiple subproblems and inputs must be specified appropriately).

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¶

Each timepoint in a GridPath model also belongs to a period (e.g. a year), which describes when decisions to build or retire infrastructure are made. A period must be specified in both capacity-expansion and production-cost models. In a production-cost simulation context, we can use the period to exogenously change the amount of available capacity, but the period temporal unit is mostly used in the capacity-expansion approach, as it defines when capacity decisions are made and new infrastructure becomes available (or is retired). That information in turn feeds into the horizon- and timepoint-level operational constraints, i.e. once a generator is build, the optimization is allowed to operate it in subsequent periods (usually for the duration of the generators’s lifetime). You must specify period duration via the period_start_year and period_end_year parameters (the duration is calculated within GridPath based on those values). Note that the start year is inclusive and the end year is exclusive. Capacity can either exist or not for the entire duration of a period. A discount factor can also be applied to weight costs differently depending on when (in which period) they are incurred.

Warning

Support for investment periods that are shorter than 1 year, e.g. monthly investment decisions, is largely untested, so be extra careful if attempting to use this functionality.

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 to `hours_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.

9.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.

9.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]` 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",` :code:`”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.

TODO: considering technology is only used on the results side, should we: keep it here?

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_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_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 `PRJ_OPR_PRDS` set defined in gridpath.project.capacity.capacity.

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_operational_lifetime_yrs_by_vintage`. For instance, capacity of the 2020 vintage with lifetime of 30 years will be assumed operational starting Jan 1, 2020 and through Dec 31, 2049, but will not be operational in 2050.
`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 `PRJ_OPR_PRDS` set defined in gridpath.project.capacity.capacity.
`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 `gen_new_lin_operational_lifetime_yrs_by_vintage`.
`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_financial_lifetime_yrs_by_vintage`. For instance, capacity of the 2020 vintage with lifetime of 30 years will be assumed to incur costs starting Jan 1, 2020 and through Dec 31, 2049, but will not be operational in 2050.
`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 `PRJ_FIN_PRDS` set defined in gridpath.project.capacity.capacity.
`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 `gen_new_lin_operational_lifetime_yrs_by_vintage`.

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 `gen_new_lin_min_cumulative_new_build_mw`.
`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 `gen_new_lin_max_cumulative_new_build_mw`.

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_operational_lifetime_yrs_by_vintage`. For instance, capacity of the 2020 vintage with lifetime of 30 years will be assumed operational starting Jan 1, 2020 and through Dec 31, 2049, but will not be operational in 2050.
`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 `PRJ_OPR_PRDS` set defined in gridpath.project.capacity.capacity.
`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_operational_lifetime_yrs_by_vintage`.
`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 `PRJ_OPR_PRDS` set defined in gridpath.project.capacity.capacity.

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` capacity type.
`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 `PRJ_OPR_PRDS` set defined in gridpath.project.capacity.capacity.
`OPR_PRDS_BY_GEN_RET_LIN` Indexed set that describes the operational periods for each `gen_ret_lin` project.

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 `gen_ret_lin_capacity_mw`.

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` capacity type.
`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 `PRJ_OPR_PRDS` set defined in gridpath.project.capacity.capacity.
`OPR_PRDS_BY_GEN_RET_BIN` Indexed set that describes the operational periods for each `gen_ret_bin` project.

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 `PRJ_OPR_PRDS` set defined in gridpath.project.capacity.capacity.

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_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`.
`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_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_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_operational_lifetime_yrs`. For instance, capacity of 2020 vintage with lifetime of 30 years will be assumed operational starting Jan 1, 2020 and through Dec 31, 2049, but will not be operational in 2050.
`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 `PRJ_OPR_PRDS` set defined in gridpath.project.capacity.capacity.
`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 `stor_new_lin_operational_lifetime_yrs`.

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 `StorNewLin_Build_MW`, making the storage duration sizing an endogenous model decision.

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_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`.
`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_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_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_operational_lifetime_yrs`. For instance, capacity of 2020 vintage with lifetime of 30 years will be assumed operational starting Jan 1, 2020 and through Dec 31, 2049, but will not be operational in 2050.
`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 `PRJ_OPR_PRDS` set defined in gridpath.project.capacity.capacity.
`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 `stor_new_bin_operational_lifetime_yrs`.
`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 `gen_new_lin_financial_lifetime_yrs_by_vintage`. For instance, capacity of the 2020 vintage with lifetime of 30 years will be assumed to incur costs starting Jan 1, 2020 and through Dec 31, 2049, but will not be operational in 2050.
`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 `PRJ_FIN_PRDS` set defined in gridpath.project.capacity.capacity.

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 `PRJ_OPR_PRDS` set defined in gridpath.project.capacity.capacity.

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_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` projects being modeled.
`DR_NEW_OPR_PRDS` Two-dimensional set of all `dr_new` projects and their operational periods. All periods for now.
`DR_NEW_FIN_PRDS` Two-dimensional set of all `dr_new` projects and their financial periods (annual costs incurred). All periods for now.
`DR_NEW_PTS` Two-dimensional set of all `dr_new` projects and their supply curve points.

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_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 `exogenous` availability type.
`AVL_EXOG_OPR_TMPS` Two-dimensional set with projects of the `exogenous` availability type and their operational timepoints.

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 `binary` availability type.
`AVL_BIN_OPR_PRDS` Two-dimensional set with projects of the `binary` availability type and their operational periods.
`AVL_BIN_OPR_TMPS` Two-dimensional set with projects of the `binary` availability type and their operational timepoints.

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_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 `avl_bin_unavl_hrs_per_prd` hours in each period.
`AvlBin_Unavl_Start_and_Stop_Constraint` Defined over: `AVL_BIN_OPR_TMPS` Link the three binary variables in each timepoint such that `AvlBin_Start_Unavailability` is 1 if the project goes from available to unavailable, and `AvlBin_Stop_Unavailability` is 1 if the project goes from unavailable to available.
`AvlBin_Min_Event_Duration_Constraint` Defined over: `AVL_BIN_OPR_TMPS` The duration of each unavailability event should be larger than or equal to `avl_bin_min_unavl_hrs_per_event` hours.
`AvlBin_Min_Time_Between_Events_Constraint` Defined over: `AVL_BIN_OPR_TMPS` The time between unavailability events should be larger than or equal to `avl_bin_min_avl_hrs_between_events` hours.

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 `continuous` availability type.
`AVL_CONT_OPR_PRDS` Two-dimensional set with projects of the `continuous` availability type and their operational periods.
`AVL_CONT_OPR_TMPS` Two-dimensional set with projects of the `continuous` availability type and their operational timepoints.

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_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 `avl_cont_unavl_hrs_per_prd` hours in each period.
`AvlCont_Unavl_Start_and_Stop_Constraint` Defined over: `AVL_CONT_OPR_TMPS` Link the three continuous variables in each timepoint such that `AvlCont_Start_Unavailability` is 1 if the project goes from available to unavailable, and `AvlCont_Stop_Unavailability` is 1 if the project goes from unavailable to available.
`AvlCont_Min_Event_Duration_Constraint` Defined over: `AVL_CONT_OPR_TMPS` The duration of each unavailability event should be larger than or equal to `avl_cont_min_unavl_hrs_per_event` hours.
`AvlCont_Min_Time_Between_Events_Constraint` Defined over: `AVL_CONT_OPR_TMPS` The time between unavailability events should be larger than or equal to `avl_cont_min_avl_hrs_between_events` hours.

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, PERIODS Within: `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`, PERIODS Within: `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` Within: `PROJECTS` set of projects we need to track for the performance standard.

Required Input Params
`performance_standard_zone` Defined over: `PERFORMANCE_STANDARD_PRJS` Within: `PERFORMANCE_STANDARD_ZONES` This param describes the performance standard zone for each performance standard project.

Derived Sets
`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.

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` operational type.
`GEN_SIMPLE_OPR_TMPS` Two-dimensional set with generators of the `gen_simple` operational type and their operational timepoints.
`GEN_SIMPLE_LINKED_TMPS` Two-dimensional set with generators of the `gen_simple` operational type and their linked timepoints.

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 `gen_simple_ramp_up_when_on_rate`.
`GenSimple_Ramp_Down_Constraint` Defined over: `GEN_SIMPLE_OPR_TMPS` Limits the allowed project downward ramp based on the `gen_simple_ramp_down_when_on_rate`.

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` operational type.
`GEN_MUST_RUN_OPR_TMPS` Two-dimensional set with generators of the `gen_must_run` operational type and their operational timepoints.

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` operational type.
`GEN_ALWAYS_ON_OPR_TMPS` Two-dimensional set with generators of the `gen_always_on` operational type and their operational timepoints.
`GEN_ALWAYS_ON_LINKED_TMPS` Two-dimensional set with generators of the `gen_always_on` operational type and their linked timepoints.

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` type can represent a fleet of similar units).
`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 `gen_always_on_ramp_up_when_on_rate`.
`GenAlwaysOn_Ramp_Down_Constraint` Defined over: `GEN_ALWAYS_ON_OPR_TMPS` Limits the allowed project downward ramp based on the `gen_always_on_ramp_down_when_on_rate`.

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` (gen_commit_lin) operational type.
`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` (gen_commit_lin) operational type that also have startup ramp rates specified.
`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_STARTUP_BY_ST_PRJS`). Startup types are ordered from hottest to coldest, e.g. if there are 3 startup types the hottest start is indicated by 1, and the coldest start is indicated by 3.
`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_STARTUP_BY_ST_PRJS` or `GEN_COMMIT_LIN_STARTUP_BY_ST_PRJS` respectively).
`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.

Linked Input Params
`gen_commit_bin_linked_commit` Defined over: `GEN_COMMIT_BIN_LINKED_TMPS` Within: `PercentFraction` `gen_commit_lin_linked_commit` Defined over: `GEN_COMMIT_LIN_LINKED_TMPS` Within: `PercentFraction` The project’s commitment status in the linked timepoints.
`gen_commit_bin_linked_startup` Defined over: `GEN_COMMIT_BIN_LINKED_TMPS` Within: `PercentFraction` `gen_commit_lin_linked_startup` Defined over: `GEN_COMMIT_LIN_LINKED_TMPS` Within: `PercentFraction` The project’s startup status in the linked timepoints.
`gen_commit_bin_linked_shutdown` Defined over: `GEN_COMMIT_BIN_LINKED_TMPS` Within: `PercentFraction` `gen_commit_lin_linked_shutdown` Defined over: `GEN_COMMIT_LIN_LINKED_TMPS` Within: `PercentFraction` The project’s shutdown status in the linked timepoints.
`gen_commit_bin_linked_power_above_pmin` Defined over: `GEN_COMMIT_BIN_LINKED_TMPS` Within: `NonNegativeReals` `gen_commit_lin_linked_power_above_pmin` Defined over: `GEN_COMMIT_LIN_LINKED_TMPS` Within: `NonNegativeReals` The project’s power provision above Pmin in the linked timepoints.
`gen_commit_bin_linked_upwards_reserves` Defined over: `GEN_COMMIT_BIN_LINKED_TMPS` Within: `NonNegativeReals` The project’s upward reserve provision in the linked timepoints.
`gen_commit_bin_linked_downwards_reserves` Defined over: `GEN_COMMIT_BIN_LINKED_TMPS` Within: `NonNegativeReals` `gen_commit_lin_linked_upwards_reserves` Defined over: `GEN_COMMIT_LIN_LINKED_TMPS` Within: `NonNegativeReals` The project’s downward reserve provision in the linked timepoints.
`gen_commit_bin_linked_ramp_up_rate_mw_per_tmp` Defined over: `GEN_COMMIT_BIN_LINKED_TMPS` Within: `NonNegativeReals` `gen_commit_lin_linked_downwards_reserves` Defined over: `GEN_COMMIT_LIN_LINKED_TMPS` Within: `NonNegativeReals` The project’s upward ramp rate in MW in the linked timepoints (depends on timepoint duration.)
`gen_commit_bin_linked_ramp_down_rate_mw_per_tmp` Defined over: `GEN_COMMIT_BIN_LINKED_TMPS` Within: `NonNegativeReals` `gen_commit_lin_linked_ramp_up_rate_mw_per_tmp` Defined over: `GEN_COMMIT_LIN_LINKED_TMPS` Within: `NonNegativeReals` The project’s downward ramp rate in MW in the linked timepoints (depends on timepoint duration.)
`gen_commit_bin_linked_provide_power_startup_by_st_mw` Defined over: `GEN_COMMIT_BIN_LINKED_TMPS_STR_TYPES` Within: `NonNegativeReals` `gen_commit_lin_linked_provide_power_startup_by_st_mw` Defined over: `GEN_COMMIT_LIN_LINKED_TMPS_STR_TYPES` Within: `NonNegativeReals` The project’s startup power provision by startup type for each linked timepoint.
`gen_commit_bin_linked_startup_ramp_rate_by_st_mw_per_tmp` Defined over: `GEN_COMMIT_BIN_LINKED_TMPS_STR_TYPES` Within: `NonNegativeReals` `gen_commit_lin_linked_startup_ramp_rate_by_st_mw_per_tmp` Defined over: `GEN_COMMIT_LIN_LINKED_TMPS_STR_TYPES` Within: `NonNegativeReals` The project’s startup ramp rate in MW by startup type in the linked timepoints (depends on timepoint duration.)
`gen_commit_bin_linked_provide_power_shutdown_mw` Defined over: `GEN_COMMIT_BIN_LINKED_TMPS` Within: `NonNegativeReals` `gen_commit_lin_linked_provide_power_shutdown_mw` Defined over: `GEN_COMMIT_LIN_LINKED_TMPS` Within: `NonNegativeReals` The project’s shutdown power provision for each linked timepoint.
`gen_commit_bin_linked_shutdown_ramp_rate_mw_per_tmp` Defined over: `GEN_COMMIT_BIN_LINKED_TMPS` Within: `NonNegativeReals` `gen_commit_lin_linked_shutdown_ramp_rate_mw_per_tmp` Defined over: `GEN_COMMIT_LIN_LINKED_TMPS` Within: `NonNegativeReals` The project’s shutdown ramp rate in MW in the linked timepoints (depends on timepoint duration.)

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 `gen_commit_bin_ramp_up_when_on_rate`, the availability and capacity in the timepoint, and the timepoint’s duration.
`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 `gen_commit_bin_ramp_down_when_on_rate` , the availability and capacity in the timepoint, and the timepoint’s duration.
`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 `gen_commit_bin_startup_plus_ramp_up_rate_by_st`, the availability and capacity in the timepoint, and the timepoint’s duration.
`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 `gen_commit_bin_shutdown_plus_ramp_down_rate`, the availability and capacity in the timepoint, and the timepoint’s duration.
`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 `gen_commit_bin_min_up_time_hours`.
`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 `gen_commit_bin_min_up_time_hours`.
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 `gen_commit_bin_ramp_up_when_on_rate`.
`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 `gen_commit_bin_ramp_down_when_on_rate`.
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 `gen_commit_bin_startup_plus_ramp_up_rate_by_st`.
`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_Startup` is one).
`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 `gen_commit_bin_startup_plus_ramp_up_rate_by_st`.
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 `gen_commit_bin_shutdown_plus_ramp_down_rate`.
`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_Shutdown` is one).
`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 `gen_commit_bin_shutdown_plus_ramp_down_rate`.
`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` operational type and their operational timepoints.
`GEN_COMMIT_CAP_LINKED_TMPS` Two-dimensional set with generators of the `gen_commit_cap` operational type and their linked timepoints.

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` type can represent a fleet of similar units).
`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 `gen_commit_cap_startup_plus_ramp_up_rate`.
`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 `gen_commit_cap_ramp_up_when_on_rate`.
`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 `gen_commit_cap_shutdown_plus_ramp_down_rate`.
`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 `gen_commit_cap_ramp_down_when_on_rate`.
`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 `gen_commit_cap_min_up_time_hours`.
`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 `gen_commit_cap_min_down_time_hours`.

gridpath.project.capacity.operational_types.gen_hydro¶

The following Pyomo model components are defined in this module:

Sets
`GEN_HYDRO` The set of generators of the `gen_hydro` operational type.
`GEN_HYDRO_OPR_HRZS` Two-dimensional set with generators of the `gen_hydro` operational type and their operational horizons.
`GEN_HYDRO_OPR_TMPS` Two-dimensional set with generators of the `gen_hydro` operational type and their operational timepoints.
`GEN_HYDRO_LINKED_TMPS` Two-dimensional set with generators of the `gen_hydro` operational type and their linked timepoints.

Required Input Params
`gen_hydro_max_power_fraction` Defined over: `GEN_HYDRO_OPR_HRZS` Within: `Reals` The project’s maximum power output in each operational horizon as a fraction of its available capacity.
`gen_hydro_min_power_fraction` Defined over: `GEN_HYDRO_OPR_HRZS` Within: `Reals` The project’s minimum power output in each operational horizon as a fraction of its available capacity.
`gen_hydro_average_power_fraction` Defined over: `GEN_HYDRO_OPR_HRZS` Within: `Reals` The project’s avarage power output in each operational horizon as a fraction of its available capacity. This can be interpreted as the project’s average capacity factor or plant load factor.

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.

Constraints
Power
`GenHydro_Max_Power_Constraint` Defined over: `GEN_HYDRO_OPR_HRZS` Limits the power plus upward reserves based on the `gen_hydro_max_power_fraction` and the available capacity.
`GenHydro_Min_Power_Constraint` Defined over: `GEN_HYDRO_OPR_HRZS` Power provision minus downward reserves should exceed a certain level based on the `gen_hydro_min_power_fraction` and the available capacity.
`GenHydro_Energy_Budget_Constraint` Defined over: `GEN_HYDRO_OPR_HRZS` The project’s average capacity factor in each operational horizon, including curtailment, should match the specified `gen_hydro_average_power_fraction`.
Ramps
`GenHydro_Ramp_Up_Constraint` Defined over: `GEN_HYDRO_OPR_TMPS` Limits the allowed project upward ramp based on the `gen_hydro_ramp_up_when_on_rate`.
`GenHydro_Ramp_Down_Constraint` Defined over: `GEN_HYDRO_OPR_TMPS` Limits the allowed project downward ramp based on the `gen_hydro_ramp_down_when_on_rate`.
Curtailment
`GenHydro_Max_Curtailment_Constraint` Defined over: `GEN_HYDRO_OPR_TMPS` Limits the allowed curtailment to the available power.

gridpath.project.capacity.operational_types.gen_hydro_must_take¶

The following Pyomo model components are defined in this module:

Sets
`GEN_HYDRO_MUST_TAKE` The set of generators of the `gen_hydro_must_take` operational type.
`GEN_HYDRO_MUST_TAKE_OPR_HRZS` Two-dimensional set with generators of the `gen_hydro_must_take` operational type and their operational horizons.
`GEN_HYDRO_MUST_TAKE_OPR_TMPS` Two-dimensional set with generators of the `gen_hydro_must_take` operational type and their operational timepoints.
`GEN_HYDRO_MUST_TAKE_LINKED_TMPS` Two-dimensional set with generators of the `gen_hydro_must_take` operational type and their linked timepoints.

Required Input Params
`gen_hydro_must_take_max_power_fraction` Defined over: `GEN_HYDRO_MUST_TAKE_OPR_HRZS` Within: `Reals` The project’s maximum power output in each operational horizon as a fraction of its available capacity.
`gen_hydro_must_take_min_power_fraction` Defined over: `GEN_HYDRO_MUST_TAKE_OPR_HRZS` Within: `Reals` The project’s minimum power output in each operational horizon as a fraction of its available capacity.
`gen_hydro_must_take_average_power_fraction` Defined over: `GEN_HYDRO_MUST_TAKE_OPR_HRZS` Within: `Reals` The project’s avarage power output in each operational horizon as a fraction of its available capacity. This can be interpreted as the project’s average capacity factor or plant load factor.

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.

Constraints
Power
`GenHydroMustTake_Max_Power_Constraint` Defined over: `GEN_HYDRO_MUST_TAKE_OPR_HRZS` Limits the power plus upward reserves based on the `gen_hydro_must_take_max_power_fraction` and the available capacity.
`GenHydroMustTake_Min_Power_Constraint` Defined over: `GEN_HYDRO_MUST_TAKE_OPR_HRZS` Power provision minus downward reserves should exceed a certain level based on the `gen_hydro_must_take_min_power_fraction` and the available capacity.
`GenHydroMustTake_Energy_Budget_Constraint` Defined over: `GEN_HYDRO_MUST_TAKE_OPR_HRZS` The project’s average capacity factor in each operational horizon, should match the specified `gen_hydro_must_take_average_power_fraction`.
Ramps
`GenHydroMustTake_Ramp_Up_Constraint` Defined over: `GEN_HYDRO_MUST_TAKE_OPR_TMPS` Limits the allowed project upward ramp based on the `gen_hydro_must_take_ramp_up_when_on_rate`.
`GenHydroMustTake_Ramp_Down_Constraint` Defined over: `GEN_HYDRO_MUST_TAKE_OPR_TMPS` Limits the allowed project downward ramp based on the `gen_hydro_must_take_ramp_down_when_on_rate`.

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` operational type.
`GEN_VAR_OPR_TMPS` Two-dimensional set with generators of the `gen_var` operational type and their operational timepoints.

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).

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_Scheduled_Curtailment_MW` Defined over: `GEN_VAR_OPR_TMPS` The available power minus what was actually provided (in MW).
`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 upward reserves in each timepoint based on the `gen_var_cap_factor` and the available capacity.
`GenVar_Min_Power_Constraint` Defined over: `GEN_VAR_OPR_TMPS` Power provision minus downward reserves should exceed 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` operational type.
`GEN_VAR_MUST_TAKE_OPR_TMPS` Two-dimensional set with generators of the `gen_var_must_take` operational type and their operational timepoints.

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` operational type.
`STOR_OPR_TMPS` Two-dimensional set with projects of the `stor` operational type and their operational timepoints.
`STOR_LINKED_TMPS` Two-dimensional set with generators of the `stor` operational type and their linked timepoints.

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` Discharging power in MW from this project in each timepoint in which the project is operational (capacity exists and the project is available).
`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` operational type.
`GEN_VAR_STOR_HYB_OPR_TMPS` Two-dimensional set with generators of the `gen_var_stor_hyb` operational type and their operational timepoints.

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 `gen_var_stor_hyb_cap_factor` and the available capacity (available power) plus the net power from storage.
`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` operational type.
`DR_OPR_TMPS` Two-dimensional set with projects of the `dr` operational type and their operational timepoints.
`DR_OPR_HRZS` Two-dimensional set with projects of the `dr` operational type and their operational horizons.

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` operational type.
`DAC_OPR_TMPS` Two-dimensional set with projects of the `dac` operational type and their operational timepoints.

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.

9.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 the static_load_mw parameter – the load requirement – defined for each load zone z and timepoint tmp, and add it 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).

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¶

The load-balance constraint in GridPath consists of production components and consumption components that are added by various GridPath modules depending on the selected features. The sum of the production components must equal the sum of the consumption components in each zone and timepoint.

At a minimum, for each load zone and timepoint, the user must specify a static load requirement input as a consumption component. On the production side, the model aggregates the power output of projects in the respective load zone and timepoint.

Note

Net power output from storage and demand-side resources can be negative and is currently aggregated with the ‘project’ production component.

Net transmission into/out of the load zone is another possible production component (see Transmission).

The user may also optionally allow unserved energy and/or overgeneration to be incurred by adding the respective variables to the production and consumption components respectively, and assigning a per unit cost for each load-balance violation type.

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}$

9.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¶

GridPath’s objective function consists of modularized components. This modularity allows for different objective functions to be defined. Here, we discuss the objective of maximizing the net present value of revenues minus costs.

Its most basic version includes the aggregated project capacity costs and aggregated project operational costs, and any load-balance penalties incurred (i.e. the aggregated unserved energy and/or overgeneration costs).

Other standard objective function components include:

aggregated transmission line capacity investment costs

aggregated transmission operational costs (hurdle rates)

aggregated reserve violation penalties

GridPath also can include custom objective function components that may not be standard for all systems. Examples currently include:

local capacity shortage penalties

planning reserve margin costs

various tuning costs

Market costs and revenues may also be included.

GridPath can include costs on carbon emissions, so certain formulations can interpreted as minimizing emissions.

All revenue and costs are in net present value terms, with a user-specified discount factor applied depending on the period.

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$

9.2. Advanced Functionality¶

This section describes GridPath’s advanced functionality that can be included by selecting optional features.

9.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 the gen_commit_lin and gen_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 the fixed_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:

9.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 `TX_OPR_PRDS` set defined in gridpath.transmission.capacity.capacity.

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_financial_lifetime_yrs_by_vintage`. For instance, capacity of the 2020 vintage with lifetime of 30 years will be assumed operational starting Jan 1, 2020 and through Dec 31, 2049, but will not be operational in 2050.
`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 `TRANMISSION_OPERATIONAL_PERIODS` set defined in gridpath.transmission.capacity.capacity.
`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 `tx_new_lin_financial_lifetime_yrs_by_vintage`.
`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_financial_lifetime_yrs_by_vintage`. For instance, capacity of the 2020 vintage with lifetime of 30 years will be assumed to incur costs starting Jan 1, 2020 and through Dec 31, 2049, but will not be operational in 2050.
`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_FIN_PRDS` set defined in gridpath.transmission.capacity.capacity.
`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 `tx_new_lin_operational_lifetime_yrs_by_vintage`.

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 `tx_new_lin transmission line`.

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 `tx_new_lin_min_cumulative_new_build_mw`.
`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 `tx_new_lin_max_cumulative_new_build_mw`.

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` operational type.
`TX_SIMPLE_OPR_TMPS` Two-dimensional set with transmission lines of the `tx_simple` operational type and their operational timepoints.

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` operational type.
`TX_DCOPF_OPR_TMPS` Two-dimensional set with transmission lines of the `tx_dcopf` operational type and their operational timepoints.

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`.
`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 `tx_dcopf` transmission line.

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.

9.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.

9.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

9.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.carbon_cap¶

Carbon cap for each carbon_cap zone

gridpath.system.policy.carbon_cap.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

9.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.

9. GridPath Functionality - Advanced¶

9.1. Core Functionality¶

9.1.1. Temporal Setup¶

gridpath.temporal¶

gridpath.temporal.operations¶

gridpath.temporal.operations.timepoints¶

gridpath.temporal.operations.horizons¶

gridpath.temporal.investment¶

gridpath.temporal.investment.periods¶

9.1.2. Geographic Setup¶

gridpath.geography.load_zones¶

9.1.3. Projects¶

gridpath.project.__init__¶

Project Capacity¶

gridpath.project.capacity¶

gridpath.project.capacity.capacity¶

gridpath.project.capacity.costs¶

gridpath.project.capacity.capacity_types¶

gridpath.project.capacity.capacity_types.gen_spec¶

gridpath.project.capacity.capacity_types.gen_new_lin¶

gridpath.project.capacity.capacity_types.gen_new_bin¶

gridpath.project.capacity.capacity_types.gen_ret_lin¶

gridpath.project.capacity.capacity_types.gen_ret_bin¶

gridpath.project.capacity.capacity_types.stor_spec¶

gridpath.project.capacity.capacity_types.stor_new_lin¶

gridpath.project.capacity.capacity_types.stor_new_bin¶

gridpath.project.capacity.capacity_types.gen_stor_hyb_spec¶

gridpath.project.capacity.capacity_types.dr_new¶

Project Availability¶

gridpath.project.availability.availability¶

gridpath.project.availability.availability_types.exogenous¶

gridpath.project.availability.availability_types.binary¶

gridpath.project.availability.availability_types.continuous¶

Project Operations¶

gridpath.project.operations¶

gridpath.project.operations.power¶

gridpath.project.operations.costs¶

gridpath.project.operations.carbon_emissions¶

gridpath.project.operations.carbon_tax¶

gridpath.project.operations.fuel_burn¶

gridpath.project.operations.cycle_select¶

gridpath.project.operations.supplemental_firing¶

gridpath.project.operations.energy_target_contributions¶

gridpath.project.operations.performance_standard¶

gridpath.project.operations.cap_factor_limits¶

gridpath.project.operations.tuning_costs¶

gridpath.project.capacity.operational_types.gen_simple¶

gridpath.project.capacity.operational_types.gen_must_run¶

gridpath.project.capacity.operational_types.gen_always_on¶

gridpath.project.capacity.operational_types.gen_commit_bin¶

gridpath.project.capacity.operational_types.gen_commit_lin¶

gridpath.project.capacity.operational_types.gen_commit_unit_common¶

gridpath.project.capacity.operational_types.gen_commit_cap¶

gridpath.project.capacity.operational_types.gen_hydro¶

gridpath.project.capacity.operational_types.gen_hydro_must_take¶

gridpath.project.capacity.operational_types.gen_var¶

gridpath.project.capacity.operational_types.gen_var_must_take¶

gridpath.project.capacity.operational_types.stor¶

gridpath.project.capacity.operational_types.gen_var_stor_hyb¶

gridpath.project.capacity.operational_types.dr¶

gridpath.project.capacity.operational_types.dac¶

9.1.4. Load Balance¶

gridpath.system.load_balance.static_load_requirement¶

gridpath.system.load_balance.aggregate_project_power¶

gridpath.system.load_balance.load_balance¶

9.1.5. Objective Function¶

gridpath.objective.project.aggregate_capacity_costs¶

gridpath.objective.project.aggregate_operational_costs¶

gridpath.objective.system.aggregate_load_balance_penalties¶

gridpath.objective.max_npv¶

9.2. Advanced Functionality¶

9.2.1. Multi-Stage¶

9.2.2. Transmission¶

gridpath.transmission¶

gridpath.transmission.capacity.capacity_types¶

gridpath.transmission.capacity.capacity_types.tx_spec¶

gridpath.transmission.capacity.capacity_types.tx_new_lin¶

gridpath.transmission.capacity.capacity¶

gridpath.transmission.operations.operational_types¶

gridpath.transmission.operations.operational_types.tx_simple¶

gridpath.project.init¶