diff --git a/Example_Systems/SmallNewEngland/OneZone/Run.jl b/Example_Systems/SmallNewEngland/OneZone/Run.jl index b44ca23ec1..7ce1891834 100644 --- a/Example_Systems/SmallNewEngland/OneZone/Run.jl +++ b/Example_Systems/SmallNewEngland/OneZone/Run.jl @@ -1,3 +1,3 @@ using GenX -run_genx_case!(dirname(@__FILE__)) +run_genx_case!(dirname(@__FILE__)) \ No newline at end of file diff --git a/docs/Project.toml b/docs/Project.toml index 8fa9639426..47a02ccab4 100644 --- a/docs/Project.toml +++ b/docs/Project.toml @@ -1,4 +1,5 @@ [deps] +DataStructures = "864edb3b-99cc-5e75-8d2d-829cb0a9cfe8" Documenter = "e30172f5-a6a5-5a46-863b-614d45cd2de4" GenX = "5d317b1e-30ec-4ed6-a8ce-8d2d88d7cfac" -DataStructures = "864edb3b-99cc-5e75-8d2d-829cb0a9cfe8" +Revise = "295af30f-e4ad-537b-8983-00126c2a3abe" diff --git a/docs/make.jl b/docs/make.jl index 4c76763ebe..2204cd19ef 100644 --- a/docs/make.jl +++ b/docs/make.jl @@ -1,8 +1,4 @@ -push!(LOAD_PATH,"../src/") -#=cd("../") -include(joinpath(pwd(), "package_activate.jl")) -genx_path = joinpath(pwd(), "src") -push!(LOAD_PATH, genx_path)=# +push!(LOAD_PATH, "../src/") import DataStructures: OrderedDict using GenX using Documenter @@ -13,18 +9,38 @@ push!(LOAD_PATH, genx_docpath) pages = OrderedDict( "Welcome Page" => [ "GenX: Introduction" => "index.md", - "Running GenX Cases" => "how_to_run_genx.md", - "Multi-Stage Capacity Expansion Planning with GenX" => "multi_stage_genx.md", + "Installation Guide" => "installation.md", "Limitation of GenX" => "limitations_genx.md", "Third Party Extensions" => "third_party_genx.md" ], + "Getting Started" => [ + "Running GenX" => "examples_casestudies.md", + "Commertial solvers" => "commercial_solvers.md", + ], + "User Guide" => [ + "Overall workflow" => "workflow.md", + "Model Configuration" => "model_configuration.md", + "Solver Configuration" => "solver_configuration.md", + "Model Inputs" => "model_input.md", + "TDR Inputs" => "TDR_input.md", + "Running the TDR" => "running_TDR.md", + "MGA package" => "generate_alternatives.md", + "Multi-stage Model" => "multi_stage_input.md", + "Method of Morris Inputs" => "methodofmorris_input.md", + "Running the Model" => "running_model.md", + "Model Outputs" => "model_output.md", + ], "Model Concept and Overview" => [ "Model Introduction" => "model_introduction.md", "Notation" => "model_notation.md", "Objective Function" => "objective_function.md", - "Power Balance" => "power_balance.md" + "Power Balance" => "power_balance.md", + "Slack Variables for Policies" => "slack_variables_overview.md", + "Maintenance" => "maintenance_overview.md", + "Time Domain Reduction" => "TDR_overview.md", + "Multi-Stage Modeling" => "multi_stage_overview.md", ], - "Model Function Reference" => [ + "Reference" => [ "Core" => "core.md", "Resources" => [ "Curtailable Variable Renewable" => "curtailable_variable_renewable.md", @@ -50,48 +66,50 @@ pages = OrderedDict( "Thermal No Commit" => "thermal_no_commit.md" ], "Hydrogen Electrolyzers" => "electrolyzers.md", + "Retrofit" => "retrofit.md", + "Resources API" => "resources.md", "Scheduled maintenance for various resources" => "maintenance.md", ], - "Multi_stage" => [ - "Configure multi-stage inputs" => "configure_multi_stage_inputs.md", - "Model multi stage: Dual Dynamic Programming Algorithm" => "dual_dynamic_programming.md", - ], "Policies" => "policies.md", - "Slack Variables for Policies" => "slack_variables_overview.md", - ], - "Methods" => "methods.md", - "Solver Configurations" => "solver_configuration.md", - "Solving the Model" => "solve_model.md", - "Model Inputs/Outputs Documentation" => [ - "Single-stage Model" => "data_documentation.md", - "Multi-stage Model" => "multi_stage_model_overview.md", + "Solver Configurations" => "solver_configuration_api.md", + "Inputs Functions" => "load_inputs.md", + "Utility Functions" => "utility_functions.md", + "TDR" => "TDR.md", + "Multi-stage" => [ + "Configure multi-stage inputs" => "configure_multi_stage_inputs.md", + "Model multi stage: Dual Dynamic Programming Algorithm" => "dual_dynamic_programming.md", + "Endogenous Retirement" => "endogenous_retirement.md", + ], + "Public API" => "public_api.md", + "Solving the Model" => "solve_model.md", + "Outputs Functions" => "write_outputs.md", + "Modeling to Generate Alternatives" => "mga.md", + "Method of Morris" => "methodofmorris.md", ], - "GenX Inputs Functions" => "load_inputs.md", - "GenX Outputs Functions" =>"write_outputs.md", - "Additional Features" => "additional_features.md", "Third Party Extensions" => "additional_third_party_extensions.md", - #"Unit Testing (Under Development)" => "unit_testing.md" + # "Unit Testing (Under Development)" => "unit_testing.md" ) makedocs(; modules=[GenX], authors="Jesse Jenkins, Nestor Sepulveda, Dharik Mallapragada, Aaron Schwartz, Neha Patankar, Qingyu Xu, Jack Morris, Sambuddha Chakrabarti", - #repo="https://github.com/sambuddhac/GenX.jl/blob/{commit}{path}#{line}", sitename="GenX", format=Documenter.HTML(; prettyurls=get(ENV, "CI", "false") == "true", - canonical="https://genxproject.github.io/GenX/stable", + canonical="https://github.com/lbonaldo/GenX/stable", assets=String[], + collapselevel=1 ), pages=[p for p in pages] + # warnonly=true ) -deploydocs(; - repo="github.com/GenXProject/GenX.git", - target = "build", - branch = "gh-pages", - devbranch = "main", - devurl = "dev", - push_preview=true, - versions = ["stable" => "v^", "v#.#"], - forcepush = false, -) +# deploydocs(; +# repo="github.com/GenXProject/GenX.git", +# target = "build", +# branch = "gh-pages", +# devbranch = "main", +# devurl = "dev", +# push_preview=true, +# versions = ["stable" => "v^", "v#.#"], +# forcepush = false, +# ) diff --git a/docs/src/TDR.md b/docs/src/TDR.md new file mode 100644 index 0000000000..64c0021aba --- /dev/null +++ b/docs/src/TDR.md @@ -0,0 +1,11 @@ +# Time Domain Reduction (TDR) + +```@autodocs +Modules = [GenX] +Pages = ["time_domain_reduction.jl"] +Order = [:type, :function] +``` + +```@docs +GenX.run_timedomainreduction! +``` \ No newline at end of file diff --git a/docs/src/TDR_input.md b/docs/src/TDR_input.md new file mode 100644 index 0000000000..4c4b9c34f6 --- /dev/null +++ b/docs/src/TDR_input.md @@ -0,0 +1,24 @@ +# Time-domain reduction + +Modeling grid operations for each hour of the year can be computationally expensive for models with many zones and resources. Time-domain reduction is often employed in capacity expansion models as a way to balance model spatial and temporal resolution as well as representation of dispatch, while ensuring reasonable computational times. GenX allows the option of performing time-domain reduction on the user supplied time-series input data to produce a representative time series at the desired level of temporal resolution. The below table summarizes the list of parameters to be specified by the user to perform the time domain reduction implemented in GenX. These parameters are passed to GenX via the YAML file `time_domain_reduction_settings.yml`. + +**Structure of the time\_domain\_reduction.yml file** + +|**Key** | **Description**| +| :------------ | :-----------| +|Timesteps\_per\_period | The number of timesteps (e.g., hours) in each representative period (i.e. 168 for weeks, 24 for days, 72 for three-day periods, etc).| +|UseExtremePeriods | 1 = Include outliers (by performance or demand/resource extreme) as their own representative extreme periods. This setting automatically includes periods based on criteria outlined in the dictionary `ExtremePeriods`. Extreme periods can be selected based on following criteria applied to demand profiles or solar and wind capacity factors profiles, at either the zonal or system level. A) absolute (timestep with min/max value) statistic (minimum, maximum) and B) integral (period with min/max summed value) statistic (minimum, maximum). For example, the user could want the hour with the most demand across the whole system to be included among the extreme periods. They would select Demand, System, Absolute, and Max.| +||0 = Do not include extreme periods.| +|ExtremePeriods | If **UseExtremePeriods = 1**, use this dictionary to select which types of extreme periods to use. Select by profile type (Demand, PV, or Wind), geography (Zone or System), grouping by timestep or by period (Absolute or Integral), and statistic (Maximum or Minimum).| +|ClusterMethod |Either `kmeans` or `kmedoids`, the method used to cluster periods and determine each time step's representative period.| +|ScalingMethod |Either `N` or `S`, the decision to normalize ([0,1]) or standardize (mean 0, variance 1) the input data prior to clustering.| +|MinPeriods |The minimum number of representative periods used to represent the input data. If using UseExtremePeriods, this must be greater or equal to the number of selected extreme periods. If `IterativelyAddPeriods` is off, this will be the total number of representative periods.| +|MaxPeriods| The maximum number of representative periods - both clustered and extreme - that may be used to represent the input data.| +|IterativelyAddPeriods |1 = Add representative periods until the error threshold between input data and represented data is met or the maximum number of representative periods is reached.| +||0 = Use only the minimum number of representative periods. This minimum value includes the selected extreme periods if `UseExtremePeriods` is on.| +|Threshold |Iterative period addition will end if the period farthest from its representative period (as measured using Euclidean distance) is within this percentage of the total possible error (for normalization) or 95% of the total possible error (± 2 σ for standardization). E.g., for a threshold of 0.01, each period must be within 1% of the spread of possible error before the clustering iterations will terminate (or until the maximum is reached).| +|IterateMethod | Either ‘cluster' (Default) or ‘extreme', whether to increment the number of clusters to the kmeans/kmedoids method or to set aside the worst-fitting periods as a new extreme periods.| +|nReps |Default = 200, the number of kmeans/kmedoids repetitions at the same setting.| +|DemandWeight| Default = 1, a multiplier on demand columns to optionally prioritize better fits for demand profiles over resource capacity factor or fuel price profiles.| +|WeightTotal |Default = 8760, the sum to which the relative weights of representative periods will be scaled.| +|ClusterFuelPrices| Either 1 or 0, whether or not to use the fuel price time series in `Fuels_data.csv` in the clustering process. If 'no', this function will still write `Fuels_data.csv` in the TimeDomainReductionFolder with reshaped fuel prices based on the number and size of the representative periods but will not use the fuel price time series for selection of representative periods.| diff --git a/docs/src/TDR_overview.md b/docs/src/TDR_overview.md new file mode 100644 index 0000000000..74de9b3364 --- /dev/null +++ b/docs/src/TDR_overview.md @@ -0,0 +1,13 @@ +# Time Domain Reduction (TDR) + +Rather than modeling and optimizing power grid operations at a high temporal resolution (e.g., hourly, over a full year) while evaluating new capacity investments, which can be computationally expensive for large-scale studies with several resources, it may be useful to consider a reduced temporal resolution to model annual grid operations. +Such a time-domain reduction is often employed in capacity expansion models as a way to balance model spatial and temporal resolution as well as representation of dispatch, while ensuring reasonable computational times. +The time-domain reduction method provided allows the user to automate these features while specifying the various parameters of the time-domain reduction 'clustering' algorithm to be used in formulating the resulting optimization model. + +### Running a case with Time Domain Reduction + +There are two ways to run a case with a reduced (e.g. less than full-year) temporal resolution. +1. Let GenX perform the time domain reduction before optimizing. +2. Bring your own clustered data + +It's also possible for GenX perform clustering separately from the optimization task. Check out the [Running the TDR](@ref) section for more information. \ No newline at end of file diff --git a/docs/src/additional_features.md b/docs/src/additional_features.md deleted file mode 100644 index acbfdd22b4..0000000000 --- a/docs/src/additional_features.md +++ /dev/null @@ -1,12 +0,0 @@ -# Additional Features - -## Modeling to Generate Alternatives -```@autodocs -Modules = [GenX] -Pages = ["modeling_to_generate_alternatives.jl"] -``` -## Method of Morris -```@autodocs -Modules = [GenX] -Pages = ["method_of_morris.jl"] -``` diff --git a/docs/src/commercial_solvers.md b/docs/src/commercial_solvers.md new file mode 100644 index 0000000000..a27b653664 --- /dev/null +++ b/docs/src/commercial_solvers.md @@ -0,0 +1,23 @@ +## Using commercial solvers: Gurobi or CPLEX + +If you want to use the commercial solvers Gurobi or CPLEX: + +- Make sure you have a valid license and the actual solvers for either of Gurobi or CPLEX installed on your machine +- Add Gurobi or CPLEX to the Julia Project. + +``` +$ julia --project=/home/youruser/GenX + +julia> +(GenX) pkg> add Gurobi +-or- +(GenX) pkg> add CPLEX +``` +```@meta +#TODO: Add instructions for adding Gurobi or CPLEX to the Julia Project with the new PR. +``` + +- Set the appropriate solver in the genx_settings.yml file of your case + +!!! warning "Warning" + Note that if you have not already installed the required Julia packages or you do not have a valid Gurobi license on your host machine, you will receive an error message and Run.jl will not run to completion. \ No newline at end of file diff --git a/docs/src/configure_multi_stage_inputs.md b/docs/src/configure_multi_stage_inputs.md index ae1c6f3e98..05b5120e2c 100644 --- a/docs/src/configure_multi_stage_inputs.md +++ b/docs/src/configure_multi_stage_inputs.md @@ -1,4 +1,4 @@ -# configure multi stage inputs +# Configure multi stage inputs ```@autodocs Modules = [GenX] Pages = ["configure_multi_stage_inputs.jl"] diff --git a/docs/src/data_documentation.md b/docs/src/data_documentation.md deleted file mode 100644 index a987a4b1dc..0000000000 --- a/docs/src/data_documentation.md +++ /dev/null @@ -1,1024 +0,0 @@ -# GenX Database Documentation - -## 1 Model setup parameters - -Model settings parameters are specified in a `genx_settings.yml` file which should be located in the current working directory (or to specify an alternative location, edit the `settings_path` variable in your `Run.jl` file). -Settings include those related to model structure, solution strategy and outputs, policy constraints, and others. Model structure related settings parameters affect the formulation of the model constraints and objective function. -Computational performance related parameters affect the accuracy of the solution. -Policy related parameters specify the policy type and policy goal. Network related parameters specify settings related to transmission network expansion and losses. -Note that all settings parameters are case sensitive. - -###### Table 1a: Summary of the Model settings parameters ---- -|**Settings Parameter** | **Description**| -| :------------ | :-----------| -|**Model structure related**|| -|TimeDomainReduction | 1 = Use time domain reduced inputs available in the folder with the name defined by settings parameter `TimeDomainReductionFolder`. If such a folder does not exist or it is empty, time domain reduction will reduce the input data and save the results there.| -||0 = Use the data in the main case folder; do not perform clustering.| -|TimeDomainReductionFolder | Name of the folder where time domain reduced input data is stored.| -|UCommit | Select technical resolution of of modeling thermal generators.| -||0 = no unit commitment.| -||1 = unit commitment with integer clustering.| -||2 = unit commitment with linearized clustering.| -|NetworkExpansion | Flag for activating or deactivating inter-regional transmission expansion.| -||1 = active| -||0 = modeling single zone or for multi-zone problems in which inter regional transmission expansion is not allowed.| -|Trans\_Loss\_Segments | Number of segments to use in piece-wise linear approximation of losses.| -||1: linear| -||>=2: piece-wise quadratic| -|Reserves | Flag for modeling operating reserves .| -||0 = No operating reserves considered. | -||1 = Consider regulation (primary) and spinning (secondary) reserves. | -|StorageLosses | Flag to account for storage related losses.| -||0 = VRE and CO2 constraints DO NOT account for energy lost. | -||1 = constraints account for energy lost. | -|**Policy related**| -|EnergyShareRequirement | Flag for specifying regional renewable portfolio standard (RPS) and clean energy standard policy (CES) related constraints.| -|| Default = 0 (No RPS or CES constraints).| -|| 1 = activate energy share requirement related constraints. | -|CO2Cap | Flag for specifying the type of CO2 emission limit constraint.| -|| 0 = no CO2 emission limit| -|| 1 = mass-based emission limit constraint| -|| 2 = demand + rate-based emission limit constraint| -|| 3 = generation + rate-based emission limit constraint| -|CapacityReserveMargin | Flag for Capacity Reserve Margin constraints. | -|| Default = 0 (No Capacity Reserve Margin constraints)| -|| 1 = activate Capacity Reserve Margin related constraints | -|MinCapReq | Minimum technology carve out requirement constraints.| -|| 1 = if one or more minimum technology capacity constraints are specified| -|| 0 = otherwise| -|MaxCapReq | Maximum system-wide technology capacity limit constraints.| -|| 1 = if one or more maximum technology capacity constraints are specified| -|| 0 = otherwise| -|**Solution strategy and outputs**|| -|Solver | Specifies the solver name (This is not case sensitive i.e. CPLEX/cplex, Gurobi/gurobi, Clp/clp indicate the same solvers, respectively). | -|ParameterScale | Flag to turn on parameter scaling wherein demand, capacity and power variables defined in GW rather than MW. This flag aides in improving the computational performance of the model. | -||1 = Scaling is activated. | -||0 = Scaling is not activated. | -|ModelingToGenerateAlternatives | Modeling to Generate Alternative Algorithm. For details, see [here](https://genxproject.github.io/GenX/dev/additional_features/#Modeling-to-Generate-Alternatives)| -||1 = Use the algorithm. | -||0 = Do not use the algorithm. | -|ModelingtoGenerateAlternativeSlack | value used to define the maximum deviation from the least-cost solution as a part of Modeling to Generate Alternative Algorithm. Can take any real value between 0 and 1. | -|WriteShadowPrices | Get the optimal values of dual variables of various model related constraints, including to estimate electricity prices, stored value of energy and the marginal CO2 prices.| -|MultiStage | Model multiple planning stages | -||1 = Model multiple planning stages as specified in `multi_stage_settings.yml` | -||0 = Model single planning stage | -|MethodofMorris | Method of Morris algorithm | -||1 = Use the algorithm. | -||0 = Do not use the algorithm. | -|**Miscellaneous**|| -|PrintModel | Flag for printing the model equations as .lp file.| -||1 = including the model equation as an output| -||0 = the model equation won't be included as an output| - -Additionally, Solver related settings parameters are specified in the appropriate .yml file (e.g. `gurobi_settings.yml` or `cplex_settings.yml`), -which should be located in the current working directory. -Note that GenX supplies default settings for most solver settings in the various solver-specific functions found in the `src/configure_solver/` directory. -To overwrite default settings, you can specify the below Solver specific settings. -Settings are specific to each solver. - -###### Table 1b: Summary of the Solver settings parameters ---- -|**Settings Parameter** | **Description**| -| :------------ | :-----------| -|**Solver settings**|| -|Method | Algorithm used to solve continuous models or the root node of a MIP model. Generally, barrier method provides the fastest run times for real-world problem set.| -|| CPLEX: CPX\_PARAM\_LPMETHOD - Default = 0; See [link](https://www.ibm.com/docs/en/icos/20.1.0?topic=parameters-algorithm-continuous-linear-problems) for more specifications.| -|| Gurobi: Method - Default = -1; See [link](https://www.gurobi.com/documentation/8.1/refman/method.html) for more specifications.| -|| clp: SolveType - Default = 5; See [link](https://www.coin-or.org/Doxygen/Clp/classClpSolve.html) for more specifications.| -|| HiGHS: Method - Default = "choose"; See [link](https://ergo-code.github.io/HiGHS/dev/options/definitions/) -|BarConvTol | Convergence tolerance for barrier algorithm.| -|| CPLEX: CPX\_PARAM\_BAREPCOMP - Default = 1e-8; See [link](https://www.ibm.com/docs/en/icos/12.8.0.0?topic=parameters-convergence-tolerance-lp-qp-problems) for more specifications.| -|| Gurobi: BarConvTol - Default = 1e-8; See [link](https://www.gurobi.com/documentation/8.1/refman/barconvtol.html)link for more specifications.| -|Feasib\_Tol | All constraints must be satisfied as per this tolerance. Note that this tolerance is absolute.| -|| CPLEX: CPX\_PARAM\_EPRHS - Default = 1e-6; See [link](https://www.ibm.com/docs/en/icos/20.1.0?topic=parameters-feasibility-tolerance) for more specifications.| -|| Gurobi: FeasibilityTol - Default = 1e-6; See [link](https://www.gurobi.com/documentation/9.1/refman/feasibilitytol.html) for more specifications.| -|| clp: PrimalTolerance - Default = 1e-7; See [link](https://www.coin-or.org/Clp/userguide/clpuserguide.html) for more specifications.| -|| clp: DualTolerance - Default = 1e-7; See [link](https://www.coin-or.org/Clp/userguide/clpuserguide.html) for more specifications.| -|Optimal\_Tol | Reduced costs must all be smaller than Optimal\_Tol in the improving direction in order for a model to be declared optimal.| -|| CPLEX: CPX\_PARAM\_EPOPT - Default = 1e-6; See [link](https://www.ibm.com/docs/en/icos/12.8.0.0?topic=parameters-optimality-tolerance) for more specifications.| -|| Gurobi: OptimalityTol - Default = 1e-6; See [link](https://www.gurobi.com/documentation/8.1/refman/optimalitytol.html) for more specifications.| -|Pre\_Solve | Controls the presolve level.| -|| Gurobi: Presolve - Default = -1; See [link](https://www.gurobi.com/documentation/8.1/refman/presolve.html) for more specifications.| -|| clp: PresolveType - Default = 5; See [link](https://www.coin-or.org/Doxygen/Clp/classClpSolve.html) for more specifications.| -|Crossover | Determines the crossover strategy used to transform the interior solution produced by barrier algorithm into a basic solution.| -|| CPLEX: CPX\_PARAM\_SOLUTIONTYPE - Default = 2; See [link](https://www.ibm.com/docs/en/icos/12.8.0.0?topic=parameters-optimality-tolerance) for more specifications.| -|| Gurobi: Crossover - Default = 0; See [link](https://www.gurobi.com/documentation/9.1/refman/crossover.html#:~:text=Use%20value%200%20to%20disable,interior%20solution%20computed%20by%20barrier.) for more specifications.| -|NumericFocus | Controls the degree to which the code attempts to detect and manage numerical issues.| -|| CPLEX: CPX\_PARAM\_NUMERICALEMPHASIS - Default = 0; See [link](https://www.ibm.com/docs/en/icos/12.8.0.0?topic=parameters-numerical-precision-emphasis) for more specifications.| -|| Gurobi: NumericFocus - Default = 0; See [link](https://www.gurobi.com/documentation/9.1/refman/numericfocus.html) for more specifications.| -|TimeLimit | Time limit to terminate the solution algorithm, model could also terminate if it reaches MIPGap before this time.| -|| CPLEX: CPX\_PARAM\_TILIM- Default = 1e+75; See [link](https://www.ibm.com/docs/en/icos/12.8.0.0?topic=parameters-optimizer-time-limit-in-seconds) for more specifications.| -|| Gurobi: TimeLimit - Default = infinity; See [link](https://www.gurobi.com/documentation/9.1/refman/timelimit.html) for more specifications.| -|| clp: MaximumSeconds - Default = -1; See [link](https://www.coin-or.org/Doxygen/Clp/classClpModel.html) for more specifications.| -|MIPGap | Optimality gap in case of mixed-integer program.| -|| CPLEX: CPX\_PARAM\_EPGAP- Default = 1e-4; See [link](https://www.ibm.com/docs/en/icos/20.1.0?topic=parameters-relative-mip-gap-tolerance) for more specifications.| -|| Gurobi: MIPGap - Default = 1e-4; See [link](https://www.gurobi.com/documentation/9.1/refman/mipgap2.html) for more specifications.| -|DualObjectiveLimit | When using dual simplex (where the objective is monotonically changing), terminate when the objective exceeds this limit.| -|| clp: DualObjectiveLimit - Default = 1e308; See [link](https://www.coin-or.org/Doxygen/Clp/classClpModel.html) for more specifications.| -|MaximumIterations | Terminate after performing this number of simplex iterations.| -|| clp: MaximumIterations - Default = 2147483647; See [link](https://www.coin-or.org/Doxygen/Clp/classClpModel.html) for more specifications.| -|LogLevel | Set to 1, 2, 3, or 4 for increasing output. Set to 0 to disable output.| -|| clp: logLevel - Default = 1; See [link](https://www.coin-or.org/Doxygen/Clp/classClpModel.html) for more specifications.| -|| cbc: logLevel - Default = 1; See [link](https://www.coin-or.org/Doxygen/Cbc/classCbcModel.html#a244a08213674ce52ddcf33ab4ff53380a185d42e67d2c4cb7b79914c0ed322b5f) for more specifications.| -|InfeasibleReturn | Set to 1 to return as soon as the problem is found to be infeasible (by default, an infeasibility proof is computed as well).| -|| clp: InfeasibleReturn - Default = 0; See [link](https://www.coin-or.org/Doxygen/Clp/classClpModel.html) for more specifications.| -|Scaling | Sets or unsets scaling; 0 -off, 1 equilibrium, 2 geometric, 3 auto, 4 dynamic(later).| -|| clp: Scaling - Default = 3; See [link](https://www.coin-or.org/Doxygen/Clp/classClpModel.html) for more specifications.| -|Perturbation | Perturbs problem; Switch on perturbation (50), automatic (100), don't try perturbing (102).| -|| clp: Perturbation - Default = 3; See [link](https://www.coin-or.org/Doxygen/Clp/classClpModel.html) for more specifications.| -|maxSolutions | Terminate after this many feasible solutions have been found.| -|| cbc: maxSolutions - Default = -1; See [link](https://www.coin-or.org/Doxygen/Cbc/classCbcModel.html#a244a08213674ce52ddcf33ab4ff53380a185d42e67d2c4cb7b79914c0ed322b5f) for more specifications.| -|maxNodes | Terminate after this many branch-and-bound nodes have been evaluated| -|| cbc: maxNodes - Default = -1; See [link](https://www.coin-or.org/Doxygen/Cbc/classCbcModel.html#a244a08213674ce52ddcf33ab4ff53380a185d42e67d2c4cb7b79914c0ed322b5f) for more specifications.| -| allowableGap | Terminate after optimality gap is less than this value (on an absolute scale)| -|| cbc: allowableGap - Default = -1; See [link](https://www.coin-or.org/Doxygen/Cbc/classCbcModel.html#a244a08213674ce52ddcf33ab4ff53380a185d42e67d2c4cb7b79914c0ed322b5f) for more specifications.| -|ratioGap | Terminate after optimality gap is smaller than this relative fraction.| -|| cbc: ratioGap - Default = Inf; See [link](https://www.coin-or.org/Doxygen/Cbc/classCbcModel.html#a244a08213674ce52ddcf33ab4ff53380a185d42e67d2c4cb7b79914c0ed322b5f) for more specifications.| -|threads | Set the number of threads to use for parallel branch & bound.| -|| cbc: threads - Default = 1; See [link](https://www.coin-or.org/Doxygen/Cbc/classCbcModel.html#a244a08213674ce52ddcf33ab4ff53380a185d42e67d2c4cb7b79914c0ed322b5f) for more specifications.| - - -## 2 Inputs - -All input files are in CSV format. Running the GenX model requires a minimum of five input files. Additionally, the user may need to specify five more input files based on model configuration and type of scenarios of interest. Description and column details of all potential input files are included in the `Input_data_explained` folder in the `Example_Systems` folder. Names of the input files and their functionality is also given below. Note that names of the input files are case sensitive. - - -###### Table 2: Summary of the input files ---- -|**Column Name** | **Description**| -| :------------ | :-----------| -|**Mandatory Files**|| -|Fuels\_data.csv |Specify fuel type, CO2 emissions intensity, and time-series of fuel prices. | -|Network.csv |Specify network topology, transmission fixed costs, capacity and loss parameters.| -|Demand\_data.csv |Specify time-series of demand profiles for each model zone, weights for each time step, demand shedding costs, and optional time domain reduction parameters.| -|Generators\_variability.csv |Specify time-series of capacity factor/availability for each resource.| -|Generators\_data.csv |Specify cost and performance data for generation, storage and demand flexibility resources.| -|**Settings-specific Files**|| -|Reserves.csv |Specify operational reserve requirements as a function of demand and renewables generation and penalty for not meeting these requirements.| -|Energy\_share\_requirement.csv |Specify regional renewable portfolio standard and clean energy standard style policies requiring minimum energy generation from qualifying resources.| -|CO2\_cap.csv |Specify regional CO2 emission limits.| -|Capacity\_reserve\_margin.csv |Specify regional capacity reserve margin requirements.| -|Minimum\_capacity\_requirement.csv |Specify regional minimum technology capacity deployment requirements.| -|Vre\_and\_stor\_data.csv |Specify cost and performance data for co-located VRE and storage resources.| -|Vre\_and\_stor\_solar\_variability.csv |Specify time-series of capacity factor/availability for each solar PV resource that exists for every co-located VRE and storage resource (in DC terms).| -|Vre\_and\_stor\_wind\_variability.csv |Specify time-series of capacity factor/availability for each wind resource that exists for every co-located VRE and storage resource (in AC terms).| - -### 2.1 Mandatory input data - - -#### 2.1.1 Fuels\_data.csv - -• **First row:** names of all fuels used in the model instance which should match the labels used in `Fuel` column in the `Generators_data.csv` file. For renewable resources or other resources that do not consume a fuel, the name of the fuel is `None`. - -• **Second row:** The second row specifies the CO2 emissions intensity of each fuel in tons/MMBtu (million British thermal units). Note that by convention, tons correspond to metric tonnes and not short tons (although as long as the user is internally consistent in their application of units, either can be used). - -• **Remaining rows:** Rest of the rows in this input file specify the time-series for prices for each fuel in $/MMBtu. A constant price can be specified by entering the same value for all hours. - -* ** First column:** The first column in this file denotes, Time\_index, represents the index of time steps in a model instance. - - -#### 2.1.2 Network.csv - -This input file contains input parameters related to: 1) definition of model zones (regions between which transmission flows are explicitly modeled) and 2) definition of transmission network topology, existing capacity, losses and reinforcement costs. The following table describe each of the mandatory parameter inputs need to be specified to run an instance of the model, along with comments for the model configurations when they are needed. - -###### Table 3: Structure of the Network.csv file ---- -|**Column Name** | **Description**| -| :------------ | :-----------| -|**Settings-specific Columns**| -|**Multiple zone model**|| -|Network\_Lines | Numerical index for each network line. The length of this column is counted but the actual values are not used.| -| z* (Network map) **OR** Origin_Zone, Destination_Zone | See below | -|Line\_Max\_Flow\_MW | Existing capacity of the inter-regional transmission line.| -|**NetworkExpansion = 1**|| -|Line\_Max\_Reinforcement\_MW |Maximum allowable capacity addition to the existing transmission line.| -|Line\_Reinforcement\_Cost\_per\_MWyr | Cost of adding new capacity to the inter-regional transmission line.| -|**Trans\_Loss\_Segments = 1**|| -|Line\_Loss\_Percentage | fractional transmission loss for each transmission line|| -|**Trans\_Loss\_Segments > 1**|| -|Ohms | Line resistance in Ohms (used to calculate I^2R losses)| -|kV | Line voltage in kV (used to calculate I^2R losses)| -|**CapacityReserveMargin > 0**|| -|CapRes\_* | Eligibility of the transmission line for adding firm capacity to the capacity reserve margin constraint. * represents the number of the capacity reserve margin constraint.| -||1 = the transmission line is eligible for adding firm capacity to the region| -||0 = the transmission line is not eligible for adding firm capacity to the region| -|DerateCapRes\_* | (0,1) value represents the derating of the firm transmission capacity for the capacity reserve margin constraint.| -|CapResExcl\_* | (-1,1,0) = -1 if the designated direction of the transmission line is inbound to locational deliverability area (LDA) modeled by the capacity reserve margin constraint. = 1 if the designated direction of the transmission line is outbound from the LDA modeled by the capacity reserve margin constraint. Zero otherwise.| -|**MultiStage == 1**| -|Capital\_Recovery\_Period |Capital recovery period (in years) used for determining overnight capital costs from annualized investment costs for network transmission line expansion. | -|Line\_Max\_Flow\_Possible\_MW |Maximum possible line flow in the current model period. Overrides Line\_Max\_Reinforcement\_MW, which is not used when performing multi-stage modeling. | - -There are two interfaces implemented for specifying the network topology itself: a matrix interface and a list interface. -Only one choice is permitted in a given file. - -The list interface consists of a column for the lines origin zone and one for the line's destination zone. -Here is a snippet of the Network.csv file for a map with three zones and two lines: -``` -Network_Lines, Origin_Zone, Destination_Zone, - 1, 1, 2, - 2, 1, 3, -``` - -The matrix interface requires N columns labeled `z1, z2, z3 ... zN`, -and L rows, one for each network line (or interregional path), with a `1` in the column corresponding to the 'origin' zone -and a `-1` in the column corresponding to the 'destination' zone for each line. -Here is the same network map implemented as a matrix: -``` -Network_Lines, z1, z2, z3, - 1, 1, -1, 0, - 2, 1, 0, -1, -``` - -Note that in either case, positive flows indicate flow from origin to destination zone; -negative flows indicate flow from destination to origin zone. - - -#### 2.1.3 Demand\_data.csv (Load\_data.csv) - -This file includes parameters to characterize model temporal resolution to approximate annual grid operations, electricity demand for each time step for each zone, and cost of load shedding. Note that GenX is designed to model hourly time steps. With some care and effort, finer (e.g. 15 minute) or courser (e.g. 2 hour) time steps can be modeled so long as all time-related parameters are scaled appropriately (e.g. time period weights, heat rates, ramp rates and minimum up and down times for generators, variable costs, etc). - -###### Table 4: Structure of the Demand\_data.csv file ---- -|**Column Name** | **Description**| -| :------------ | :-----------| -|**Mandatory Columns**| -|Voll |Value of lost load (also referred to as non-served energy) in $/MWh.| -|Demand\_Segment |Number of demand curtailment/unserved demand segments with different cost and capacity of curtailable demand for each segment. User-specified demand segments. Integer values starting with 1 in the first row. Additional segements added in subsequent rows.| -|Cost\_of\_Demand\_Curtailment\_per\_MW |Cost of non-served energy/demand curtailment (for each segment), reported as a fraction of value of the lost load (non-served demand). If *Demand\_Segment = 1*, then this parameter is a scalar and equal to one. In general this parameter is a vector of length equal to the length of Demand\_Segment.| -|Max\_Demand\_Curtailment| Maximum time-dependent demand curtailable in each segment, reported as % of the demand in each zone and each period. *If Demand\_Segment = 1*, then this parameter is a scalar and equal to one. In general this parameter is a vector of length given by length of Demand\_segment.| -|Time\_Index |Index defining time step in the model.| -|Demand\_MW\_z* |Demand profile of a zone z* in MW; if multiple zones, this parameter will be a matrix with columns equal to number of zones (each column named appropriate zone number appended to parameter) and rows equal to number of time periods of grid operations being modeled.| -|Rep\_Periods |Number of representative periods (e.g. weeks, days) that are modeled to approximate annual grid operations. This is always a single entry. For a full-year model, this is `1`.| -|Timesteps\_per\_Rep\_Period |Number of timesteps per representative period (e.g. 168 if period is set as a week using hour-long time steps). This is always a single entry: all representative periods have the same length. For a full-year model, this entry is equal to the number of time steps.| -|Sub\_Weights |Number of annual time steps (e.g. hours) represented by each timestep in a representative period. The length of this column is equal to the number of representative periods. The sum of the elements should be equal to the total number of time steps in a model time horizon (e.g. 8760 hours if modeling 365 days or 8736 if modeling 52 weeks).| - - - -#### 2.1.4 Generator\_variability.csv - -This file contains the time-series of capacity factors / availability of each resource included in the `Generators_data.csv` file for each time step (e.g. hour) modeled. - -• First column: The first column contains the time index of each row (starting in the second row) from 1 to N. - -• Second column onwards: Resources are listed from the second column onward with headers matching each resource name in the `Generators_data.csv` file in any order. The availability for each resource at each time step is defined as a fraction of installed capacity and should be between 0 and 1. Note that for this reason, resource names specified in `Generators_data.csv` must be unique. Note that for Hydro reservoir resources (i.e. `HYDRO = 1` in the `Generators_data.csv`), values in this file correspond to inflows (in MWhs) to the hydro reservoir as a fraction of installed power capacity, rather than hourly capacity factor. Note that for co-located VRE and storage resources, solar PV and wind resource profiles should not be located in this file but rather in separate variability files (these variabilities can be in the `Generators_variability.csv` if time domain reduction functionalities will be utilized because the time domain reduction functionalities will separate the files after the clustering is completed). - -#### 2.1.5 Generators\_data.csv - -This file contains cost and performance parameters for various generators and other resources (storage, flexible demand, etc) included in the model formulation. - -###### Table 5: Mandatory columns in the Generators\_data.csv file ---- -|**Column Name** | **Description**| -| :------------ | :-----------| -|Resource | This column contains **unique** names of resources available to the model. Resources can include generators, storage, and flexible or time shiftable demand.| -|Zone | Integer representing zone number where the resource is located. | -|**Technology type flags**| -|New\_Build | {-1, 0, 1}, Flag for resource (storage, generation) eligibility for capacity expansion.| -||New\_Build = 1: eligible for capacity expansion and retirement. | -||New\_Build = 0: not eligible for capacity expansion, eligible for retirement.| -||New\_Build = -1: not eligible for capacity expansion or retirement.| -|THERM | {0, 1, 2}, Flag to indicate membership in set of thermal resources (e.g. nuclear, combined heat and power, natural gas combined cycle, coal power plant)| -||THERM = 0: Not part of set (default) | -||THERM = 1: If the power plant relies on thermal energy input and subject unit commitment constraints/decisions if `UCommit >= 1` (e.g. cycling decisions/costs/constraints). | -||THERM = 2: If the power plant relies on thermal energy input and is subject to simplified economic dispatch constraints (ramping limits and minimum output level but no cycling decisions/costs/constraints). | -|Cap\_size | Size (MW) of a single generating unit. This is used only for resources with integer unit commitment (`THERM = 1`) - not relevant for other resources.| -|VRE | {0, 1}, Flag to indicate membership in set of dispatchable (or curtailable) variable renewable energy resources (onshore wind, offshore wind, utility-scale solar PV, and distributed solar PV subject to dispatch signals).| -||VRE = 0: Not part of set (default) | -||VRE = 1: Dispatchable variable renewable energy (VRE) resources. | -|Num\_VRE\_bins | Number of resource availability profiles considered for each VRE resource per zone. This parameter is used to decide the number of capacity investment decision variables related to a single variable renewable energy technology in each zone.| -||Num\_VRE\_bins = 1: using a single resource availability profile per technology per zone. 1 capacity investment decision variable and 1 generator RID tracking technology power output (and in each zone).| -||Num\_VRE\_bins > 1: using multiple resource availability profiles per technology per zone. Num\_VRE\_bins capacity investment decision variables and 1 generator RID used to define technology power output at each time step (and in each zone). Example: Suppose we are modeling 3 bins of wind profiles for each zone. Then include 3 rows with wind resource names as Wind\_1, Wind\_2, and Wind\_3 and a corresponding increasing sequence of RIDs. Set Num\_VRE\_bins for the generator with smallest RID, Wind\_1, to be 3 and set Num\_VRE\_bins for the other rows corresponding to Wind\_2 and Wind\_3, to be zero. By setting Num\_VRE\_bins for Wind\_2 and Wind\_3, the model eliminates the power outputs variables for these generators. The power output from the technology across all bins is reported in the power output variable for the first generator. This allows for multiple bins without significantly increasing number of model variables (adding each bin only adds one new capacity variable and no operational variables). See documentation for `curtailable_variable_renewable()` for more. | -|MUST\_RUN | {0, 1}, Flag to indicate membership in set of must-run plants (could be used to model behind-the-meter PV not subject to dispatch signals/curtailment, run-of-river hydro that cannot spill water, must-run or self-committed thermal generators, etc). | -||MUST\_RUN = 0: Not part of set (default) | -||MUST\_RUN = 1: Must-run (non-dispatchable) resources.| -|STOR | {0, 1, 2}, Flag to indicate membership in set of storage resources and designate which type of storage resource formulation to employ.| -||STOR = 0: Not part of set (default) | -||STOR = 1: Discharging power capacity and energy capacity are the investment decision variables; symmetric charge/discharge power capacity with charging capacity equal to discharging capacity (e.g. lithium-ion battery storage).| -||STOR = 2: Discharging, charging power capacity and energy capacity are investment variables; asymmetric charge and discharge capacities using distinct processes (e.g. hydrogen electrolysis, storage, and conversion to power using fuel cell or combustion turbine).| -|FLEX | {0, 1}, Flag to indicate membership in set of flexible demand-side resources (e.g. scheduleable or time shiftable demand such as automated EV charging, smart thermostat systems, irrigation pumping demand etc).| -||FLEX = 0: Not part of set (default) | -||FLEX = 1: Flexible demand resource.| -|HYDRO | {0, 1}, Flag to indicate membership in set of reservoir hydro resources.| -||HYDRO = 0: Not part of set (default) | -||HYDRO = 1: Hydropower with reservoir modeling, including inflows, spillage, ramp rate limits and minimum operating level and efficiency loss associated with discharging. Reservoir capacity can be represented as a ratio or energy to power. This type of plant cannot charge from grid.| -|ELECTROLYZER | {0, 1}, Flag to indicate membership in set of electrolysis resources (optional input column).| -||ELECTROLYZER = 0: Not part of set (default) | -||ELECTROLYZER = 1: Electrolyzer resources.| -|LDS | {0, 1}, Flag to indicate the resources eligible for long duration storage constraints with inter period linkage (e.g., reservoir hydro, hydrogen storage). Note that for co-located VRE-STOR resources, this flag must be 0 (LDS_VRE_STOR flag exists in VRE-STOR dataframe). | -||LDS = 0: Not part of set (default) | -||LDS = 1: Long duration storage resources| -|VRE_STOR | {0, 1}, Flag to indicate membership in set of co-located variable renewable energy resources (onshore wind and utility-scale solar PV) and storage resources (either short- or long-duration energy storage with symmetric or asymmetric charging or discharging capabilities).| -||VRE_STOR = 0: Not part of set (default) | -||VRE_STOR = 1: Co-located VRE and storage (VRE-STOR) resources. | -|**Existing technology capacity**| -|Existing\_Cap\_MW |The existing capacity of a power plant in MW. Note that for co-located VRE-STOR resources, this capacity represents the existing AC grid connection capacity in MW. | -|Existing\_Cap\_MWh |The existing capacity of storage in MWh where `STOR = 1` or `STOR = 2`. Note that for co-located VRE-STOR resources, this capacity represents the existing capacity of storage in MWh. | -|Existing\_Charge\_Cap\_MW |The existing charging capacity for resources where `STOR = 2`.| -|**Capacity/Energy requirements**| -|Max\_Cap\_MW |-1 (default) – no limit on maximum discharge capacity of the resource. If non-negative, represents maximum allowed discharge capacity (in MW) of the resource. Note that for co-located VRE-STOR resources, this capacity represents the maximum AC grid connection capacity in MW. | -|Max\_Cap\_MWh |-1 (default) – no limit on maximum energy capacity of the resource. If non-negative, represents maximum allowed energy capacity (in MWh) of the resource with `STOR = 1` or `STOR = 2`. Note that for co-located VRE-STOR resources, this capacity represents the maximum capacity of storage in MWh. | -|Max\_Charge\_Cap\_MW |-1 (default) – no limit on maximum charge capacity of the resource. If non-negative, represents maximum allowed charge capacity (in MW) of the resource with `STOR = 2`.| -|Min\_Cap\_MW |-1 (default) – no limit on minimum discharge capacity of the resource. If non-negative, represents minimum allowed discharge capacity (in MW) of the resource. Note that for co-located VRE-STOR resources, this capacity represents the minimum AC grid connection capacity in MW. | -|Min\_Cap\_MWh| -1 (default) – no limit on minimum energy capacity of the resource. If non-negative, represents minimum allowed energy capacity (in MWh) of the resource with `STOR = 1` or `STOR = 2`. Note that for co-located VRE-STOR resources, this capacity represents the minimum capacity of storage in MWh. | -|Min\_Charge\_Cap\_MW |-1 (default) – no limit on minimum charge capacity of the resource. If non-negative, represents minimum allowed charge capacity (in MW) of the resource with `STOR = 2`.| -|**Cost parameters**| -|Inv\_Cost\_per\_MWyr | Annualized capacity investment cost of a technology ($/MW/year). Note that for co-located VRE-STOR resources, this annualized capacity investment cost pertains to the grid connection.| -|Inv\_Cost\_per\_MWhyr | Annualized investment cost of the energy capacity for a storage technology ($/MW/year), applicable to either `STOR = 1` or `STOR = 2`. Note that for co-located VRE-STOR resources, this annualized investment cost of the energy capacity pertains to the co-located storage resource.| -|Inv\_Cost\_Charge\_per\_MWyr | Annualized capacity investment cost for the charging portion of a storage technology with `STOR = 2` ($/MW/year). | -|Fixed\_OM\_Cost\_per\_MWyr | Fixed operations and maintenance cost of a technology ($/MW/year). Note that for co-located VRE-STOR resources, this fixed operations and maintenance cost pertains to the grid connection.| -|Fixed\_OM\_Cost\_per\_MWhyr | Fixed operations and maintenance cost of the energy component of a storage technology ($/MWh/year). Note that for co-located VRE-STOR resources, this fixed operations and maintenance cost of the energy component pertains to the co-located storage resource. | -|Fixed\_OM\_Cost\_Charge\_per\_MWyr | Fixed operations and maintenance cost of the charging component of a storage technology of type `STOR = 2`. | -|Var\_OM\_Cost\_per\_MWh | Variable operations and maintenance cost of a technology ($/MWh). Note that for co-located VRE-STOR resources, these costs apply to the AC generation sent to the grid from the entire site. | -|Var\_OM\_Cost\_per\_MWhIn | Variable operations and maintenance cost of the charging aspect of a storage technology with `STOR = 2`, or variable operations and maintenance costs associated with flexible demand deferral with `FLEX = 1`. Otherwise 0 ($/MWh). Note that for co-located VRE-STOR resources, these costs must be 0 (specific variable operations and maintenance costs exist in VRE-STOR dataframe). | -|**Technical performance parameters**| -|Heat\_Rate\_MMBTU\_per\_MWh |Heat rate of a generator or MMBtu of fuel consumed per MWh of electricity generated for export (net of on-site consumption). The heat rate is the inverse of the efficiency: a lower heat rate is better. Should be consistent with fuel prices in terms of reporting on higher heating value (HHV) or lower heating value (LHV) basis. | -|Fuel |Fuel needed for a generator. The names should match with the ones in the `Fuels_data.csv`. | -|Self\_Disch |[0,1], The power loss of storage technologies per hour (fraction loss per hour)- only applies to storage techs. Note that for co-located VRE-STOR resources, this value applies to the storage component of each resource.| -|Min\_Power |[0,1], The minimum generation level for a unit as a fraction of total capacity. This value cannot be higher than the smallest time-dependent CF value for a resource in `Generators_variability.csv`. Applies to thermal plants, and reservoir hydro resource (`HYDRO = 1`).| -|Ramp\_Up\_Percentage |[0,1], Maximum increase in power output from between two periods (typically hours), reported as a fraction of nameplate capacity. Applies to thermal plants, and reservoir hydro resource (`HYDRO = 1`).| -|Ramp\_Dn\_Percentage |[0,1], Maximum decrease in power output from between two periods (typically hours), reported as a fraction of nameplate capacity. Applies to thermal plants, and reservoir hydro resource (`HYDRO = 1`).| -|Eff\_Up |[0,1], Efficiency of charging storage – applies to storage technologies (all STOR types except co-located storage resources).| -|Eff\_Down |[0,1], Efficiency of discharging storage – applies to storage technologies (all STOR types except co-located storage resources). | -|Hydro\_Energy\_to\_Power\_Ratio |The rated number of hours of reservoir hydro storage at peak discharge power output. Applies to `HYDRO = 1` (hours). | -|Min\_Duration |Specifies the minimum ratio of installed energy to discharged power capacity that can be installed. Applies to STOR types 1 and 2 (hours). Note that for co-located VRE-STOR resources, this value does not apply. | -|Max\_Duration |Specifies the maximum ratio of installed energy to discharged power capacity that can be installed. Applies to STOR types 1 and 2 (hours). Note that for co-located VRE-STOR resources, this value does not apply. | -|Max\_Flexible\_Demand\_Delay |Maximum number of hours that demand can be deferred or delayed. Applies to resources with FLEX type 1 (hours). | -|Max\_Flexible\_Demand\_Advance |Maximum number of hours that demand can be scheduled in advance of the original schedule. Applies to resources with FLEX type 1 (hours). | -|Flexible\_Demand\_Energy\_Eff |[0,1], Energy efficiency associated with time shifting demand. Represents energy losses due to time shifting (or 'snap back' effect of higher consumption due to delay in use) that may apply to some forms of flexible demand. Applies to resources with FLEX type 1 (hours). For example, one may need to pre-cool a building more than normal to advance demand. | -|**Required for writing outputs**| -|region | Name of the model region| -|cluster | Number of the cluster when representing multiple clusters of a given technology in a given region. | -|**MultiStage == 1**| -|Capital\_Recovery\_Period |Capital recovery period (in years) used for determining overnight capital costs from annualized investment costs. Note that for co-located VRE-STOR resources, this value pertains to the grid connection (other capital recovery periods for different components of the resource can be found in the VRE-STOR dataframe). | -|Lifetime |Lifetime (in years) used for determining endogenous retirements of newly built capacity. Note that the same lifetime is used for each component of a co-located VRE-STOR resource. | -|Min\_Retired\_Cap\_MW |Minimum required discharge capacity retirements in the current model period. This field can be used to enforce lifetime retirements of existing capacity. Note that for co-located VRE-STOR resources, this value pertains to the grid connection (other minimum required discharge capacity retirements for different components of the resource can be found in the VRE-STOR dataframe). | -|Min\_Retired\_Energy\_Cap\_MW |Minimum required energy capacity retirements in the current model period. This field can be used to enforce lifetime retirements of existing energy capacity. Note that for co-located VRE-STOR resources, this value pertains to the storage component (other minimum required capacity retirements for different components of the resource can be found in the VRE-STOR dataframe).| -|Min\_Retired\_Charge\_Cap\_MW |Minimum required energy capacity retirements in the current model period. This field can be used to enforce lifetime retirements of existing charge capacity. | - -###### Table 6: Settings-specific columns in the Generators\_data.csv file ---- -|**Column Name** | **Description**| -| :------------ | :-----------| -|**UCommit >= 1** | The following settings apply only to thermal plants with unit commitment constraints (`THERM = 1`).| -|Up\_Time| Minimum amount of time a resource has to stay in the committed state.| -|Down\_Time |Minimum amount of time a resource has to remain in the shutdown state.| -|Start\_Cost\_per\_MW |Cost per MW of nameplate capacity to start a generator ($/MW per start). Multiplied by the number of generation units (each with a pre-specified nameplate capacity) that is turned on.| -|Start\_Fuel\_MMBTU\_per\_MW |Startup fuel use per MW of nameplate capacity of each generator (MMBtu/MW per start).| -|**Reserves = 1** | The following settings apply to thermal, dispatchable VRE, hydro and storage resources| -|Reg\_Cost |Cost of providing regulation reserves ($/MW per time step/hour).| -|Rsv\_Cost |Cost of providing upwards spinning or contingency reserves ($/MW per time step/hour).| -|Reg\_Max |[0,1], Fraction of nameplate capacity that can committed to provided regulation reserves. .| -|Rsv\_Max |[0,1], Fraction of nameplate capacity that can committed to provided upwards spinning or contingency reserves.| -|**EnergyShareRequirement > 0**|| -|ESR\_*| Flag to indicate which resources are considered for the Energy Share Requirement constraint. Note that this flag must be 0 for co-located VRE-STOR resources (policy inputs are read from the specific VRE-STOR dataframe).| -||1- included| -||0- excluded| -|**CapacityReserveMargin > 0**|| -|CapRes\_* |[0,1], Fraction of the resource capacity eligible for contributing to the capacity reserve margin constraint (e.g. derate factor). Note that this fraction must be 0 for co-located VRE-STOR resources (policy inputs are read from the specific VRE-STOR dataframe).| -|**ModelingToGenerateAlternatives = 1**|| -|MGA |Eligibility of the technology for Modeling To Generate Alternative (MGA) run. | -||1 = Technology is available for the MGA run.| -||0 = Technology is unavailable for the MGA run (e.g. storage technologies).| -|Resource\_Type |For the MGA run, we categorize all the resources in a few resource types. We then find maximally different generation portfolio based on these resource types. For example, existing solar and new solar resources could be represented by a resource type names `Solar`. Categorization of resources into resource types is user dependent. Note that this fraction must be 0 for co-located VRE-STOR resources (policy inputs are read from the specific VRE-STOR dataframe).| -|**MinCapReq = 1**| -|MinCapTag\_*| Eligibility of resources to participate in Minimum Technology Carveout constraint. \* corresponds to the ith row of the file `Minimum_capacity_requirement.csv`. Note that this eligibility must be 0 for co-located VRE-STOR resources (policy inputs are read from the specific VRE-STOR dataframe).| -|**MaxCapReq = 1**| -|MaxCapTag\_*| Eligibility of resources to participate in Maximum Technology Carveout constraint. \* corresponds to the ith row of the file `Maximum_capacity_requirement.csv`. Note that this eligibility must be 0 for co-located VRE-STOR resources (policy inputs are read from the specific VRE-STOR dataframe).| -|**PiecewiseFuelUsage-related parameters required if any resources have nonzero PWFU fuel usage, heat rates, and load points**| -|PWFU\_Fuel\_Usage\_Zero\_Load\_MMBTU\_per\_h|The fuel usage (MMBTU/h) for the first PWFU segemnt (y-intercept) at zero load.| -|PWFU\_Heat\_Rate\_MMBTU\_per\_MWh\_*i| The slope of fuel usage function of the segment i.| -|PWFU\_Load\_Point\_MW\_*i| The end of segment i (MW).| -|**Maintenance data**| -|MAINT|[0,1], toggles scheduled maintenance formulation.| -|Maintenance\_Duration| (Positive integer, less than total length of simulation.) Duration of the maintenance period, in number of timesteps. Only used if `MAINT=1`.| -|Maintenance\_Cycle\_Length\_Years| Length of scheduled maintenance cycle, in years. `1` is maintenance every year, `3` is every three years, etc. (Positive integer. Only used if `MAINT=1`.)| -|Maintenance\_Begin\_Cadence| Cadence of timesteps in which scheduled maintenance can begin. `1` means that a maintenance period can start in any timestep, `24` means it can start only in timesteps 1, 25, 49, etc. A larger number can decrease the simulation computational cost as it limits the optimizer's choices. (Positive integer, less than total length of simulation. Only used if `MAINT=1`.)| -|**Electrolyzer related parameters required if the set ELECTROLYZER is not empty**| -|Hydrogen_MWh_Per_Tonne| Electrolyzer efficiency in megawatt-hours (MWh) of electricity per metric tonne of hydrogen produced (MWh/t)| -|Electrolyzer_Min_kt| Minimum annual quantity of hydrogen that must be produced by electrolyzer in kilotonnes (kt)| -|Hydrogen_Price_Per_Tonne| Price (or value) of hydrogen per metric tonne ($/t)| -|Qualified_Hydrogen_Supply| {0,1}, Indicates that generator or storage resources is eligible to supply electrolyzers in the same zone (used for hourly clean supply constraint)| -|**CO2-related parameters required if any resources have nonzero CO2_Capture_Fraction**| -|CO2\_Capture\_Fraction |[0,1], The CO2 capture fraction of CCS-equipped power plants during steady state operation. This value should be 0 for generators without CCS. | -|CO2\_Capture\_Fraction\_Startup |[0,1], The CO2 capture fraction of CCS-equipped power plants during the startup events. This value should be 0 for generators without CCS | -|Biomass | {0, 1}, Flag to indicate if generator uses biomass as feedstock (optional input column).| -||Biomass = 0: Not part of set (default). | -||Biomass = 1: Uses biomass as fuel.| -|CCS\_Disposal\_Cost\_per\_Metric_Ton | Cost associated with CCS disposal ($/tCO2), including pipeline, injection and storage costs of CCS-equipped generators.| - - - -### 2.2 Optional inputs files - -#### 2.2.1 Online Time-domain reduction - -Modeling grid operations for each hour of the year can be computationally expensive for models with many zones and resources. Time-domain reduction is often employed in capacity expansion models as a way to balance model spatial and temporal resolution as well as representation of dispatch, while ensuring reasonable computational times. GenX allows the option of performing time-domain reduction on the user supplied time-series input data to produce a representative time series at the desired level of temporal resolution. The below table summarizes the list of parameters to be specified by the user to perform the time domain reduction implemented in GenX. These parameters are passed to GenX via the YAML file `time_domain_reduction_settings.yml`. - -###### Table 7: Structure of the time_domain_reduction.yml file ---- -|**Key** | **Description**| -| :------------ | :-----------| -|Timesteps\_per\_period | The number of timesteps (e.g., hours) in each representative period (i.e. 168 for weeks, 24 for days, 72 for three-day periods, etc).| -|UseExtremePeriods | 1 = Include outliers (by performance or demand/resource extreme) as their own representative extreme periods. This setting automatically includes periods based on criteria outlined in the dictionary `ExtremePeriods`. Extreme periods can be selected based on following criteria applied to demand profiles or solar and wind capacity factors profiles, at either the zonal or system level. A) absolute (timestep with min/max value) statistic (minimum, maximum) and B) integral (period with min/max summed value) statistic (minimum, maximum). For example, the user could want the hour with the most demand across the whole system to be included among the extreme periods. They would select Demand, System, Absolute, and Max.| -||0 = Do not include extreme periods.| -|ExtremePeriods | If UseExtremePeriods = 1, use this dictionary to select which types of extreme periods to use. Select by profile type (Demand, PV, or Wind), geography (Zone or System), grouping by timestep or by period (Absolute or Integral), and statistic (Maximum or Minimum).| -|ClusterMethod |Either `kmeans` or `kmedoids`, the method used to cluster periods and determine each time step's representative period.| -|ScalingMethod |Either ‘N' or ‘S', the decision to normalize ([0,1]) or standardize (mean 0, variance 1) the input data prior to clustering.| -|MinPeriods |The minimum number of representative periods used to represent the input data. If using UseExtremePeriods, this must be greater or equal to the number of selected extreme periods. If `IterativelyAddPeriods` is off, this will be the total number of representative periods.| -|MaxPeriods| The maximum number of representative periods - both clustered and extreme - that may be used to represent the input data.| -|IterativelyAddPeriods |1 = Add representative periods until the error threshold between input data and represented data is met or the maximum number of representative periods is reached.| -||0 = Use only the minimum number of representative periods. This minimum value includes the selected extreme periods if `UseExtremePeriods` is on.| -|Threshold |Iterative period addition will end if the period farthest from its representative period (as measured using Euclidean distance) is within this percentage of the total possible error (for normalization) or 95% of the total possible error (± 2 σ for standardization). E.g., for a threshold of 0.01, each period must be within 1% of the spread of possible error before the clustering iterations will terminate (or until the maximum is reached).| -|IterateMethod | Either ‘cluster' (Default) or ‘extreme', whether to increment the number of clusters to the kmeans/kmedoids method or to set aside the worst-fitting periods as a new extreme periods.| -|nReps |Default 200, the number of kmeans/kmedoids repetitions at the same setting.| -|DemandWeight| Default 1, a multiplier on demand columns to optionally prioritize better fits for demand profiles over resource capacity factor or fuel price profiles.| -|WeightTotal |Default 8760, the sum to which the relative weights of representative periods will be scaled.| -|ClusterFuelPrices| Either 1 or 0, whether or not to use the fuel price time series in `Fuels_data.csv` in the clustering process. If 'no', this function will still write `Fuels_data.csv` in the TimeDomainReductionFolder with reshaped fuel prices based on the number and size of the representative periods but will not use the fuel price time series for selection of representative periods.| - - - -#### 2.2.2 Reserves.csv - -This file includes parameter inputs needed to model time-dependent procurement of regulation and spinning reserves. This file is needed if `Reserves` flag is activated in the YAML file `genx_settings.yml`. - -###### Table 8: Structure of the Reserves.csv file ---- -|**Column Name** | **Description**| -| :------------ | :-----------| -|Reg\_Req\_Percent\_Demand |[0,1], Regulation requirement as a percent of time-dependent demand; here demand is the total across all model zones.| -|Reg\_Req\_Percent\_VRE |[0,1], Regulation requirement as a percent of time-dependent wind and solar generation (summed across all model zones).| -|Rsv\_Req\_Percent\_Demand [0,1], |Spinning up or contingency reserve requirement as a percent of time-dependent demand (which is summed across all zones).| -|Rsv\_Req\_Percent\_VRE |[0,1], Spinning up or contingency reserve requirement as a percent of time-dependent wind and solar generation (which is summed across all zones).| -|Unmet\_Rsv\_Penalty\_Dollar\_per\_MW |Penalty for not meeting time-dependent spinning reserve requirement ($/MW per time step).| -|Dynamic\_Contingency |Flags to include capacity (generation or transmission) contingency to be added to the spinning reserve requirement.| -|Dynamic\_Contingency |= 1: contingency set to be equal to largest installed thermal unit (only applied when `UCommit = 1`).| -||= 2: contingency set to be equal to largest committed thermal unit each time period (only applied when `UCommit = 1`).| -|Static\_Contingency\_MW |A fixed static contingency in MW added to reserve requirement. Applied when `UCommit = 1` and `DynamicContingency = 0`, or when `UCommit = 2`. Contingency term not included in operating reserve requirement when this value is set to 0 and DynamicContingency is not active.| - - - -#### 2.2.3 Energy\_share\_requirement.csv - -This file contains inputs specifying minimum energy share requirement policies, such as Renewable Portfolio Standard (RPS) or Clean Energy Standard (CES) policies. This file is needed if parameter EnergyShareRequirement has a non-zero value in the YAML file `genx_settings.yml`. - -Note: this file should use the same region name as specified in the `Generators_data.csv` file. - -###### Table 9: Structure of the Energy\_share\_requirement.csv file ---- -|**Column Name** | **Description**| -| :------------ | :-----------| -|Region\_description |Region name| -|Network\_zones |zone number represented as z*| -|ESR\_* |[0,1], Energy share requirements as a share of zonal demand (calculated on an annual basis). * represents the number of the ESR constraint, given by the number of ESR\_* columns in the `Energy_share_requirement.csv` file.| - - - -#### 2.2.4 CO2\_cap.csv - -This file contains inputs specifying CO2 emission limits policies (e.g. emissions cap and permit trading programs). This file is needed if `CO2Cap` flag is activated in the YAML file `genx_settings.yml`. `CO2Cap` flag set to 1 represents mass-based (tCO2 ) emission target. `CO2Cap` flag set to 2 is specified when emission target is given in terms of rate (tCO2/MWh) and is based on total demand met. `CO2Cap` flag set to 3 is specified when emission target is given in terms of rate (tCO2 /MWh) and is based on total generation. - -###### Table 10: Structure of the CO2\_cap.csv file ---- -|**Column Name** | **Description**| -| :------------ | :-----------| -|Region\_description |Region name| -|Network\_zones| zone number represented as z*| -|CO\_2\_Cap\_Zone_* |If a zone is eligible for the emission limit constraint, then this column is set to 1, else 0.| -|CO\_2\_Max\_tons\_MWh_* |Emission limit in terms of rate| -|CO\_2\_Max\_Mtons_* |Emission limit in absolute values, in Million of tons | -| | where in the above inputs, * represents the number of the emission limit constraints. For example, if the model has 2 emission limit constraints applied separately for 2 zones, the above CSV file will have 2 columns for specifying emission limit in terms on rate: CO\_2\_Max\_tons\_MWh\_1 and CO\_2\_Max\_tons\_MWh\_2.| - - - -#### 2.2.5 Capacity\_reserve\_margin.csv - -This file contains the regional capacity reserve margin requirements. This file is needed if parameter CapacityReserveMargin has a non-zero value in the YAML file `genx_settings.yml`. - -Note: this file should use the same region name as specified in the `Generators_data.csv` file - -###### Table 11: Structure of the Capacity\_reserve\_margin.csv file ---- -|**Column Name** | **Description**| -| :------------ | :-----------| -|Region\_description |Region name| -|Network\_zones |zone number represented as z*| -|CapRes\_* |[0,1], Capacity reserve margin requirements of a zone, reported as a fraction of demand| - - - -#### 2.2.6 Minimum\_capacity\_requirement.csv - -This file contains the minimum capacity carve-out requirement to be imposed (e.g. a storage capacity mandate or offshore wind capacity mandate). This file is needed if the `MinCapReq` flag has a non-zero value in the YAML file `genx_settings.yml`. - -###### Table 12: Structure of the Minimum\_capacity\_requirement.csv file ---- -|**Column Name** | **Description**| -| :------------ | :-----------| -|MinCapReqConstraint |Index of the minimum capacity carve-out requirement.| -|Constraint\_Description |Names of minimum capacity carve-out constraints; not to be read by model, but used as a helpful notation to the model user. | -|Min\_MW | minimum capacity requirement [MW]| - - -Some of the columns specified in the input files in Section 2.2 and 2.1 are not used in the GenX model formulation. These columns are necessary for interpreting the model outputs and used in the output module of the GenX. - -#### 2.2.7 Maximum\_capacity\_requirement.csv - -This contains the maximum capacity limits to be imposed (e.g. limits on total deployment of solar, wind, or batteries in the system as a whole or in certain collections of zones). -It is required if the `MaxCapReq` flag has a non-zero value in `genx_settings.yml`. - -###### Table 13: Structure of the Maximum\_capacity\_requirement.csv file ---- -|**Column Name** | **Description**| -| :------------ | :-----------| -|MaxCapReqConstraint |Index of the maximum capacity limit.| -|Constraint\_Description |Names of maximum capacity limit; not to be read by model, but used as a helpful notation to the model user. | -|Max\_MW | maximum capacity limit [MW]| - - -Some of the columns specified in the input files in Section 2.2 and 2.1 are not used in the GenX model formulation. These columns are necessary for interpreting the model outputs and used in the output module of the GenX. - -#### 2.2.8 Method\_of\_morris\_range.csv - -This file contains the settings parameters required to run the Method of Morris algorithm in GenX. This file is needed if the `MethodofMorris` flag is ON in the YAML file `genx_settings.yml`. - -###### Table 14: Structure of the Method\_of\_morris\_range.csv file ---- -|**Column Name** | **Description**| -| :------------ | :-----------| -|Resource | This column contains **unique** names of resources available to the model. Resources can include generators, storage, and flexible or time shiftable demand.| -|Zone | Integer representing zone number where the resource is located. | -|Lower\_bound | Percentage lower deviation from the nominal value| -|Upper\_bound| Percentage upper deviation from the nominal value| -|Parameter| Column from the `Generators_data.csv` file containing uncertain parameters| -|Group| Group the uncertain parameters that will be changed all at once while performing the sensitivity analysis. For example, if the fuel price of natural gas is uncertain, all generators consuming natural gas should be in the same group. Group name is user defined| -|p_steps| Number of steps between upper and lower bound| -|total\_num\_trajectory| Total number of trakectories through the design matrix| -|num\_trajectory| Selected number of trajectories throigh the design matrix| -|len\_design\_mat| Length of the design matrix| -|policy| Name of the policy| - -Notes: -1. Upper and lower bounds are specified in terms of percentage deviation from the nominal value. -2. Percentage variation for uncertain parameters in a given group is identical. For example, if solar cluster 1 and solar cluster 2 both belong to the ‘solar’ group, their Lower_bound and Upper_bound must be identical -3. P\_steps should at least be = 1\%, i.e., Upper\_bound – Lower\_bound $<$ p\_steps -4. P\_steps for parameters in one group must be identical -5. Total\_num\_trajectory should be around 3 to 4 times the total number of uncertain parameters -6. num\_trajectory should be approximately equal to the total number of uncertain parameters -7. len\_design_mat should be 1.5 to 2 times the total number of uncertain parameters -8. Higher number of num\_trajectory and len_design_mat would lead to higher accuracy -9. Upper and lower bounds should be specified for all the resources included in the `Generators_data.csv` file. If a parameter related to a particular resource is not uncertain, specify upper bound = lower bound = 0. - -#### 2.2.9 Vre\_and\_stor\_data.csv - -This file contains additional cost and performance parameters for specifically co-located VRE and storage resources included in the model formulation. -Each co-located VRE and storage generator must be explicitly listed in the `Generators_data.csv` and have the matching unique **Resource** name and **R\_ID** in both the `Generators_data.csv` and the `Vre_and_stor_data.csv`. -This file supplements the `Generators_data.csv` by specifically adding VRE-STOR data and flags that are unique to how this module functions. -Some cost and performance parameters for each co-located resource will be read in from the `Generators_data.csv` (as indicated above in the explanation of inputs from `Generators_data.csv` and from Table 15) and the rest of the specific inputs will be noted here for each resource. -Each co-located VRE and storage resource can be easily configured to contain either a co-located VRE-storage resource, standalone VRE resource (either wind, solar PV, or both), or standalone storage resource. - -###### Table 15: Additional & modified columns for co-located VRE-STOR resources in the Generators\_data.csv file (already noted above but explicitly defined here) ---- -|**Column Name** | **Description**| -| :------------ | :-----------| -|**Added Columns**| -|VRE_STOR | {0, 1}, Flag to indicate membership in set of co-located variable renewable energy resources (onshore wind and utility-scale solar PV) and storage resources (either short- or long-duration energy storage with symmetric or asymmetric charging or discharging capabilities).| -||VRE_STOR = 0: Not part of set (default) | -||VRE_STOR = 1: Co-located VRE and storage (VRE-STOR) resources. | -|**Modified Columns**| -|Existing\_Cap\_MW |The existing capacity of a power plant in MW. Note that for co-located VRE-STOR resources, this capacity represents the existing AC grid connection capacity in MW. | -|Existing\_Cap\_MWh |The existing capacity of storage in MWh where `VRE_STOR = 1`. Note that for co-located VRE-STOR resources, this capacity represents the existing capacity of storage in MWh. | -|Max\_Cap\_MW |-1 (default) – no limit on maximum discharge capacity of the resource. If non-negative, represents maximum allowed discharge capacity (in MW) of the resource. Note that for co-located VRE-STOR resources, this capacity represents the maximum AC grid connection capacity in MW. | -|Max\_Cap\_MWh |-1 (default) – no limit on maximum energy capacity of the resource. If non-negative, represents maximum allowed energy capacity (in MWh) of the resource with or `VRE_STOR = 1`. Note that for co-located VRE-STOR resources, this capacity represents the maximum capacity of storage in MWh. | -|Min\_Cap\_MW |-1 (default) – no limit on minimum discharge capacity of the resource. If non-negative, represents minimum allowed discharge capacity (in MW) of the resource. Note that for co-located VRE-STOR resources, this capacity represents the minimum AC grid connection capacity in MW. | -|Min\_Cap\_MWh| -1 (default) – no limit on minimum energy capacity of the resource. If non-negative, represents minimum allowed energy capacity (in MWh) of the resource with `STOR = 1` or `STOR = 2` or `VRE_STOR = 1`. Note that for co-located VRE-STOR resources, this capacity represents the minimum capacity of storage in MWh. | -|Inv\_Cost\_per\_MWyr | Annualized capacity investment cost of a technology ($/MW/year). Note that for co-located VRE-STOR resources, this annualized capacity investment cost pertains to the grid connection.| -|Inv\_Cost\_per\_MWhyr | Annualized investment cost of the energy capacity for a storage technology ($/MW/year), applicable to either `STOR = 1` or `STOR = 2`. Note that for co-located VRE-STOR resources, this annualized investment cost of the energy capacity pertains to the co-located storage resource.| -|Fixed\_OM\_Cost\_per\_MWyr | Fixed operations and maintenance cost of a technology ($/MW/year). Note that for co-located VRE-STOR resources, this fixed operations and maintenance cost pertains to the grid connection.| -|Fixed\_OM\_Cost\_per\_MWhyr | Fixed operations and maintenance cost of the energy component of a storage technology ($/MWh/year). Note that for co-located VRE-STOR resources, this fixed operations and maintenance cost of the energy component pertains to the co-located storage resource. | -|Self\_Disch |[0,1], The power loss of storage technologies per hour (fraction loss per hour)- only applies to storage techs. Note that for co-located VRE-STOR resources, this value applies to the storage component of each resource.| -|Reg\_Cost | **(If Reserves = 1)** Cost of providing regulation reserves ($/MW per time step/hour).| -|Rsv\_Cost | **(If Reserves = 1)** Cost of providing upwards spinning or contingency reserves ($/MW per time step/hour).| -|Reg\_Max | **(If Reserves = 1)** [0,1], Fraction of nameplate capacity that can committed to provided regulation reserves. .| -|Rsv\_Max | **(If Reserves = 1)** [0,1], Fraction of nameplate capacity that can committed to provided upwards spinning or contingency reserves.| -|Capital\_Recovery\_Period | **(If MultiStage == 1)** Capital recovery period (in years) used for determining overnight capital costs from annualized investment costs. Note that for co-located VRE-STOR resources, this value pertains to the grid connection (other capital recovery periods for different components of the resource can be found in the VRE-STOR dataframe). | -|Lifetime | **(If MultiStage == 1)** Lifetime (in years) used for determining endogenous retirements of newly built capacity. Note that the same lifetime is used for each component of a co-located VRE-STOR resource. | -|Min\_Retired\_Cap\_MW | **(If MultiStage == 1)** Minimum required discharge capacity retirements in the current model period. This field can be used to enforce lifetime retirements of existing capacity. Note that for co-located VRE-STOR resources, this value pertains to the grid connection (other minimum required discharge capacity retirements for different components of the resource can be found in the VRE-STOR dataframe). | -|Min\_Retired\_Energy\_Cap\_MW | **(If MultiStage == 1)** Minimum required energy capacity retirements in the current model period. This field can be used to enforce lifetime retirements of existing energy capacity. Note that for co-located VRE-STOR resources, this value pertains to the storage component (other minimum required capacity retirements for different components of the resource can be found in the VRE-STOR dataframe).| -|MinCapTag\_*| **(If MinCapReq = 1)** Eligibility of resources' grid connection to participate in Minimum Technology Carveout constraint. \* corresponds to the ith row of the file `Minimum_capacity_requirement.csv`. Note that this eligibility must only apply to the interconnection capacity for co-located VRE-STOR resources (policy inputs for solar PV, wind, or battery minimum capacities are read from the specific VRE-STOR dataframe).| -|MaxCapTag\_*| **(If MaxCapReq = 1)** Eligibility of resources' grid connection to participate in Maximum Technology Carveout constraint. \* corresponds to the ith row of the file `Maximum_capacity_requirement.csv`. Note that this eligibility must only apply to the interconnection capacity for co-located VRE-STOR resources (policy inputs for solar PV, wind, or battery maxmum capacities are read from the specific VRE-STOR dataframe).| -|**Columns that Must Be Set to Zero**| -|Var\_OM\_Cost\_per\_MWhIn | Variable operations and maintenance cost of the charging aspect of a storage technology with `STOR = 2`, or variable operations and maintenance costs associated with flexible demand deferral with `FLEX = 1`. Otherwise 0 ($/MWh). Note that for co-located VRE-STOR resources, these costs must be 0 (specific variable operations and maintenance costs exist in VRE-STOR dataframe). | -|ESR\_*| **(If EnergyShareRequirement > 0)** Flag to indicate which resources are considered for the Energy Share Requirement constraint. Note that this flag must be 0 for co-located VRE-STOR resources (policy inputs are read from the specific VRE-STOR dataframe).| -|CapRes\_* | **(If CapacityReserveMargin > 0)** [0,1], Fraction of the resource capacity eligible for contributing to the capacity reserve margin constraint (e.g. derate factor). Note that this fraction must be 0 for co-located VRE-STOR resources (policy inputs are read from the specific VRE-STOR dataframe).| -|LDS | {0, 1}, Flag to indicate the resources eligible for long duration storage constraints with inter period linkage (e.g., reservoir hydro, hydrogen storage). Note that for co-located VRE-STOR resources, this flag must be 0 (LDS_VRE_STOR flag exists in VRE-STOR dataframe). | -||LDS = 0: Not part of set (default) | -||LDS = 1: Long duration storage resources| - -###### Table 16: Mandatory columns in the Vre\_and\_stor\_data.csv file - ---- -|**Column Name** | **Description**| -| :------------ | :-----------| -|Resource | This column contains **unique** names of the co-located VRE and storage resources available to the model and must match the `Generators_data.csv`. | -|Zone | Integer representing zone number where the resource is located. | -|R\_ID | Each resource receives a **unique** number ID, which is explicitly defined in the `Generators_data.csv` or implicitly defined in the GenX model after all of the data has been loaded. The R\_ID of each co-located resource must match the R\_ID either explicitly or implicitly defined in the `Generators_data.csv`.| -|**Technology type flags**| -|SOLAR | {0, 1}, Flag to indicate membership in the set of co-located VRE-storage resources with a solar PV component.| -||SOLAR = 0: Not part of set (default) | -||SOLAR = 1: If the co-located VRE-storage resource can produce solar PV energy. || -|WIND | {0, 1}, Flag to indicate membership in the set of co-located VRE-storage resources with a wind component.| -||WIND = 0: Not part of set (default) | -||WIND = 1: If the co-located VRE-storage resource can produce wind energy. || -|STOR_DC_DISCHARGE | {0, 1, 2}, Flag to indicate membership in set of co-located VRE-storage resources that discharge behind the meter and through the inverter (DC).| -||STOR_DC_DISCHARGE = 0: Not part of set (default) | -||STOR_DC_DISCHARGE = 1: If the co-located VRE-storage resource contains symmetric charge/discharge power capacity with charging capacity equal to discharging capacity (e.g. lithium-ion battery storage). Note that if STOR_DC_DISCHARGE = 1, STOR_DC_CHARGE = 1.| -||STOR_DC_DISCHARGE = 2: If the co-located VRE-storage resource has asymmetric discharge capacities using distinct processes (e.g. hydrogen electrolysis, storage, and conversion to power using fuel cell or combustion turbine).| -|STOR_DC_CHARGE | {0, 1, 2}, Flag to indicate membership in set of co-located VRE-storage resources that charge through the inverter (DC).| -||STOR_DC_CHARGE = 0: Not part of set (default) | -||STOR_DC_CHARGE = 1: If the co-located VRE-storage resource contains symmetric charge/discharge power capacity with charging capacity equal to discharging capacity (e.g. lithium-ion battery storage). Note that if STOR_DC_CHARGE = 1, STOR_DC_DISCHARGE = 1.| -||STOR_DC_CHARGE = 2: If the co-located VRE-storage resource has asymmetric charge capacities using distinct processes (e.g. hydrogen electrolysis, storage, and conversion to power using fuel cell or combustion turbine).| -|STOR_AC_DISCHARGE | {0, 1, 2}, Flag to indicate membership in set of co-located VRE-storage resources that discharges AC.| -||STOR_AC_DISCHARGE = 0: Not part of set (default) | -||STOR_AC_DISCHARGE = 1: If the co-located VRE-storage resource contains symmetric charge/discharge power capacity with charging capacity equal to discharging capacity (e.g. lithium-ion battery storage). Note that if STOR_AC_DISCHARGE = 1, STOR_AC_CHARGE = 1.| -||STOR_AC_DISCHARGE = 2: If the co-located VRE-storage resource has asymmetric discharge capacities using distinct processes (e.g. hydrogen electrolysis, storage, and conversion to power using fuel cell or combustion turbine).| -|STOR_AC_CHARGE | {0, 1, 2}, Flag to indicate membership in set of co-located VRE-storage resources that charge AC.| -||STOR_AC_CHARGE = 0: Not part of set (default) | -||STOR_AC_CHARGE = 1: If the co-located VRE-storage resource contains symmetric charge/discharge power capacity with charging capacity equal to discharging capacity (e.g. lithium-ion battery storage). Note that if STOR_AC_CHARGE = 1, STOR_AC_DISCHARGE = 1.| -||STOR_AC_CHARGE = 2: If the co-located VRE-storage resource has asymmetric charge capacities using distinct processes (e.g. hydrogen electrolysis, storage, and conversion to power using fuel cell or combustion turbine).| -|LDS_VRE_STOR | {0, 1}, Flag to indicate the co-located VRE-storage resources eligible for long duration storage constraints with inter period linkage (e.g., reservoir hydro, hydrogen storage). | -||LDS_VRE_STOR = 0: Not part of set (default) | -||LDS_VRE_STOR = 1: Long duration storage resources| -|**Existing technology capacity**| -|Existing\_Cap\_Inverter\_MW |The existing capacity of co-located VRE-STOR resource's inverter in MW (AC). | -|Existing\_Cap\_Solar\_MW |The existing capacity of co-located VRE-STOR resource's solar PV in MW (DC). | -|Existing\_Cap\_Wind\_MW |The existing capacity of co-located VRE-STOR resource's wind in MW (AC). | -|Existing\_Cap\_Discharge\_DC\_MW |The existing discharge capacity of co-located VRE-STOR resource's storage component in MW (DC). Note that this only applies to resources where `STOR_DC_DISCHARGE = 2`. | -|Existing\_Cap\_Charge\_DC\_MW |The existing charge capacity of co-located VRE-STOR resource's storage component in MW (DC). Note that this only applies to resources where `STOR_DC_CHARGE = 2`. | -|Existing\_Cap\_Discharge\_AC\_MW |The existing discharge capacity of co-located VRE-STOR resource's storage component in MW (AC). Note that this only applies to resources where `STOR_AC_DISCHARGE = 2`. | -|Existing\_Cap\_Charge\_AC\_MW |The existing charge capacity of co-located VRE-STOR resource's storage component in MW (AC). Note that this only applies to resources where `STOR_DC_CHARGE = 2`. | -|**Capacity/Energy requirements**| -|Max\_Cap\_Inverter\_MW |-1 (default) – no limit on maximum inverter capacity of the resource. If non-negative, represents maximum allowed inverter capacity (in MW AC) of the resource. | -|Max\_Cap\_Solar\_MW |-1 (default) – no limit on maximum solar PV capacity of the resource. If non-negative, represents maximum allowed solar PV capacity (in MW DC) of the resource. | -|Max\_Cap\_Wind\_MW |-1 (default) – no limit on maximum wind capacity of the resource. If non-negative, represents maximum allowed wind capacity (in MW AC) of the resource. | -|Max\_Cap\_Discharge\_DC\_MW |-1 (default) – no limit on maximum DC discharge capacity of the resource. If non-negative, represents maximum allowed DC discharge capacity (in MW DC) of the resource with `STOR_DC_DISCHARGE = 2`.| -|Max\_Cap\_Charge\_DC\_MW |-1 (default) – no limit on maximum DC charge capacity of the resource. If non-negative, represents maximum allowed DC charge capacity (in MW DC) of the resource with `STOR_DC_CHARGE = 2`.| -|Max\_Cap\_Discharge\_AC\_MW |-1 (default) – no limit on maximum AC discharge capacity of the resource. If non-negative, represents maximum allowed AC discharge capacity (in MW AC) of the resource with `STOR_AC_DISCHARGE = 2`.| -|Max\_Cap\_Charge\_AC\_MW |-1 (default) – no limit on maximum AC charge capacity of the resource. If non-negative, represents maximum allowed AC charge capacity (in MW AC) of the resource with `STOR_AC_CHARGE = 2`.| -|Min\_Cap\_Inverter\_MW |-1 (default) – no limit on minimum inverter capacity of the resource. If non-negative, represents minimum allowed inverter capacity (in MW AC) of the resource. | -|Min\_Cap\_Solar\_MW |-1 (default) – no limit on minimum solar PV capacity of the resource. If non-negative, represents minimum allowed solar PV capacity (in MW DC) of the resource. | -|Min\_Cap\_Wind\_MW |-1 (default) – no limit on minimum wind capacity of the resource. If non-negative, represents minimum allowed wind capacity (in MW AC) of the resource. | -|Min\_Cap\_Discharge\_DC\_MW |-1 (default) – no limit on minimum DC discharge capacity of the resource. If non-negative, represents minimum allowed DC discharge capacity (in MW DC) of the resource with `STOR_DC_DISCHARGE = 2`.| -|Min\_Cap\_Charge\_DC\_MW |-1 (default) – no limit on minimum DC charge capacity of the resource. If non-negative, represents minimum allowed DC charge capacity (in MW DC) of the resource with `STOR_DC_CHARGE = 2`.| -|Min\_Cap\_Discharge\_AC\_MW |-1 (default) – no limit on minimum AC discharge capacity of the resource. If non-negative, represents minimum allowed AC discharge capacity (in MW AC) of the resource with `STOR_AC_DISCHARGE = 2`.| -|Min\_Cap\_Charge\_AC\_MW |-1 (default) – no limit on minimum AC charge capacity of the resource. If non-negative, represents minimum allowed AC charge capacity (in MW AC) of the resource with `STOR_AC_CHARGE = 2`.| -|**Cost parameters**| -|Inv\_Cost\_Inverter\_per\_MWyr | Annualized capacity investment cost of the inverter component ($/MW-AC/year). | -|Inv\_Cost\_Solar\_per\_MWyr | Annualized capacity investment cost of the solar PV component ($/MW-DC/year). | -|Inv\_Cost\_Wind\_per\_MWyr | Annualized capacity investment cost of the wind component ($/MW-AC/year). | -|Inv\_Cost\_Discharge\_DC\_per\_MWyr | Annualized capacity investment cost for the discharging portion of a storage technology with `STOR_DC_DISCHARGE = 2` ($/MW-DC/year). | -|Inv\_Cost\_Charge\_DC\_per\_MWyr | Annualized capacity investment cost for the charging portion of a storage technology with `STOR_DC_CHARGE = 2` ($/MW-DC/year). | -|Inv\_Cost\_Discharge\_AC\_per\_MWyr | Annualized capacity investment cost for the discharging portion of a storage technology with `STOR_AC_DISCHARGE = 2` ($/MW-AC/year). | -|Inv\_Cost\_Charge\_AC\_per\_MWyr | Annualized capacity investment cost for the charging portion of a storage technology with `STOR_AC_CHARGE = 2` ($/MW-AC/year). | -|Fixed\_OM\_Inverter\_Cost\_per\_MWyr | Fixed operations and maintenance cost of the inverter component ($/MW-AC/year).| -|Fixed\_OM\_Solar\_Cost\_per\_MWyr | Fixed operations and maintenance cost of the solar PV component ($/MW-DC/year).| -|Fixed\_OM\_Wind\_Cost\_per\_MWyr | Fixed operations and maintenance cost of the wind component ($/MW-AC/year).| -|Fixed\_OM\_Cost\_Discharge\_DC\_per\_MWyr | Fixed operations and maintenance cost of the discharging component of a storage technology with `STOR_DC_DISCHARGE = 2` ($/MW-DC/year).| -|Fixed\_OM\_Cost\_Charge\_DC\_per\_MWyr | Fixed operations and maintenance cost of the charging component of a storage technology with `STOR_DC_CHARGE = 2` ($/MW-DC/year).| -|Fixed\_OM\_Cost\_Discharge\_AC\_per\_MWyr | Fixed operations and maintenance cost of the discharging component of a storage technology with `STOR_AC_DISCHARGE = 2` ($/MW-AC/year).| -|Fixed\_OM\_Cost\_Charge\_AC\_per\_MWyr | Fixed operations and maintenance cost of the charging component of a storage technology with `STOR_AC_CHARGE = 2` ($/MW-AC/year).| -|Var\_OM\_Cost\_per\_MWh\_Solar | Variable operations and maintenance cost of the solar PV component (multiplied by the inverter efficiency for AC terms) ($/MWh). | -|Var\_OM\_Cost\_per\_MWh\_Wind | Variable operations and maintenance cost of the wind component ($/MWh). | -|Var\_OM\_Cost\_per\_MWh\_Discharge_DC | Variable operations and maintenance cost of the discharging component of a storage technology with `STOR_DC_DISCHARGE = 2` (multiplied by the inverter efficiency for AC terms) ($/MWh). | -|Var\_OM\_Cost\_per\_MWh\_Charge_DC | Variable operations and maintenance cost of the charging component of a storage technology with `STOR_DC_CHARGE = 2` (divided by the inverter efficiency for AC terms) ($/MWh). | -|Var\_OM\_Cost\_per\_MWh\_Discharge_AC | Variable operations and maintenance cost of the discharging component of a storage technology with `STOR_AC_DISCHARGE = 2` ($/MWh). | -|Var\_OM\_Cost\_per\_MWh\_Charge_AC | Variable operations and maintenance cost of the charging component of a storage technology with `STOR_AC_CHARGE = 2` ($/MWh). | -|**Technical performance parameters**| -|EtaInverter |[0,1], Inverter efficiency representing losses from converting DC to AC power and vice versa for each technology | -|Inverter_Ratio_Solar |-1 (default) - no required ratio between solar PV capacity built to inverter capacity built. If non-negative, represents the ratio of solar PV capacity built to inverter capacity built.| -|Inverter_Ratio_Wind |-1 (default) - no required ratio between wind capacity built to grid connection capacity built. If non-negative, represents the ratio of wind capacity built to grid connection capacity built.| -|Power\_to\_Energy\_AC |The power to energy conversion for the storage component for AC discharging/charging of symmetric storage resources.| -|Power\_to\_Energy\_DC |The power to energy conversion for the storage component for DC discharging/charging of symmetric storage resources.| -|Eff\_Up\_DC |[0,1], Efficiency of DC charging storage – applies to storage technologies (all STOR types). | -|Eff\_Down\_DC |[0,1], Efficiency of DC discharging storage – applies to storage technologies (all STOR types). | -|Eff\_Up\_AC |[0,1], Efficiency of AC charging storage – applies to storage technologies (all STOR types). | -|Eff\_Down\_AC |[0,1], Efficiency of AC discharging storage – applies to storage technologies (all STOR types). | -|**Required for writing outputs**| -|region | Name of the model region| -|cluster | Number of the cluster when representing multiple clusters of a given technology in a given region. | -|technology | Non-unique name of resource (e.g. solar PV, wind) to classify each resource for post-processing purposes. | -|**MultiStage == 1**| -|Capital\_Recovery\_Period_DC |Capital recovery period (in years) used for determining overnight capital costs from annualized investment costs for the inverter component. | -|Capital\_Recovery\_Period_Solar |Capital recovery period (in years) used for determining overnight capital costs from annualized investment costs for the solar PV component. | -|Capital\_Recovery\_Period_Wind |Capital recovery period (in years) used for determining overnight capital costs from annualized investment costs for the wind component. | -|Capital\_Recovery\_Period_Discharge_DC |Capital recovery period (in years) used for determining overnight capital costs from annualized investment costs for the discharge DC component when `STOR_DC_DISCHARGE = 2 `. | -|Capital\_Recovery\_Period_Charge_DC |Capital recovery period (in years) used for determining overnight capital costs from annualized investment costs for the charge DC component when `STOR_DC_CHARGE = 2 `. | -|Capital\_Recovery\_Period_Discharge_AC |Capital recovery period (in years) used for determining overnight capital costs from annualized investment costs for the discharge AC component when `STOR_AC_DISCHARGE = 2 `. | -|Capital\_Recovery\_Period_Charge_AC |Capital recovery period (in years) used for determining overnight capital costs from annualized investment costs for the charge AC component when `STOR_AC_CHARGE = 2 `. | -|Min\_Retired\_Cap\_Inverter\_MW |Minimum required inverter capacity retirements in the current model period. This field can be used to enforce lifetime retirements of existing capacity.| -|Min\_Retired\_Cap\_Solar\_MW |Minimum required solar capacity retirements in the current model period. This field can be used to enforce lifetime retirements of existing capacity.| -|Min\_Retired\_Cap\_Wind\_MW |Minimum required wind capacity retirements in the current model period. This field can be used to enforce lifetime retirements of existing capacity.| -|Min\_Retired\_Cap\_Discharge_DC\_MW |Minimum required discharge capacity retirements in the current model period for storage resources with `STOR_DC_DISCHARGE = 2`. This field can be used to enforce lifetime retirements of existing capacity.| -|Min\_Retired\_Cap\_Charge_DC\_MW |Minimum required charge capacity retirements in the current model period for storage resources with `STOR_DC_CHARGE = 2`. This field can be used to enforce lifetime retirements of existing capacity.| -|Min\_Retired\_Cap\_Discharge_AC\_MW |Minimum required discharge capacity retirements in the current model period for storage resources with `STOR_AC_DISCHARGE = 2`. This field can be used to enforce lifetime retirements of existing capacity.| -|Min\_Retired\_Cap\_Charge_AC\_MW |Minimum required charge capacity retirements in the current model period for storage resources with `STOR_AC_CHARGE = 2`. This field can be used to enforce lifetime retirements of existing capacity.| -| WACC\_DC | The line-specific weighted average cost of capital for the inverter component. | -| WACC\_Solar | The line-specific weighted average cost of capital for the solar PV component. | -| WACC\_Wind | The line-specific weighted average cost of capital for the wind component. | -| WACC\_Discharge\_DC | The line-specific weighted average cost of capital for the discharging DC storage component with `STOR_DC_DISCHARGE = 2`. | -| WACC\_Charge\_DC | The line-specific weighted average cost of capital for the charging DC storage component with `STOR_DC_CHARGE = 2`. | -| WACC\_Discharge\_AC | The line-specific weighted average cost of capital for the discharging AC storage component with `STOR_AC_DISCHARGE = 2`. | -| WACC\_Charge\_AC | The line-specific weighted average cost of capital for the charging AC storage component with `STOR_AC_CHARGE = 2`. | - -###### Table 17: Settings-specific columns in the Vre\_stor\_data.csv file ---- -|**Column Name** | **Description**| -| :------------ | :-----------| -|**EnergyShareRequirement > 0**|| -|ESRVreStor\_*| Flag to indicate which resources are considered for the Energy Share Requirement constraint. | -||1- included| -||0- excluded| -|**CapacityReserveMargin > 0**|| -|CapResVreStor\_* |[0,1], Fraction of the resource capacity eligible for contributing to the capacity reserve margin constraint (e.g. derate factor). | -|**MinCapReq = 1**| -|MinCapTagSolar\_*| Eligibility of resources with a solar PV component (multiplied by the inverter efficiency for AC terms) to participate in Minimum Technology Carveout constraint. \* corresponds to the ith row of the file `Minimum_capacity_requirement.csv`. | -|MinCapTagWind\_*| Eligibility of resources with a wind component to participate in Minimum Technology Carveout constraint (AC terms). \* corresponds to the ith row of the file `Minimum_capacity_requirement.csv`. | -|MinCapTagStor\_*| Eligibility of resources with a storage component to participate in Minimum Technology Carveout constraint (discharge capacity in AC terms). \* corresponds to the ith row of the file `Minimum_capacity_requirement.csv`.| -|**MaxCapReq = 1**| -|MaxCapTagSolar\_*| Eligibility of resources with a solar PV component (multiplied by the inverter efficiency for AC terms) to participate in Maximum Technology Carveout constraint. \* corresponds to the ith row of the file `Maximum_capacity_requirement.csv`. | -|MaxCapTagWind\_*| Eligibility of resources with a wind component to participate in Maximum Technology Carveout constraint (AC terms). \* corresponds to the ith row of the file `Maximum_capacity_requirement.csv`. | -|MaxCapTagStor\_*| Eligibility of resources with a storage component to participate in Maximum Technology Carveout constraint (discharge capacity in AC terms). \* corresponds to the ith row of the file `Maximum_capacity_requirement.csv`.| - -#### 2.2.10 Vre\_and\_stor\_solar\_variability.csv - -This file contains the time-series of capacity factors / availability of the solar PV component (DC capacity factors) of each co-located resource included in the `Vre_and_stor_data.csv` file for each time step (e.g. hour) modeled. - -• first column: The first column contains the time index of each row (starting in the second row) from 1 to N. - -• Second column onwards: Resources are listed from the second column onward with headers matching each resource name in the `Generators_data.csv` and `Vre_and_stor_data.csv` files in any order. The availability for each resource at each time step is defined as a fraction of installed capacity and should be between 0 and 1. Note that for this reason, resource names specified in `Generators_data.csv` and `Vre_and_stor_data.csv` must be unique. - -#### 2.2.11 Vre\_and\_stor\_wind\_variability.csv - -This file contains the time-series of capacity factors / availability of the wind component (AC capacity factors) of each co-located resource included in the `Vre_and_stor_data.csv` file for each time step (e.g. hour) modeled. - -• First column: The first column contains the time index of each row (starting in the second row) from 1 to N. - -• Second column onwards: Resources are listed from the second column onward with headers matching each resource name in the `Generators_data.csv` and `Vre_and_stor_data.csv` files in any order. The availability for each resource at each time step is defined as a fraction of installed capacity and should be between 0 and 1. Note that for this reason, resource names specified in `Generators_data.csv` and `Vre_and_stor_data.csv` must be unique. - - -## 3 Outputs - -The table below summarizes the units of each output variable reported as part of the various CSV files produced after each model run. The reported units are also provided. If a result file includes time-dependent values, the value will not include the hour weight in it. An annual sum ("AnnualSum") column/row will be provided whenever it is possible (e.g., `emissions.csv`). - -### 3.1 Default output files - - -#### 3.1.1 capacity.csv - -Reports optimal values of investment variables (except StartCap, which is an input) - -###### Table 15: Structure of the capacity.csv file ---- -|**Output** |**Description** |**Units** | -| :------------ | :-----------|:-----------| -| StartCap |Initial power capacity of each resource type in each zone; this is an input |MW | -| RetCap |Retired power capacity of each resource type in each zone |MW | -| NewCap |Installed capacity of each resource type in each zone |MW| -| EndCap| Total power capacity of each resource type in each zone |MW | -| CapacityConstraintDual |Shadow price of the capacity limit set by Max_Cap_MW for each resource type in each zone. Values are multiplied by -1 so that the output is >=0. |$/MW | -| StartEnergyCap |Initial energy capacity of each resource type in each zone; this is an input and applies only to storage tech.| MWh | -| RetEnergyCap |Retired energy capacity of each resource type in each zone; applies only to storage tech. |MWh | -| NewEnergyCap| Installed energy capacity of each resource type in each zone; applies only to storage tech. |MWh | -| EndEnergyCap |Total installed energy capacity of each resource type in each zone; applies only to storage tech. |MWh | -| StartChargeCap| Initial charging power capacity of `STOR = 2` resource type in each zone; this is an input |MW | -| RetChargeCap |Retired charging power capacity of `STOR = 2` resource type in each zone |MW | -| NewChargeCap |Installed charging capacity of each resource type in each zone |MW | -| EndChargeCap |Total charging power capacity of each resource type in each zone |MW| - - - -#### 3.1.2 costs.csv - -Reports optimal objective function value and contribution of each term by zone. - -###### Table 16: Structure of the costs.csv file ---- -|**Output** |**Description** |**Units** | -| :------------ | :-----------|:-----------| -| cTotal |Total objective function value |$ | -| cFix |Total annualized investment and fixed operating & maintainenance (FOM) costs associated with all resources |$ | -| cVar |Total annual variable cost associated with all resources; includes fuel costs for thermal plants |$| -| cNSE |Total annual cost of non-served energy |$| -| cStart |Total annual cost of start-up of thermal power plants| $| -| cUnmetRsv |Total annual cost of not meeting time-dependent operating reserve (spinning) requirements |$ | -| cNetworkExp |Total cost of network expansion |$| -| cEmissionsRevenue |Total and zonal emissions revenue |$ | -| cEmissionsCost |Total an zonal emissions cost |$ | - - - -#### 3.1.3 emissions.csv - -Reports CO2 emissions by zone at each hour; an annual sum row will be provided. If any emission cap is present, emission prices each zone faced by each cap will be copied on top of this table with the following strucutre. - -###### Table 17: Structure of emission prices in the emissions.csv file ---- -|**Output** |**Description** |**Units** | -| :------------ | :-----------|:-----------| -|CO_2\_price |Marginal CO2 abatement cost associated with constraint on maximum annual CO2 emissions; will be same across zones if CO2 emissions constraint is applied for the entire region and not zone-wise |\$/ tonne CO2. | - - - -#### 3.1.4 nse.csv - -Reports non-served energy for every model zone, time step and cost-segment. - - -#### 3.1.5 power.csv - -Reports power discharged by each resource (generation, storage, demand response) in each model time step. - - -#### 3.1.6 reliability.csv - -Reports dual variable of maximum non-served energy constraint (shadow price of reliability constraint) for each model zone and time step. - - -#### 3.1.7 prices.csv - -Reports marginal electricity price for each model zone and time step. Marginal electricity price is equal to the dual variable of the power balance constraint. If GenX is configured as a mixed integer linear program, then this output is only generated if `WriteShadowPrices` flag is activated. If configured as a linear program (i.e. linearized unit commitment or economic dispatch) then output automatically available. - - -#### 3.1.8 status.csv - -Reports computational performance of the model and objective function related information. - -###### Table 18: Structure of the status.csv file ---- -|**Output** |**Description** |**Units** | -| :------------ | :-----------|:-----------| -|Status | termination criteria (optimal, timelimit etc.).|| -|solve | Solve time including time for pre-solve |seconds | -|Objval | Optimal objective function value |$| -|Objbound | Best objective lower bound | $ | -|FinalMIPGap |Optimality gap at termination in case of a mixed-integer linear program (MIP gap); when using Gurobi, the lower bound and MIP gap is reported excluding constant terms (E.g. fixed cost of existing generators that cannot be retired) in the objective function and hence may not be directly usable. |Fraction| - - - -#### 3.1.9 NetRevenue.csv - -This file summarizes the cost, revenue and profit for each generation technology for each region. - -###### Table 19: Stucture of the NetRevenue.csv file ---- -|**Output** |**Description** |**Units** | -| :------------ | :-----------|:-----------| -| Fixed\_OM\_cost\_MW | Fixed Operation and Maintenance cost of the MW capacity. |$| -| Fixed\_OM\_cost\_MWh| Fixed Operation and Maintenance cost of the MWh capacity. Only applicable to energy storage.| $ | -| Var\_OM\_cost\_out| Variable Operation and Maintenance cost of the power generation or discharge. |$ | -| Var\_OM\_cost\_in |Variable Operation and Maintenance cost of the power charge/pumping. Only applicable to energy storage. |$ | -| Fuel\_cost| Fuel cost of the power generation. Only applicable to generation that burns fuel. |$ | -| Charge\_cost |Cost of charging power (due to the payment for electricity) Only applicable to energy storage. |$| -| EmissionsCost| Cost of buying emission credit. |$ | -| StartCost |Cost of generator start-up. |$ | -| Inv\_cost\_MW |Cost of building MW capacity. |$ | -| Inv\_cost\_MWh| Cost of building MWh capacity. |$ | -| EnergyRevenue |Revenue of generating power.| $ | -| SubsidyRevenue| Revenue of Min\_Cap subsidy. |$ | -| ReserveMarginRevenue| Revenue earned from capacity reserve margin constraints. |$| -| ESRRevenue| Revenue selling renewable/clean energy credits. |$ | -| Revenue| Total Revenue.| $ | -| Cost| Total Cost. |$ | -| Profit |Revenue minus Cost. |$ | - - - -### 3.2 Settings-specific outputs - -This section includes the output files that GenX will print if corresponding function is specified in the Settings. - - -#### 3.2.1 CapacityValue.csv - -This file includes the time-dependent capacity value calculated for each generator. GenX will print this file only if the capacity reserve margin constraints are modeled through the setting file. Each row of the file (excluding the header) corresponds to a generator specified in the inputs. Each column starting from the t1 to the second last one stores the result of capacity obligation provided in each hour divided by the total capacity. Thus the number is unitless. If the capacity margin reserve is not binding for one hour, GenX will return zero. The last column specified the name of the corresponding capacity reserve constraint. Note that, if the user calculates the hour-weight-averaged capacity value for each generator using data of the binding hours, the result is what RTO/ISO call capacity credit. - - - - -#### 3.2.2 EnergyRevenue.csv - -This file includes the energy revenue in $ earned by each generator through injecting into the grid. Only annual sum values are available. - - -#### 3.2.3 ChargingCost.csv - -This file includes the charging cost in $ of earned by each generator through withdrawing from the grid. Only annual sum values are available. - - -#### 3.2.4 ReserveMargin.csv - -This file includes the shadow prices of the capacity reserve margin constraints. GenX will print this file only when capacity reserve margin is modeled and the shadow price can be obtained form the solver, as described earlier. Each row (except the header) corresponds to a capacity reserve margin constraint, and each column corresponds to an time step. As a reminder, GenX models the capacity reserve margin (aka capacity market) at the time-dependent level, and each constraint either stands for an overall market or a locality constraint. - - -#### 3.2.5 ReserveMarginRevenue.csv - -This file includes the capacity revenue earned by each generator listed in the input file. GenX will print this file only when capacity reserve margin is modeled and the shadow price can be obtained form the solver. Each row corresponds to a generator, and each column starting from the 6th to the second last is the total revenue from each capacity reserve margin constraint. The revenue is calculated as the capacity contribution of each time steps multiplied by the shadow price, and then the sum is taken over all modeled time steps. The last column is the total revenue received from all capacity reserve margin constraints. As a reminder, GenX models the capacity reserve margin (aka capacity market) at the time-dependent level, and each constraint either stands for an overall market or a locality constraint. - - -#### 3.2.6 ESR\_prices.csv - -This file includes the renewable/clean energy credit price of each modeled RPS/CES constraint. GenX will print this file only when RPS/CES is modeled and the shadow price can be obtained form the solver. The unit is $/MWh. - - -#### 3.2.7 ESR\_Revenue.csv - -This file includes the renewable/clean credit revenue earned by each generator listed in the input file. GenX will print this file only when RPS/CES is modeled and the shadow price can be obtained form the solver. Each row corresponds to a generator, and each column starting from the 6th to the second last is the total revenue earned from each RPS constraint. The revenue is calculated as the total annual generation (if elgible for the corresponding constraint) multiplied by the RPS/CES price. The last column is the total revenue received from all constraint. The unit is $. - - -#### 3.2.8 SubsidyRevenue.csv - -This file includes subsidy revenue earned if a generator specified Min\_Cap is provided in the input file. GenX will print this file only the shadow price can be obtained form the solver. Do not confuse this with the Minimum Capacity Carveout constraint, which is for a subset of generators, and a separate revenue term will be calculated in other files. The unit is $. - -#### 3.2.9 vre_stor_capacity.csv - -Reports optimal values of investment variables (except StartCap, which is an input) for co-located VRE and storage resources - -###### Table 14: Structure of the vre_stor_capacity.csv file ---- -|**Output** |**Description** |**Units** | -| :------------ | :-----------|:-----------| -| StartCapSolar |Initial solar PV capacity of each resource type in each zone; this is an input |MW DC| -| RetCapSolar |Retired solar PV capacity of each resource type in each zone |MW DC| -| NewCapSolar |Installed solar PV capacity of each resource type in each zone |MW DC| -| EndCapSolar| Total solar PV capacity of each resource type in each zone |MW DC| -| StartCapWind |Initial wind capacity of each resource type in each zone; this is an input |MW AC| -| RetCapWind |Retired wind capacity of each resource type in each zone |MW AC| -| NewCapWind |Installed wind capacity of each resource type in each zone |MW AC| -| EndCapWind| Total wind capacity of each resource type in each zone |MW AC| -| StartCapDC |Initial inverter capacity of each resource type in each zone; this is an input |MW AC| -| RetCapDC |Retired inverter capacity of each resource type in each zone |MW AC| -| NewCapDC |Installed inverter capacity of each resource type in each zone |MW AC| -| EndCapDC| Total inverter capacity of each resource type in each zone |MW AC| -| StartCapGrid |Initial grid connection capacity of each resource type in each zone; this is an input |MW AC| -| RetCapGrid |Retired grid connection capacity of each resource type in each zone |MW AC| -| NewCapGrid |Installed grid connection capacity of each resource type in each zone |MW AC| -| EndCapGrid| Total gri connection capacity of each resource type in each zone |MW AC| -| StartEnergyCap |Initial energy capacity of each resource type in each zone; this is an input and applies only to storage tech.| MWh | -| RetEnergyCap |Retired energy capacity of each resource type in each zone; applies only to storage tech. |MWh | -| NewEnergyCap| Installed energy capacity of each resource type in each zone; applies only to storage tech. |MWh | -| EndEnergyCap |Total installed energy capacity of each resource type in each zone; applies only to storage tech. |MWh | -| StartChargeACCap| Initial charging AC power capacity of `STOR_AC_CHARGE = 2` resource type in each zone; this is an input |MW AC| -| RetChargeACCap |Retired charging AC power capacity of `STOR_AC_CHARGE = 2` resource type in each zone |MW AC| -| NewChargeACCap |Installed charging AC capacity of each resource type in each zone |MW AC| -| EndChargeAC Cap |Total charging power AC capacity of each resource type in each zone |MW AC| -| StartChargeDCCap| Initial charging DC power capacity of `STOR_DC_CHARGE = 2` resource type in each zone; this is an input |MW DC| -| RetChargeDCCap |Retired charging DC power capacity of `STOR_DC_CHARGE = 2` resource type in each zone |MW DC| -| NewChargeDCCap |Installed charging DC capacity of each resource type in each zone |MW DC| -| EndChargeDC Cap |Total charging power DC capacity of each resource type in each zone |MW DC| -| StartDischargeACCap| Initial discharging AC power capacity of `STOR_AC_DISCHARGE = 2` resource type in each zone; this is an input |MW AC| -| RetDischargeACCap |Retired discharging AC power capacity of `STOR_AC_DISCHARGE = 2` resource type in each zone |MW AC| -| NewDischargeACCap |Installed discharging AC capacity of each resource type in each zone |MW AC| -| EndDischargeAC Cap |Total discharging power AC capacity of each resource type in each zone |MW AC| -| StartDischargeDCCap| Initial discharging DC power capacity of `STOR_DC_DISCHARGE = 2` resource type in each zone; this is an input |MW DC| -| RetDischargeDCCap |Retired discharging DC power capacity of `STOR_DC_DISCHARGE = 2` resource type in each zone |MW DC| -| NewDischargeDCCap |Installed discharging DC capacity of each resource type in each zone |MW DC| -| EndDischargeDC Cap |Total discharging power DC capacity of each resource type in each zone |MW DC| - -#### 3.2.10 vre_stor_dc_charge.csv - -Reports DC charging by each co-located VRE and storage resource (could include grid or BTM charging) in each model time step. - -#### 3.2.11 vre_stor_ac_charge.csv - -Reports AC charging by each co-located VRE and storage resource (could include grid or BTM charging) in each model time step. - -#### 3.2.12 vre_stor_dc_discharge.csv - -Reports storage DC discharging by each co-located VRE and storage resource in each model time step. - -#### 3.2.13 vre_stor_ac_discharge.csv - -Reports storage AC discharging charging by each co-located VRE and storage resource in each model time step. - - -#### 3.2.14 vre_stor_solar_power.csv - -Reports solar PV generation in AC terms by each co-located VRE and storage resource in each model time step. - -#### 3.2.15 vre_stor_wind_power.csv - -Reports wind generation in AC terms by each co-located VRE and storage resource in each model time step. - -#### 3.2.16 maint_down.csv - -Only written if at least one plant has the scheduled maintenance formulation enabled. -Reports the number of resource-components which are under maintenance during each model time step. diff --git a/docs/src/documentation.md b/docs/src/documentation.md deleted file mode 100644 index 02c1f9ab04..0000000000 --- a/docs/src/documentation.md +++ /dev/null @@ -1,5 +0,0 @@ -# Documentation -```@autodocs -Modules = [GenX] -Pages = ["documentation.jl"] -``` \ No newline at end of file diff --git a/docs/src/dual_dynamic_programming.md b/docs/src/dual_dynamic_programming.md index ca999976f3..27fa03bc72 100644 --- a/docs/src/dual_dynamic_programming.md +++ b/docs/src/dual_dynamic_programming.md @@ -2,7 +2,4 @@ ```@autodocs Modules = [GenX] Pages = ["dual_dynamic_programming.jl"] -``` - -## Suggested Reading -The solution strategy implemented for solving the multi-stage investment planning model follows the decomposition algorithm described in [Lara et al, Deterministic electric power infrastructure planning: Mixed-integer programming model and nested decomposition algorithm, European Journal of Operations Research, 271(3), 1037-1054, 2018](https://www.sciencedirect.com/science/article/pii/S0377221718304466). The decomposition algorithm adapts previous nested Benders methods by handling integer and continuous state variables, although at the expense of losing its finite convergence property due to potential duality gap. \ No newline at end of file +``` \ No newline at end of file diff --git a/docs/src/endogenous_retirement.md b/docs/src/endogenous_retirement.md new file mode 100644 index 0000000000..84b44db745 --- /dev/null +++ b/docs/src/endogenous_retirement.md @@ -0,0 +1,6 @@ +# Endogenous Retirement + +```@autodocs +Modules = [GenX] +Pages = ["endogenous_retirement.jl"] +``` \ No newline at end of file diff --git a/docs/src/examples_casestudies.md b/docs/src/examples_casestudies.md new file mode 100644 index 0000000000..0aabdc7d3a --- /dev/null +++ b/docs/src/examples_casestudies.md @@ -0,0 +1,118 @@ +# Running GenX + +This section describes how to run GenX with the examples provided in the repository and with user-defined cases. To have a deeper understanding of how to structure the input files and the settings, please refer to the [GenX Inputs](@ref) and [Model settings parameters](@ref) sections of the [User Guide](@ref). + +## GenX examples and case studies +GenX repository contains several examples to get you started with GenX. These examples are located in the [Example_Systems](https://github.com/GenXProject/GenX/tree/main/Example_Systems) folder of the repository and are designed to be easy to run and to demonstrate the main features of GenX. + +The available examples are: + +- SmallNewEngland +- RealSystemExample +- RetrofitExample +- MethodofMorrisExample +- Input_data_explained + +### Running an example + +!!! note "Note" + The following instructions assume that you have already installed GenX and its dependencies. If you haven't, please follow the instructions in the [Installation Guide](@ref). + +Each example folder contains a set of `.csv` files for the inputs of GenX, a `Settings` folder for the configuration of the model and the solver, and a `Run.jl` file that can be used to run each example. For instance, to run the `SmallNewEngland` example with a single zone, follow these steps: +1. Open a terminal and navigate to the `GenX` repository. +2. Run the following command: +``` +$ julia --project Example_Systems/SmallNewEngland/OneZone/Run.jl` +``` +This command will run the `Run.jl` file located in the `Example_Systems/SmallNewEngland/OneZone` folder. The `--project` flag tells Julia to activate the environment defined in the `Project.toml` file located in the `GenX` folder. This file contains the correct list dependencies to run GenX. The `Run.jl` file will read the inputs of GenX from the `.csv` files located in the `Example_Systems/SmallNewEngland/OneZone` folder and will write the results in a `Results` folder located in the same directory as `Run.jl`. + +!!! tip "Tip" + Running the command + ``` + $ julia --project Example_Systems/SmallNewEngland/OneZone/Run.jl` + ``` + from the `GenX` folder is equivalent to open a Julia REPL and call the `Run.jl` file using the `include` function: + ``` + $ julia --project + julia> include("Example_Systems/SmallNewEngland/OneZone/Run.jl") + ``` + The second option is recommended if you want to run GenX multiple times with different settings because it avoids the overhead of recompiling the code every time you run it. + +To run an example from a different directory, you can use the following command: + +``` +$ julia --project="/path/to/GenX" /path/to/GenX/Example_Systems/SmallNewEngland/OneZone/Run.jl` +``` +where `/path/to/GenX` is the path to the `GenX` repository. + +!!! note "Note" + The default solver for GenX is [HiGHS](https://github.com/jump-dev/HiGHS.jl). + +For more information on what happens when you run a GenX case, see the [Running GenX](@ref) section. + +## Running GenX with user-defined cases +To run GenX with a user-defined case, you need to create a folder `MyCase` with the following structure: +``` +MyCase +├── Demand_data.csv +├── Energy_share_requirements.csv +├── Fuel_data.csv +├── Generators_data.csv +├── Generators_variability.csv +[...] # Other input files +├── Settings +│ ├── genx_settings.yml # GenX settings +│ ├── [solver_name]_settings.yml # Solver settings +| [optional] +│ ├── multi_stage_settings.yml # Multi-stage settings +│ └── time_domain_reduction.yml # Time-domain clustering settings +└── Run.jl +``` +where `MyCase` is the name of the folder of the case. The `Run.jl` file is the entry point for running GenX and it should contain the following code: +```julia +using GenX +run_genx_case!(dirname(@__FILE__)) +``` +To run the case, open a terminal and run the following command: +``` +$ julia --project="/path/to/GenX" /path/to/MyCase/Run.jl +``` +where `/path/to/GenX` is the path to the `GenX` repository, and `/path/to/MyCase` is the path to the folder of the `MyCase` case. +Alternatively, you can run the case from a Julia REPL: +``` +$ julia --project="/path/to/GenX" +julia> include("/path/to/MyCase/Run.jl") +``` + +## What happens when you run a case +*Added in 0.3.4* + +The entry point for running a GenX case is the `run_genx_case!("path/to/case")` function, where `path/to/case` is the path to the case directory that contains the `.csv` files with the inputs for GenX and the `Settings` folder with the configuration files. + +The following are the main steps performed in that function: + +1. Establish path to environment setup files and GenX source files. +2. Read in model settings `genx_settings.yml` from the example directory. +3. Configure solver settings. +4. Load the model inputs from the example directory and perform time-domain clustering if required. +5. Generate a GenX model instance. +6. Solve the model. +7. Write the output files to a specified directory. + +After the script runs to completion, results will be written to a folder called `Results`, located in the current working directory. + +## Additional method for running GenX cases +Added in 0.3.4 + +An alternative method for running GenX cases is to use the `run_genx_case!` function directly from a Julia REPL. This is particularly useful if one wants to run multiple GenX cases in sequence, as GenX needs only to be compiled by Julia once, and can be somewhat faster. + +Start Julia pointed at the GenX environment, and then proceed as follows: + +``` +$ julia --project=/path/to/GenX + +julia> using GenX + +julia> run_genx_case!("/path/to/case") +``` +where `/path/to/case` is the path to the case directory that contains the `.csv` files with the inputs for GenX and the `Settings` folder with the configuration files. All output will be written in that case's folder, as usual. Examples can be run in this way as well by using the path to the example directory in place of `/path/to/case`. diff --git a/docs/src/generate_alternatives.md b/docs/src/generate_alternatives.md new file mode 100644 index 0000000000..2484e2f7ad --- /dev/null +++ b/docs/src/generate_alternatives.md @@ -0,0 +1,15 @@ +## Running Modeling to Generate Alternatives with GenX + +GenX includes a modeling to generate alternatives (MGA) package that can be used to automatically enumerate a diverse set of near cost-optimal solutions to electricity system planning problems. To use the MGA algorithm, user will need to perform the following tasks: + +1. Add a `Resource_Type` column in the `Generators_data.csv` file denoting the type of each technology. +2. Add a MGA column in the `Generators_data.csv` file denoting the availability of the technology. +3. Set the `ModelingToGenerateAlternatives` flag in the `GenX_Settings.yml` file to 1. +4. Set the `ModelingtoGenerateAlternativeSlack` flag in the `GenX_Settings.yml` file to the desirable level of slack. +5. Create a `Rand_mga_objective_coefficients.csv` file to provide random objective function coefficients for each MGA iteration. + +For each iteration, number of rows in the `Rand_mga_objective_coefficients`.csv file represents the number of distinct technology types while number of columns represent the number of model zones. + +Solve the model using `Run.jl` file. + +Results from the MGA algorithm would be saved in MGA_max and MGA_min folders in the `Example_Systems/` folder. \ No newline at end of file diff --git a/docs/src/how_to_run_genx.md b/docs/src/how_to_run_genx.md deleted file mode 100644 index 8090347df1..0000000000 --- a/docs/src/how_to_run_genx.md +++ /dev/null @@ -1,140 +0,0 @@ -# Requirements - -GenX currently exists in version 0.3.6 and runs only on Julia v1.5.x, 1.6.x, 1.7.x, 1.8.x, and 1.9.x, where x>=0 and a minimum version of JuMP v1.1.1. We recommend the users to either stick to a particular version of Julia to run GenX. If however, the users decide to switch between versions, it's very important to delete the old Manifest.toml file and do a fresh build of GenX when switching between Julia versions. -For those users who has previously cloned GenX, and has been running it successfully so far, -and therefore might be unwilling to run it on the latest version of Julia: -please look into the GitHub branch, [old_version](https://github.com/GenXProject/GenX/tree/old_version). -It is currently setup to use one of the following open-source freely available solvers: -(A) the default solver: [HiGHS](https://github.com/jump-dev/HiGHS.jl) for linear programming and MILP, -(B) [Clp](https://github.com/jump-dev/Clp.jl) for linear programming (LP) problems, -(C) [Cbc](https://github.com/jump-dev/Cbc.jl) for mixed integer linear programming (MILP) problems -We also provide the option to use one of these two commercial solvers: -(D) [Gurobi](https://www.gurobi.com), or -(E) [CPLEX](https://www.ibm.com/analytics/cplex-optimizer). -Note that using Gurobi and CPLEX requires a valid license on the host machine. -There are two ways to run GenX with either type of solver options (open-source free or, licensed commercial) as detailed in the section, `Running an Instance of GenX`. - -The file `Project.toml` in the parent directory lists all of the packages and their versions needed to run GenX. -You can see all of the packages installed in your Julia environment and their version numbers by running `pkg> status` on the package manager command line in the Jula REPL. - -## Documentation - -Detailed documentation for GenX can be found [here](https://genxproject.github.io/GenX/dev). -It includes details of each of GenX's methods, required and optional input files, and outputs. -Interested users may also want to browse through [prior publications](https://energy.mit.edu/genx/#publications) that have used GenX to understand the various features of the tool. - -## Running an Instance of GenX -1. Download or clone the GenX repository on your machine. -For this tutorial it will be assumed to be within your home directory: `/home/youruser/GenX`. -### Creating the Julia environment and installing dependencies -2. Start a terminal and navigate into the `GenX` folder. -3. Type `julia --project=.` to start an instance of the `julia` kernel with the `project` set to the current folder. - The `.` indicates the current folder. On Windows the location of Julia can also be specified as e.g., 'C:\julia-1.6.0\bin\julia.exe --project=.' - - If it's your first time running GenX (or, if you have pulled after some major upgrades/release/version) execute steps 3-6. - -4. Type `]` to bring up the package system `(GenX) pkg >` prompt. This indicates that the GenX project was detected. If you see `(@v1.6) pkg>` as the prompt, then the `project` was not successfully set. -5. Type `instantiate` from the `(GenX) pkg` prompt. - On Windows there is an issue with the prepopulated MUMPS_seq_jll v5.5.1 that prevents compilation of the solvers. To avoid this issue type 'add MUMPS_seq_jll@5.4.1' after running instantiate. -6. Type `st` to check that the dependecies have been installed. If there is no error, it has been successful. -7. Type the back key to come back to the `julia>` prompt. - - These steps can be skipped on subsequent runs. - - Steps 2-5 are shown in Figure 1 and Steps 6-8 are shown in Figure 2. - - ![Creating the Julia environment and installing dependencies: Steps 2-7](assets/GenX_setup_tutorial_part_1.png) - *Figure 1. Creating the Julia environment and installing dependencies from Project.toml file from inside the GenX folder: Steps 2-5* - -8. Since we have already started Julia, we can run a case by executing the command `julia> include(“/Run.jl”)`. - -For example, in order to run the OneZone case within the `Example_Systems/SmallNewEngland` folder, -type `include("Example_Systems/SmallNewEngland/OneZone/Run.jl")` from the `julia>` prompt. - -![Creating the Julia environment and installing dependencies: Steps 6-8](assets/GenX_setup_tutorial_part_2.png) -*Figure 2. Creating the Julia environment and installing dependencies from Project.toml file from inside the GenX folder: Steps 6-8* - -After the script runs to completion, results will be written to a folder called “Results”, located in the same directory as `Run.jl`. - -### Running a case - -Once Steps 1-6 have been performed, a case can be run from the terminal in a single line. -There's no need to be in a certain folder to run a case, but it is required to point `julia` to the project that you created. - -For example, from inside the `GenX` folder: -`/home/youruser/GenX > julia --project=. /home/youruser/GenX/Example_Systems/SmallNewEngland/OneZone/Run.jl` - -Or from another folder - -`/arbitrary/location > julia --project="/home/youruser/GenX" /home/youruser/GenX/Example_Systems/SmallNewEngland/OneZone/Run.jl` - -In fact, a best practice is to place your cases outside of the GenX repository: - -`/arbitrary/location > julia --project="/home/youruser/GenX" /your/custom/case/Run.jl` - -### What happens when you run a case - -The Run.jl file in each of the example systems calls a function `run_genx_case!("path/to/case")` which is suitable for capacity expansion modeling of several varieties. -The following are the main steps performed in that function: - -1. Establish path to environment setup files and GenX source files. -2. Read in model settings `genx_settings.yml` from the example directory. -3. Configure solver settings. -4. Load the model inputs from the example directory and perform time-domain clustering if required. -5. Generate a GenX model instance. -6. Solve the model. -7. Write the output files to a specified directory. - -If your needs are more complex, it is possible to use a customized run script in place of simply calling `run_genx_case!`; the contents of that function could be a starting point. - -## Using commercial solvers: Gurobi or CPLEX -If you want to use the commercial solvers Gurobi or CPLEX: - -1. Make sure you have a valid license and the actual solvers for either of Gurobi or CPLEX installed on your machine -2. Add Gurobi or CPLEX to the Julia Project. - -``` -> julia --project=/home/youruser/GenX - -julia> -(GenX) pkg> add Gurobi --or- -(GenX) pkg> add CPLEX -``` -3. At the beginning of the `GenX/src/GenX.jl` file, uncomment `using Gurobi` and/or `using CPLEX`. -4. Set the appropriate solver in the `genx_settings.yml` file of your case - -Note that if you have not already installed the required Julia packages or you do not have a valid Gurobi license on your host machine, you will receive an error message and Run.jl will not run to completion. - - -## Running Modeling to Generate Alternatives with GenX -GenX includes a modeling to generate alternatives (MGA) package that can be used to automatically enumerate a diverse set of near cost-optimal solutions to electricity system planning problems. To use the MGA algorithm, user will need to perform the following tasks: - -1. Add a `Resource_Type` column in the `Generators_data.csv` file denoting the type of each technology. -2. Add a `MGA` column in the `Generators_data.csv` file denoting the availability of the technology. -3. Set the `ModelingToGenerateAlternatives` flag in the `GenX_Settings.yml` file to 1. -4. Set the `ModelingtoGenerateAlternativeSlack` flag in the `GenX_Settings.yml` file to the desirable level of slack. -5. Create a `Rand_mga_objective_coefficients.csv` file to provide random objective function coefficients for each MGA iteration. - For each iteration, number of rows in the `Rand_mga_objective_coefficients.csv` file represents the number of distinct technology types while number of columns represent the number of model zones. -6. Solve the model using `Run.jl` file. - -Results from the MGA algorithm would be saved in `MGA_max` and `MGA_min` folders in the `Example_Systems/` folder. - -## Additional method for running GenX cases -_Added in 0.3.4_ - -The `GenX` module exports a function called `run_genx_case!`. -This function is designed to be used in a script; in fact it is used in each `Run.jl` file. -If one wants to run multiple GenX cases in sequence, this can be especially useful, as `GenX` needs only to be compiled by Julia once, and can be somewhat faster. - - -Start julia pointed at the appropriate Project, and then proceed as follows: -``` -> julia --project=/home/youruser/GenX - -julia> using GenX - -julia> run_genx_case!("/path/to/case") -``` -All output will be written in that case's folder, as usual. - diff --git a/docs/src/index.md b/docs/src/index.md index 29e54bf482..c5a094a620 100644 --- a/docs/src/index.md +++ b/docs/src/index.md @@ -1,10 +1,7 @@ # GenX Documentation +Welcome to the GenX documentation! -```@meta -CurrentModule = GenX -``` - -## Overview +## What is GenX? GenX is a highly-configurable, [open source](https://github.com/GenXProject/GenX/blob/main/LICENSE) electricity resource capacity expansion model that incorporates several state-of-the-art practices in electricity system planning to offer improved decision support for a changing electricity landscape. @@ -12,10 +9,79 @@ The model was [originally developed](https://energy.mit.edu/publication/enhanced GenX is a constrained linear or mixed integer linear optimization model that determines the portfolio of electricity generation, storage, transmission, and demand-side resource investments and operational decisions to meet electricity demand in one or more future planning years at lowest cost, while subject to a variety of power system operational constraints, resource availability limits, and other imposed environmental, market design, and policy constraints. -GenX features a modular and transparent code structure developed in [Julia](http://julialang.org/) + [JuMP](http://jump.dev/). The model is designed to be highly flexible and configurable for use in a variety of applications from academic research and technology evaluation to public policy and regulatory analysis and resource planning. Depending on the planning problem or question to be studied, GenX can be configured with varying levels of model resolution and scope, with regards to: (1) temporal resolution of time series data such as electricity demand and renewable energy availability; (2) power system operational detail and unit commitment constraints; and (3) geospatial resolution and transmission network representation. The model is also capable of representing a full range of conventional and novel electricity resources, including thermal generators, variable renewable resources (wind and solar), run-of-river, reservoir and pumped-storage hydroelectric generators, energy storage devices, demand-side flexibility, demand response, and several advanced technologies such as long-duration energy storage. +GenX features a modular and transparent code structure developed in [Julia](http://julialang.org/) + [JuMP](http://jump.dev/). The model is designed to be highly flexible and configurable for use in a variety of applications from academic research and technology evaluation to public policy and regulatory analysis and resource planning. See the **User Guide** for more information on how to use GenX. +```@meta +# and the **Developer Guide** for more information on how to contribute to GenX. +``` + +## Uses + +From a centralized planning perspective, the GenX model can help to determine the investments needed to supply future electricity demand at minimum cost, as is common in least-cost utility planning or integrated resource planning processes. In the context of liberalized markets, the model can be used by regulators and policy makers for indicative energy planning or policy analysis in order to establish a long-term vision of efficient market and policy outcomes. The model can also be used for techno-economic assessment of emerging electricity generation, storage, and demand-side resources and to enumerate the effect of parametric uncertainty (e.g., technology costs, fuel costs, demand, policy decisions) on the system-wide value or role of different resources. ## How to cite GenX We recommend users of GenX to cite it in their academic publications and patent filings. Here's the text to put up as the citation for GenX: -`MIT Energy Initiative and Princeton University ZERO lab. [GenX](https://github.com/GenXProject/GenX): a configurable power system capacity expansion model for studying low-carbon energy futures n.d. https://github.com/GenXProject/GenX +`MIT Energy Initiative and Princeton University ZERO lab. [GenX](https://github.com/GenXProject/GenX): a configurable power system capacity expansion model for studying low-carbon energy futures n.d. https://github.com/GenXProject/GenX. + +## Package Manual + +```@contents +Pages = ["running_genx.md", + "commercial_solvers.md", + "generate_alternatives.md", + "workflow.md", + "model_configuration.md", + "solver_configuration.md", + "model_input.md", + "TDR_input.md", + "running_TDR.md", + "multi_stage_input.md", + "methodofmorris_input.md", + "running_model.md", + "model_output.md", + "model_introduction.md", + "model_notation.md", + "objective_function.md", + "power_balance.md", + "slack_variables_overview.md", + "TDR_overview.md", + "multi_stage_overview.md", + "additional_third_party_extensions.md"] +Depth = 2 +``` + +## Index + +```@index +Pages = ["core.md", + "curtailable_variable_renewable.md", + "flexible_demand.md", + "hydro_res.md", + "hydro_inter_period_linkage.md", + "must_run.md", + "storage.md", + "investment_charge.md", + "investment_energy.md", + "long_duration_storage.md", + "storage_all.md", + "storage_asymmetric.md", + "storage_symmetric.md", + "vre_stor.md", + "thermal.md", + "thermal_commit.md", + "thermal_no_commit.md", + "electrolyzers.md", + "maintenance.md", + "policies.md", + "solver_configuration.md", + "load_inputs.md", + "TDR.md", + "configure_multi_stage_inputs.md", + "dual_dynamic_programming.md", + "solve_model.md", + "mga.md", + "methodofmorris.md", + "write_outputs.md"] +``` +## License \ No newline at end of file diff --git a/docs/src/installation.md b/docs/src/installation.md new file mode 100644 index 0000000000..6f51ec9915 --- /dev/null +++ b/docs/src/installation.md @@ -0,0 +1,64 @@ +# Installation Guide +This guide will walk you through the steps to install Julia, the GenX package, and the required dependencies to run GenX. + +## Installing Julia +GenX currently exists in version 0.3.6 and runs only on Julia v1.5.x, 1.6.x, 1.7.x, 1.8.x, and 1.9.x, where x>=0 and a minimum version of [JuMP](https://jump.dev/JuMP.jl/stable/) v1.1.1. To install Julia, please follow the instructions on the [Julia website](https://julialang.org/downloads/). + +!!! note "Note" + We recommend the users to stick to a particular version of Julia to run GenX. If however, the users decide to switch between versions, it's very important to delete the old `Manifest.toml` file and do a fresh build of GenX. + +## Downloading GenX and installing dependencies +After installing Julia, you can download GenX by either cloning the repository or downloading the zip file from the [GenX GitHub page](https://github.com/GenXProject/GenX). For this tutorial it will be assumed to be within your home directory: `/home/youruser/GenX`. +Once you have downloaded GenX, you can install the dependencies by following the steps below: + +1\. Start a terminal and navigate into the `GenX` folder. + +2\. Type `julia --project=.` to start an instance of the `julia` kernel with the `project` set to the current folder. The flag `--project=.` indicates that Julia will activate the project environment using the `Project.toml` present in the current folder, `.`. If running on Windows, the location of Julia can also be specified as e.g., `C:\julia-1.6.0\bin\julia.exe --project=.`. + +!!! tip "Tip" + The file `Project.toml` in the parent directory lists all of the dependencies and their versions needed to run GenX. You can see all of the packages installed in your Julia environment and their version numbers by running `pkg> status` or `pkg> st` on the package manager command line in the Jula REPL (for more information on the Julia package manager, read the documentation for the [Pkg.jl](https://pkgdocs.julialang.org/v1/environments/) or for the [Julia standard library](https://docs.julialang.org/en/v1/stdlib/Pkg/)). + +!!! tip "Tip" + `julia --project` is a shortcut for `julia --project=.` + +3\. Type `]` to bring up the package system `(GenX) pkg >` prompt. This indicates that the GenX project was detected. + +!!! warning "Warning" + If you see `(@v1.6) pkg>` as the prompt, then the `project` was not successfully set. + +4\. Type `instantiate` from the `(GenX) pkg` prompt. + +!!! note "Note for Windows users" + On Windows there is an issue with the prepopulated `MUMPS_seq_jll v5.5.1` that prevents compilation of the solvers. To avoid this issue type `add MUMPS_seq_jll@5.4.1` after running instantiate. + +5\. Type `st` to check that the dependecies have been installed. If there is no error, it has been successful. + +!!! tip "Tip" + Type the back key to come back to the `julia>` prompt from the package manager. + +The above steps are shown in Figure 1 and Figure 2. + +![Creating the Julia environment and installing dependencies: Steps 2-4](assets/GenX_setup_tutorial_part_1.png) +*Figure 1. Creating the Julia environment and installing dependencies from Project.toml file from inside the GenX folder.* + +![Creating the Julia environment and installing dependencies: Step 5](assets/GenX_setup_tutorial_part_2.png) +*Figure 2. Creating the Julia environment and installing dependencies from Project.toml file from inside the GenX folder: Step 5* + +## Installing solvers +GenX requires a solver to be installed to solve the optimization problem. By default, GenX uses one of the following open-source freely available solvers: + +1. [HiGHS](https://github.com/jump-dev/HiGHS.jl) for linear programming and MILP (default solver) +2. [Clp](https://github.com/jump-dev/Clp.jl) for linear programming (LP) problems +3. [Cbc](https://github.com/jump-dev/Cbc.jl) for mixed integer linear programming (MILP) problems + +We also provide the option to use one of these two commercial solvers: +4. [Gurobi](https://www.gurobi.com) +5. [CPLEX](https://www.ibm.com/analytics/cplex-optimizer). + +!!! note "Note on commercial solvers" + Using Gurobi and CPLEX requires a valid license on the host machine. + +## Notes on previous versions of GenX +For those users who has previously cloned GenX, and has been running it successfully so far, and therefore might be unwilling to run it on the latest version of Julia: please look into the GitHub branch, [old_version](https://github.com/GenXProject/GenX/tree/old_version). + + diff --git a/docs/src/investment_multi_stage.md b/docs/src/investment_multi_stage.md deleted file mode 100644 index a05a517318..0000000000 --- a/docs/src/investment_multi_stage.md +++ /dev/null @@ -1,17 +0,0 @@ -# Investment multi stage -```@autodocs -Modules = [GenX] -Pages = ["investment_multi_stage.jl"] -``` - -# Storage multi stage -```@autodocs -Modules = [GenX] -Pages = ["storage_multi_stage.jl"] -``` - -# Transmission multi stage -```@autodocs -Modules = [GenX] -Pages = ["transmission_multi_stage.jl"] -``` \ No newline at end of file diff --git a/docs/src/limitations_genx.md b/docs/src/limitations_genx.md index a8314a43ed..e717c9c178 100644 --- a/docs/src/limitations_genx.md +++ b/docs/src/limitations_genx.md @@ -1,24 +1,25 @@ # Limitations of the GenX Model While the benefits of an openly available generation and transmission expansion model are high, many approximations have been made due to missing data or to manage computational tractability. The assumptions of the GenX model are listed below. It serves as a caveat to the user and as an encouragement to improve the approximations. -## Time period +#### 1. Time period GenX makes the simplifying assumption that each time period contains n copies of a single, representative year. GenX optimizes generation and transmission capacity for just this characteristic year within each time period, assuming the results for different years in the same time period are identical. However, the GenX objective function accounts only for the cost of the final model time period. -## Cost +#### 2. Cost The GenX objective function assumes that the cost of powerplants is specified in the unit of currency per unit of capacity. GenX also assumes that the capital cost of technologies is paid through loans. -## Market +#### 3.Market GenX is a bottom-up (technology-explicit), partial equilibrium model that assumes perfect markets for commodities. In other words, each commodity is produced such that the sum of producer and consumer surplus is maximized. -## Technology +#### 4. Technology Behavioral response and acceptance of new technology are often modeled simplistically as a discount rate or by externally fixing the technology capacity. A higher, technology-specific discount rate represents consumer reluctance to accept newer technologies. -## Uncertainty -Because each model realization assumes a particular state of the world based on the input values drawn, the parameter uncertainty is propagated through the model in the case of myopic model runs -## Decision-making +#### 5. Uncertainty +Because each model realization assumes a particular state of the world based on the input values drawn, the parameter uncertainty is propagated through the model in the case of myopic model runs. + +#### 6. Decision-making GenX assumes rational decision making, with perfect information and perfect foresight, and simultaneously optimizes all decisions over the user-specified time horizon. -## Demand +#### 7. Demand GenX assumes price-elastic demand segments that are represented using piece-wise approximation rather than an inverse demand curve to keep the model linear. diff --git a/docs/src/load_generators_data_multi_stage.md b/docs/src/load_generators_data_multi_stage.md deleted file mode 100644 index a6fc67326c..0000000000 --- a/docs/src/load_generators_data_multi_stage.md +++ /dev/null @@ -1,5 +0,0 @@ -# load generators data multi stage -```@autodocs -Modules = [GenX] -Pages = ["load_generators_data_multi_stage.jl"] -``` diff --git a/docs/src/load_inputs_multi_stage.md b/docs/src/load_inputs_multi_stage.md deleted file mode 100644 index 23914f6d68..0000000000 --- a/docs/src/load_inputs_multi_stage.md +++ /dev/null @@ -1,5 +0,0 @@ -# load inputs multi stage -```@autodocs -Modules = [GenX] -Pages = ["load_inputs_multi_stage.jl"] -``` diff --git a/docs/src/load_network_data_multi_stage.md b/docs/src/load_network_data_multi_stage.md deleted file mode 100644 index 93256b3b59..0000000000 --- a/docs/src/load_network_data_multi_stage.md +++ /dev/null @@ -1,5 +0,0 @@ -# load network data multi stage -```@autodocs -Modules = [GenX] -Pages = ["load_network_data_multi_stage.jl"] -``` diff --git a/docs/src/maintenance.md b/docs/src/maintenance.md index 6e02c28bc5..f84b066335 100644 --- a/docs/src/maintenance.md +++ b/docs/src/maintenance.md @@ -1,101 +1,13 @@ # Optimized Scheduled Maintenance _Added in v0.4_ -In the real world, some types of resources (notably, fission) require regular scheduled maintenance, which often takes several weeks. -During this time, the plant produces no power. -This module allows GenX to find the best time of year for plants to undergo maintenance. - -Scheduled maintenance is implemented **only** for thermal plants with unit commitment (THERM=1). - -## Description of the maintenance model -A plant requires a single contiguous period of $h \ge 1$ hours of maintenance, every $y \ge 1$ years. -For each plant, the best time to start the maintenance period is determined by the optimizer. - -During maintenance, the plant cannot be "commited", and therefore - -* uses no fuel, -* produces no power, -* and does not contribute to reserves. - -Additionally, - -* the plant does not contribute to any Capacity Reserve Margin. - -### Treatment of plants that require maintenance only every few years -GenX models a long-term equilibrium, -and each problem generally represents a single full year. -If a plant requires maintenance every $y$ years, we take the simplification that at least $1/y$ of the plants must undergo maintenance in the modeled year. - -See also "Interaction with integer unit commitment" below. - -### Reduction of number of possible start dates -This module creates constraints which work across long periods, and consequently can be very expensive to solve. -In order to reduce the expense, the set of possible maintenance start dates can be limited. -Rather than have maintenance potentially start every hour, one can have possible start dates which are once per day, once per week, etc. -(In reality, maintenance is likely scheduled months in advance, so optimizing down to the hour may not be realistic anyway.) - -## How to use -There are four columns which need to be added to the plant data, i.e. in `Generators_data.csv`: - -1. `MAINT` should be `1` for plants that require maintenance and `0` otherwise. -2. `Maintenance_Duration` is the number of hours the maintenance period lasts. -3. `Maintenance_Cycle_Length_Years`. If `1`, maintenance every year, if `3` maintenance every 3 years, etc. -4. `Maintenance_Begin_Cadence`. Spacing between hours in which maintenance can start. - -The last three fields must be integers which are greater than 0. -They are ignored for any plants which do not require maintenance. - -`Maintenance_Duration` must be less than the total number of hours in the year. - -If `Maintenance_Begin_Cadence` is `1` then the maintenance can begin in any hour. -If it is `168` then it can begin in hours 1, 169, 337, etc. - -## Restrictions on use -The maintenance module has these restrictions: - -- More than a single maintenance period per year (i.e. every three months) is not possible in the current formulation. -- Only full-year cases can be run; there must be only one "representative period". -It would not make sense to model a *month*-long maintenance period when the year is modeled as a series of representative *weeks*, for example. - -### Interaction with integer unit commitment -If integer unit commitment is on (`UCommit=1`) this module may not produce correct results; there may be more maintenance than the user wants. -This is because the formulation specifies that the number of plants that go down for maintenance in the simulated year must be at least (the number of plants in the zone)/(the maintenance cycle length in years). -As a reminder, the number of plants is `eTotalCap / Cap_Size`. - -If there were three 500 MW plants (total 1500 MW) in a zone, and they require maintenance every three years (`Maintenance_Cycle_Length_Years=3`), -the formulation will work properly: one of the three plants will go under maintenance. - -But if there was only one 500 MW plant, and it requires maintenance every 3 years, the constraint will still make it do maintenance **every year**, because `ceil(1/3)` is `1`. The whole 500 MW plant will do maintenance. This is the unexpected behavior. - -However, if integer unit commitment was relaxed to "linearized" unit commitment (`UCommit=2`), the model will have only 500 MW / 3 = 166.6 MW worth of this plant do maintenance. - -## Hint: pre-scheduling maintenance -If you want to pre-schedule when maintenance occurs, you might not need this module. -Instead, you could set the maximum power output of the plant to zero for a certain period, or make its fuel extremely expensive during that time. -However, the plant would still be able to contribute to the Capacity Reserve Margin. - -## Outputs produced -If at least one plant has `MAINT=1`, a file `maint_down.csv` will be written listing how many plants are down for maintenance in each timestep. - -## Notes on mathematical formulation -The formulation of the maintenance state is very similar to the formulation of unit commitment. - -There is a variable called something like `vMSHUT` which is analogous to `vSTART` and controls the start of the maintenance period. -There is another variable called something like `vMDOWN` analogous to `vCOMMIT` which controls the maintenance status in any hour. - -A constraint ensures that the value of `vMDOWN` in any hour is always more than the number of `vMSHUT`s in the previous `Maintenance_Duration` hours. - -Another constraint ensures that the number of plants committed (`vCOMMIT`) at any one time plus the number of plants under maintenance (`vMDOWN`) is less than the total number of plants. - -## Developer note: adding maintenance to a resource -The maintenance formulation is applied on a per-resource basis, by calling the function `maintenance_formulation!`. - ```@docs GenX.maintenance_formulation! -``` - -See `maintenance_formulation_thermal_commit!` for an example of how to apply it to a new resource. - -* The resource must have a `vCOMMIT`-like variable which is proportional to maximum the power output, etc at any given timestep. -* The resource must have a `eTotalCap`-like quantity and a `Cap_Size`-like parameter; only the ratio of the two is used. - +GenX.resources_with_maintenance +GenX.maintenance_down_name +GenX.maintenance_shut_name +GenX.controlling_maintenance_start_hours +GenX.ensure_maintenance_variable_records! +GenX.has_maintenance +GenX.maintenance_down_variables +``` \ No newline at end of file diff --git a/docs/src/maintenance_overview.md b/docs/src/maintenance_overview.md new file mode 100644 index 0000000000..b4ffaa6035 --- /dev/null +++ b/docs/src/maintenance_overview.md @@ -0,0 +1,96 @@ +# Optimized Scheduled Maintenance +_Added in v0.4_ + +In the real world, some types of resources (notably, fission) require regular scheduled maintenance, which often takes several weeks. +During this time, the plant produces no power. +This module allows GenX to find the best time of year for plants to undergo maintenance. + +Scheduled maintenance is implemented **only** for thermal plants with unit commitment (THERM=1). + +## Description of the maintenance model +A plant requires a single contiguous period of $h \ge 1$ hours of maintenance, every $y \ge 1$ years. +For each plant, the best time to start the maintenance period is determined by the optimizer. + +During maintenance, the plant cannot be "commited", and therefore + +* uses no fuel, +* produces no power, +* and does not contribute to reserves. + +Additionally, + +* the plant does not contribute to any Capacity Reserve Margin. + +### Treatment of plants that require maintenance only every few years +GenX models a long-term equilibrium, +and each problem generally represents a single full year. +If a plant requires maintenance every $y$ years, we take the simplification that at least $1/y$ of the plants must undergo maintenance in the modeled year. + +See also "Interaction with integer unit commitment" below. + +### Reduction of number of possible start dates +This module creates constraints which work across long periods, and consequently can be very expensive to solve. +In order to reduce the expense, the set of possible maintenance start dates can be limited. +Rather than have maintenance potentially start every hour, one can have possible start dates which are once per day, once per week, etc. +(In reality, maintenance is likely scheduled months in advance, so optimizing down to the hour may not be realistic anyway.) + +## How to use +There are four columns which need to be added to the plant data, i.e. in `Generators_data.csv`: + +1. `MAINT` should be `1` for plants that require maintenance and `0` otherwise. +2. `Maintenance_Duration` is the number of hours the maintenance period lasts. +3. `Maintenance_Cycle_Length_Years`. If `1`, maintenance every year, if `3` maintenance every 3 years, etc. +4. `Maintenance_Begin_Cadence`. Spacing between hours in which maintenance can start. + +The last three fields must be integers which are greater than 0. +They are ignored for any plants which do not require maintenance. + +`Maintenance_Duration` must be less than the total number of hours in the year. + +If `Maintenance_Begin_Cadence` is `1` then the maintenance can begin in any hour. +If it is `168` then it can begin in hours 1, 169, 337, etc. + +## Restrictions on use +The maintenance module has these restrictions: + +- More than a single maintenance period per year (i.e. every three months) is not possible in the current formulation. +- Only full-year cases can be run; there must be only one "representative period". +It would not make sense to model a *month*-long maintenance period when the year is modeled as a series of representative *weeks*, for example. + +### Interaction with integer unit commitment +If integer unit commitment is on (`UCommit=1`) this module may not produce correct results; there may be more maintenance than the user wants. +This is because the formulation specifies that the number of plants that go down for maintenance in the simulated year must be at least (the number of plants in the zone)/(the maintenance cycle length in years). +As a reminder, the number of plants is `eTotalCap / Cap_Size`. + +If there were three 500 MW plants (total 1500 MW) in a zone, and they require maintenance every three years (`Maintenance_Cycle_Length_Years=3`), +the formulation will work properly: one of the three plants will go under maintenance. + +But if there was only one 500 MW plant, and it requires maintenance every 3 years, the constraint will still make it do maintenance **every year**, because `ceil(1/3)` is `1`. The whole 500 MW plant will do maintenance. This is the unexpected behavior. + +However, if integer unit commitment was relaxed to "linearized" unit commitment (`UCommit=2`), the model will have only 500 MW / 3 = 166.6 MW worth of this plant do maintenance. + +## Hint: pre-scheduling maintenance +If you want to pre-schedule when maintenance occurs, you might not need this module. +Instead, you could set the maximum power output of the plant to zero for a certain period, or make its fuel extremely expensive during that time. +However, the plant would still be able to contribute to the Capacity Reserve Margin. + +## Outputs produced +If at least one plant has `MAINT=1`, a file `maint_down.csv` will be written listing how many plants are down for maintenance in each timestep. + +## Notes on mathematical formulation +The formulation of the maintenance state is very similar to the formulation of unit commitment. + +There is a variable called something like `vMSHUT` which is analogous to `vSTART` and controls the start of the maintenance period. +There is another variable called something like `vMDOWN` analogous to `vCOMMIT` which controls the maintenance status in any hour. + +A constraint ensures that the value of `vMDOWN` in any hour is always more than the number of `vMSHUT`s in the previous `Maintenance_Duration` hours. + +Another constraint ensures that the number of plants committed (`vCOMMIT`) at any one time plus the number of plants under maintenance (`vMDOWN`) is less than the total number of plants. + +## Developer note: adding maintenance to a resource +The maintenance formulation is applied on a per-resource basis, by calling the function [`GenX.maintenance_formulation!`](@ref). + +See [`GenX.maintenance_formulation_thermal_commit!`](@ref) for an example of how to apply it to a new resource. + +* The resource must have a `vCOMMIT`-like variable which is proportional to maximum the power output, etc at any given timestep. +* The resource must have a `eTotalCap`-like quantity and a `Cap_Size`-like parameter; only the ratio of the two is used. diff --git a/docs/src/methodofmorris.md b/docs/src/methodofmorris.md new file mode 100644 index 0000000000..b55484ad40 --- /dev/null +++ b/docs/src/methodofmorris.md @@ -0,0 +1,5 @@ +# Method of Morris +```@autodocs +Modules = [GenX] +Pages = ["method_of_morris.jl"] +``` diff --git a/docs/src/methodofmorris_input.md b/docs/src/methodofmorris_input.md new file mode 100644 index 0000000000..f643bb1182 --- /dev/null +++ b/docs/src/methodofmorris_input.md @@ -0,0 +1,31 @@ +# Method\_of\_morris\_range.csv ([Example](https://github.com/GenXProject/GenX/blob/main/Example_Systems/MethodofMorrisExample/OneZone/Method_of_morris_range.csv)) + +This file contains the settings parameters required to run the Method of Morris algorithm in GenX. + +!!! note "Note" + This file is needed if the `MethodofMorris` flag is ON in the YAML file `genx_settings.yml`. + +|**Column Name** | **Description**| +| :------------ | :-----------| +|Resource | This column contains **unique** names of resources available to the model. Resources can include generators, storage, and flexible or time shiftable demand.| +|Zone | Integer representing zone number where the resource is located. | +|Lower\_bound | Percentage lower deviation from the nominal value| +|Upper\_bound| Percentage upper deviation from the nominal value| +|Parameter| Column from the `Generators_data.csv` file containing uncertain parameters| +|Group| Group the uncertain parameters that will be changed all at once while performing the sensitivity analysis. For example, if the fuel price of natural gas is uncertain, all generators consuming natural gas should be in the same group. Group name is user defined| +|p_steps| Number of steps between upper and lower bound| +|total\_num\_trajectory| Total number of trakectories through the design matrix| +|num\_trajectory| Selected number of trajectories throigh the design matrix| +|len\_design\_mat| Length of the design matrix| +|policy| Name of the policy| + +Notes: +1. Upper and lower bounds are specified in terms of percentage deviation from the nominal value. +2. Percentage variation for uncertain parameters in a given group is identical. For example, if solar cluster 1 and solar cluster 2 both belong to the ‘solar’ group, their `Lower_bound` and `Upper_bound` must be identical. +3. `P_steps` should at least be = 1%, i.e., `Upper_bound – Lower_bound < p_steps` +4. `P_steps` for parameters in one group must be identical +5. `Total_num_trajectory` should be around 3 to 4 times the total number of uncertain parameters +6. `num_trajectory` should be approximately equal to the total number of uncertain parameters +7. `len_design_mat` should be 1.5 to 2 times the total number of uncertain parameters +8. Higher number of `num_trajectory` and `len_design_mat` would lead to higher accuracy +9. Upper and lower bounds should be specified for all the resources included in the `Generators_data.csv` file. If a parameter related to a particular resource is not uncertain, specify upper bound = lower bound = 0. \ No newline at end of file diff --git a/docs/src/methods.md b/docs/src/methods.md deleted file mode 100644 index 2dfe075e00..0000000000 --- a/docs/src/methods.md +++ /dev/null @@ -1,136 +0,0 @@ -# Methods -## Time Domain Reduction (TDR) - -Rather than modeling and optimizing power grid operations at a high temporal resolution (e.g., hourly, over a full year) while evaluating new capacity investments, which can be computationally expensive for large-scale studies with several resources, it may be useful to consider a reduced temporal resolution to model annual grid operations. -Such a time-domain reduction is often employed in capacity expansion models as a way to balance model spatial and temporal resolution as well as representation of dispatch, while ensuring reasonable computational times. -The time-domain reduction method provided allows the user to automate these features while specifying the various parameters of the time-domain reduction 'clustering' algorithm to be used in formulating the resulting optimization model. - -### Running a case with Time Domain Reduction - -There are two ways to run a case with a reduced (e.g. less than full-year) temporal resolution. -1. Let GenX perform the time domain reduction before optimizing. -2. Bring your own clustered data - -It's also possible for GenX perform clustering separately from the optimization task. - -### Method 1: Let GenX perform the time domain reduction (clustering) - -Set `TimeDomainReduction: 1` in the GenX settings for the case. - -When the case is run (but before the optimization model is built), -reduced time series data will be output to a folder within the case, (typically) `TDR_Results`. -Note that if the data already exists in that folder, it will *not* be overwritten. -If a user wants to change the time domain reduction settings and try again, the folder should be deleted before the case is run. - -The clustering is done according to the settings in `time_domain_reduction.yml`. -These are described in the Inputs section of [data_documentation](data_documentation.md). - -Time domain clustering can only be performed on data which represents a single contiguous period: typically a year of 8760 or 8736 hours. - -The header of the file `Demand_data.csv` (formerly `Load_data.csv`) in the main case folder will typically look like this: -``` -..., Rep_Periods, Timesteps_per_Rep_Period, Sub_Weights, ... - 1, 8760, 8760, -``` - -For an example that uses this method, see `Example_Systems/RealSystemExample/ISONE_Singlezone`. - -Note that for co-located VRE and storage resources, if GenX performs the time domain reduction clustering, all variable renewable energy variabilities must be in the `Generators_variability.csv` in addition to these files existing in the inputs folder because GenX will separate the wind and solar PV capacity factors after the clustering has been completed into `Vre_and_stor_solar_variability.csv` and `Vre_and_stor_wind_variability.csv`. -However, if a user brings their own clustered data, these three files must be separated by the user (and no co-located VRE variabilities should be found in `Generators_variability.csv`). - -### Method 2: Bring your own clustered data -The second method is to use an external program to generate the reduced ('clustered') time series data. -For instance, [PowerGenome](https://github.com/PowerGenome/PowerGenome) has a capability to construct GenX cases with clustered time series data. - -Running using this method **requires** setting `TimeDomainReduction: 0` in the GenX settings for the case. - -Clustered time series data requires specifying the clustering data using three columns in `Demand_data.csv`: `Rep_Periods`, `Timesteps_per_Rep_Period`, and `Sub_Weights`. -For example, a problem representing a full year via 3 representative weeks, and where the first week represents one which is twice as common as the others, would look like - -``` -..., Rep_Periods, Timesteps_per_Rep_Period, Sub_Weights, ... - 3, 168, 4368.0, - 2184.0, - 2184.0, -``` -In this example, the first week represents a total of `26*168 = 4368` hours over a full year. - -The time series data are written in single unbroken columns: in this example, the `Time_Index` ranges from 1 to 504. - -For problems involving Long Duration Storage, a file `Period_map.csv` is necessary to describe how these representative periods occur throughout the modeled year. - -See also the Inputs section of [data_documentation](data_documentation.md). - -For an example that uses this method, see `Example_Systems/RealSystemExample/ISONE_Trizone`. - -### Performing time domain reduction (TDR) separately from optimization -_Added in 0.3.4_ - -It may be useful to perform time domain reduction (TDR) (or "clustering") on a set of inputs before using them as part of full GenX optimization task. -For example, a user might want to test various TDR settings and examine the resulting clustered inputs. -This can now be performed using the `run_timedomainreduction!` function. - -``` -> julia --project=/home/youruser/GenX - -julia> using GenX -julia> run_timedomainreduction!("/path/to/case") -``` - -This function will obey the settings in `path/to/case/Settings/time_domain_reduction_settings.yml`. -It will output the resulting clustered time series files in the case. - -Running this function will *overwrite* these files in the case. -This is done with the expectation that the user is trying out various settings. - - -### Developer's docs for internal functions related to time domain reduction - -```@autodocs -Modules = [GenX] -Pages = ["time_domain_reduction.jl"] -Order = [:type, :function] -``` - -## Multi-Stage Modeling - -GenX can be configured for multi-stage modeling with perfect foresight. The dual dynamic program (DDP) algorithm is a well-known approach for solving multi-stage optimization problems in a computationally efficient manner, first proposed by Pereira and -Pinto (1991). This algorithm splits up a multi-stage investment planning problem into multiple, single-period sub-problems. Each period is solved iteratively as a separate linear program sub-problem (“forward pass”), and information from future periods is shared with past periods (“backwards pass”) so that investment decisions made in subsequent iterations reflect the contributions of present-day investments to future costs. Multi-period modeling functionality is designed as a "wrapper" around GenX, and to the extent possible, existing methods were left unchanged. - -The time-domain reduction method provided allows the user to automate these feature by specifying the various parameters related to the time-domain reduction algorithm (via time\_domain\_reduction\_settings.yml described under Model Inputs/Outputs documentations/Inputs), including the desired level of temporal resolution to be used in formulating the resulting optimization model. - -```@autodocs -Modules = [GenX] -Pages = ["dual_dynamic_programming.jl"] -Order = [:type, :function] -``` - -```@autodocs -Modules = [GenX] -Pages = ["configure_multi_stage_inputs.jl"] -Order = [:type, :function] -``` - -```@autodocs -Modules = [GenX] -Pages = ["investment_multi_stage.jl"] -Order = [:type, :function] -``` - -```@autodocs -Modules = [GenX] -Pages = ["storage_multi_stage.jl"] -Order = [:type, :function] -``` - -```@autodocs -Modules = [GenX] -Pages = ["transmission_multi_stage.jl"] -Order = [:type, :function] -``` - -```@autodocs -Modules = [GenX] -Pages = ["write_capacity_multi_stage.jl"] -Order = [:type, :function] -``` diff --git a/docs/src/mga.md b/docs/src/mga.md new file mode 100644 index 0000000000..187684bf08 --- /dev/null +++ b/docs/src/mga.md @@ -0,0 +1,5 @@ +# Modeling to Generate Alternatives +```@autodocs +Modules = [GenX] +Pages = ["modeling_to_generate_alternatives.jl"] +``` diff --git a/docs/src/model_configuration.md b/docs/src/model_configuration.md new file mode 100644 index 0000000000..9365ea9d18 --- /dev/null +++ b/docs/src/model_configuration.md @@ -0,0 +1,91 @@ +# Model settings parameters + +The first step in configuring a GenX model is to specify the model settings parameters. These parameters are specified in a `genx_settings.yml` file inside a `Settings` folder which must be located in the current working directory. Settings include those related to model structure, solution strategy and outputs, policy constraints, and others. In particular: +- Model structure related settings parameters affect the formulation of the model constraints and objective function. +- Computational performance related parameters affect the accuracy of the solution. +- Policy related parameters specify the policy type and policy goal. +- Network related parameters specify settings related to transmission network expansion and losses. +Note that all settings parameters are case sensitive. + +The following tables summarize the model settings parameters and their default/possible values. + +## 1. Model structure related settings parameters + +|**Parameter** | **Description**| +| :------------ | :-----------| +|UCommit | Select technical resolution of of modeling thermal generators.| +||0 = no unit commitment.| +||1 = unit commitment with integer clustering.| +||2 = unit commitment with linearized clustering.| +|Reserves | Flag for modeling operating reserves .| +||0 = No operating reserves considered. | +||1 = Consider regulation (primary) and spinning (secondary) reserves. | +|StorageLosses | Flag to account for storage related losses.| +||0 = VRE and CO2 constraints DO NOT account for energy lost. | +||1 = constraints account for energy lost. | +|TimeDomainReduction | 1 = Use time domain reduced inputs available in the folder with the name defined by settings parameter `TimeDomainReductionFolder`. If such a folder does not exist or it is empty, time domain reduction will reduce the input data and save the results there.| +||0 = Use the data in the main case folder; do not perform clustering.| +|TimeDomainReductionFolder | Name of the folder insie the current working directory where time domain reduced input data is stored.| + +## 2. Solution strategy + +|**Parameter** | **Description**| +| :------------ | :-----------| +|Solver | Specifies the solver name (This is not case sensitive i.e. CPLEX/cplex, Gurobi/gurobi, Clp/clp indicate the same solvers, respectively). | +|ParameterScale | Flag to turn on parameter scaling wherein demand, capacity and power variables defined in GW rather than MW. This flag aides in improving the computational performance of the model. | +||1 = Scaling is activated. | +||0 = Scaling is not activated. | +|MultiStage | Model multiple planning stages | +||1 = Model multiple planning stages as specified in `multi_stage_settings.yml` | +||0 = Model single planning stage | +|ModelingToGenerateAlternatives | Modeling to Generate Alternative Algorithm. For details, see [here](https://genxproject.github.io/GenX/dev/additional_features/#Modeling-to-Generate-Alternatives)| +||1 = Use the algorithm. | +||0 = Do not use the algorithm. | +|ModelingtoGenerateAlternativeSlack | value used to define the maximum deviation from the least-cost solution as a part of Modeling to Generate Alternative Algorithm. Can take any real value between 0 and 1. | +|MethodofMorris | Method of Morris algorithm | +||1 = Use the algorithm. | +||0 = Do not use the algorithm. | + +## 3. Policy related + +|**Parameter** | **Description**| +| :------------ | :-----------| +|CO2Cap | Flag for specifying the type of CO2 emission limit constraint.| +|| 0 = no CO2 emission limit| +|| 1 = mass-based emission limit constraint| +|| 2 = demand + rate-based emission limit constraint| +|| 3 = generation + rate-based emission limit constraint| +|EnergyShareRequirement | Flag for specifying regional renewable portfolio standard (RPS) and clean energy standard policy (CES) related constraints.| +|| Default = 0 (No RPS or CES constraints).| +|| 1 = activate energy share requirement related constraints. | +|CapacityReserveMargin | Flag for Capacity Reserve Margin constraints. | +|| Default = 0 (No Capacity Reserve Margin constraints)| +|| 1 = activate Capacity Reserve Margin related constraints | +|MinCapReq | Minimum technology carve out requirement constraints.| +|| 1 = if one or more minimum technology capacity constraints are specified| +|| 0 = otherwise| +|MaxCapReq | Maximum system-wide technology capacity limit constraints.| +|| 1 = if one or more maximum technology capacity constraints are specified| +|| 0 = otherwise| + +## 4. Network related + +|**Parameter** | **Description**| +| :------------ | :-----------| +|NetworkExpansion | Flag for activating or deactivating inter-regional transmission expansion.| +||1 = active| +||0 = modeling single zone or for multi-zone problems in which inter regional transmission expansion is not allowed.| +|Trans\_Loss\_Segments | Number of segments to use in piece-wise linear approximation of losses.| +||1: linear| +||>=2: piece-wise quadratic| + +## 5. Outputs + +|**Parameter** | **Description**| +| :------------ | :-----------| +|PrintModel | Flag for printing the model equations as .lp file.| +||1 = including the model equation as an output| +||0 = the model equation won't be included as an output| +|WriteShadowPrices | Get the optimal values of dual variables of various model related constraints, including to estimate electricity prices, stored value of energy and the marginal CO2 prices.| + +The next step in configuring a GenX model is to specify the solver settings parameters using a `[solver_name]_settings.yml` file inside the `Settings` folder. The solver settings parameters are solver specific and are described in the following section. diff --git a/docs/src/model_input.md b/docs/src/model_input.md new file mode 100644 index 0000000000..26a0e4ba8c --- /dev/null +++ b/docs/src/model_input.md @@ -0,0 +1,376 @@ +# GenX Inputs + +All input files are in CSV format. Running the GenX model requires a minimum of five **mandatory input files**: + +1. Fuels\_data.csv: specify fuel type, CO2 emissions intensity, and time-series of fuel prices. +2. Network.csv: specify network topology, transmission fixed costs, capacity and loss parameters. +3. Demand\_data.csv: specify time-series of demand profiles for each model zone, weights for each time step, demand shedding costs, and optional time domain reduction parameters. +4. Generators\_variability.csv: specify time-series of capacity factor/availability for each resource. +5. Generators\_data.csv: specify cost and performance data for generation, storage and demand flexibility resources. + +Additionally, the user may need to specify eight more **settings-specific** input files based on model configuration and type of scenarios of interest: +1. Reserves.csv: specify operational reserve requirements as a function of demand and renewables generation and penalty for not meeting these requirements. +2. Energy\_share\_requirement.csv: specify regional renewable portfolio standard and clean energy standard style policies requiring minimum energy generation from qualifying resources. +3. CO2\_cap.csv: specify regional CO2 emission limits. +4. Capacity\_reserve\_margin.csv: specify regional capacity reserve margin requirements. +5. Minimum\_capacity\_requirement.csv: specify regional minimum technology capacity deployment requirements. +6. Vre\_and\_stor\_data.csv: specify cost and performance data for co-located VRE and storage resources. +7. Vre\_and\_stor\_solar\_variability.csv: specify time-series of capacity factor/availability for each solar PV resource that exists for every co-located VRE and storage resource (in DC terms). +8. Vre\_and\_stor\_wind\_variability.csv: specify time-series of capacity factor/availability for each wind resource that exists for every co-located VRE and storage resource (in AC terms). + +Description and column details of all potential input files are included in the `Input_data_explained` folder in the `Example_Systems` folder. Names of the input files and their functionality is also given below. + +!!! note "Note" + Names of the input files are case sensitive. + + +## 1 Mandatory input data + + +### 1.1 Fuels\_data.csv + +• **First row:** names of all fuels used in the model instance which should match the labels used in `Fuel` column in the `Generators_data.csv` file. For renewable resources or other resources that do not consume a fuel, the name of the fuel is `None`. + +• **Second row:** The second row specifies the CO2 emissions intensity of each fuel in tons/MMBtu (million British thermal units). Note that by convention, tons correspond to metric tonnes and not short tons (although as long as the user is internally consistent in their application of units, either can be used). + +• **Remaining rows:** Rest of the rows in this input file specify the time-series for prices for each fuel in $/MMBtu. A constant price can be specified by entering the same value for all hours. + +* ** First column:** The first column in this file denotes, Time\_index, represents the index of time steps in a model instance. + + +### 1.2 Network.csv + +This input file contains input parameters related to: 1) definition of model zones (regions between which transmission flows are explicitly modeled) and 2) definition of transmission network topology, existing capacity, losses and reinforcement costs. The following table describe each of the mandatory parameter inputs need to be specified to run an instance of the model, along with comments for the model configurations when they are needed. + +###### Table 3: Structure of the Network.csv file +--- +|**Column Name** | **Description**| +| :------------ | :-----------| +|**Settings-specific Columns**| +|**Multiple zone model**|| +|Network\_Lines | Numerical index for each network line. The length of this column is counted but the actual values are not used.| +| z* (Network map) **OR** Origin_Zone, Destination_Zone | See below | +|Line\_Max\_Flow\_MW | Existing capacity of the inter-regional transmission line.| +|**NetworkExpansion = 1**|| +|Line\_Max\_Reinforcement\_MW |Maximum allowable capacity addition to the existing transmission line.| +|Line\_Reinforcement\_Cost\_per\_MWyr | Cost of adding new capacity to the inter-regional transmission line.| +|**Trans\_Loss\_Segments = 1**|| +|Line\_Loss\_Percentage | fractional transmission loss for each transmission line|| +|**Trans\_Loss\_Segments > 1**|| +|Ohms | Line resistance in Ohms (used to calculate I^2R losses)| +|kV | Line voltage in kV (used to calculate I^2R losses)| +|**CapacityReserveMargin > 0**|| +|CapRes\_* | Eligibility of the transmission line for adding firm capacity to the capacity reserve margin constraint. * represents the number of the capacity reserve margin constraint.| +||1 = the transmission line is eligible for adding firm capacity to the region| +||0 = the transmission line is not eligible for adding firm capacity to the region| +|DerateCapRes\_* | (0,1) value represents the derating of the firm transmission capacity for the capacity reserve margin constraint.| +|CapResExcl\_* | (-1,1,0) = -1 if the designated direction of the transmission line is inbound to locational deliverability area (LDA) modeled by the capacity reserve margin constraint. = 1 if the designated direction of the transmission line is outbound from the LDA modeled by the capacity reserve margin constraint. Zero otherwise.| +|**MultiStage == 1**| +|Capital\_Recovery\_Period |Capital recovery period (in years) used for determining overnight capital costs from annualized investment costs for network transmission line expansion. | +|Line\_Max\_Flow\_Possible\_MW |Maximum possible line flow in the current model period. Overrides Line\_Max\_Reinforcement\_MW, which is not used when performing multi-stage modeling. | + +There are two interfaces implemented for specifying the network topology itself: a matrix interface and a list interface. +Only one choice is permitted in a given file. + +The list interface consists of a column for the lines origin zone and one for the line's destination zone. +Here is a snippet of the Network.csv file for a map with three zones and two lines: +``` +Network_Lines, Origin_Zone, Destination_Zone, + 1, 1, 2, + 2, 1, 3, +``` + +The matrix interface requires N columns labeled `z1, z2, z3 ... zN`, +and L rows, one for each network line (or interregional path), with a `1` in the column corresponding to the 'origin' zone +and a `-1` in the column corresponding to the 'destination' zone for each line. +Here is the same network map implemented as a matrix: +``` +Network_Lines, z1, z2, z3, + 1, 1, -1, 0, + 2, 1, 0, -1, +``` + +Note that in either case, positive flows indicate flow from origin to destination zone; +negative flows indicate flow from destination to origin zone. + + +### 1.3 Load\_data.csv + +This file includes parameters to characterize model temporal resolution to approximate annual grid operations, electricity demand for each time step for each zone, and cost of load shedding. Note that GenX is designed to model hourly time steps. With some care and effort, finer (e.g. 15 minute) or courser (e.g. 2 hour) time steps can be modeled so long as all time-related parameters are scaled appropriately (e.g. time period weights, heat rates, ramp rates and minimum up and down times for generators, variable costs, etc). + +###### Table 4: Structure of the Load\_data.csv file +--- +|**Column Name** | **Description**| +| :------------ | :-----------| +|**Mandatory Columns**| +|Voll |Value of lost load in $/MWh.| +|Demand\_Segment |Number of demand curtailment/lost load segments with different cost and capacity of curtailable demand for each segment. User-specified demand segments. Integer values starting with 1 in the first row. Additional segements added in subsequent rows.| +|Cost\_of\_Demand\_Curtailment\_per\_MW |Cost of non-served energy/demand curtailment (for each segment), reported as a fraction of value of lost load. If *Demand\_Segment = 1*, then this parameter is a scalar and equal to one. In general this parameter is a vector of length equal to the length of Demand\_Segment.| +|Max\_Demand\_Curtailment| Maximum time-dependent demand curtailable in each segment, reported as % of the demand in each zone and each period. *If Demand\_Segment = 1*, then this parameter is a scalar and equal to one. In general this parameter is a vector of length given by length of Demand\_segment.| +|Time\_Index |Index defining time step in the model.| +|Load\_MW\_z* |Load profile of a zone z* in MW; if multiple zones, this parameter will be a matrix with columns equal to number of zones (each column named appropriate zone number appended to parameter) and rows equal to number of time periods of grid operations being modeled.| +|Rep\_Periods |Number of representative periods (e.g. weeks, days) that are modeled to approximate annual grid operations. This is always a single entry. For a full-year model, this is `1`.| +|Timesteps\_per\_Rep\_Period |Number of timesteps per representative period (e.g. 168 if period is set as a week using hour-long time steps). This is always a single entry: all representative periods have the same length. For a full-year model, this entry is equal to the number of time steps.| +|Sub\_Weights |Number of annual time steps (e.g. hours) represented by each timestep in a representative period. The length of this column is equal to the number of representative periods. The sum of the elements should be equal to the total number of time steps in a model time horizon (e.g. 8760 hours if modeling 365 days or 8736 if modeling 52 weeks).| + + + +### 1.4 Generator\_variability.csv + +This file contains the time-series of capacity factors / availability of each resource included in the `Generators_data.csv` file for each time step (e.g. hour) modeled. + +• first column: The first column contains the time index of each row (starting in the second row) from 1 to N. + +• Second column onwards: Resources are listed from the second column onward with headers matching each resource name in the `Generators_data.csv` file in any order. The availability for each resource at each time step is defined as a fraction of installed capacity and should be between 0 and 1. Note that for this reason, resource names specified in `Generators_data.csv` must be unique. Note that for Hydro reservoir resources (i.e. `HYDRO = 1` in the `Generators_data.csv`), values in this file correspond to inflows (in MWhs) to the hydro reservoir as a fraction of installed power capacity, rather than hourly capacity factor. + +### 1.5 Generators\_data.csv + +This file contains cost and performance parameters for various generators and other resources (storage, flexible demand, etc) included in the model formulation. + +###### Table 5: Mandatory columns in the Generators\_data.csv file +--- +|**Column Name** | **Description**| +| :------------ | :-----------| +|Resource | This column contains **unique** names of resources available to the model. Resources can include generators, storage, and flexible or time shiftable demand/loads.| +|Zone | Integer representing zone number where the resource is located. | +|**Technology type flags**| +|New\_Build | {-1, 0, 1}, Flag for resource (storage, generation) eligibility for capacity expansion.| +||New\_Build = 1: eligible for capacity expansion and retirement. | +||New\_Build = 0: not eligible for capacity expansion, eligible for retirement.| +||New\_Build = -1: not eligible for capacity expansion or retirement.| +|THERM | {0, 1, 2}, Flag to indicate membership in set of thermal resources (e.g. nuclear, combined heat and power, natural gas combined cycle, coal power plant)| +||THERM = 0: Not part of set (default) | +||THERM = 1: If the power plant relies on thermal energy input and subject unit commitment constraints/decisions if `UCommit >= 1` (e.g. cycling decisions/costs/constraints). | +||THERM = 2: If the power plant relies on thermal energy input and is subject to simplified economic dispatch constraints (ramping limits and minimum output level but no cycling decisions/costs/constraints). | +|Cap\_size | Size (MW) of a single generating unit. This is used only for resources with integer unit commitment (`THERM = 1`) - not relevant for other resources.| +|VRE | {0, 1}, Flag to indicate membership in set of dispatchable (or curtailable) variable renewable energy resources (onshore wind, offshore wind, utility-scale solar PV, and distributed solar PV subject to dispatch signals).| +||VRE = 0: Not part of set (default) | +||VRE = 1: Dispatchable variable renewable energy (VRE) resources. | +|Num\_VRE\_bins | Number of resource availability profiles considered for each VRE resource per zone. This parameter is used to decide the number of capacity investment decision variables related to a single variable renewable energy technology in each zone.| +||Num\_VRE\_bins = 1: using a single resource availability profile per technology per zone. 1 capacity investment decision variable and 1 generator RID tracking technology power output (and in each zone).| +||Num\_VRE\_bins > 1: using multiple resource availability profiles per technology per zone. Num\_VRE\_bins capacity investment decision variables and 1 generator RID used to define technology power output at each time step (and in each zone). Example: Suppose we are modeling 3 bins of wind profiles for each zone. Then include 3 rows with wind resource names as Wind\_1, Wind\_2, and Wind\_3 and a corresponding increasing sequence of RIDs. Set Num\_VRE\_bins for the generator with smallest RID, Wind\_1, to be 3 and set Num\_VRE\_bins for the other rows corresponding to Wind\_2 and Wind\_3, to be zero. By setting Num\_VRE\_bins for Wind\_2 and Wind\_3, the model eliminates the power outputs variables for these generators. The power output from the technology across all bins is reported in the power output variable for the first generator. This allows for multiple bins without significantly increasing number of model variables (adding each bin only adds one new capacity variable and no operational variables). See documentation for `curtailable_variable_renewable()` for more. | +|MUST\_RUN | {0, 1}, Flag to indicate membership in set of must-run plants (could be used to model behind-the-meter PV not subject to dispatch signals/curtailment, run-of-river hydro that cannot spill water, must-run or self-committed thermal generators, etc). | +||MUST\_RUN = 0: Not part of set (default) | +||MUST\_RUN = 1: Must-run (non-dispatchable) resources.| +|STOR | {0, 1, 2}, Flag to indicate membership in set of storage resources and designate which type of storage resource formulation to employ.| +||STOR = 0: Not part of set (default) | +||STOR = 1: Discharging power capacity and energy capacity are the investment decision variables; symmetric charge/discharge power capacity with charging capacity equal to discharging capacity (e.g. lithium-ion battery storage).| +||STOR = 2: Discharging, charging power capacity and energy capacity are investment variables; asymmetric charge and discharge capacities using distinct processes (e.g. hydrogen electrolysis, storage, and conversion to power using fuel cell or combustion turbine).| +|FLEX | {0, 1}, Flag to indicate membership in set of flexible demand-side resources (e.g. scheduleable or time shiftable loads such as automated EV charging, smart thermostat systems, irrigating pumping loads etc).| +||FLEX = 0: Not part of set (default) | +||FLEX = 1: Flexible demand resource.| +|HYDRO | {0, 1}, Flag to indicate membership in set of reservoir hydro resources.| +||HYDRO = 0: Not part of set (default) | +||HYDRO = 1: Hydropower with reservoir modeling, including inflows, spillage, ramp rate limits and minimum operating level and efficiency loss associated with discharging. Reservoir capacity can be represented as a ratio or energy to power. This type of plant cannot charge from grid.| +|LDS | {0, 1}, Flag to indicate the resources eligible for long duration storage constraints with inter period linkage (e.g., reservoir hydro, hydrogen storage)| +||LDS = 0: Not part of set (default) | +||LDS = 1: Long duration storage resources| +|**Existing technology capacity**| +|Existing\_Cap\_MW |The existing capacity of a power plant in MW.| +|Existing\_Cap\_MWh |The existing capacity of storage in MWh where `STOR = 1` or `STOR = 2`.| +|Existing\_Charge\_Cap\_MW |The existing charging capacity for resources where `STOR = 2`.| +|**Capacity/Energy requirements**| +|Max\_Cap\_MW |-1 (default) – no limit on maximum discharge capacity of the resource. If non-negative, represents maximum allowed discharge capacity (in MW) of the resource.| +|Max\_Cap\_MWh |-1 (default) – no limit on maximum energy capacity of the resource. If non-negative, represents maximum allowed energy capacity (in MWh) of the resource with `STOR = 1` or `STOR = 2`.| +|Max\_Charge\_Cap\_MW |-1 (default) – no limit on maximum charge capacity of the resource. If non-negative, represents maximum allowed charge capacity (in MW) of the resource with `STOR = 2`.| +|Min\_Cap\_MW |-1 (default) – no limit on minimum discharge capacity of the resource. If non-negative, represents minimum allowed discharge capacity (in MW) of the resource.| +|Min\_Cap\_MWh| -1 (default) – no limit on minimum energy capacity of the resource. If non-negative, represents minimum allowed energy capacity (in MWh) of the resource with `STOR = 1` or `STOR = 2`.| +|Min\_Charge\_Cap\_MW |-1 (default) – no limit on minimum charge capacity of the resource. If non-negative, represents minimum allowed charge capacity (in MW) of the resource with `STOR = 2`.| +|**Cost parameters**| +|Inv\_Cost\_per\_MWyr | Annualized capacity investment cost of a technology ($/MW/year). | +|Inv\_Cost\_per\_MWhyr | Annualized investment cost of the energy capacity for a storage technology ($/MW/year), applicable to either `STOR = 1` or `STOR = 2`. | +|Inv\_Cost\_Charge\_per\_MWyr | Annualized capacity investment cost for the charging portion of a storage technology with `STOR = 2` ($/MW/year). | +|Fixed\_OM\_Cost\_per\_MWy | Fixed operations and maintenance cost of a technology ($/MW/year). | +|Fixed\_OM\_Cost\_per\_MWhyr | Fixed operations and maintenance cost of the energy component of a storage technology ($/MWh/year). | +|Fixed\_OM\_Cost\_charge\_per\_MWyr | Fixed operations and maintenance cost of the charging component of a storage technology of type `STOR = 2`. | +|Var\_OM\_Cost\_per\_MWh | Variable operations and maintenance cost of a technology ($/MWh). | +|Var\_OM\_Cost\_per\_MWhIn | Variable operations and maintenance cost of the charging aspect of a storage technology with `STOR = 2`, or variable operations and maintenance costs associated with flexible demand deferral with `FLEX = 1`. Otherwise 0 ($/MWh). | +|**Technical performance parameters**| +|Heat\_Rate\_MMBTU\_per\_MWh |Heat rate of a generator or MMBtu of fuel consumed per MWh of electricity generated for export (net of on-site house loads). The heat rate is the inverse of the efficiency: a lower heat rate is better. Should be consistent with fuel prices in terms of reporting on higher heating value (HHV) or lower heating value (LHV) basis. | +|Fuel |Fuel needed for a generator. The names should match with the ones in the `Fuels_data.csv`. | +|Self\_Disch |[0,1], The power loss of storage technologies per hour (fraction loss per hour)- only applies to storage techs.| +|Min\_Power |[0,1], The minimum generation level for a unit as a fraction of total capacity. This value cannot be higher than the smallest time-dependent CF value for a resource in `Generators_variability.csv`. Applies to thermal plants, and reservoir hydro resource (`HYDRO = 1`).| +|Ramp\_Up\_Percentage |[0,1], Maximum increase in power output from between two periods (typically hours), reported as a fraction of nameplate capacity. Applies to thermal plants, and reservoir hydro resource (`HYDRO = 1`).| +|Ramp\_Dn\_Percentage |[0,1], Maximum decrease in power output from between two periods (typically hours), reported as a fraction of nameplate capacity. Applies to thermal plants, and reservoir hydro resource (`HYDRO = 1`).| +|Eff\_Up |[0,1], Efficiency of charging storage – applies to storage technologies (all STOR types). | +|Eff\_Down |[0,1], Efficiency of discharging storage – applies to storage technologies (all STOR types). | +|Hydro\_Energy\_to\_Power\_Ratio |The rated number of hours of reservoir hydro storage at peak discharge power output. Applies to `HYDRO = 1` (hours). | +|Min\_Duration |Specifies the minimum ratio of installed energy to discharged power capacity that can be installed. Applies to STOR types 1 and 2 (hours). | +|Max\_Duration |Specifies the maximum ratio of installed energy to discharged power capacity that can be installed. Applies to STOR types 1 and 2 (hours). | +|Max\_Flexible\_Demand\_Delay |Maximum number of hours that demand can be deferred or delayed. Applies to resources with FLEX type 1 (hours). | +|Max\_Flexible\_Demand\_Advance |Maximum number of hours that demand can be scheduled in advance of the original schedule. Applies to resources with FLEX type 1 (hours). | +|Flexible\_Demand\_Energy\_Eff |[0,1], Energy efficiency associated with time shifting demand. Represents energy losses due to time shifting (or 'snap back' effect of higher consumption due to delay in use) that may apply to some forms of flexible demand. Applies to resources with FLEX type 1 (hours). For example, one may need to pre-cool a building more than normal to advance demand. | +|**Required for writing outputs**| +|region | Name of the model region| +|cluster | Number of the cluster when representing multiple clusters of a given technology in a given region. | +|**MultiStage == 1**| +|Capital\_Recovery\_Period |Capital recovery period (in years) used for determining overnight capital costs from annualized investment costs. | +|Lifetime |Lifetime (in years) used for determining endogenous retirements of newly built capacity. | +|Min\_Retired\_Cap\_MW |Minimum required discharge capacity retirements in the current model period. This field can be used to enforce lifetime retirements of existing capacity. | +|Min\_Retired\_Cap\_MW |Minimum required discharge capacity retirements in the current model period. This field can be used to enforce lifetime retirements of existing discharge capacity. | +|Min\_Retired\_Energy\_Cap\_MW |Minimum required energy capacity retirements in the current model period. This field can be used to enforce lifetime retirements of existing energy capacity. | +|Min\_Retired\_Charge\_Cap\_MW |Minimum required energy capacity retirements in the current model period. This field can be used to enforce lifetime retirements of existing charge capacity. | +###### Table 6: Settings-specific columns in the Generators\_data.csv file +--- +|**Column Name** | **Description**| +| :------------ | :-----------| +|**UCommit >= 1** | The following settings apply only to thermal plants with unit commitment constraints (`THERM = 1`).| +|Up\_Time| Minimum amount of time a resource has to stay in the committed state.| +|Down\_Time |Minimum amount of time a resource has to remain in the shutdown state.| +|Start\_Cost\_per\_MW |Cost per MW of nameplate capacity to start a generator ($/MW per start). Multiplied by the number of generation units (each with a pre-specified nameplate capacity) that is turned on.| +|Start\_Fuel\_MMBTU\_per\_MW |Startup fuel use per MW of nameplate capacity of each generator (MMBtu/MW per start).| +|**Reserves = 1** | The following settings apply to thermal, dispatchable VRE, hydro and storage resources| +|Reg\_Cost |Cost of providing regulation reserves ($/MW per time step/hour).| +|Rsv\_Cost |Cost of providing upwards spinning or contingency reserves ($/MW per time step/hour).| +|Reg\_Max |[0,1], Fraction of nameplate capacity that can committed to provided regulation reserves. .| +|Rsv\_Max |[0,1], Fraction of nameplate capacity that can committed to provided upwards spinning or contingency reserves.| +|**EnergyShareRequirement > 0**|| +|ESR\_*| Flag to indicate which resources are considered for the Energy Share Requirement constraint.| +||1- included| +||0- excluded| +|**CapacityReserveMargin > 0**|| +|CapRes\_* |[0,1], Fraction of the resource capacity eligible for contributing to the capacity reserve margin constraint (e.g. derate factor).| +|**ModelingToGenerateAlternatives = 1**|| +|MGA |Eligibility of the technology for Modeling To Generate Alternative (MGA) run. | +||1 = Technology is available for the MGA run.| +||0 = Technology is unavailable for the MGA run (e.g. storage technologies).| +|Resource\_Type |For the MGA run, we categorize all the resources in a few resource types. We then find maximally different generation portfolio based on these resource types. For example, existing solar and new solar resources could be represented by a resource type names `Solar`. Categorization of resources into resource types is user dependent.| +|**MinCapReq = 1**| +|MinCapTag\_*| Eligibility of resources to participate in Minimum Technology Carveout constraint. \* corresponds to the ith row of the file `Minimum_capacity_requirement.csv`.| +|**MaxCapReq = 1**| +|MaxCapTag\_*| Eligibility of resources to participate in Maximum Technology Carveout constraint. \* corresponds to the ith row of the file `Maximum_capacity_requirement.csv`.| + + +## 2. Optional inputs files + +### 2.1 Reserves.csv + +This file includes parameter inputs needed to model time-dependent procurement of regulation and spinning reserves. This file is needed if `Reserves` flag is activated in the YAML file `genx_settings.yml`. + +###### Table 7: Structure of the Reserves.csv file +--- +|**Column Name** | **Description**| +| :------------ | :-----------| +|Reg\_Req\_Percent\_Load |[0,1], Regulation requirement as a percent of time-dependent load; here load is the total across all model zones.| +|Reg\_Req\_Percent\_VRE |[0,1], Regulation requirement as a percent of time-dependent wind and solar generation (summed across all model zones).| +|Rsv\_Req\_Percent\_Load [0,1], |Spinning up or contingency reserve requirement as a percent of time-dependent load (which is summed across all zones).| +|Rsv\_Req\_Percent\_VRE |[0,1], Spinning up or contingency reserve requirement as a percent of time-dependent wind and solar generation (which is summed across all zones).| +|Unmet\_Rsv\_Penalty\_Dollar\_per\_MW |Penalty for not meeting time-dependent spinning reserve requirement ($/MW per time step).| +|Dynamic\_Contingency |Flags to include capacity (generation or transmission) contingency to be added to the spinning reserve requirement.| +|Dynamic\_Contingency |= 1: contingency set to be equal to largest installed thermal unit (only applied when `UCommit = 1`).| +||= 2: contingency set to be equal to largest committed thermal unit each time period (only applied when `UCommit = 1`).| +|Static\_Contingency\_MW |A fixed static contingency in MW added to reserve requirement. Applied when `UCommit = 1` and `DynamicContingency = 0`, or when `UCommit = 2`. Contingency term not included in operating reserve requirement when this value is set to 0 and DynamicContingency is not active.| + + + +### 2.2 Energy\_share\_requirement.csv + +This file contains inputs specifying minimum energy share requirement policies, such as Renewable Portfolio Standard (RPS) or Clean Energy Standard (CES) policies. This file is needed if parameter EnergyShareRequirement has a non-zero value in the YAML file `genx_settings.yml`. + +Note: this file should use the same region name as specified in the `Generators_data.csv` file. + +###### Table 8: Structure of the Energy\_share\_requirement.csv file +--- +|**Column Name** | **Description**| +| :------------ | :-----------| +|Region\_description |Region name| +|Network\_zones |zone number represented as z*| +|ESR\_* |[0,1], Energy share requirements as a share of zonal demand (calculated on an annual basis). * represents the number of the ESR constraint, given by the number of ESR\_* columns in the `Energy_share_requirement.csv` file.| + + + +### 2.3 CO2\_cap.csv + +This file contains inputs specifying CO2 emission limits policies (e.g. emissions cap and permit trading programs). This file is needed if `CO2Cap` flag is activated in the YAML file `genx_settings.yml`. `CO2Cap` flag set to 1 represents mass-based (tCO2 ) emission target. `CO2Cap` flag set to 2 is specified when emission target is given in terms of rate (tCO2/MWh) and is based on total demand met. `CO2Cap` flag set to 3 is specified when emission target is given in terms of rate (tCO2 /MWh) and is based on total generation. + +###### Table 9: Structure of the CO2\_cap.csv file +--- +|**Column Name** | **Description**| +| :------------ | :-----------| +|Region\_description |Region name| +|Network\_zones| zone number represented as z*| +|CO\_2\_Cap\_Zone_* |If a zone is eligible for the emission limit constraint, then this column is set to 1, else 0.| +|CO\_2\_Max\_tons\_MWh_* |Emission limit in terms of rate| +|CO\_2\_Max\_Mtons_* |Emission limit in absolute values, in Million of tons | +| | where in the above inputs, * represents the number of the emission limit constraints. For example, if the model has 2 emission limit constraints applied separately for 2 zones, the above CSV file will have 2 columns for specifying emission limit in terms on rate: CO\_2\_Max\_tons\_MWh\_1 and CO\_2\_Max\_tons\_MWh\_2.| + + + +### 2.4 Capacity\_reserve\_margin.csv + +This file contains the regional capacity reserve margin requirements. This file is needed if parameter CapacityReserveMargin has a non-zero value in the YAML file `genx_settings.yml`. + +Note: this file should use the same region name as specified in the `Generators_data.csv` file + +###### Table 10: Structure of the Capacity\_reserve\_margin.csv file +--- +|**Column Name** | **Description**| +| :------------ | :-----------| +|Region\_description |Region name| +|Network\_zones |zone number represented as z*| +|CapRes\_* |[0,1], Capacity reserve margin requirements of a zone, reported as a fraction of demand| + + + +### 2.5 Minimum\_capacity\_requirement.csv + +This file contains the minimum capacity carve-out requirement to be imposed (e.g. a storage capacity mandate or offshore wind capacity mandate). This file is needed if the `MinCapReq` flag has a non-zero value in the YAML file `genx_settings.yml`. + +###### Table 11: Structure of the Minimum\_capacity\_requirement.csv file +--- +|**Column Name** | **Description**| +| :------------ | :-----------| +|MinCapReqConstraint |Index of the minimum capacity carve-out requirement.| +|Constraint\_Description |Names of minimum capacity carve-out constraints; not to be read by model, but used as a helpful notation to the model user. | +|Min\_MW | minimum capacity requirement [MW]| + + +Some of the columns specified in the input files in Section 2.2 and 2.1 are not used in the GenX model formulation. These columns are necessary for interpreting the model outputs and used in the output module of the GenX. + +### 2.6 Maximum\_capacity\_requirement.csv + +This contains the maximum capacity limits to be imposed (e.g. limits on total deployment of solar, wind, or batteries in the system as a whole or in certain collections of zones). +It is required if the `MaxCapReq` flag has a non-zero value in `genx_settings.yml`. + +###### Table 12: Structure of the Maximum\_capacity\_requirement.csv file +--- +|**Column Name** | **Description**| +| :------------ | :-----------| +|MaxCapReqConstraint |Index of the maximum capacity limit.| +|Constraint\_Description |Names of maximum capacity limit; not to be read by model, but used as a helpful notation to the model user. | +|Max\_MW | maximum capacity limit [MW]| + + +Some of the columns specified in the input files in Section 2.2 and 2.1 are not used in the GenX model formulation. These columns are necessary for interpreting the model outputs and used in the output module of the GenX. + +### 2.7 Method\_of\_morris\_range.csv + +This file contains the settings parameters required to run the Method of Morris algorithm in GenX. This file is needed if the `MethodofMorris` flag is ON in the YAML file `genx_settings.yml`. + +###### Table 13: Structure of the Method\_of\_morris\_range.csv file +--- +|**Column Name** | **Description**| +| :------------ | :-----------| +|Resource | This column contains **unique** names of resources available to the model. Resources can include generators, storage, and flexible or time shiftable demand/loads.| +|Zone | Integer representing zone number where the resource is located. | +|Lower\_bound | Percentage lower deviation from the nominal value| +|Upper\_bound| Percentage upper deviation from the nominal value| +|Parameter| Column from the `Generators_data.csv` file containing uncertain parameters| +|Group| Group the uncertain parameters that will be changed all at once while performing the sensitivity analysis. For example, if the fuel price of natural gas is uncertain, all generators consuming natural gas should be in the same group. Group name is user defined| +|p_steps| Number of steps between upper and lower bound| +|total\_num\_trajectory| Total number of trakectories through the design matrix| +|num\_trajectory| Selected number of trajectories throigh the design matrix| +|len\_design\_mat| Length of the design matrix| +|policy| Name of the policy| + +!!! note "Notes" +1. Upper and lower bounds are specified in terms of percentage deviation from the nominal value. +2. Percentage variation for uncertain parameters in a given group is identical. For example, if solar cluster 1 and solar cluster 2 both belong to the ‘solar’ group, their Lower_bound and Upper_bound must be identical +3. P\_steps should at least be = 1\%, i.e., Upper\_bound – Lower\_bound $<$ p\_steps +4. P\_steps for parameters in one group must be identical +5. Total\_num\_trajectory should be around 3 to 4 times the total number of uncertain parameters +6. num\_trajectory should be approximately equal to the total number of uncertain parameters +7. len\_design_mat should be 1.5 to 2 times the total number of uncertain parameters +8. Higher number of num\_trajectory and len_design_mat would lead to higher accuracy +9. Upper and lower bounds should be specified for all the resources included in the `Generators_data.csv` file. If a parameter related to a particular resource is not uncertain, specify upper bound = lower bound = 0. + diff --git a/docs/src/model_notation.md b/docs/src/model_notation.md index defffad6fc..51aacbb4dd 100644 --- a/docs/src/model_notation.md +++ b/docs/src/model_notation.md @@ -66,84 +66,84 @@ $\mathcal{W} \subseteq \mathcal{G}$ | where $\mathcal{W}$ set of hydroelectric g --- |**Notation** | **Description**| | :------------ | :-----------| -|$\Omega_{y,z} \in \mathbb{R}_+$ | Installed capacity in terms of the number of units (each unit, being of size $\overline{\Omega}_{y,z}^{size}$) of resource $y$ in zone $z$ [Dimensionless] (Note that for co-located VRE and storage resources, this value represents the installed capacity of the grid connection in MW AC)| -|$\Omega^{energy}_{y,z} \in \mathbb{R}_+$ | Installed energy capacity of resource $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O} \cup y \in \mathcal{VS}^{stor}$ [MWh] (Note that for co-located VRE and storage resources, this value represents the installed capacity of the storage component in MWh)| -|$\Omega^{charge}_{y,z} \in \mathbb{R}_+$ | Installed charging power capacity of resource $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O}^{asym}$ [MW]| -|$\Omega^{pv}_{y,z} \in \mathbb{R}_+$ | Installed solar PV capacity of resource $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a solar PV component, $y \in \mathcal{VS}^{pv}$ [MW DC]| -|$\Omega^{wind}_{y,z} \in \mathbb{R}_+$ | Installed wind capacity of resource $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a wind component, $y \in \mathcal{VS}^{wind}$ [MW AC]| -|$\Omega^{inv}_{y,z} \in \mathbb{R}_+$ | Installed inverter capacity of resource $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an inverter component, $y \in \mathcal{VS}^{inv}$ [MW AC]| -|$\Omega^{dc,dis}_{y,z} \in \mathbb{R}_+$ | Installed storage DC discharge capacity of resource $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage DC discharge component, $y \in \mathcal{VS}^{asym,dc,dis}$ [MW DC]| -|$\Omega^{dc,cha}_{y,z} \in \mathbb{R}_+$ | Installed storage DC charge capacity of resource $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage DC charge component, $y \in \mathcal{VS}^{asym,dc,cha}$ [MW DC]| -|$\Omega^{ac,dis}_{y,z} \in \mathbb{R}_+$ | Installed storage AC discharge capacity of resource $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage AC discharge component, $y \in \mathcal{VS}^{asym,ac,dis}$ [MW AC]| -|$\Omega^{ac,cha}_{y,z} \in \mathbb{R}_+$ | Installed storage AC charge capacity of resource $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage AC charge component, $y \in \mathcal{VS}^{asym,ac,cha}$ [MW AC]| -|$\Delta_{y,z} \in \mathbb{R}_+$ | Retired capacity of technology $y$ from existing capacity in zone $z$ [MW] (Note that for co-located VRE and storage resources, this value represents the retired capacity of the grid connection in MW AC)| -|$\Delta^{energy}_{y,z} \in \mathbb{R}_+$ | Retired energy capacity of technology $y$ from existing capacity in zone $z$ - only applicable for storage resources, $y \in \mathcal{O} \cup y \in \mathcal{VS}^{stor}$ [MWh] (Note that for co-located VRE and storage resources, this value represents the retired capacity of the storage component in MWh)| -|$\Delta^{charge}_{y,z} \in \mathbb{R}_+$ | Retired charging capacity of technology $y$ from existing capacity in zone $z$ - only applicable for storage resources, $y \in \mathcal{O}^{asym}$[MW]| -|$\Delta^{pv}_{y,z} \in \mathbb{R}_+$ | Retired solar PV capacity of technology $y$ from existing capacity in zone $z$ - only applicable for co-located VRE and storage resources with a solar PV component, $y \in \mathcal{VS}^{pv}$ [MW DC]| -|$\Delta^{wind}_{y,z} \in \mathbb{R}_+$ | Retired wind capacity of technology $y$ from existing capacity in zone $z$ - only applicable for co-located VRE and storage resources with a wind component, $y \in \mathcal{VS}^{wind}$ [MW AC]| -|$\Delta^{inv}_{y,z} \in \mathbb{R}_+$ | Retired inverter capacity of technology $y$ from existing capacity in zone $z$ - only applicable for co-located VRE and storage resources with an inverter component, $y \in \mathcal{VS}^{inv}$ [MW AC]| -|$\Delta^{dc,dis}_{y,z} \in \mathbb{R}_+$ | Retired storage DC discharge capacity of technology $y$ from existing capacity in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage DC discharge component, $y \in \mathcal{VS}^{asym,dc,dis}$ [MW DC]| -|$\Delta^{dc,cha}_{y,z} \in \mathbb{R}_+$ | Retired storage DC charge capacity of technology $y$ from existing capacity in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage DC charge component, $y \in \mathcal{VS}^{asym,dc,cha}$ [MW DC]| -|$\Delta^{ac,dis}_{y,z} \in \mathbb{R}_+$ | Retired storage AC discharge capacity of technology $y$ from existing capacity in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage AC discharge component, $y \in \mathcal{VS}^{asym,ac,dis}$ [MW AC]| -|$\Delta^{ac,cha}_{y,z} \in \mathbb{R}_+$ | Retired storage AC charge capacity of technology $y$ from existing capacity in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage AC charge component, $y \in \mathcal{VS}^{asym,ac,cha}$ [MW AC]| -|$\Delta_{y,z}^{total} \in \mathbb{R}_+$ | Total installed capacity of technology $y$ in zone $z$ [MW] (Note that co-located VRE and storage resources, this value represents the total capacity of the grid connection in MW AC) | -|$\Delta_{y,z}^{total,energy} \in \mathbb{R}_+$ | Total installed energy capacity of technology $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O} \cup y \in \mathcal{VS}^{stor}$ [MWh] (Note that co-located VRE and storage resources, this value represents the total installed energy capacity of the storage component in MWh) | -|$\Delta_{y,z}^{total,charge} \in \mathbb{R}_+$ | Total installed charging power capacity of technology $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O}^{asym}$ [MW]| -|$\Delta_{y,z}^{total,pv} \in \mathbb{R}_+$ | Total installed solar PV capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a solar PV component, $y \in \mathcal{VS}^{pv}$ [MW DC]| -|$\Delta_{y,z}^{total,wind} \in \mathbb{R}_+$ | Total installed wind capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a wind component, $y \in \mathcal{VS}^{wind}$ [MW AC]| -|$\Delta_{y,z}^{total,inv} \in \mathbb{R}_+$ | Total installed inverter capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an inverter component, $y \in \mathcal{VS}^{inv}$ [MW AC]| -|$\Delta_{y,z}^{total,dc,dis} \in \mathbb{R}_+$ | Total installed storage DC discharge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage DC discharge component, $y \in \mathcal{VS}^{asym,dc,dis}$ [MW DC]| -|$\Delta_{y,z}^{total,dc,cha} \in \mathbb{R}_+$ | Total installed storage DC charge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage DC charge component, $y \in \mathcal{VS}^{asym,dc,cha}$ [MW DC]| -|$\Delta_{y,z}^{total,ac,dis} \in \mathbb{R}_+$ | Total installed storage AC discharge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage AC discharge component, $y \in \mathcal{VS}^{asym,ac,dis}$ [MW AC]| -|$\Delta_{y,z}^{total,ac,cha} \in \mathbb{R}_+$ | Total installed storage AC charge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage AC charge component, $y \in \mathcal{VS}^{asym,ac,cha}$ [MW AC]| -|$\bigtriangleup\varphi^{max}_{l}$ | Additional transmission capacity added to line $l$ [MW] | -|$\Theta_{y,z,t} \in \mathbb{R}_+$ | Energy injected into the grid by technology $y$ at time step $t$ in zone $z$ [MWh]| -|$\Theta^{pv}_{y,z,t} \in \mathbb{R}_+$ | Energy generated by the solar PV component into the grid by technology $y$ at time step $t$ in zone $z$ - only applicable for co-located VRE and storage resources with a solar PV component, $y \in \mathcal{VS}^{pv}$ [MWh]| -|$\Theta^{wind}_{y,z,t} \in \mathbb{R}_+$ | Energy generated by the wind component into the grid by technology $y$ at time step $t$ in zone $z$ - only applicable for co-located VRE and storage resources with a wind component, $y \in \mathcal{VS}^{wind}$ [MWh]| -|$\Theta^{dc}_{y,z,t} \in \mathbb{R}_+$ | Energy discharged by the storage DC component into the grid by technology $y$ at time step $t$ in zone $z$ - only applicable for co-located VRE and storage resources with a discharge DC component, $y \in \mathcal{VS}^{sym,dc} \cup y \in \mathcal{VS}^{asym,dc,dis}$ [MWh]| -|$\Theta^{ac}_{y,z,t} \in \mathbb{R}_+$ | Energy discharged by the storage AC component into the grid by technology $y$ at time step $t$ in zone $z$ - only applicable for co-located VRE and storage resources with a discharge AC component, $y \in \mathcal{VS}^{sym,ac} \cup y \in \mathcal{VS}^{asym,ac,dis}$ [MWh]| -|$\Pi_{y,z,t} \in \mathbb{R}_+$ | Energy withdrawn from grid by technology $y$ at time step $t$ in zone $z$ [MWh]| -|$\Pi^{dc}_{y,z,t} \in \mathbb{R}_+$ | Energy withdrawn from the VRE and grid by technology $y$ at time step $t$ in zone $z$ - only applicable for co-located VRE and storage resources with a charge DC component, $y \in \mathcal{VS}^{sym,dc} \cup y \in \mathcal{VS}^{asym,dc,cha}$ [MWh]| -|$\Pi^{ac}_{y,z,t} \in \mathbb{R}_+$ | Energy withdrawn from the VRE and grid by technology $y$ at time step $t$ in zone $z$ - only applicable for co-located VRE and storage resources with a charge AC component, $y \in \mathcal{VS}^{sym,ac} \cup y \in \mathcal{VS}^{asym,ac,cha}$ [MWh]| -|$\Gamma_{y,z,t} \in \mathbb{R}_+$ | Stored energy level of technology $y$ at end of time step $t$ in zone $z$ [MWh]| -|$\Lambda_{s,z,t} \in \mathbb{R}_+$ | Non-served energy/curtailed demand from the price-responsive demand segment $s$ in zone $z$ at time step $t$ [MWh] | -|$l_{l,t} \in \mathbb{R}_+$ | Losses in line $l$ at time step $t$ [MWh]| -|$\varrho_{y,z,t}\in \mathbb{R}_+$ | Spillage from a reservoir technology $y$ at end of time step $t$ in zone $z$ [MWh]| -|$f_{y,z,t}\in \mathbb{R}_+$ | Frequency regulation contribution [MW] for up and down reserves from technology $y$ in zone $z$ at time $t$\footnote{Regulation reserve contribution are modeled to be symmetric, consistent with current practice in electricity markets} | -|$r_{y,z,t} \in \mathbb{R}_+$ | Upward spinning reserves contribution [MW] from technology $y$ in zone $z$ at time $t$\footnote{we are not modeling down spinning reserves since these are usually never binding for high variable renewable energy systems}| -|$f^{charge}_{y,z,t}\in \mathbb{R}_+$ | Frequency regulation contribution [MW] for up and down reserves from charging storage technology $y$ in zone $z$ at time $t$ | -|$f^{discharge}_{y,z,t}\in \mathbb{R}_+$ | Frequency regulation contribution [MW] for up and down reserves from discharging storage technology $y$ in zone $z$ at time $t$ | -|$r^{charge}_{y,z,t} \in \mathbb{R}_+$ | Upward spinning reserves contribution [MW] from charging storage technology $y$ in zone $z$ at time $t$| -|$r^{discharge}_{y,z,t} \in \mathbb{R}_+$ | Upward spinning reserves contribution [MW] from discharging storage technology $y$ in zone $z$ at time $t$| +|$\Omega_{y,z} \in \mathbb{R}_+$ | Installed capacity in terms of the number of units (each unit, being of size $\overline{\Omega}_{y,z}^{size}$) of resource $y$ in zone $z$ \[Dimensionless\] (Note that for co-located VRE and storage resources, this value represents the installed capacity of the grid connection in \[MW AC\])| +|$\Omega^{energy}_{y,z} \in \mathbb{R}_+$ | Installed energy capacity of resource $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O} \cup y \in \mathcal{VS}^{stor}$ \[MWh] (Note that for co-located VRE and storage resources, this value represents the installed capacity of the storage component in MWh)| +|$\Omega^{charge}_{y,z} \in \mathbb{R}_+$ | Installed charging power capacity of resource $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O}^{asym}$ \[MW\]| +|$\Omega^{pv}_{y,z} \in \mathbb{R}_+$ | Installed solar PV capacity of resource $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a solar PV component, $y \in \mathcal{VS}^{pv}$ \[MW DC\]| +|$\Omega^{wind}_{y,z} \in \mathbb{R}_+$ | Installed wind capacity of resource $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a wind component, $y \in \mathcal{VS}^{wind}$ \[MW AC\]| +|$\Omega^{inv}_{y,z} \in \mathbb{R}_+$ | Installed inverter capacity of resource $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an inverter component, $y \in \mathcal{VS}^{inv}$ \[MW AC\]| +|$\Omega^{dc,dis}_{y,z} \in \mathbb{R}_+$ | Installed storage DC discharge capacity of resource $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage DC discharge component, $y \in \mathcal{VS}^{asym,dc,dis}$ \[MW DC\]| +|$\Omega^{dc,cha}_{y,z} \in \mathbb{R}_+$ | Installed storage DC charge capacity of resource $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage DC charge component, $y \in \mathcal{VS}^{asym,dc,cha}$ \[MW DC\]| +|$\Omega^{ac,dis}_{y,z} \in \mathbb{R}_+$ | Installed storage AC discharge capacity of resource $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage AC discharge component, $y \in \mathcal{VS}^{asym,ac,dis}$ \[MW AC\]| +|$\Omega^{ac,cha}_{y,z} \in \mathbb{R}_+$ | Installed storage AC charge capacity of resource $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage AC charge component, $y \in \mathcal{VS}^{asym,ac,cha}$ \[MW AC\]| +|$\Delta_{y,z} \in \mathbb{R}_+$ | Retired capacity of technology $y$ from existing capacity in zone $z$ \[MW\] (Note that for co-located VRE and storage resources, this value represents the retired capacity of the grid connection in MW AC)| +|$\Delta^{energy}_{y,z} \in \mathbb{R}_+$ | Retired energy capacity of technology $y$ from existing capacity in zone $z$ - only applicable for storage resources, $y \in \mathcal{O} \cup y \in \mathcal{VS}^{stor}$ \[MWh] (Note that for co-located VRE and storage resources, this value represents the retired capacity of the storage component in MWh)| +|$\Delta^{charge}_{y,z} \in \mathbb{R}_+$ | Retired charging capacity of technology $y$ from existing capacity in zone $z$ - only applicable for storage resources, $y \in \mathcal{O}^{asym}$\[MW\]| +|$\Delta^{pv}_{y,z} \in \mathbb{R}_+$ | Retired solar PV capacity of technology $y$ from existing capacity in zone $z$ - only applicable for co-located VRE and storage resources with a solar PV component, $y \in \mathcal{VS}^{pv}$ \[MW DC\]| +|$\Delta^{wind}_{y,z} \in \mathbb{R}_+$ | Retired wind capacity of technology $y$ from existing capacity in zone $z$ - only applicable for co-located VRE and storage resources with a wind component, $y \in \mathcal{VS}^{wind}$ \[MW AC\]| +|$\Delta^{inv}_{y,z} \in \mathbb{R}_+$ | Retired inverter capacity of technology $y$ from existing capacity in zone $z$ - only applicable for co-located VRE and storage resources with an inverter component, $y \in \mathcal{VS}^{inv}$ \[MW AC\]| +|$\Delta^{dc,dis}_{y,z} \in \mathbb{R}_+$ | Retired storage DC discharge capacity of technology $y$ from existing capacity in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage DC discharge component, $y \in \mathcal{VS}^{asym,dc,dis}$ \[MW DC\]| +|$\Delta^{dc,cha}_{y,z} \in \mathbb{R}_+$ | Retired storage DC charge capacity of technology $y$ from existing capacity in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage DC charge component, $y \in \mathcal{VS}^{asym,dc,cha}$ \[MW DC\]| +|$\Delta^{ac,dis}_{y,z} \in \mathbb{R}_+$ | Retired storage AC discharge capacity of technology $y$ from existing capacity in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage AC discharge component, $y \in \mathcal{VS}^{asym,ac,dis}$ \[MW AC\]| +|$\Delta^{ac,cha}_{y,z} \in \mathbb{R}_+$ | Retired storage AC charge capacity of technology $y$ from existing capacity in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage AC charge component, $y \in \mathcal{VS}^{asym,ac,cha}$ \[MW AC\]| +|$\Delta_{y,z}^{total} \in \mathbb{R}_+$ | Total installed capacity of technology $y$ in zone $z$ \[MW\] (Note that co-located VRE and storage resources, this value represents the total capacity of the grid connection in MW AC) | +|$\Delta_{y,z}^{total,energy} \in \mathbb{R}_+$ | Total installed energy capacity of technology $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O} \cup y \in \mathcal{VS}^{stor}$ \[MWh] (Note that co-located VRE and storage resources, this value represents the total installed energy capacity of the storage component in MWh) | +|$\Delta_{y,z}^{total,charge} \in \mathbb{R}_+$ | Total installed charging power capacity of technology $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O}^{asym}$ \[MW\]| +|$\Delta_{y,z}^{total,pv} \in \mathbb{R}_+$ | Total installed solar PV capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a solar PV component, $y \in \mathcal{VS}^{pv}$ \[MW DC\]| +|$\Delta_{y,z}^{total,wind} \in \mathbb{R}_+$ | Total installed wind capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a wind component, $y \in \mathcal{VS}^{wind}$ \[MW AC\]| +|$\Delta_{y,z}^{total,inv} \in \mathbb{R}_+$ | Total installed inverter capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an inverter component, $y \in \mathcal{VS}^{inv}$ \[MW AC\]| +|$\Delta_{y,z}^{total,dc,dis} \in \mathbb{R}_+$ | Total installed storage DC discharge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage DC discharge component, $y \in \mathcal{VS}^{asym,dc,dis}$ \[MW DC\]| +|$\Delta_{y,z}^{total,dc,cha} \in \mathbb{R}_+$ | Total installed storage DC charge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage DC charge component, $y \in \mathcal{VS}^{asym,dc,cha}$ \[MW DC\]| +|$\Delta_{y,z}^{total,ac,dis} \in \mathbb{R}_+$ | Total installed storage AC discharge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage AC discharge component, $y \in \mathcal{VS}^{asym,ac,dis}$ \[MW AC\]| +|$\Delta_{y,z}^{total,ac,cha} \in \mathbb{R}_+$ | Total installed storage AC charge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage AC charge component, $y \in \mathcal{VS}^{asym,ac,cha}$ \[MW AC\]| +|$\bigtriangleup\varphi^{max}_{l}$ | Additional transmission capacity added to line $l$ \[MW\] | +|$\Theta_{y,z,t} \in \mathbb{R}_+$ | Energy injected into the grid by technology $y$ at time step $t$ in zone $z$ \[MWh]| +|$\Theta^{pv}_{y,z,t} \in \mathbb{R}_+$ | Energy generated by the solar PV component into the grid by technology $y$ at time step $t$ in zone $z$ - only applicable for co-located VRE and storage resources with a solar PV component, $y \in \mathcal{VS}^{pv}$ \[MWh]| +|$\Theta^{wind}_{y,z,t} \in \mathbb{R}_+$ | Energy generated by the wind component into the grid by technology $y$ at time step $t$ in zone $z$ - only applicable for co-located VRE and storage resources with a wind component, $y \in \mathcal{VS}^{wind}$ \[MWh]| +|$\Theta^{dc}_{y,z,t} \in \mathbb{R}_+$ | Energy discharged by the storage DC component into the grid by technology $y$ at time step $t$ in zone $z$ - only applicable for co-located VRE and storage resources with a discharge DC component, $y \in \mathcal{VS}^{sym,dc} \cup y \in \mathcal{VS}^{asym,dc,dis}$ \[MWh]| +|$\Theta^{ac}_{y,z,t} \in \mathbb{R}_+$ | Energy discharged by the storage AC component into the grid by technology $y$ at time step $t$ in zone $z$ - only applicable for co-located VRE and storage resources with a discharge AC component, $y \in \mathcal{VS}^{sym,ac} \cup y \in \mathcal{VS}^{asym,ac,dis}$ \[MWh]| +|$\Pi_{y,z,t} \in \mathbb{R}_+$ | Energy withdrawn from grid by technology $y$ at time step $t$ in zone $z$ \[MWh]| +|$\Pi^{dc}_{y,z,t} \in \mathbb{R}_+$ | Energy withdrawn from the VRE and grid by technology $y$ at time step $t$ in zone $z$ - only applicable for co-located VRE and storage resources with a charge DC component, $y \in \mathcal{VS}^{sym,dc} \cup y \in \mathcal{VS}^{asym,dc,cha}$ \[MWh]| +|$\Pi^{ac}_{y,z,t} \in \mathbb{R}_+$ | Energy withdrawn from the VRE and grid by technology $y$ at time step $t$ in zone $z$ - only applicable for co-located VRE and storage resources with a charge AC component, $y \in \mathcal{VS}^{sym,ac} \cup y \in \mathcal{VS}^{asym,ac,cha}$ \[MWh]| +|$\Gamma_{y,z,t} \in \mathbb{R}_+$ | Stored energy level of technology $y$ at end of time step $t$ in zone $z$ \[MWh]| +|$\Lambda_{s,z,t} \in \mathbb{R}_+$ | Non-served energy/curtailed demand from the price-responsive demand segment $s$ in zone $z$ at time step $t$ \[MWh] | +|$l_{l,t} \in \mathbb{R}_+$ | Losses in line $l$ at time step $t$ \[MWh]| +|$\varrho_{y,z,t}\in \mathbb{R}_+$ | Spillage from a reservoir technology $y$ at end of time step $t$ in zone $z$ \[MWh]| +|$f_{y,z,t}\in \mathbb{R}_+$ | Frequency regulation contribution \[MW\] for up and down reserves from technology $y$ in zone $z$ at time $t$\footnote{Regulation reserve contribution are modeled to be symmetric, consistent with current practice in electricity markets} | +|$r_{y,z,t} \in \mathbb{R}_+$ | Upward spinning reserves contribution \[MW\] from technology $y$ in zone $z$ at time $t (we are not modeling down spinning reserves since these are usually never binding for high variable renewable energy systems)| +|$f^{charge}_{y,z,t}\in \mathbb{R}_+$ | Frequency regulation contribution \[MW\] for up and down reserves from charging storage technology $y$ in zone $z$ at time $t$ | +|$f^{discharge}_{y,z,t}\in \mathbb{R}_+$ | Frequency regulation contribution \[MW\] for up and down reserves from discharging storage technology $y$ in zone $z$ at time $t$ | +|$r^{charge}_{y,z,t} \in \mathbb{R}_+$ | Upward spinning reserves contribution \[MW\] from charging storage technology $y$ in zone $z$ at time $t$| +|$r^{discharge}_{y,z,t} \in \mathbb{R}_+$ | Upward spinning reserves contribution \[MW\] from discharging storage technology $y$ in zone $z$ at time $t$| |$r^{unmet}_t \in \mathbb{R}_+$ | Shortfall in provision of upward operating spinning reserves during each time period $t \in T$ | -|$f^{pv}_{y,z,t}\in \mathbb{R}_+$ | Frequency regulation contribution [MW] for up and down reserves for the solar PV component from technology $y$ in zone $z$ at time $t$ - only applicable for co-located VRE and storage resources with a solar PV component, $y \in \mathcal{VS}^{pv}$ | -|$r^{pv}_{y,z,t} \in \mathbb{R}_+$ | Upward spinning reserves contribution [MW] for the solar PV component from technology $y$ in zone $z$ at time $t$ - only applicable for co-located VRE and storage resources with a solar PV component, $y \in \mathcal{VS}^{pv}$ | -|$f^{wind}_{y,z,t}\in \mathbb{R}_+$ | Frequency regulation contribution [MW] for up and down reserves for the wind component from technology $y$ in zone $z$ at time $t$ - only applicable for co-located VRE and storage resources with a wind component, $y \in \mathcal{VS}^{wind}$ | -|$r^{wind}_{y,z,t} \in \mathbb{R}_+$ | Upward spinning reserves contribution [MW] for the wind component from technology $y$ in zone $z$ at time $t$ - only applicable for co-located VRE and storage resources with a wind component, $y \in \mathcal{VS}^{wind}$ | -|$f^{dc,dis}_{y,z,t}\in \mathbb{R}_+$ | Frequency regulation contribution [MW] for up and down reserves for the storage DC discharge component from technology $y$ in zone $z$ at time $t$ - only applicable for co-located VRE and storage resources with a storage DC discharge component, $y \in \mathcal{VS}^{sym,dc} \cup y \in \mathcal{VS}^{asym,dc,dis}$ | -|$r^{dc,dis}_{y,z,t} \in \mathbb{R}_+$ | Upward spinning reserves contribution [MW] for the storage DC discharge component from technology $y$ in zone $z$ at time $t$ - only applicable for co-located VRE and storage resources with a storage DC discharge component, $y \in \mathcal{VS}^{sym,dc} \cup y \in \mathcal{VS}^{asym,dc,dis}$ | -|$f^{dc,cha}_{y,z,t}\in \mathbb{R}_+$ | Frequency regulation contribution [MW] for up and down reserves for the storage DC charge component from technology $y$ in zone $z$ at time $t$ - only applicable for co-located VRE and storage resources with a storage DC charge component, $y \in \mathcal{VS}^{sym,dc} \cup y \in \mathcal{VS}^{asym,dc,cha}$ | -|$r^{dc,cha}_{y,z,t} \in \mathbb{R}_+$ | Upward spinning reserves contribution [MW] for the storage DC charge component from technology $y$ in zone $z$ at time $t$ - only applicable for co-located VRE and storage resources with a storage DC charge component, $y \in \mathcal{VS}^{sym,dc} \cup y \in \mathcal{VS}^{asym,dc,cha}$ | -|$f^{ac,dis}_{y,z,t}\in \mathbb{R}_+$ | Frequency regulation contribution [MW] for up and down reserves for the storage AC discharge component from technology $y$ in zone $z$ at time $t$ - only applicable for co-located VRE and storage resources with a storage AC discharge component, $y \in \mathcal{VS}^{sym,ac} \cup y \in \mathcal{VS}^{asym,ac,dis}$ | -|$r^{ac,dis}_{y,z,t} \in \mathbb{R}_+$ | Upward spinning reserves contribution [MW] for the storage AC discharge component from technology $y$ in zone $z$ at time $t$ - only applicable for co-located VRE and storage resources with a storage AC discharge component, $y \in \mathcal{VS}^{sym,ac} \cup y \in \mathcal{VS}^{asym,ac,dis}$ | -|$f^{ac,cha}_{y,z,t}\in \mathbb{R}_+$ | Frequency regulation contribution [MW] for up and down reserves for the storage AC charge component from technology $y$ in zone $z$ at time $t$ - only applicable for co-located VRE and storage resources with a storage AC charge component, $y \in \mathcal{VS}^{sym,ac} \cup y \in \mathcal{VS}^{asym,ac,cha}$ | -|$r^{ac,cha}_{y,z,t} \in \mathbb{R}_+$ | Upward spinning reserves contribution [MW] for the storage AC charge component from technology $y$ in zone $z$ at time $t$ - only applicable for co-located VRE and storage resources with a storage AC charge component, $y \in \mathcal{VS}^{sym,ac} \cup y \in \mathcal{VS}^{asym,ac,cha}$ | +|$f^{pv}_{y,z,t}\in \mathbb{R}_+$ | Frequency regulation contribution \[MW\] for up and down reserves for the solar PV component from technology $y$ in zone $z$ at time $t$ - only applicable for co-located VRE and storage resources with a solar PV component, $y \in \mathcal{VS}^{pv}$ | +|$r^{pv}_{y,z,t} \in \mathbb{R}_+$ | Upward spinning reserves contribution \[MW\] for the solar PV component from technology $y$ in zone $z$ at time $t$ - only applicable for co-located VRE and storage resources with a solar PV component, $y \in \mathcal{VS}^{pv}$ | +|$f^{wind}_{y,z,t}\in \mathbb{R}_+$ | Frequency regulation contribution \[MW\] for up and down reserves for the wind component from technology $y$ in zone $z$ at time $t$ - only applicable for co-located VRE and storage resources with a wind component, $y \in \mathcal{VS}^{wind}$ | +|$r^{wind}_{y,z,t} \in \mathbb{R}_+$ | Upward spinning reserves contribution \[MW\] for the wind component from technology $y$ in zone $z$ at time $t$ - only applicable for co-located VRE and storage resources with a wind component, $y \in \mathcal{VS}^{wind}$ | +|$f^{dc,dis}_{y,z,t}\in \mathbb{R}_+$ | Frequency regulation contribution \[MW\] for up and down reserves for the storage DC discharge component from technology $y$ in zone $z$ at time $t$ - only applicable for co-located VRE and storage resources with a storage DC discharge component, $y \in \mathcal{VS}^{sym,dc} \cup y \in \mathcal{VS}^{asym,dc,dis}$ | +|$r^{dc,dis}_{y,z,t} \in \mathbb{R}_+$ | Upward spinning reserves contribution \[MW\] for the storage DC discharge component from technology $y$ in zone $z$ at time $t$ - only applicable for co-located VRE and storage resources with a storage DC discharge component, $y \in \mathcal{VS}^{sym,dc} \cup y \in \mathcal{VS}^{asym,dc,dis}$ | +|$f^{dc,cha}_{y,z,t}\in \mathbb{R}_+$ | Frequency regulation contribution \[MW\] for up and down reserves for the storage DC charge component from technology $y$ in zone $z$ at time $t$ - only applicable for co-located VRE and storage resources with a storage DC charge component, $y \in \mathcal{VS}^{sym,dc} \cup y \in \mathcal{VS}^{asym,dc,cha}$ | +|$r^{dc,cha}_{y,z,t} \in \mathbb{R}_+$ | Upward spinning reserves contribution \[MW\] for the storage DC charge component from technology $y$ in zone $z$ at time $t$ - only applicable for co-located VRE and storage resources with a storage DC charge component, $y \in \mathcal{VS}^{sym,dc} \cup y \in \mathcal{VS}^{asym,dc,cha}$ | +|$f^{ac,dis}_{y,z,t}\in \mathbb{R}_+$ | Frequency regulation contribution \[MW\] for up and down reserves for the storage AC discharge component from technology $y$ in zone $z$ at time $t$ - only applicable for co-located VRE and storage resources with a storage AC discharge component, $y \in \mathcal{VS}^{sym,ac} \cup y \in \mathcal{VS}^{asym,ac,dis}$ | +|$r^{ac,dis}_{y,z,t} \in \mathbb{R}_+$ | Upward spinning reserves contribution \[MW\] for the storage AC discharge component from technology $y$ in zone $z$ at time $t$ - only applicable for co-located VRE and storage resources with a storage AC discharge component, $y \in \mathcal{VS}^{sym,ac} \cup y \in \mathcal{VS}^{asym,ac,dis}$ | +|$f^{ac,cha}_{y,z,t}\in \mathbb{R}_+$ | Frequency regulation contribution \[MW\] for up and down reserves for the storage AC charge component from technology $y$ in zone $z$ at time $t$ - only applicable for co-located VRE and storage resources with a storage AC charge component, $y \in \mathcal{VS}^{sym,ac} \cup y \in \mathcal{VS}^{asym,ac,cha}$ | +|$r^{ac,cha}_{y,z,t} \in \mathbb{R}_+$ | Upward spinning reserves contribution \[MW\] for the storage AC charge component from technology $y$ in zone $z$ at time $t$ - only applicable for co-located VRE and storage resources with a storage AC charge component, $y \in \mathcal{VS}^{sym,ac} \cup y \in \mathcal{VS}^{asym,ac,cha}$ | |$\alpha^{Contingency,Aux}_{y,z} \in \{0,1\}$ | Binary variable that is set to be 1 if the total installed capacity $\Delta^{\text{total}}_{y,z} > 0$ for any generator $y \in \mathcal{UC}$ and zone $z$, and can be 0 otherwise | -|$\Phi_{l,t} \in \mathbb{R}_+$ | Power flow in line $l$ at time step $t$ [MWh]| +|$\Phi_{l,t} \in \mathbb{R}_+$ | Power flow in line $l$ at time step $t$ \[MWh]| |$v_{y,z,t}$ | Commitment state of the generation cluster $y$ in zone $z$ at time $t$| |$\mathcal{X}_{y,z,t}$ | Number of startup decisions, of the generation cluster $y$ in zone $z$ at time $t$| |$\zeta_{y,z,t}$ | Number of shutdown decisions, of the generation cluster $y$ in zone $z$ at time $t$| -|$\mathcal{Q}_{o,n} \in \mathbb{R}_+$ | Inventory of storage of type $o$ at the beginning of input period $n$ [MWh]| -|$\Delta\mathcal{Q}_{o,m} \in \mathbb{R}$ | Excess storage inventory built up during representative period $m$ [MWh]| +|$\mathcal{Q}_{o,n} \in \mathbb{R}_+$ | Inventory of storage of type $o$ at the beginning of input period $n$ \[MWh]| +|$\Delta\mathcal{Q}_{o,m} \in \mathbb{R}$ | Excess storage inventory built up during representative period $m$ \[MWh]| |$ON^{+}_{l,t} \in \{0,1\} $ | Binary variable to activate positive flows on line $l$ in time $t$| -|$TransON^{+}_{l,t} \in \mathbb{R}_+$ | Variable defining maximum positive flow in line $l$ in time $t$ [MW]| -|$\Theta^{CRM}_{y,z,t} \in \mathbb{R}_+$ | "Virtual" energy discharged by a storage resource that contributes to the capacity reserve margin for technology $y$ at time step $t$ in zone $z$ - only applicable for storage resources with activated capacity reserve margin policies, $y \in \mathcal{O}$ [MWh]| -|$\Pi^{CRM}_{y,z,t} \in \mathbb{R}_+$ | "Virtual" energy withdrawn by a storage resource from the grid by technology $y$ at time step $t$ in zone $z$ - only applicable for storage resources with activated capacity reserve margin policies, $y \in \mathcal{O}$ [MWh]| -|$\Theta^{CRM,dc}_{y,z,t} \in \mathbb{R}_+$ | "Virtual" energy discharged by a storage DC component that contributes to the capacity reserve margin for technology $y$ at time step $t$ in zone $z$ - only applicable for co-located VRE and storage resources with activated capacity reserve margin policies, $y \in \mathcal{VS}^{stor}$ [MWh]| -|$\Pi^{CRM,dc}_{y,z,t} \in \mathbb{R}_+$ | "Virtual" energy withdrawn by a storage DC component from the grid by technology $y$ at time step $t$ in zone $z$ - only applicable for co-located VRE and storage resources with activated capacity reserve margin policies, $y \in \mathcal{VS}^{stor}$ [MWh]| -|$\Theta^{CRM,ac}_{y,z,t} \in \mathbb{R}_+$ | "Virtual" energy discharged by a storage AC component that contributes to the capacity reserve margin for technology $y$ at time step $t$ in zone $z$ - only applicable for co-located VRE and storage resources with activated capacity reserve margin policies, $y \in \mathcal{VS}^{stor}$ [MWh]| -|$\Pi^{CRM,ac}_{y,z,t} \in \mathbb{R}_+$ | "Virtual" energy withdrawn by a storage AC component from the grid by technology $y$ at time step $t$ in zone $z$ - only applicable for co-located VRE and storage resources with activated capacity reserve margin policies, $y \in \mathcal{VS}^{stor}$ [MWh]| -|$\Gamma^{CRM}_{y,z,t} \in \mathbb{R}_+$ | Total "virtual" state of charge being held in reserves for technology $y$ at time step $t$ in zone $z$ - only applicable for standalone storage and co-located VRE and storage resources with activated capacity reserve margin policies, $y \in \mathcal{O} \cup y \in \mathcal{VS}^{stor}$ [MWh]| +|$TransON^{+}_{l,t} \in \mathbb{R}_+$ | Variable defining maximum positive flow in line $l$ in time $t$ \[MW\]| +|$\Theta^{CRM}_{y,z,t} \in \mathbb{R}_+$ | "Virtual" energy discharged by a storage resource that contributes to the capacity reserve margin for technology $y$ at time step $t$ in zone $z$ - only applicable for storage resources with activated capacity reserve margin policies, $y \in \mathcal{O}$ \[MWh]| +|$\Pi^{CRM}_{y,z,t} \in \mathbb{R}_+$ | "Virtual" energy withdrawn by a storage resource from the grid by technology $y$ at time step $t$ in zone $z$ - only applicable for storage resources with activated capacity reserve margin policies, $y \in \mathcal{O}$ \[MWh]| +|$\Theta^{CRM,dc}_{y,z,t} \in \mathbb{R}_+$ | "Virtual" energy discharged by a storage DC component that contributes to the capacity reserve margin for technology $y$ at time step $t$ in zone $z$ - only applicable for co-located VRE and storage resources with activated capacity reserve margin policies, $y \in \mathcal{VS}^{stor}$ \[MWh]| +|$\Pi^{CRM,dc}_{y,z,t} \in \mathbb{R}_+$ | "Virtual" energy withdrawn by a storage DC component from the grid by technology $y$ at time step $t$ in zone $z$ - only applicable for co-located VRE and storage resources with activated capacity reserve margin policies, $y \in \mathcal{VS}^{stor}$ \[MWh]| +|$\Theta^{CRM,ac}_{y,z,t} \in \mathbb{R}_+$ | "Virtual" energy discharged by a storage AC component that contributes to the capacity reserve margin for technology $y$ at time step $t$ in zone $z$ - only applicable for co-located VRE and storage resources with activated capacity reserve margin policies, $y \in \mathcal{VS}^{stor}$ \[MWh]| +|$\Pi^{CRM,ac}_{y,z,t} \in \mathbb{R}_+$ | "Virtual" energy withdrawn by a storage AC component from the grid by technology $y$ at time step $t$ in zone $z$ - only applicable for co-located VRE and storage resources with activated capacity reserve margin policies, $y \in \mathcal{VS}^{stor}$ \[MWh]| +|$\Gamma^{CRM}_{y,z,t} \in \mathbb{R}_+$ | Total "virtual" state of charge being held in reserves for technology $y$ at time step $t$ in zone $z$ - only applicable for standalone storage and co-located VRE and storage resources with activated capacity reserve margin policies, $y \in \mathcal{O} \cup y \in \mathcal{VS}^{stor}$ \[MWh]| --- @@ -151,55 +151,55 @@ $\mathcal{W} \subseteq \mathcal{G}$ | where $\mathcal{W}$ set of hydroelectric g --- |**Notation** | **Description**| | :------------ | :-----------| -|$D_{z,t}$ | Electricity demand in zone $z$ and at time step $t$ [MWh]| +|$D_{z,t}$ | Electricity demand in zone $z$ and at time step $t$ \[MWh\]| |$\tau^{period}$ | number of time steps in each representative period $w \in \mathcal{W}^{rep}$ and each input period $w \in \mathcal{W}^{input}$| -|$\omega_{t}$ | weight of each model time step $\omega_t =1 \forall t \in T$ when modeling each time step of the year at an hourly resolution [1/year]| -|$n_s^{slope}$ | Cost of non-served energy/demand curtailment for price-responsive demand segment $s$ [\$/MWh]| -|$n_s^{size}$ | Size of price-responsive demand segment $s$ as a fraction of the hourly zonal demand [%]| -|$\overline{\Omega}_{y,z}$ | Maximum capacity of technology $y$ in zone $z$ [MW] (Note that for co-located VRE and storage resources, this value represents the maximum grid connection capacity in MW AC)| -|$\underline{\Omega}_{y,z}$ | Minimum capacity of technology $y$ in zone $z$ [MW] (Note that for co-located VRE and storage resources, this value represents the minimum grid connection capacity in MW AC)| -|$\overline{\Omega}^{energy}_{y,z}$ | Maximum energy capacity of technology $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O} \cup y \in \mathcal{VS}^{stor}$ [MWh] (Note that for co-located VRE and storage resources, this value represents the maximum storage component in MWh)| -|$\underline{\Omega}^{energy}_{y,z}$ | Minimum energy capacity of technology $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O} \cup y \in \mathcal{VS}^{stor}$ [MWh] (Note that for co-located VRE and storage resources, this value represents the minimum storage component in MWh)| -|$\overline{\Omega}^{charge}_{y,z}$ | Maximum charging power capacity of technology $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O}^{asym}$ [MW]| -|$\underline{\Omega}^{charge}_{y,z}$ | Minimum charging capacity of technology $y$ in zone $z$- only applicable for storage resources, $y \in \mathcal{O}^{asym}$ [MW]| -|$\overline{\Omega}^{pv}_{y,z}$ | Maximum solar PV capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a solar PV component, $y \in \mathcal{VS}^{pv}$ [MW DC]| -|$\underline{\Omega}^{pv}_{y,z}$ | Minimum solar PV capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a solar PV component, $y \in \mathcal{VS}^{pv}$ [MW DC]| -|$\overline{\Omega}^{wind}_{y,z}$ | Maximum wind capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a wind component, $y \in \mathcal{VS}^{wind}$ [MW AC]| -|$\underline{\Omega}^{wind}_{y,z}$ | Minimum wind capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a wind component, $y \in \mathcal{VS}^{wind}$ [MW AC]| -|$\overline{\Omega}^{inv}_{y,z}$ | Maximum inverter capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an inverter component, $y \in \mathcal{VS}^{inv}$ [MW AC]| -|$\underline{\Omega}^{inv}_{y,z}$ | Minimum inverter capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an inverter component, $y \in \mathcal{VS}^{inv}$ [MW AC]| -|$\overline{\Omega}^{dc,dis}_{y,z}$ | Maximum storage DC discharge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage DC discharge component, $y \in \mathcal{VS}^{asym,dc,dis}$ [MW DC]| -|$\underline{\Omega}^{dc,dis}_{y,z}$ | Minimum storage DC discharge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage DC discharge component, $y \in \mathcal{VS}^{asym,dc,dis}$ [MW DC]| -|$\overline{\Omega}^{dc,cha}_{y,z}$ | Maximum storage DC charge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage DC charge component, $y \in \mathcal{VS}^{asym,dc,cha}$ [MW DC]| -|$\underline{\Omega}^{dc,cha}_{y,z}$ | Minimum storage DC charge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage DC charge component, $y \in \mathcal{VS}^{asym,dc,cha}$ [MW DC]| -|$\overline{\Omega}^{ac,dis}_{y,z}$ | Maximum storage AC discharge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage AC discharge component, $y \in \mathcal{VS}^{asym,ac,dis}$ [MW AC]| -|$\underline{\Omega}^{ac,dis}_{y,z}$ | Minimum storage AC discharge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage AC discharge component, $y \in \mathcal{VS}^{asym,ac,dis}$ [MW AC]| -|$\overline{\Omega}^{ac,cha}_{y,z}$ | Maximum storage AC charge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage AC charge component, $y \in \mathcal{VS}^{asym,ac,cha}$ [MW AC]| -|$\underline{\Omega}^{ac,cha}_{y,z}$ | Minimum storage AC charge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage AC charge component, $y \in \mathcal{VS}^{asym,ac,cha}$ [MW AC]| -|$\overline{\Delta}_{y,z}$ | Existing installed capacity of technology $y$ in zone $z$ [MW] (Note that for co-located VRE and storage resources, this value represents the existing installed capacity of the grid connection in MW AC)| -|$\overline{\Delta^{energy}_{y,z}}$ | Existing installed energy capacity of technology $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O} \cup y \in \mathcal{VS}^{stor}$ [MWh] (Note that for co-located VRE and storage resources, this value represents the existing installed energy capacity of the storage component in MWh)| -|$\overline{\Delta^{charge}_{y,z}}$ | Existing installed charging capacity of technology $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O}$ [MW]| -|$\overline{\Delta^{pv}_{y,z}}$ | Existing installed solar PV capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a solar PV component, $y \in \mathcal{VS}^{pv}$ [MW DC]| -|$\overline{\Delta^{wind}_{y,z}}$ | Existing installed wind capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a wind component, $y \in \mathcal{VS}^{wind}$ [MW AC]| -|$\overline{\Delta^{inv}_{y,z}}$ | Existing installed inverter capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an inverter component, $y \in \mathcal{VS}^{inv}$ [MW AC]| -|$\overline{\Delta^{dc,dis}_{y,z}}$ | Existing installed storage DC discharge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage DC discharge component, $y \in \mathcal{VS}^{asym,dc,dis}$ [MW DC]| -|$\overline{\Delta^{dc,cha}_{y,z}}$ | Existing installed storage DC charge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage DC charge component, $y \in \mathcal{VS}^{asym,dc,cha}$ [MW DC]| -|$\overline{\Delta^{ac,dis}_{y,z}}$ | Existing installed storage AC discharge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage AC discharge component, $y \in \mathcal{VS}^{asym,ac,dis}$ [MW AC]| -|$\overline{\Delta^{dc,cha}_{y,z}}$ | Existing installed storage AC charge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage AC charge component, $y \in \mathcal{VS}^{asym,dc,cha}$ [MW AC]| -|$\overline{\Omega}_{y,z}^{size}$ | Unit size of technology $y$ in zone $z$ [MW]| -|$\pi_{y,z}^{INVEST}$ | Investment cost (annual amortization of total construction cost) for power capacity of technology $y$ in zone $z$ [\$/MW-yr] (Note that for co-located VRE and storage resources, this value represents the investment cost of the grid connection capacity in \$/MW AC-yr)| -|$\pi_{y,z}^{INVEST,energy}$ | Investment cost (annual amortization of total construction cost) for energy capacity of technology $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O} \cup y \in \mathcal{VS}^{pv}$ [\$/MWh-yr] (Note that for co-located VRE and storage resources, this value represents the investment cost of the energy capacity of the storage component in \$/MWh-yr)| -|$\pi_{y,z}^{INVEST,charge}$ | Investment cost (annual amortization of total construction cost) for charging power capacity of technology $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O}$ [\$/MW-yr]| -|$\pi_{y,z}^{INVEST,pv}$ | Investment cost (annual amortization of total construction cost) for solar PV capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a solar PV component, $y \in \mathcal{VS}^{pv}$ [\$/MW DC-yr]| -|$\pi_{y,z}^{INVEST,wind}$ | Investment cost (annual amortization of total construction cost) for wind capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a wind component, $y \in \mathcal{VS}^{wind}$ [\$/MW AC-yr]| -|$\pi_{y,z}^{INVEST,inv}$ | Investment cost (annual amortization of total construction cost) for inverter capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an inverter component, $y \in \mathcal{VS}^{inv}$ [\$/MW AC-yr]| +|$\omega_{t}$ | weight of each model time step $\omega_t =1 \forall t \in T$ when modeling each time step of the year at an hourly resolution \[1/year\]| +|$n_s^{slope}$ | Cost of non-served energy/demand curtailment for price-responsive demand segment $s$ \[\$/MWh\]| +|$n_s^{size}$ | Size of price-responsive demand segment $s$ as a fraction of the hourly zonal demand \[%\]| +|$\overline{\Omega}_{y,z}$ | Maximum capacity of technology $y$ in zone $z$ \[MW\] (Note that for co-located VRE and storage resources, this value represents the maximum grid connection capacity in MW AC)| +|$\underline{\Omega}_{y,z}$ | Minimum capacity of technology $y$ in zone $z$ \[MW\] (Note that for co-located VRE and storage resources, this value represents the minimum grid connection capacity in MW AC)| +|$\overline{\Omega}^{energy}_{y,z}$ | Maximum energy capacity of technology $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O} \cup y \in \mathcal{VS}^{stor}$ \[MWh\] (Note that for co-located VRE and storage resources, this value represents the maximum storage component in MWh)| +|$\underline{\Omega}^{energy}_{y,z}$ | Minimum energy capacity of technology $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O} \cup y \in \mathcal{VS}^{stor}$ \[MWh\] (Note that for co-located VRE and storage resources, this value represents the minimum storage component in MWh)| +|$\overline{\Omega}^{charge}_{y,z}$ | Maximum charging power capacity of technology $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O}^{asym}$ \[MW\]| +|$\underline{\Omega}^{charge}_{y,z}$ | Minimum charging capacity of technology $y$ in zone $z$- only applicable for storage resources, $y \in \mathcal{O}^{asym}$ \[MW\]| +|$\overline{\Omega}^{pv}_{y,z}$ | Maximum solar PV capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a solar PV component, $y \in \mathcal{VS}^{pv}$ \[MW DC\]| +|$\underline{\Omega}^{pv}_{y,z}$ | Minimum solar PV capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a solar PV component, $y \in \mathcal{VS}^{pv}$ \[MW DC\]| +|$\overline{\Omega}^{wind}_{y,z}$ | Maximum wind capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a wind component, $y \in \mathcal{VS}^{wind}$ \[MW AC\]| +|$\underline{\Omega}^{wind}_{y,z}$ | Minimum wind capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a wind component, $y \in \mathcal{VS}^{wind}$ \[MW AC\]| +|$\overline{\Omega}^{inv}_{y,z}$ | Maximum inverter capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an inverter component, $y \in \mathcal{VS}^{inv}$ \[MW AC\]| +|$\underline{\Omega}^{inv}_{y,z}$ | Minimum inverter capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an inverter component, $y \in \mathcal{VS}^{inv}$ \[MW AC\]| +|$\overline{\Omega}^{dc,dis}_{y,z}$ | Maximum storage DC discharge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage DC discharge component, $y \in \mathcal{VS}^{asym,dc,dis}$ \[MW DC\]| +|$\underline{\Omega}^{dc,dis}_{y,z}$ | Minimum storage DC discharge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage DC discharge component, $y \in \mathcal{VS}^{asym,dc,dis}$ \[MW DC\]| +|$\overline{\Omega}^{dc,cha}_{y,z}$ | Maximum storage DC charge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage DC charge component, $y \in \mathcal{VS}^{asym,dc,cha}$ \[MW DC\]| +|$\underline{\Omega}^{dc,cha}_{y,z}$ | Minimum storage DC charge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage DC charge component, $y \in \mathcal{VS}^{asym,dc,cha}$ \[MW DC\]| +|$\overline{\Omega}^{ac,dis}_{y,z}$ | Maximum storage AC discharge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage AC discharge component, $y \in \mathcal{VS}^{asym,ac,dis}$ \[MW AC\]| +|$\underline{\Omega}^{ac,dis}_{y,z}$ | Minimum storage AC discharge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage AC discharge component, $y \in \mathcal{VS}^{asym,ac,dis}$ \[MW AC\]| +|$\overline{\Omega}^{ac,cha}_{y,z}$ | Maximum storage AC charge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage AC charge component, $y \in \mathcal{VS}^{asym,ac,cha}$ \[MW AC\]| +|$\underline{\Omega}^{ac,cha}_{y,z}$ | Minimum storage AC charge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage AC charge component, $y \in \mathcal{VS}^{asym,ac,cha}$ \[MW AC\]| +|$\overline{\Delta}_{y,z}$ | Existing installed capacity of technology $y$ in zone $z$ \[MW\] (Note that for co-located VRE and storage resources, this value represents the existing installed capacity of the grid connection in \[MW AC\])| +|$\overline{\Delta^{energy}_{y,z}}$ | Existing installed energy capacity of technology $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O} \cup y \in \mathcal{VS}^{stor}$ \[MWh] (Note that for co-located VRE and storage resources, this value represents the existing installed energy capacity of the storage component in MWh)| +|$\overline{\Delta^{charge}_{y,z}}$ | Existing installed charging capacity of technology $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O}$ \[MW\]| +|$\overline{\Delta^{pv}_{y,z}}$ | Existing installed solar PV capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a solar PV component, $y \in \mathcal{VS}^{pv}$ \[MW DC\]| +|$\overline{\Delta^{wind}_{y,z}}$ | Existing installed wind capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a wind component, $y \in \mathcal{VS}^{wind}$ \[MW AC\]| +|$\overline{\Delta^{inv}_{y,z}}$ | Existing installed inverter capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an inverter component, $y \in \mathcal{VS}^{inv}$ \[MW AC\]| +|$\overline{\Delta^{dc,dis}_{y,z}}$ | Existing installed storage DC discharge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage DC discharge component, $y \in \mathcal{VS}^{asym,dc,dis}$ \[MW DC\]| +|$\overline{\Delta^{dc,cha}_{y,z}}$ | Existing installed storage DC charge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage DC charge component, $y \in \mathcal{VS}^{asym,dc,cha}$ \[MW DC\]| +|$\overline{\Delta^{ac,dis}_{y,z}}$ | Existing installed storage AC discharge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage AC discharge component, $y \in \mathcal{VS}^{asym,ac,dis}$ \[MW AC\]| +|$\overline{\Delta^{dc,cha}_{y,z}}$ | Existing installed storage AC charge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an asymmetric storage AC charge component, $y \in \mathcal{VS}^{asym,dc,cha}$ \[MW AC\]| +|$\overline{\Omega}_{y,z}^{size}$ | Unit size of technology $y$ in zone $z$ \[MW\]| +|$\pi_{y,z}^{INVEST}$ | Investment cost (annual amortization of total construction cost) for power capacity of technology $y$ in zone $z$ \[\$/MW-yr\] (Note that for co-located VRE and storage resources, this value represents the investment cost of the grid connection capacity in \$/MW AC-yr)| +|$\pi_{y,z}^{INVEST,energy}$ | Investment cost (annual amortization of total construction cost) for energy capacity of technology $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O} \cup y \in \mathcal{VS}^{pv}$ \[\$/MWh-yr\] (Note that for co-located VRE and storage resources, this value represents the investment cost of the energy capacity of the storage component in \$/MWh-yr)| +|$\pi_{y,z}^{INVEST,charge}$ | Investment cost (annual amortization of total construction cost) for charging power capacity of technology $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O}$ \[\$/MW-yr\]| +|$\pi_{y,z}^{INVEST,pv}$ | Investment cost (annual amortization of total construction cost) for solar PV capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a solar PV component, $y \in \mathcal{VS}^{pv}$ \[\$/MW DC-yr\]| +|$\pi_{y,z}^{INVEST,wind}$ | Investment cost (annual amortization of total construction cost) for wind capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a wind component, $y \in \mathcal{VS}^{wind}$ \[\$/MW AC-yr\]| +|$\pi_{y,z}^{INVEST,inv}$ | Investment cost (annual amortization of total construction cost) for inverter capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an inverter component, $y \in \mathcal{VS}^{inv}$ \[\$/MW AC-yr\]| |$\pi_{y,z}^{INVEST,dc,dis}$ | Investment cost (annual amortization of total construction cost) for storage DC discharge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a storage DC discharge component, $y \in \mathcal{VS}^{asym,dc,dis}$ [\$/MW DC-yr]| |$\pi_{y,z}^{INVEST,dc,cha}$ | Investment cost (annual amortization of total construction cost) for storage DC charge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a storage DC charge component, $y \in \mathcal{VS}^{asym,dc,cha}$ [\$/MW DC-yr]| |$\pi_{y,z}^{INVEST,ac,dis}$ | Investment cost (annual amortization of total construction cost) for storage AC discharge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a storage AC discharge component, $y \in \mathcal{VS}^{asym,ac,dis}$ [\$/MW AC-yr]| |$\pi_{y,z}^{INVEST,ac,cha}$ | Investment cost (annual amortization of total construction cost) for storage AC charge capacity of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a storage AC charge component, $y \in \mathcal{VS}^{asym,ac,cha}$ [\$/MW AC-yr]| -|$\pi_{y,z}^{FOM}$ | Fixed O&M cost of technology $y$ in zone $z$ [\$/MW-yr] (Note that for co-located VRE and storage resources, this value represents the fixed O&M cost of the grid connection capacity in \$/MW AC-yr) | -|$\pi_{y,z}^{FOM,energy}$ | Fixed O&M cost of energy component of technology $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O} \cup y \in \mathcal{VS}^{stor}$ [\$/MWh-yr] (Note that for co-located VRE and storage resources, this value represents the fixed O&M cost of the storage energy capacity in \$/MWh-yr)| -|$\pi_{y,z}^{FOM,charge}$ | Fixed O&M cost of charging power component of technology $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O}$ [\$/MW-yr]| +|$\pi_{y,z}^{FOM}$ | Fixed O&M cost of technology $y$ in zone $z$ \[\$/MW-yr\] (Note that for co-located VRE and storage resources, this value represents the fixed O&M cost of the grid connection capacity in \$/MW AC-yr) | +|$\pi_{y,z}^{FOM,energy}$ | Fixed O&M cost of energy component of technology $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O} \cup y \in \mathcal{VS}^{stor}$ \[\$/MWh-yr\] (Note that for co-located VRE and storage resources, this value represents the fixed O&M cost of the storage energy capacity in \$/MWh-yr)| +|$\pi_{y,z}^{FOM,charge}$ | Fixed O&M cost of charging power component of technology $y$ in zone $z$ - only applicable for storage resources, $y \in \mathcal{O}$ \[\$/MW-yr\]| |$\pi_{y,z}^{FOM,pv}$ | Fixed O&M cost of the solar PV component of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a solar PV component, $y \in \mathcal{VS}^{pv}$ [\$/MW DC-yr]| |$\pi_{y,z}^{FOM,wind}$ | Fixed O&M cost of the wind component of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with a wind component, $y \in \mathcal{VS}^{wind}$ [\$/MW AC-yr]| |$\pi_{y,z}^{FOM,inv}$ | Fixed O&M cost of the inverter component of technology $y$ in zone $z$ - only applicable for co-located VRE and storage resources with an inverter component, $y \in \mathcal{VS}^{inv}$ [\$/MW AC-yr]| @@ -219,15 +219,15 @@ $\mathcal{W} \subseteq \mathcal{G}$ | where $\mathcal{W}$ set of hydroelectric g |$\pi_{y,z}^{START}$ | Startup cost of technology $y$ in zone $z$ [\$/startup]| |$\upsilon^{reg}_{y,z}$ | Maximum fraction of capacity that a resource $y$ in zone $z$ can contribute to frequency regulation reserve requirements| |$\upsilon^{rsv}_{y,z}$ | Maximum fraction of capacity that a resource $y$ in zone $z$ can contribute to upward operating (spinning) reserve requirements| -|$\pi^{Unmet}_{rsv}$ | Cost of unmet spinning reserves in [\$/MW]| +|$\pi^{Unmet}_{rsv}$ | Cost of unmet spinning reserves in [\$/MW\]| |$\epsilon^{demand}_{reg}$ | Frequency regulation reserve requirement as a fraction of forecasted demand in each time step | |$\epsilon^{vre}_{reg}$ | Frequency regulation reserve requirement as a fraction of variable renewable energy generation in each time step | |$\epsilon^{demand}_{rsv}$ | Operating (spinning) reserve requirement as a fraction of forecasted demand in each time step | |$\epsilon^{vre}_{rsv}$ | Operating (spinning) reserve requirement as a fraction of forecasted variable renewable energy generation in each time step | |$\epsilon_{y,z}^{CO_2}$ | CO$_2$ emissions per unit energy produced by technology $y$ in zone $z$ [metric tons/MWh]| |$\epsilon_{y,z,p}^{MinTech}$ | Equals to 1 if a generator of technology $y$ in zone $z$ is eligible for minimum capacity carveout policy $p \in \mathcal{P}^{MinTech}$, otherwise 0| -|$REQ_p^{MinTech}$ | The minimum capacity requirement of minimum capacity carveout policy $p \in \mathcal{P}^{MinTech}$ [MW]| -|$REQ_p^{MaxTech}$ | The maximum capacity requirement of minimum capacity carveout policy $p \in \mathcal{P}^{MinTech}$ [MW]| +|$REQ_p^{MinTech}$ | The minimum capacity requirement of minimum capacity carveout policy $p \in \mathcal{P}^{MinTech}$ [MW\]| +|$REQ_p^{MaxTech}$ | The maximum capacity requirement of minimum capacity carveout policy $p \in \mathcal{P}^{MinTech}$ [MW\]| |$\epsilon_{y,z,p}^{CRM}$ | Capacity derating factor of technology $y$ in zone $z$ for capacity reserve margin policy $p \in \mathcal{P}^{CRM}$ [fraction]| |$RM_{z,p}^{CRM}$ | Reserve margin of zone $z$ of capacity reserve margin policy $p \in \mathcal{P}^{CRM}$ [fraction]| |$\epsilon_{z,p,mass}^{CO_2}$ | Emission budget of zone $z$ under the emission cap $p \in \mathcal{P}^{CO_2}_{mass}$ [ million of metric tonnes]| @@ -249,7 +249,7 @@ $\mathcal{W} \subseteq \mathcal{G}$ | where $\mathcal{W}$ set of hydroelectric g |$\eta_{y,z}^{inverter}$ | Inverter efficiency representing losses from converting DC to AC power and vice versa for technology $y$ in zone $z$ for co-located VRE and storage resources [%]| |$\eta_{y,z}^{ILR,pv}$ | Inverter loading ratio (the solar PV capacity sizing to the inverter capacity built) of technology $y$ in zone $z$ for co-located VRE and storage resources with a solar PV component [%]| |$\eta_{y,z}^{ILR,wind}$ | Inverter loading ratio (the wind PV capacity sizing to the grid connection capacity built) of technology $y$ in zone $z$ for co-located VRE and storage resources with a wind component [%]| -|$\mu_{y,z}^{stor}$ | Ratio of energy capacity to discharge power capacity for storage technology (and hydro reservoir) $y$ in zone $z$ [MWh/MW]| +|$\mu_{y,z}^{stor}$ | Ratio of energy capacity to discharge power capacity for storage technology (and hydro reservoir) $y$ in zone $z$ [MWh/MW\]| |$\mu_{y,z}^{dc,stor}$ | Ratio of discharge power capacity to energy capacity for the storage DC component of co-located VRE and storage technology $y$ in zone $z$ [MW/MWh]| |$\mu_{y,z}^{ac,stor}$ | Ratio of discharge power capacity to energy capacity for the storage AC component of co-located VRE and storage technology $y$ in zone $z$ [MW/MWh]| |$\mu_{y,z}^{\mathcal{DF}}$ | Maximum percentage of hourly demand that can be shifted by technology $y$ in zone $z$ [%]| @@ -262,7 +262,7 @@ $\mathcal{W} \subseteq \mathcal{G}$ | where $\mathcal{W}$ set of hydroelectric g |$\eta_{y,z}^{dflex}$ | energy losses associated with shifting the flexible demand [%]| |$\mu_{p,z}^{\mathcal{ESR}}$ | share of total demand in each model zone $z \in \mathcal{ESR}^{p}$ that must be served by qualifying renewable energy resources $y \in \mathcal{G}^{ESR}_{p}$| |$f(n)$ | Mapping each modeled period $n \in \mathcal{N}$ to corresponding representative period $w \in \mathcal{W}$| -|$\eta_{y}^{electrolyzer}$ | Efficiency of the electrolyzer $y$ in megawatt-hours (MWh) of electricity per metric tonne of hydrogen produced [MWh/t] (optional parameter)| -|$\$^{hydrogen}_y}$ | Price of hydrogen per metric tonne for electrolyzer $y$ [\$/t] (optional parameter)| -|$\mathcal{Min kt}_y$ | Minimum annual quantity of hydrogen that must be produced by electrolyzer $y$ in kilotonnes [kt] (optional parameter)| +|$\eta_{y}^{electrolyzer}$ | Efficiency of the electrolyzer $y$ in megawatt-hours (MWh) of electricity per metric tonne of hydrogen produced \[MWh/t\] (optional parameter)| +|$\$^{hydrogen}_y$ | Price of hydrogen per metric tonne for electrolyzer $y$ \[\$/t\] (optional parameter)| +|$\mathcal{Min kt}_y$ | Minimum annual quantity of hydrogen that must be produced by electrolyzer $y$ in kilotonnes \[kt\] (optional parameter)| --- diff --git a/docs/src/model_output.md b/docs/src/model_output.md new file mode 100644 index 0000000000..18cf1a18ca --- /dev/null +++ b/docs/src/model_output.md @@ -0,0 +1,155 @@ +# GenX Outputs + +The table below summarizes the units of each output variable reported as part of the various CSV files produced after each model run. The reported units are also provided. If a result file includes time-dependent values, the value will not include the hour weight in it. An annual sum ("AnnualSum") column/row will be provided whenever it is possible (e.g., `emissions.csv`). + +## 1 Default output files + +### 1.1 capacity.csv + +Reports optimal values of investment variables (except StartCap, which is an input) + +###### Table 15: Structure of the capacity.csv file +--- +|**Output** |**Description** |**Units** | +| :------------ | :-----------|:-----------| +| StartCap |Initial power capacity of each resource type in each zone; this is an input |MW | +| RetCap |Retired power capacity of each resource type in each zone |MW | +| NewCap |Installed capacity of each resource type in each zone |MW| +| EndCap| Total power capacity of each resource type in each zone |MW | +| StartEnergyCap |Initial energy capacity of each resource type in each zone; this is an input and applies only to storage tech.| MWh | +| RetEnergyCap |Retired energy capacity of each resource type in each zone; applies only to storage tech. |MWh | +| NewEnergyCap| Installed energy capacity of each resource type in each zone; applies only to storage tech. |MWh | +| EndEnergyCap |Total installed energy capacity of each resource type in each zone; applies only to storage tech. |MWh | +| StartChargeCap| Initial charging power capacity of `STOR = 2` resource type in each zone; this is an input |MW | +| RetChargeCap |Retired charging power capacity of `STOR = 2` resource type in each zone |MW | +| NewChargeCap |Installed charging capacity of each resource type in each zone |MW | +| EndChargeCap |Total charging power capacity of each resource type in each zone |MW| + +### 1.2 costs.csv + +Reports optimal objective function value and contribution of each term by zone. + +###### Table 16: Structure of the costs.csv file +--- +|**Output** |**Description** |**Units** | +| :------------ | :-----------|:-----------| +| cTotal |Total objective function value |$ | +| cFix |Total annualized investment and fixed operating & maintainenance (FOM) costs associated with all resources |$ | +| cVar |Total annual variable cost associated with all resources; includes fuel costs for thermal plants |$| +| cNSE |Total annual cost of non-served energy |$| +| cStart |Total annual cost of start-up of thermal power plants| $| +| cUnmetRsv |Total annual cost of not meeting time-dependent operating reserve (spinning) requirements |$ | +| cNetworkExp |Total cost of network expansion |$| +| cEmissionsRevenue |Total and zonal emissions revenue |$ | +| cEmissionsCost |Total an zonal emissions cost |$ | + +### 1.3 emissions.csv + +Reports CO2 emissions by zone at each hour; an annual sum row will be provided. If any emission cap is present, emission prices each zone faced by each cap will be copied on top of this table with the following strucutre. + +###### Table 17: Structure of emission prices in the emissions.csv file +--- +|**Output** |**Description** |**Units** | +| :------------ | :-----------|:-----------| +|CO_2\_price |Marginal CO2 abatement cost associated with constraint on maximum annual CO2 emissions; will be same across zones if CO2 emissions constraint is applied for the entire region and not zone-wise |\$/ tonne CO2. | + +### 1.4 nse.csv + +Reports non-served energy for every model zone, time step and cost-segment. + +### 1.5 power.csv + +Reports power discharged by each resource (generation, storage, demand response) in each model time step. + +### 1.6 reliability.csv + +Reports dual variable of maximum non-served energy constraint (shadow price of reliability constraint) for each model zone and time step. + +### 1.7 prices.csv + +Reports marginal electricity price for each model zone and time step. Marginal electricity price is equal to the dual variable of the load balance constraint. If GenX is configured as a mixed integer linear program, then this output is only generated if `WriteShadowPrices` flag is activated. If configured as a linear program (i.e. linearized unit commitment or economic dispatch) then output automatically available. + +### 1.8 status.csv + +Reports computational performance of the model and objective function related information. + +###### Table 18: Structure of the status.csv file +--- +|**Output** |**Description** |**Units** | +| :------------ | :-----------|:-----------| +|Status | termination criteria (optimal, timelimit etc.).|| +|solve | Solve time including time for pre-solve |seconds | +|Objval | Optimal objective function value |$| +|Objbound | Best objective lower bound | $ | +|FinalMIPGap |Optimality gap at termination in case of a mixed-integer linear program (MIP gap); when using Gurobi, the lower bound and MIP gap is reported excluding constant terms (E.g. fixed cost of existing generators that cannot be retired) in the objective function and hence may not be directly usable. |Fraction| + +### 1.9 NetRevenue.csv + +This file summarizes the cost, revenue and profit for each generation technology for each region. + +###### Table 19: Stucture of the NetRevenue.csv file +--- +|**Output** |**Description** |**Units** | +| :------------ | :-----------|:-----------| +| Fixed\_OM\_cost\_MW | Fixed Operation and Maintenance cost of the MW capacity. |$| +| Fixed\_OM\_cost\_MWh| Fixed Operation and Maintenance cost of the MWh capacity. Only applicable to energy storage.| $ | +| Var\_OM\_cost\_out| Variable Operation and Maintenance cost of the power generation or discharge. |$ | +| Var\_OM\_cost\_in |Variable Operation and Maintenance cost of the power charge/pumping. Only applicable to energy storage. |$ | +| Fuel\_cost| Fuel cost of the power generation. Only applicable to generation that burns fuel. |$ | +| Charge\_cost |Cost of charging power (due to the payment for electricity) Only applicable to energy storage. |$| +| EmissionsCost| Cost of buying emission credit. |$ | +| StartCost |Cost of generator start-up. |$ | +| Inv\_cost\_MW |Cost of building MW capacity. |$ | +| Inv\_cost\_MWh| Cost of building MWh capacity. |$ | +| EnergyRevenue |Revenue of generating power.| $ | +| SubsidyRevenue| Revenue of Min\_Cap subsidy. |$ | +| ReserveMarginRevenue| Revenue earned from capacity reserve margin constraints. |$| +| ESRRevenue| Revenue selling renewable/clean energy credits. |$ | +| Revenue| Total Revenue.| $ | +| Cost| Total Cost. |$ | +| Profit |Revenue minus Cost. |$ | + +## 2 Settings-specific outputs + +This section includes the output files that GenX will print if corresponding function is specified in the Settings. + +### 2.1 CapacityValue.csv + +This file includes the time-dependent capacity value calculated for each generator. GenX will print this file only if the capacity reserve margin constraints are modeled through the setting file. Each row of the file (excluding the header) corresponds to a generator specified in the inputs. Each column starting from the t1 to the second last one stores the result of capacity obligation provided in each hour divided by the total capacity. Thus the number is unitless. If the capacity margin reserve is not binding for one hour, GenX will return zero. The last column specified the name of the corresponding capacity reserve constraint. Note that, if the user calculates the hour-weight-averaged capacity value for each generator using data of the binding hours, the result is what RTO/ISO call capacity credit. + + + +### 2.2 EnergyRevenue.csv + +This file includes the energy revenue in $ earned by each generator through injecting into the grid. Only annual sum values are available. + +### 2.3 ChargingCost.csv + +This file includes the charging cost in $ of earned by each generator through withdrawing from the grid. Only annual sum values are available. + +### 2.4 ReserveMargin.csv + +This file includes the shadow prices of the capacity reserve margin constraints. GenX will print this file only when capacity reserve margin is modeled and the shadow price can be obtained form the solver, as described earlier. Each row (except the header) corresponds to a capacity reserve margin constraint, and each column corresponds to an time step. As a reminder, GenX models the capacity reserve margin (aka capacity market) at the time-dependent level, and each constraint either stands for an overall market or a locality constraint. + +### 2.5 ReserveMarginRevenue.csv + +This file includes the capacity revenue earned by each generator listed in the input file. GenX will print this file only when capacity reserve margin is modeled and the shadow price can be obtained form the solver. Each row corresponds to a generator, and each column starting from the 6th to the second last is the total revenue from each capacity reserve margin constraint. The revenue is calculated as the capacity contribution of each time steps multiplied by the shadow price, and then the sum is taken over all modeled time steps. The last column is the total revenue received from all capacity reserve margin constraints. As a reminder, GenX models the capacity reserve margin (aka capacity market) at the time-dependent level, and each constraint either stands for an overall market or a locality constraint. + +### 2.6 ESR\_prices.csv + +This file includes the renewable/clean energy credit price of each modeled RPS/CES constraint. GenX will print this file only when RPS/CES is modeled and the shadow price can be obtained form the solver. The unit is $/MWh. + +### 2.7 ESR\_Revenue.csv + +This file includes the renewable/clean credit revenue earned by each generator listed in the input file. GenX will print this file only when RPS/CES is modeled and the shadow price can be obtained form the solver. Each row corresponds to a generator, and each column starting from the 6th to the second last is the total revenue earned from each RPS constraint. The revenue is calculated as the total annual generation (if elgible for the corresponding constraint) multiplied by the RPS/CES price. The last column is the total revenue received from all constraint. The unit is $. + +### 2.8 SubsidyRevenue.csv + +This file includes subsidy revenue earned if a generator specified Min\_Cap is provided in the input file. GenX will print this file only the shadow price can be obtained form the solver. Do not confuse this with the Minimum Capacity Carveout constraint, which is for a subset of generators, and a separate revenue term will be calculated in other files. The unit is $. diff --git a/docs/src/multi_stage_model_overview.md b/docs/src/multi_stage_input.md similarity index 98% rename from docs/src/multi_stage_model_overview.md rename to docs/src/multi_stage_input.md index 68d0133450..1a7c2d9a37 100644 --- a/docs/src/multi_stage_model_overview.md +++ b/docs/src/multi_stage_input.md @@ -1,4 +1,5 @@ -# Multi-stage modeling overview +# Multi-stage setup + This section describes the available features, inputs and model components related to formulating and solving multi-stage investment planning problems. Two different types of multi-stage problems can be setup: * Perfect foresight: A single multi-stage investment planning problem that simultaneously optimizes capacity and operations across all specified investment stages * Myopic: Sequential solution of single-stage investment planning for each investment stage, where capacity additions and retirements from the previous stages are used to determine initial (or existing) capacity at the beginning of the current stage. @@ -11,9 +12,9 @@ The table below summarizes the key differences in the two model setups. | Objective function cost basis | Net present value | Annualized costs | | Price/dual variable information available? | No | Yes | -## Additional inputs needed for multi-stage modeling (need to convert to tables) +### Additional inputs needed for multi-stage modeling -### Input data files +#### Input data files Instead of one set of input files, there is one directory of input files that needs to be provided for each planning period or stage (e.g., “Inputs/Inputs_p1/” for the first period “Inputs/Inputs_p2/” for the second period, etc.). Below we list the additional parameters that must be provided in the corresponding stage-specific input files to instantiate a multi-stage planning problem. @@ -57,7 +58,7 @@ Instead of one set of input files, there is one directory of input files that ne | WACC | The line-specific weighted average cost of capital. | -### Settings Files +#### Settings Files A separate settings.yml file includes a list of parameters to be specified to formulate the multi-stage planning model. | | **multi\_stage\_settings.yml** | diff --git a/docs/src/multi_stage_genx.md b/docs/src/multi_stage_overview.md similarity index 63% rename from docs/src/multi_stage_genx.md rename to docs/src/multi_stage_overview.md index 33c9f6b447..3ac665f6bd 100644 --- a/docs/src/multi_stage_genx.md +++ b/docs/src/multi_stage_overview.md @@ -1,12 +1,12 @@ -## Multi-stage investment planning +# Multi-stage investment planning _Added in 0.3_ GenX can be used to study the long-term evolution of the power system across multiple investment stages, in the following two ways: * The user can formulate and solve a deterministic **multi-stage planning problem with perfect foresight** i.e. demand, cost, and policy assumptions about all stages are known and exploited to determine the least-cost investment trajectory for the entire period. - The solution of this multi-stage problem relies on exploiting the decomposable nature of the multi-stage problem via the implementation of the dual dynamic programming algorithm, described in [Lara et al. 2018 here](https://www.sciencedirect.com/science/article/abs/pii/S0377221718304466). + The solution of this multi-stage problem relies on exploiting the decomposable nature of the multi-stage problem via the implementation of the dual dynamic programming algorithm, described in [Lara et al. 2018 here](https://www.sciencedirect.com/science/article/abs/pii/S0377221718304466). This algorithm splits up a multi-stage investment planning problem into multiple, single-period sub-problems. Each period is solved iteratively as a separate linear program sub-problem (“forward pass”), and information from future periods is shared with past periods (“backwards pass”) so that investment decisions made in subsequent iterations reflect the contributions of present-day investments to future costs. The decomposition algorithm adapts previous nested Benders methods by handling integer and continuous state variables, although at the expense of losing its finite convergence property due to potential duality gap. * The user can formulate a **sequential, myopic multi-stage planning problem**, where the model solves a sequence of single-stage investment planning problems wherein investment decisions in each stage are individually optimized to meet demand given assumptions for the current planning stage and with investment decisions from previous stages treated as inputs for the current stage. We refer to this as "myopic" (or shortsighted) mode since the solution does not account for information about future stages in determining investments for a given stage. This version is generally more computationally efficient than the deterministic multi-stage expansion with perfect foresight mode. -More information on this feature can be found in the section on `Multi-stage` under the `Model function reference` tab. +More information on this feature can be found in the section [Multi-stage setup](@ref). \ No newline at end of file diff --git a/docs/src/policies.md b/docs/src/policies.md index 38f793805f..9735354c1d 100644 --- a/docs/src/policies.md +++ b/docs/src/policies.md @@ -1,26 +1,23 @@ # Emission mitigation policies ## Capacity Reserve Margin -```@autodocs -Modules = [GenX] -Pages = ["cap_reserve_margin.jl"] +```@docs +GenX.cap_reserve_margin! ``` ## CO$_2$ Constraint Policy -```@autodocs -Modules = [GenX] -Pages = ["co2_cap.jl"] +```@docs +GenX.co2_cap! ``` ## Energy Share Requirement -```@autodocs -Modules = [GenX] -Pages = ["energy_share_requirement.jl"] +```@docs +GenX.load_energy_share_requirement! +GenX.energy_share_requirement! ``` ## Minimum Capacity Requirement -```@autodocs -Modules = [GenX] -Pages = ["minimum_capacity_requirement.jl"] +```@docs +GenX.minimum_capacity_requirement! ``` ## Maximum Capacity Requirement diff --git a/docs/src/public_api.md b/docs/src/public_api.md new file mode 100644 index 0000000000..1c44dbae43 --- /dev/null +++ b/docs/src/public_api.md @@ -0,0 +1,7 @@ +# Public Documentation + +Documentation for GenX public interface. + +```@docs +GenX.run_genx_case! +``` \ No newline at end of file diff --git a/docs/src/resources.md b/docs/src/resources.md new file mode 100644 index 0000000000..921c36134e --- /dev/null +++ b/docs/src/resources.md @@ -0,0 +1,9 @@ +# Resources API +_Added in v0.4_ + +```@docs +GenX.check_resource_type_flags +GenX.check_longdurationstorage_applicability +GenX.check_maintenance_applicability +GenX.check_resource +``` \ No newline at end of file diff --git a/docs/src/retrofit.md b/docs/src/retrofit.md new file mode 100644 index 0000000000..011377e0de --- /dev/null +++ b/docs/src/retrofit.md @@ -0,0 +1,5 @@ +## Retrofit + +```@docs +GenX.retrofit +``` \ No newline at end of file diff --git a/docs/src/running_TDR.md b/docs/src/running_TDR.md new file mode 100644 index 0000000000..c52e819cc5 --- /dev/null +++ b/docs/src/running_TDR.md @@ -0,0 +1,69 @@ +# Running the TDR + +## Running a case with Time Domain Reduction + +There are two ways to run a case with a reduced (e.g. less than full-year) temporal resolution. +1. Let GenX perform the time domain reduction before optimizing. +2. Bring your own clustered data + +It's also possible for GenX perform clustering separately from the optimization task. + +## Method 1: Let GenX perform the time domain reduction (clustering) + +Set `TimeDomainReduction: 1 `in the GenX settings for the case. + +When the case is run (but before the optimization model is built), reduced time series data will be output to a folder within the case, (typically) `TDR_Results`. Note that if the data already exists in that folder, it will not be overwritten. If a user wants to change the time domain reduction settings and try again, the folder should be deleted before the case is run. + +The clustering is done according to the settings in `time_domain_reduction.yml`. These are described in the Inputs section of data_documentation. + +Time domain clustering can only be performed on data which represents a single contiguous period: typically a year of 8760 or 8736 hours. + +The header of the file `Load_data.csv` in the main case folder will typically look like this: + +``` +..., Rep_Periods, Timesteps_per_Rep_Period, Sub_Weights, ... + 1, 8760, 8760, +``` + +For an example that uses this method, see `Example_Systems/RealSystemExample/ISONE_Singlezone`. + +## Method 2: Bring your own clustered data + +The second method is to use an external program to generate the reduced ('clustered') time series data. For instance, PowerGenome has a capability to construct GenX cases with clustered time series data. + +Running using this method **requires** setting `TimeDomainReduction: 0` in the GenX settings for the case. + +Clustered time series data requires specifying the clustering data using three columns in `Load_data.csv`: `Rep_Periods`, `Timesteps_per_Rep_Period`, and `Sub_Weights`. For example, a problem representing a full year via 3 representative weeks, and where the first week represents one which is twice as common as the others, would look like + +``` +..., Rep_Periods, Timesteps_per_Rep_Period, Sub_Weights, ... + 3, 168, 4368.0, + 2184.0, + 2184.0, +``` + +In this example, the first week represents a total of `26*168 = 4368` hours over a full year. + +The time series data are written in single unbroken columns: in this example, the `Time_Index` ranges from 1 to 504. + +For problems involving Long Duration Storage, a file `Period_map.csv` is necessary to describe how these representative periods occur throughout the modeled year. + +See also the [Time-domain reduction](@ref). + +For an example that uses this method, see `Example_Systems/RealSystemExample/ISONE_Trizone`. + +## Performing time domain reduction (TDR) separately from optimization +*Added in 0.3.4* + +It may be useful to perform time domain reduction (TDR) (or "clustering") on a set of inputs before using them as part of full GenX optimization task. For example, a user might want to test various TDR settings and examine the resulting clustered inputs. This can now be performed using the run_timedomainreduction! function. + +``` +$ julia --project=/home/youruser/GenX + +julia> using GenX +julia> run_timedomainreduction!("/path/to/case") +``` + +This function will obey the settings in `path/to/case/Settings/time_domain_reduction_settings.yml`. It will output the resulting clustered time series files in the case. + +Running this function will overwrite these files in the case. This is done with the expectation that the user is trying out various settings. \ No newline at end of file diff --git a/docs/src/running_model.md b/docs/src/running_model.md new file mode 100644 index 0000000000..2192f2117d --- /dev/null +++ b/docs/src/running_model.md @@ -0,0 +1,35 @@ +# Running the model + +When running a new case, it is recommended to create a new folder for the case outside of the `GenX` repository. This folder should contain all the `.csv` input files described in the [GenX Inputs](@ref) section, as well as the `Settings` folder containing at least the `genx_settings.yml` and `[solver_name].yml` files. + +!!! tip "Tip" + Check out the [Running GenX](@ref) for additional information on how to run GenX and what happens when you run a case. + +Once the model and the solver are set up, and once all the `.csv` input files are ready, GenX can be run using the following command: + +``` +$ julia --project=/path/to/GenX + +julia> using GenX +julia> run_genx_case!("/path/to/case") +``` + +where `/path/to/GenX` is the path to the `GenX` repository, and `/path/to/case` is the path to the folder of the case. + +Alternatively, you can create a `Run.jl` file with the following code: + +```julia +using GenX +run_genx_case!(dirname(@__FILE__)) +``` +and and place it in the case folder. Then, you can run the case by opening a terminal and running the following command: + +```bash +$ julia --project="/path/to/GenX" /path/to/case/Run.jl +``` +where `/path/to/GenX` is the path to the `GenX` repository, and `/path/to/case` is the path to the folder of the case. + +The output files will be saved in the `Results` folder inside the case folder. Check out the [GenX Outputs](@ref) section for more information on the output files. + +!!! note "Slack Variables" + To run a case with **slack variables**, check out the [Policy Slack Variables](@ref) section. \ No newline at end of file diff --git a/docs/src/slack_variables_overview.md b/docs/src/slack_variables_overview.md index 5b9830f317..47b44b2cc5 100644 --- a/docs/src/slack_variables_overview.md +++ b/docs/src/slack_variables_overview.md @@ -18,26 +18,30 @@ Slack variables will only be activated when the relevant policy type is itself a For some policy types, slack variables are activated by providing a new input file, while for others they are activated by modifying an existing file. Instructions for each policy type are listed below: -### Capacity Reserve Margin +## Capacity Reserve Margin + Slack variables for Capacity Reserve Margin constraints are created when GenX detects the presence of the file `Capacity_reserve_margin_slack.csv` in the Inputs folder. This file should contain two columns: one titled 'CRM_Constraint' naming the individual Capacity Reserve Margin constraints in the same order in which they are listed in the first row of `Capacity_reserve_margin.csv`, and a second titled 'PriceCap' containing the price thresholds for each constraint. The units for these thresholds are $/MW. -### CO2 Cap +## CO2 Cap Slack variables for CO2 Cap constraints are created when GenX detects the presence of the file `CO2_cap_slack.csv` in the Inputs folder. This file should contain two columns: one titled 'CO2_Cap_Constraint' naming the individual CO2 Cap constraints in the same order in which they are listed in the first row of `CO2_Cap.csv`, and a second titled 'PriceCap' containing the price thresholds for each constraint. The units for these thresholds are $/ton. The CO2 Cap slack variable itself is always in units of tons of CO2, even if the CO2 Cap is a rate-based cap. -### Energy Share Requirement +## Energy Share Requirement + Slack variables for Energy Share Requirement constraints are created when GenX detects the presence of the file `Energy_share_requirement_slack.csv` in the Inputs folder. This file should contain two columns: one titled 'ESR_Constraint' naming the individual Energy Share Requirement constraints in the same order in which they are listed in the first row of `Energy_share_requirement.csv`, and a second titled 'PriceCap' containing the price thresholds for each constraint. The units for these thresholds are \$/MWh. -### Minimum Capacity Requirement +## Minimum Capacity Requirement + Slack variables for Minimum Capacity Requirement constraints are created when GenX detects the presence of a column titled 'PriceCap' in the file `Minimum_capacity_requirement.csv`. This column contains the price thresholds for each Minimum Capacity Requirement constraint, in units of \$/MW. -### Maximum Capacity Requirement +## Maximum Capacity Requirement + Slack variables for Maximum Capacity Requirement constraints are created when GenX detects the presence of a column titled 'PriceCap' in the file `Maximum_capacity_requirement.csv`. This column contains the price thresholds for each Maximum Capacity Requirement constraint, in units of \$/MW. @@ -53,39 +57,4 @@ GenX will also print the total cost associated with each activated slack variabl The folder `Example_Systems/SmallNewEngland/ThreeZones_Slack_Variables_Example` contains examples of the input files needed to activate slack variables for each of the policy types in GenX. Running this example with a given set of policy constraints activated will generate the relevant slack variables and print their outputs. - -## Relevant Files - -### Capacity Reserve Margin -```@autodocs -Modules = [GenX] -Pages = ["cap_reserve_margin.jl"] -``` - - -### CO2 Cap -```@autodocs -Modules = [GenX] -Pages = ["co2_cap.jl"] -``` - - -### Energy Share Requirement -```@autodocs -Modules = [GenX] -Pages = ["energy_share_requirement.jl"] -``` - - -### Minimum Capacity Requirement -```@autodocs -Modules = [GenX] -Pages = ["minimum_capacity_requirement.jl"] -``` - - -### Maximum Capacity Requirement -```@autodocs -Modules = [GenX] -Pages = ["maximum_capacity_requirement.jl"] -``` + \ No newline at end of file diff --git a/docs/src/solver_configuration.md b/docs/src/solver_configuration.md index 559d9c358c..4466b90914 100644 --- a/docs/src/solver_configuration.md +++ b/docs/src/solver_configuration.md @@ -1,42 +1,80 @@ -# Configuring the Solvers -```@autodocs -Modules = [GenX] -Pages = ["configure_solver.jl"] -``` +# Solver Configuration -## Configuring HiGHS -```@autodocs -Modules = [GenX] -Pages = ["configure_highs.jl"] -``` +To define and solve the optimization problems, GenX relies on [JuMP](https://jump.dev/JuMP.jl/stable/), a domain-specific modeling language for mathematical optimization written in Julia, and on a variety of open-source and commercial solvers. GenX supports the following solvers: +- [Cbc](https://github.com/coin-or/Cbc) (open-source) +- [Clp](https://github.com/coin-or/Clp) (open-source) +- [CPLEX](https://www.ibm.com/analytics/cplex-optimizer) (commercial) +- [Gurobi](https://www.gurobi.com/) (commercial) +- [HiGHS](https://highs.dev/) (open-source) +- [SCIP](https://scip.zib.de/) (open-source) -## Configuring Gurobi -```@autodocs -Modules = [GenX] -Pages = ["configure_gurobi.jl"] -``` +Solver related settings parameters are specified in the appropriate .yml file (e.g. `highs_settings.yml`, `gurobi_settings.yml`, etc.), which should be located in the `Settings` folder inside the current working directory (the same `Settings` folder where `genx_settings.yml` is located). Settings are specific to each solver. Check the `Example_Systems` folder for examples of solver settings files and parameters. -## Configuring CPLEX -```@autodocs -Modules = [GenX] -Pages = ["configure_cplex.jl"] -``` +!!! note "Note" + GenX supplies default settings for most solver settings in the various solver-specific functions found in the `src/configure_solver/` directory. + To overwrite default settings, you can specify the below Solver specific settings. -## Configuring Clp -```@autodocs -Modules = [GenX] -Pages = ["configure_clp.jl"] -``` +The following table summarizes the solver settings parameters and their default/possible values. +!!! tip "Tip" + Since each solver has its own set of parameters names, together with a description of the parameter, the table provides a reference to the the corresponding solver specific parameter name. -## Configuring Cbc -```@autodocs -Modules = [GenX] -Pages = ["configure_cbc.jl"] -``` +#### Solver settings parameters** -## Configuring SCIP -```@autodocs -Modules = [GenX] -Pages = ["configure_scip.jl"] -``` \ No newline at end of file +|**Settings Parameter** | **Description**| +|:----------------------|:---------------| +|Method | Algorithm used to solve continuous models or the root node of a MIP model. Generally, barrier method provides the fastest run times for real-world problem set.| +|| **CPLEX**: CPX\_PARAM\_LPMETHOD - Default = 0; See [link](https://www.ibm.com/docs/en/icos/22.1.1?topic=parameters-algorithm-continuous-linear-problems) for more specifications.| +|| **Gurobi**: Method - Default = -1; See [link](https://www.gurobi.com/documentation/8.1/refman/method.html) for more specifications.| +|| **clp**: SolveType - Default = 5; See [link](https://www.coin-or.org/Doxygen/Clp/classClpSolve.html) for more specifications.| +|| **HiGHS**: Method - Default = "choose"; See [link](https://ergo-code.github.io/HiGHS/dev/options/definitions/) for more specifications.| +|BarConvTol | Convergence tolerance for barrier algorithm.| +|| **CPLEX**: CPX\_PARAM\_BAREPCOMP - Default = 1e-8; See [link](https://www.ibm.com/docs/en/icos/22.1.1?topic=parameters-convergence-tolerance-lp-qp-problems) for more specifications.| +|| **Gurobi**: BarConvTol - Default = 1e-8; See [link](https://www.gurobi.com/documentation/8.1/refman/barconvtol.html) for more specifications.| +|Feasib\_Tol | All constraints must be satisfied as per this tolerance. Note that this tolerance is absolute.| +|| **CPLEX**: CPX\_PARAM\_EPRHS - Default = 1e-6; See [link](https://www.ibm.com/docs/en/icos/22.1.1?topic=parameters-feasibility-tolerance) for more specifications.| +|| **Gurobi**: FeasibilityTol - Default = 1e-6; See [link](https://www.gurobi.com/documentation/9.1/refman/feasibilitytol.html) for more specifications.| +|| **clp**: PrimalTolerance - Default = 1e-7; See [link](https://www.coin-or.org/Clp/userguide/clpuserguide.html) for more specifications.| +|| **clp**: DualTolerance - Default = 1e-7; See [link](https://www.coin-or.org/Clp/userguide/clpuserguide.html) for more specifications.| +|Optimal\_Tol | Reduced costs must all be smaller than Optimal\_Tol in the improving direction in order for a model to be declared optimal.| +|| **CPLEX**: CPX\_PARAM\_EPOPT - Default = 1e-6; See [link](https://www.ibm.com/docs/en/icos/22.1.1?topic=parameters-optimality-tolerance) for more specifications.| +|| **Gurobi**: OptimalityTol - Default = 1e-6; See [link](https://www.gurobi.com/documentation/8.1/refman/optimalitytol.html) for more specifications.| +|Pre\_Solve | Controls the presolve level.| +|| **Gurobi**: Presolve - Default = -1; See [link](https://www.gurobi.com/documentation/8.1/refman/presolve.html) for more specifications.| +|| **clp**: PresolveType - Default = 5; See [link](https://www.coin-or.org/Doxygen/Clp/classClpSolve.html) for more specifications.| +|Crossover | Determines the crossover strategy used to transform the interior solution produced by barrier algorithm into a basic solution.| +|| **CPLEX**: CPX\_PARAM\_SOLUTIONTYPE - Default = 2; See [link](https://www.ibm.com/docs/en/icos/22.1.1?topic=parameters-optimality-tolerance) for more specifications.| +|| **Gurobi**: Crossover - Default = 0; See [link](https://www.gurobi.com/documentation/9.1/refman/crossover.html#:~:text=Use%20value%200%20to%20disable,interior%20solution%20computed%20by%20barrier.) for more specifications.| +|NumericFocus | Controls the degree to which the code attempts to detect and manage numerical issues.| +|| **CPLEX**: CPX\_PARAM\_NUMERICALEMPHASIS - Default = 0; See [link](https://www.ibm.com/docs/en/icos/22.1.1?topic=parameters-numerical-precision-emphasis) for more specifications.| +|| **Gurobi**: NumericFocus - Default = 0; See [link](https://www.gurobi.com/documentation/9.1/refman/numericfocus.html) for more specifications.| +|TimeLimit | Time limit to terminate the solution algorithm, model could also terminate if it reaches MIPGap before this time.| +|| **CPLEX**: CPX\_PARAM\_TILIM- Default = 1e+75; See [link](https://www.ibm.com/docs/en/icos/22.1.1?topic=parameters-optimizer-time-limit-in-seconds) for more specifications.| +|| **Gurobi**: TimeLimit - Default = infinity; See [link](https://www.gurobi.com/documentation/9.1/refman/timelimit.html) for more specifications.| +|| **clp**: MaximumSeconds - Default = -1; See [link](https://www.coin-or.org/Doxygen/Clp/classClpModel.html) for more specifications.| +|MIPGap | Optimality gap in case of mixed-integer program.| +|| **CPLEX**: CPX\_PARAM\_EPGAP- Default = 1e-4; See [link](https://www.ibm.com/docs/en/icos/22.1.1?topic=parameters-relative-mip-gap-tolerance) for more specifications.| +|| **Gurobi**: MIPGap - Default = 1e-4; See [link](https://www.gurobi.com/documentation/9.1/refman/mipgap2.html) for more specifications.| +|DualObjectiveLimit | When using dual simplex (where the objective is monotonically changing), terminate when the objective exceeds this limit.| +|| **clp**: DualObjectiveLimit - Default = 1e308; See [link](https://www.coin-or.org/Doxygen/Clp/classClpModel.html) for more specifications.| +|MaximumIterations | Terminate after performing this number of simplex iterations.| +|| **clp**: MaximumIterations - Default = 2147483647; See [link](https://www.coin-or.org/Doxygen/Clp/classClpModel.html) for more specifications.| +|LogLevel | Set to 1, 2, 3, or 4 for increasing output. Set to 0 to disable output.| +|| **clp**: logLevel - Default = 1; See [link](https://www.coin-or.org/Doxygen/Clp/classClpModel.html) for more specifications.| +|| **cbc**: logLevel - Default = 1; See [link](https://www.coin-or.org/Doxygen/Cbc/classCbcModel.html#a244a08213674ce52ddcf33ab4ff53380a185d42e67d2c4cb7b79914c0ed322b5f) for more specifications.| +|InfeasibleReturn | Set to 1 to return as soon as the problem is found to be infeasible (by default, an infeasibility proof is computed as well).| +|| **clp**: InfeasibleReturn - Default = 0; See [link](https://www.coin-or.org/Doxygen/Clp/classClpModel.html) for more specifications.| +|Scaling | Sets or unsets scaling; 0 -off, 1 equilibrium, 2 geometric, 3 auto, 4 dynamic(later).| +|| **clp**: Scaling - Default = 3; See [link](https://www.coin-or.org/Doxygen/Clp/classClpModel.html) for more specifications.| +|Perturbation | Perturbs problem; Switch on perturbation (50), automatic (100), don't try perturbing (102).| +|| **clp**: Perturbation - Default = 3; See [link](https://www.coin-or.org/Doxygen/Clp/classClpModel.html) for more specifications.| +|maxSolutions | Terminate after this many feasible solutions have been found.| +|| **cbc**: maxSolutions - Default = -1; See [link](https://www.coin-or.org/Doxygen/Cbc/classCbcModel.html#a244a08213674ce52ddcf33ab4ff53380a185d42e67d2c4cb7b79914c0ed322b5f) for more specifications.| +|maxNodes | Terminate after this many branch-and-bound nodes have been evaluated| +|| **cbc**: maxNodes - Default = -1; See [link](https://www.coin-or.org/Doxygen/Cbc/classCbcModel.html#a244a08213674ce52ddcf33ab4ff53380a185d42e67d2c4cb7b79914c0ed322b5f) for more specifications.| +| allowableGap | Terminate after optimality gap is less than this value (on an absolute scale)| +|| **cbc**: allowableGap - Default = -1; See [link](https://www.coin-or.org/Doxygen/Cbc/classCbcModel.html#a244a08213674ce52ddcf33ab4ff53380a185d42e67d2c4cb7b79914c0ed322b5f) for more specifications.| +|ratioGap | Terminate after optimality gap is smaller than this relative fraction.| +|| **cbc**: ratioGap - Default = Inf; See [link](https://www.coin-or.org/Doxygen/Cbc/classCbcModel.html#a244a08213674ce52ddcf33ab4ff53380a185d42e67d2c4cb7b79914c0ed322b5f) for more specifications.| +|threads | Set the number of threads to use for parallel branch & bound.| +|| **cbc**: threads - Default = 1; See [link](https://www.coin-or.org/Doxygen/Cbc/classCbcModel.html#a244a08213674ce52ddcf33ab4ff53380a185d42e67d2c4cb7b79914c0ed322b5f) for more specifications.| diff --git a/docs/src/solver_configuration_api.md b/docs/src/solver_configuration_api.md new file mode 100644 index 0000000000..559d9c358c --- /dev/null +++ b/docs/src/solver_configuration_api.md @@ -0,0 +1,42 @@ +# Configuring the Solvers +```@autodocs +Modules = [GenX] +Pages = ["configure_solver.jl"] +``` + +## Configuring HiGHS +```@autodocs +Modules = [GenX] +Pages = ["configure_highs.jl"] +``` + + +## Configuring Gurobi +```@autodocs +Modules = [GenX] +Pages = ["configure_gurobi.jl"] +``` + +## Configuring CPLEX +```@autodocs +Modules = [GenX] +Pages = ["configure_cplex.jl"] +``` + +## Configuring Clp +```@autodocs +Modules = [GenX] +Pages = ["configure_clp.jl"] +``` + +## Configuring Cbc +```@autodocs +Modules = [GenX] +Pages = ["configure_cbc.jl"] +``` + +## Configuring SCIP +```@autodocs +Modules = [GenX] +Pages = ["configure_scip.jl"] +``` \ No newline at end of file diff --git a/docs/src/storage.md b/docs/src/storage.md index 63cc7277d5..c6057a2289 100644 --- a/docs/src/storage.md +++ b/docs/src/storage.md @@ -1,5 +1,4 @@ # Storage -```@autodocs -Modules = [GenX] -Pages = ["storage.jl"] +```@docs +GenX.storage! ``` diff --git a/docs/src/unit_testing.md b/docs/src/unit_testing.md deleted file mode 100644 index cab62de281..0000000000 --- a/docs/src/unit_testing.md +++ /dev/null @@ -1,5 +0,0 @@ -# Unit Testing Modules (Currently under Active Development) -```@autodocs -Modules = [GenX] -Pages = ["simple_operation.jl"] -``` \ No newline at end of file diff --git a/docs/src/utility_functions.md b/docs/src/utility_functions.md new file mode 100644 index 0000000000..21fe42da40 --- /dev/null +++ b/docs/src/utility_functions.md @@ -0,0 +1,6 @@ +# Utility Functions + +```@autodocs +Modules = [GenX] +Pages = ["utility.jl"] +``` \ No newline at end of file diff --git a/docs/src/workflow.md b/docs/src/workflow.md new file mode 100644 index 0000000000..cbcd51232a --- /dev/null +++ b/docs/src/workflow.md @@ -0,0 +1,36 @@ +# User Guide + +## Introduction +GenX is a constrained **linear** or **mixed integer linear optimization model** that determines the portfolio of electricity generation, storage, transmission, and demand-side resource investments and operational decisions to meet electricity demand in one or more future planning years at lowest cost, while subject to a variety of power system operational constraints, resource availability limits, and other imposed environmental, market design, and policy constraints. + +Depending on the planning problem or question to be studied, GenX can be configured with varying levels of model resolution and scope, with regards to: +1. Temporal resolution of time series data such as **electricity demand** and **renewable energy availability**; +2. Power system **operational detail** and unit **commitment constraints**; +3. **Geospatial resolution** and **transmission network** representation. + +The model is also capable of representing a full range of conventional and novel electricity resources, including thermal generators, variable renewable resources (wind and solar), run-of-river, reservoir and pumped-storage hydroelectric generators, energy storage devices, demand-side flexibility, demand response, and several advanced technologies such as long-duration energy storage. + +## Workflow +The flexibility of GenX is achieved through a modular and transparent code structure developed in [Julia](http://julialang.org/) + [JuMP](http://jump.dev/). The software workflow includes two main steps: + +1. **Model configuration** and **building**: this step involves the specification of the planning problem to be studied, including time dependent data like electricity demand, renewable energy availability and fuel prices, number and type of resources included in the model, graph representation of the transmission network, and the set of constraints and objectives to be imposed. + +2. **Model execution**: once the model is configured, a solver is called to find the optimal solution to the planning problem. The solution is then post-processed to generate a set of output files that can be used for further analysis. + +The next sections in this guide provide more details on how to perform all the steps in the workflow: +1. [Model settings parameters](@ref): `genx_settings.yml` +2. [Solver Configuration](@ref): `[solver_name]_settings.yml` +3. [GenX Inputs](@ref) +4. [Time-domain reduction](@ref): `time_domain_reduction.yml` (optional) +5. [Multi-stage setup](@ref): `multi_stage_settings.yml` (optional) +6. [Running the model](@ref) +7. [GenX Outputs](@ref) + +## Single and Multi-stage investment planning + +In addition to the standard single-stage planning mode, in which the produces a single snapshot of the minimum-cost generation capacity mix to meet demand at least cost under some pre-specified future conditions, recent improvements in the GenX source code (part of v0.3 release) enable its use for studying **long-term evolution** of the power system across multiple investment stages. GenX can be used to study multi-stage power system planning in the following two ways: + +- The user can formulate and solve a deterministic multi-stage planning problem with perfect foresight i.e. demand, cost, and policy assumptions about all stages are known and exploited to determine the least-cost investment trajectory for the entire period. The solution relies on exploiting the decomposable nature of the multi-stage problem via the implementation of the dual dynamic programming algorithm, described in [Lara et al. 2018 here](https://www.sciencedirect.com/science/article/abs/pii/S0377221718304466). + +- The user can formulate a sequential, myopic multi-stage planning problem, where the model solves a sequence of single-stage investment planning problems wherein investment decisions in each stage are individually optimized to meet demand given assumptions for the current planning stage and with investment decisions from previous stages treated as inputs for the current stage. We refer to this as "myopic" (or shortsighted) mode since the solution does not account for information about future stages in determining investments for a given stage. This version is generally more computationally efficient than the deterministic multi-stage expansion with perfect foresight mode. + diff --git a/docs/src/write_outputs.md b/docs/src/write_outputs.md index b87cd18082..c558f54f80 100644 --- a/docs/src/write_outputs.md +++ b/docs/src/write_outputs.md @@ -1,7 +1,7 @@ # Functions for Writing the Different Results/Outputs to Separate Files ```@autodocs Modules = [GenX] -Pages = ["write_outputs.jl"] +Pages = ["write_outputs.jl", "choose_output_dir.jl", "dftranspose.jl"] ``` ## Write Status @@ -10,12 +10,22 @@ Modules = [GenX] Pages = ["write_status.jl"] ``` +## Write CO_2 Cap +```@docs +GenX.write_co2_cap +``` + ## Write Costs ```@autodocs Modules = [GenX] Pages = ["write_costs.jl"] ``` +## Write Fuel Consumption +```@docs +GenX.write_fuel_consumption +``` + ## Write Emissions ```@autodocs Modules = [GenX] @@ -112,13 +122,26 @@ Pages = ["write_net_revenue.jl"] ``` ## Write Co-Located VRE and Storage files -```@autodocs -Modules = [GenX] -Pages = ["write_vre_stor.jl"] +```@docs +GenX.write_vre_stor +GenX.write_vre_stor_capacity +GenX.write_vre_stor_charge +GenX.write_vre_stor_discharge +``` + +## Write Multi-stage files +```@docs +GenX.write_multi_stage_costs +GenX.write_multi_stage_stats +GenX.write_multi_stage_settings +GenX.write_multi_stage_network_expansion +GenX.write_multi_stage_capacities_charge +GenX.write_multi_stage_capacities_energy ``` -## Write Settings files +## Write maintenance files ```@autodocs Modules = [GenX] -Pages = ["write_settings.jl"] +Pages = ["write_maintenance.jl"] ``` + diff --git a/src/GenX.jl b/src/GenX.jl index 9e828c1e7a..133d9ac4fe 100644 --- a/src/GenX.jl +++ b/src/GenX.jl @@ -76,9 +76,6 @@ include_all_in_folder("write_outputs") include("time_domain_reduction/time_domain_reduction.jl") include("time_domain_reduction/precluster.jl") -#Just for unit testing; Under active development -include("simple_operation.jl") - include_all_in_folder("multi_stage") include_all_in_folder("additional_tools") end diff --git a/src/multi_stage/endogenous_retirement.jl b/src/multi_stage/endogenous_retirement.jl index c329b61fa1..b1f47f2741 100644 --- a/src/multi_stage/endogenous_retirement.jl +++ b/src/multi_stage/endogenous_retirement.jl @@ -1,5 +1,5 @@ @doc raw""" - function get_retirement_stage(cur_stage::Int, stage_len::Int, lifetime::Int, stage_lens::Array{Int, 1}) + get_retirement_stage(cur_stage::Int, stage_len::Int, lifetime::Int, stage_lens::Array{Int, 1}) This function determines the model stage before which all newly built capacity must be retired. Used to enforce endogenous lifetime retirements in multi-stage modeling. diff --git a/src/simple_operation.jl b/src/simple_operation.jl index 3afe8a5385..aa6d784cb2 100644 --- a/src/simple_operation.jl +++ b/src/simple_operation.jl @@ -1,9 +1,3 @@ -@doc raw""" - simple_operation(num1::Float64, num2::Float64) - -This is just a simple function for adding two numbers intended to start off the unit testing. This function -isn't used in GenX and will be replaced by the ones that are used as we develop the fully-grown unit testing. -""" function simple_operation(num1::Float64, num2::Float64) num3 = num1 + num2 return num3 diff --git a/src/write_outputs/write_vre_stor.jl b/src/write_outputs/write_vre_stor.jl index 77fa13b073..6d71e0d5d8 100644 --- a/src/write_outputs/write_vre_stor.jl +++ b/src/write_outputs/write_vre_stor.jl @@ -3,7 +3,6 @@ Function for writing the vre-storage specific files. """ - function write_vre_stor(path::AbstractString, inputs::Dict, setup::Dict, EP::Model) ### CAPACITY DECISIONS ### diff --git a/test/runtests.jl b/test/runtests.jl index 59093d9103..fc4eb685d8 100644 --- a/test/runtests.jl +++ b/test/runtests.jl @@ -5,10 +5,6 @@ using Logging include("utilities.jl") -@testset "Simple operation" begin - include("simple_op_test.jl") -end - @testset "Resource validation" begin include("resource_test.jl") end