var documenterSearchIndex = {"docs":
[{"location":"api/#API-Reference","page":"API Reference","title":"API Reference","text":"","category":"section"},{"location":"api/#Read-data,-build-model-and-optimize","page":"API Reference","title":"Read data, build model & optimize","text":"","category":"section"},{"location":"api/","page":"API Reference","title":"API Reference","text":"UnitCommitment.read\nUnitCommitment.read_benchmark\nUnitCommitment.build_model\nUnitCommitment.optimize!\nUnitCommitment.solution\nUnitCommitment.validate\nUnitCommitment.write","category":"page"},{"location":"api/#UnitCommitment.read","page":"API Reference","title":"UnitCommitment.read","text":"read(path::AbstractString)::UnitCommitmentInstance\n\nRead instance from a file. The file may be gzipped.\n\nExample\n\ninstance = UnitCommitment.read(\"/path/to/input.json.gz\")\n\n\n\n\n\n","category":"function"},{"location":"api/#UnitCommitment.read_benchmark","page":"API Reference","title":"UnitCommitment.read_benchmark","text":"read_benchmark(name::AbstractString)::UnitCommitmentInstance\n\nRead one of the benchmark instances included in the package. See Instances for the entire list of benchmark instances available.\n\nExample\n\ninstance = UnitCommitment.read_benchmark(\"matpower/case3375wp/2017-02-01\")\n\n\n\n\n\n","category":"function"},{"location":"api/#UnitCommitment.build_model","page":"API Reference","title":"UnitCommitment.build_model","text":"function build_model(;\n    instance::UnitCommitmentInstance,\n    optimizer = nothing,\n    formulation = Formulation(),\n    variable_names::Bool = false,\n)::JuMP.Model\n\nBuild the JuMP model corresponding to the given unit commitment instance.\n\nArguments\n\ninstance:   the instance.\noptimizer:   the optimizer factory that should be attached to this model (e.g. Cbc.Optimizer).   If not provided, no optimizer will be attached.\nformulation:   the MIP formulation to use. By default, uses a formulation that combines   modeling components from different publications that provides good   performance across a wide variety of instances. An alternative formulation   may also be provided.\nvariable_names:    if true, set variable and constraint names. Important if the model is going   to be exported to an MPS file. For large models, this can take significant   time, so it's disabled by default.\n\nExamples\n\n# Read benchmark instance\ninstance = UnitCommitment.read_benchmark(\"matpower/case118/2017-02-01\")\n\n# Construct model (using state-of-the-art defaults)\nmodel = UnitCommitment.build_model(\n    instance = instance,\n    optimizer = Cbc.Optimizer,\n)\n\n# Construct model (using customized formulation)\nmodel = UnitCommitment.build_model(\n    instance = instance,\n    optimizer = Cbc.Optimizer,\n    formulation = Formulation(\n        pwl_costs = KnuOstWat2018.PwlCosts(),\n        ramping = MorLatRam2013.Ramping(),\n        startup_costs = MorLatRam2013.StartupCosts(),\n        transmission = ShiftFactorsFormulation(\n            isf_cutoff = 0.005,\n            lodf_cutoff = 0.001,\n        ),\n    ),\n)\n\n\n\n\n\n","category":"function"},{"location":"api/#UnitCommitment.optimize!","page":"API Reference","title":"UnitCommitment.optimize!","text":"optimize!(model::JuMP.Model)::Nothing\n\nSolve the given unit commitment model. Unlike JuMP.optimize!, this uses more advanced methods to accelerate the solution process and to enforce transmission and N-1 security constraints.\n\n\n\n\n\n","category":"function"},{"location":"api/#UnitCommitment.solution","page":"API Reference","title":"UnitCommitment.solution","text":"solution(model::JuMP.Model)::OrderedDict\n\nExtracts the optimal solution from the UC.jl model. The model must be solved beforehand.\n\nExample\n\nUnitCommitment.optimize!(model)\nsolution = UnitCommitment.solution(model)\n\n\n\n\n\n","category":"function"},{"location":"api/#UnitCommitment.validate","page":"API Reference","title":"UnitCommitment.validate","text":"validate(instance, solution)::Bool\n\nVerifies that the given solution is feasible for the problem. If feasible, silently returns true. In infeasible, returns false and prints the validation errors to the screen.\n\nThis function is implemented independently from the optimization model in model.jl, and therefore can be used to verify that the model is indeed producing valid solutions. It can also be used to verify the solutions produced by other optimization packages.\n\n\n\n\n\n","category":"function"},{"location":"api/#UnitCommitment.write","page":"API Reference","title":"UnitCommitment.write","text":"write(filename::AbstractString, solution::AbstractDict)::Nothing\n\nWrite the given solution to a JSON file.\n\nExample\n\nsolution = UnitCommitment.solution(model)\nUnitCommitment.write(\"/tmp/output.json\", solution)\n\n\n\n\n\n","category":"function"},{"location":"api/#Modify-instance","page":"API Reference","title":"Modify instance","text":"","category":"section"},{"location":"api/","page":"API Reference","title":"API Reference","text":"UnitCommitment.slice\nUnitCommitment.randomize!(::UnitCommitment.UnitCommitmentInstance)\nUnitCommitment.generate_initial_conditions!","category":"page"},{"location":"api/#UnitCommitment.slice","page":"API Reference","title":"UnitCommitment.slice","text":"slice(instance, range)\n\nCreates a new instance, with only a subset of the time periods. This function does not modify the provided instance. The initial conditions are also not modified.\n\nExample\n\n# Build a 2-hour UC instance\ninstance = UnitCommitment.read_benchmark(\"matpower/case118/2017-02-01\")\nmodified = UnitCommitment.slice(instance, 1:2)\n\n\n\n\n\n","category":"function"},{"location":"api/#UnitCommitment.randomize!-Tuple{UnitCommitmentInstance}","page":"API Reference","title":"UnitCommitment.randomize!","text":"function randomize!(\n    instance::UnitCommitmentInstance;\n    method = UnitCommitment.XavQiuAhm2021.Randomization();\n    rng = MersenneTwister(),\n)::Nothing\n\nRandomizes instance parameters according to the provided randomization method.\n\nExample\n\ninstance = UnitCommitment.read_benchmark(\"matpower/case118/2017-02-01\")\nUnitCommitment.randomize!(instance)\nmodel = UnitCommitment.build_model(; instance)\n\n\n\n\n\n","category":"method"},{"location":"api/#UnitCommitment.generate_initial_conditions!","page":"API Reference","title":"UnitCommitment.generate_initial_conditions!","text":"generate_initial_conditions!(instance, optimizer)\n\nGenerates feasible initial conditions for the given instance, by constructing and solving a single-period mixed-integer optimization problem, using the given optimizer. The instance is modified in-place.\n\n\n\n\n\n","category":"function"},{"location":"api/#Formulations","page":"API Reference","title":"Formulations","text":"","category":"section"},{"location":"api/","page":"API Reference","title":"API Reference","text":"UnitCommitment.Formulation\nUnitCommitment.ShiftFactorsFormulation\nUnitCommitment.ArrCon2000\nUnitCommitment.CarArr2006\nUnitCommitment.DamKucRajAta2016\nUnitCommitment.Gar1962\nUnitCommitment.KnuOstWat2018\nUnitCommitment.MorLatRam2013\nUnitCommitment.PanGua2016\nUnitCommitment.WanHob2016","category":"page"},{"location":"api/#UnitCommitment.Formulation","page":"API Reference","title":"UnitCommitment.Formulation","text":"struct Formulation\n    prod_vars::ProductionVarsFormulation\n    pwl_costs::PiecewiseLinearCostsFormulation\n    ramping::RampingFormulation\n    startup_costs::StartupCostsFormulation\n    status_vars::StatusVarsFormulation\n    transmission::TransmissionFormulation\nend\n\nStruct provided to build_model that holds various formulation components.\n\nFields\n\nprod_vars: Formulation for the production decision variables\npwl_costs: Formulation for the piecewise linear costs\nramping: Formulation for ramping constraints\nstartup_costs: Formulation for time-dependent start-up costs\nstatus_vars: Formulation for the status variables (e.g. is_on, is_off)\ntransmission: Formulation for transmission and N-1 security constraints\n\n\n\n\n\n","category":"type"},{"location":"api/#UnitCommitment.ShiftFactorsFormulation","page":"API Reference","title":"UnitCommitment.ShiftFactorsFormulation","text":"struct ShiftFactorsFormulation <: TransmissionFormulation\n    isf_cutoff::Float64 = 0.005\n    lodf_cutoff::Float64 = 0.001\n    precomputed_isf=nothing\n    precomputed_lodf=nothing\nend\n\nTransmission formulation based on Injection Shift Factors (ISF) and Line Outage Distribution Factors (LODF). Constraints are enforced in a lazy way.\n\nArguments\n\nprecomputed_isf:   the injection shift factors matrix. If not provided, it will be computed.\nprecomputed_lodf:    the line outage distribution factors matrix. If not provided, it will be   computed.\nisf_cutoff:    the cutoff that should be applied to the ISF matrix. Entries with magnitude   smaller than this value will be set to zero.\nlodf_cutoff:    the cutoff that should be applied to the LODF matrix. Entries with magnitude   smaller than this value will be set to zero.\n\n\n\n\n\n","category":"type"},{"location":"api/#UnitCommitment.ArrCon2000","page":"API Reference","title":"UnitCommitment.ArrCon2000","text":"Formulation described in:\n\nArroyo, J. M., & Conejo, A. J. (2000). Optimal response of a thermal unit\nto an electricity spot market. IEEE Transactions on power systems, 15(3), \n1098-1104. DOI: https://doi.org/10.1109/59.871739\n\n\n\n\n\n","category":"module"},{"location":"api/#UnitCommitment.CarArr2006","page":"API Reference","title":"UnitCommitment.CarArr2006","text":"Formulation described in:\n\nCarrión, M., & Arroyo, J. M. (2006). A computationally efficient\nmixed-integer linear formulation for the thermal unit commitment problem.\nIEEE Transactions on power systems, 21(3), 1371-1378.\nDOI: https://doi.org/10.1109/TPWRS.2006.876672\n\n\n\n\n\n","category":"module"},{"location":"api/#UnitCommitment.DamKucRajAta2016","page":"API Reference","title":"UnitCommitment.DamKucRajAta2016","text":"Formulation described in:\n\nDamcı-Kurt, P., Küçükyavuz, S., Rajan, D., & Atamtürk, A. (2016). A polyhedral\nstudy of production ramping. Mathematical Programming, 158(1), 175-205.\nDOI: https://doi.org/10.1007/s10107-015-0919-9\n\n\n\n\n\n","category":"module"},{"location":"api/#UnitCommitment.Gar1962","page":"API Reference","title":"UnitCommitment.Gar1962","text":"Formulation described in:\n\nGarver, L. L. (1962). Power generation scheduling by integer\nprogramming-development of theory. Transactions of the American Institute\nof Electrical Engineers. Part III: Power Apparatus and Systems, 81(3), 730-734.\nDOI: https://doi.org/10.1109/AIEEPAS.1962.4501405\n\n\n\n\n\n","category":"module"},{"location":"api/#UnitCommitment.KnuOstWat2018","page":"API Reference","title":"UnitCommitment.KnuOstWat2018","text":"Formulation described in:\n\nKnueven, B., Ostrowski, J., & Watson, J. P. (2018). Exploiting identical\ngenerators in unit commitment. IEEE Transactions on Power Systems, 33(4),\n4496-4507. DOI: https://doi.org/10.1109/TPWRS.2017.2783850\n\n\n\n\n\n","category":"module"},{"location":"api/#UnitCommitment.MorLatRam2013","page":"API Reference","title":"UnitCommitment.MorLatRam2013","text":"Formulation described in:\n\nMorales-España, G., Latorre, J. M., & Ramos, A. (2013). Tight and compact\nMILP formulation for the thermal unit commitment problem. IEEE Transactions\non Power Systems, 28(4), 4897-4908. DOI: https://doi.org/10.1109/TPWRS.2013.2251373\n\n\n\n\n\n","category":"module"},{"location":"api/#UnitCommitment.PanGua2016","page":"API Reference","title":"UnitCommitment.PanGua2016","text":"Formulation described in:\n\nPan, K., & Guan, Y. (2016). Strong formulations for multistage stochastic\nself-scheduling unit commitment. Operations Research, 64(6), 1482-1498.\nDOI: https://doi.org/10.1287/opre.2016.1520\n\n\n\n\n\n","category":"module"},{"location":"api/#UnitCommitment.WanHob2016","page":"API Reference","title":"UnitCommitment.WanHob2016","text":"Formulation described in:\n\nB. Wang and B. F. Hobbs, \"Real-Time Markets for Flexiramp: A Stochastic \nUnit Commitment-Based Analysis,\" in IEEE Transactions on Power Systems, \nvol. 31, no. 2, pp. 846-860, March 2016, doi: 10.1109/TPWRS.2015.2411268.\n\n\n\n\n\n","category":"module"},{"location":"api/#Solution-Methods","page":"API Reference","title":"Solution Methods","text":"","category":"section"},{"location":"api/","page":"API Reference","title":"API Reference","text":"UnitCommitment.XavQiuWanThi2019.Method","category":"page"},{"location":"api/#UnitCommitment.XavQiuWanThi2019.Method","page":"API Reference","title":"UnitCommitment.XavQiuWanThi2019.Method","text":"mutable struct Method\n    time_limit::Float64\n    gap_limit::Float64\n    two_phase_gap::Bool\n    max_violations_per_line::Int\n    max_violations_per_period::Int\nend\n\nLazy constraint solution method described in:\n\nXavier, A. S., Qiu, F., Wang, F., & Thimmapuram, P. R. (2019). Transmission\nconstraint filtering in large-scale security-constrained unit commitment. \nIEEE Transactions on Power Systems, 34(3), 2457-2460.\nDOI: https://doi.org/10.1109/TPWRS.2019.2892620\n\nFields\n\ntime_limit:   the time limit over the entire optimization procedure.\ngap_limit:    the desired relative optimality gap. Only used when two_phase_gap=true.\ntwo_phase_gap:    if true, solve the problem with large gap tolerance first, then reduce   the gap tolerance when no further violated constraints are found.\nmax_violations_per_line:   maximum number of violated transmission constraints to add to the   formulation per transmission line.\nmax_violations_per_period:   maximum number of violated transmission constraints to add to the   formulation per time period.\n\n\n\n\n\n","category":"type"},{"location":"api/#Randomization-Methods","page":"API Reference","title":"Randomization Methods","text":"","category":"section"},{"location":"api/","page":"API Reference","title":"API Reference","text":"UnitCommitment.XavQiuAhm2021.Randomization","category":"page"},{"location":"api/#UnitCommitment.XavQiuAhm2021.Randomization","page":"API Reference","title":"UnitCommitment.XavQiuAhm2021.Randomization","text":"struct Randomization\n    cost = Uniform(0.95, 1.05)\n    load_profile_mu = [...]\n    load_profile_sigma = [...]\n    load_share = Uniform(0.90, 1.10)\n    peak_load = Uniform(0.6 * 0.925, 0.6 * 1.075)\n    randomize_costs = true\n    randomize_load_profile = true\n    randomize_load_share = true\nend\n\nRandomization method that changes: (1) production and startup costs, (2) share of load coming from each bus, (3) peak system load, and (4) temporal load profile, as follows:\n\nProduction and startup costs:  For each unit u, the vectors u.min_power_cost and u.cost_segments  are multiplied by a constant α[u] sampled from the provided cost  distribution. If randomize_costs is false, skips this step.\nLoad share: For each bus b and time t, the value b.load[t] is multiplied by (β[b] * b.load[t]) / sum(β[b2] * b2.load[t] for b2 in buses), where β[b] is sampled from the provided load_share distribution. If randomize_load_share is false, skips this step.\nPeak system load and temporal load profile:  Sets the peak load to ρ * C, where ρ is sampled from peak_load and C  is the maximum system capacity, at any time. Also scales the loads of all  buses, so that system_load[t+1] becomes equal to system_load[t] * γ[t],  where γ[t] is sampled from Normal(load_profile_mu[t], load_profile_sigma[t]).\nThe system load for the first time period is set so that the peak load  matches ρ * C. If load_profile_sigma and load_profile_mu have fewer  elements than instance.time, wraps around. If randomize_load_profile  is false, skips this step.\n\nThe default parameters were obtained based on an analysis of publicly available bid and hourly data from PJM, corresponding to the month of January, 2017. For more details, see Section 4.2 of the paper.\n\nReferences\n\nXavier, Álinson S., Feng Qiu, and Shabbir Ahmed. \"Learning to solve large-scale security-constrained unit commitment problems.\" INFORMS Journal on Computing 33.2 (2021): 739-756. DOI: 10.1287/ijoc.2020.0976\n\n\n\n\n\n","category":"type"},{"location":"usage/#Usage","page":"Usage","title":"Usage","text":"","category":"section"},{"location":"usage/#Installation","page":"Usage","title":"Installation","text":"","category":"section"},{"location":"usage/","page":"Usage","title":"Usage","text":"UnitCommitment.jl was tested and developed with Julia 1.7. To install Julia, please follow the installation guide on the official Julia website. To install UnitCommitment.jl, run the Julia interpreter, type ] to open the package manager, then type:","category":"page"},{"location":"usage/","page":"Usage","title":"Usage","text":"pkg> add UnitCommitment@0.3","category":"page"},{"location":"usage/","page":"Usage","title":"Usage","text":"To test that the package has been correctly installed, run:","category":"page"},{"location":"usage/","page":"Usage","title":"Usage","text":"pkg> test UnitCommitment","category":"page"},{"location":"usage/","page":"Usage","title":"Usage","text":"If all tests pass, the package should now be ready to be used by any Julia script on the machine.","category":"page"},{"location":"usage/","page":"Usage","title":"Usage","text":"To solve the optimization models, a mixed-integer linear programming (MILP) solver is also required. Please see the JuMP installation guide for more instructions on installing a solver. Typical open-source choices are Cbc and GLPK. In the instructions below, Cbc will be used, but any other MILP solver listed in JuMP installation guide should also be compatible.","category":"page"},{"location":"usage/#Typical-Usage","page":"Usage","title":"Typical Usage","text":"","category":"section"},{"location":"usage/#Solving-user-provided-instances","page":"Usage","title":"Solving user-provided instances","text":"","category":"section"},{"location":"usage/","page":"Usage","title":"Usage","text":"The first step to use UC.jl is to construct a JSON file describing your unit commitment instance. See Data Format for a complete description of the data format UC.jl expects. The next steps, as shown below, are to: (1) read the instance from file; (2) construct the optimization model; (3) run the optimization; and (4) extract the optimal solution.","category":"page"},{"location":"usage/","page":"Usage","title":"Usage","text":"using Cbc\nusing JSON\nusing UnitCommitment\n\n# 1. Read instance\ninstance = UnitCommitment.read(\"/path/to/input.json\")\n\n# 2. Construct optimization model\nmodel = UnitCommitment.build_model(\n    instance=instance,\n    optimizer=Cbc.Optimizer,\n)\n\n# 3. Solve model\nUnitCommitment.optimize!(model)\n\n# 4. Write solution to a file\nsolution = UnitCommitment.solution(model)\nUnitCommitment.write(\"/path/to/output.json\", solution)","category":"page"},{"location":"usage/#Solving-benchmark-instances","page":"Usage","title":"Solving benchmark instances","text":"","category":"section"},{"location":"usage/","page":"Usage","title":"Usage","text":"UnitCommitment.jl contains a large number of benchmark instances collected from the literature and converted into a common data format. To solve one of these instances individually, instead of constructing your own, the function read_benchmark can be used, as shown below. See Instances for the complete list of available instances.","category":"page"},{"location":"usage/","page":"Usage","title":"Usage","text":"using UnitCommitment\ninstance = UnitCommitment.read_benchmark(\"matpower/case3375wp/2017-02-01\")","category":"page"},{"location":"usage/#Advanced-usage","page":"Usage","title":"Advanced usage","text":"","category":"section"},{"location":"usage/#Customizing-the-formulation","page":"Usage","title":"Customizing the formulation","text":"","category":"section"},{"location":"usage/","page":"Usage","title":"Usage","text":"By default, build_model uses a formulation that combines modeling components from different publications, and that has been carefully tested, using our own benchmark scripts, to provide good performance across a wide variety of instances. This default formulation is expected to change over time, as new methods are proposed in the literature. You can, however, construct your own formulation, based on the modeling components that you choose, as shown in the next example.","category":"page"},{"location":"usage/","page":"Usage","title":"Usage","text":"using Cbc\nusing UnitCommitment\n\nimport UnitCommitment:\n    Formulation,\n    KnuOstWat2018,\n    MorLatRam2013,\n    ShiftFactorsFormulation\n\ninstance = UnitCommitment.read_benchmark(\n    \"matpower/case118/2017-02-01\",\n)\n\nmodel = UnitCommitment.build_model(\n    instance = instance,\n    optimizer = Cbc.Optimizer,\n    formulation = Formulation(\n        pwl_costs = KnuOstWat2018.PwlCosts(),\n        ramping = MorLatRam2013.Ramping(),\n        startup_costs = MorLatRam2013.StartupCosts(),\n        transmission = ShiftFactorsFormulation(\n            isf_cutoff = 0.005,\n            lodf_cutoff = 0.001,\n        ),\n    ),\n)","category":"page"},{"location":"usage/#Generating-initial-conditions","page":"Usage","title":"Generating initial conditions","text":"","category":"section"},{"location":"usage/","page":"Usage","title":"Usage","text":"When creating random unit commitment instances for benchmark purposes, it is often hard to compute, in advance, sensible initial conditions for all generators. Setting initial conditions naively (for example, making all generators initially off and producing no power) can easily cause the instance to become infeasible due to excessive ramping. Initial conditions can also make it hard to modify existing instances. For example, increasing the system load without carefully modifying the initial conditions may make the problem infeasible or unrealistically challenging to solve.","category":"page"},{"location":"usage/","page":"Usage","title":"Usage","text":"To help with this issue, UC.jl provides a utility function which can generate feasible initial conditions by solving a single-period optimization problem, as shown below:","category":"page"},{"location":"usage/","page":"Usage","title":"Usage","text":"using Cbc\nusing UnitCommitment\n\n# Read original instance\ninstance = UnitCommitment.read(\"instance.json\")\n\n# Generate initial conditions (in-place)\nUnitCommitment.generate_initial_conditions!(instance, Cbc.Optimizer)\n\n# Construct and solve optimization model\nmodel = UnitCommitment.build_model(\n    instance=instance,\n    optimizer=Cbc.Optimizer,\n)\nUnitCommitment.optimize!(model)","category":"page"},{"location":"usage/","page":"Usage","title":"Usage","text":"warning: Warning\nThe function generate_initial_conditions! may return different initial conditions after each call, even if the same instance and the same optimizer is provided. The particular algorithm may also change in a future version of UC.jl. For these reasons, it is recommended that you generate initial conditions exactly once for each instance and store them for later use.","category":"page"},{"location":"usage/#Verifying-solutions","page":"Usage","title":"Verifying solutions","text":"","category":"section"},{"location":"usage/","page":"Usage","title":"Usage","text":"When developing new formulations, it is very easy to introduce subtle errors in the model that result in incorrect solutions. To help with this, UC.jl includes a utility function that verifies if a given solution is feasible, and, if not, prints all the validation errors it found. The implementation of this function is completely independent from the implementation of the optimization model, and therefore can be used to validate it. The function can also be used to verify solutions produced by other optimization packages, as long as they follow the UC.jl data format.","category":"page"},{"location":"usage/","page":"Usage","title":"Usage","text":"using JSON\nusing UnitCommitment\n\n# Read instance\ninstance = UnitCommitment.read(\"instance.json\")\n\n# Read solution (potentially produced by other packages) \nsolution = JSON.parsefile(\"solution.json\")\n\n# Validate solution and print validation errors\nUnitCommitment.validate(instance, solution)","category":"page"},{"location":"model/#JuMP-Model","page":"JuMP Model","title":"JuMP Model","text":"","category":"section"},{"location":"model/","page":"JuMP Model","title":"JuMP Model","text":"In this page, we describe the JuMP optimization model produced by the function UnitCommitment.build_model. A detailed understanding of this model is not necessary if you are just interested in using the package to solve some standard unit commitment cases, but it may be useful, for example, if you need to solve a slightly different problem, with additional variables and constraints. The notation in this page generally follows [KnOsWa20].","category":"page"},{"location":"model/#Decision-variables","page":"JuMP Model","title":"Decision variables","text":"","category":"section"},{"location":"model/#Generators","page":"JuMP Model","title":"Generators","text":"","category":"section"},{"location":"model/","page":"JuMP Model","title":"JuMP Model","text":"Name Symbol Description Unit\nis_on[g,t] u_g(t) True if generator g is on at time t. Binary\nswitch_on[g,t] v_g(t) True is generator g switches on at time t. Binary\nswitch_off[g,t] w_g(t) True if generator g switches off at time t. Binary\nprod_above[g,t] p_g(t) Amount of power produced by generator g above its minimum power output at time t. For example, if the minimum power of generator g is 100 MW and g is producing 115 MW of power at time t, then prod_above[g,t] equals 15.0. MW\nsegprod[g,t,k] p^k_g(t) Amount of power from piecewise linear segment k produced by generator g at time t. For example, if cost curve for generator g is defined by the points (100, 1400), (110, 1600), (130, 2200) and (135, 2400), and if the generator is producing 115 MW of power at time t, then segprod[g,t,:] equals [10.0, 5.0, 0.0]. MW\nreserve[r,g,t] r_g(t) Amount of reserve r provided by unit g at time t. MW\nstartup[g,t,s] delta^s_g(t) True if generator g switches on at time t incurring start-up costs from start-up category s. Binary","category":"page"},{"location":"model/#Buses","page":"JuMP Model","title":"Buses","text":"","category":"section"},{"location":"model/","page":"JuMP Model","title":"JuMP Model","text":"Name Symbol Description Unit\nnet_injection[b,t] n_b(t) Net injection at bus b at time t. MW\ncurtail[b,t] s^+_b(t) Amount of load curtailed at bus b at time t MW","category":"page"},{"location":"model/#Price-sensitive-loads","page":"JuMP Model","title":"Price-sensitive loads","text":"","category":"section"},{"location":"model/","page":"JuMP Model","title":"JuMP Model","text":"Name Symbol Description Unit\nloads[s,t] d_s(t) Amount of power served to price-sensitive load s at time t. MW","category":"page"},{"location":"model/#Transmission-lines","page":"JuMP Model","title":"Transmission lines","text":"","category":"section"},{"location":"model/","page":"JuMP Model","title":"JuMP Model","text":"Name Symbol Description Unit\nflow[l,t] f_l(t) Power flow on line l at time t. MW\noverflow[l,t] f^+_l(t) Amount of flow above the limit for line l at time t. MW","category":"page"},{"location":"model/","page":"JuMP Model","title":"JuMP Model","text":"warning: Warning\nSince transmission and N-1 security constraints are enforced in a lazy way, most of the flow[l,t] variables are never added to the model. Accessing model[:flow][l,t] without first checking that the variable exists will likely generate an error.","category":"page"},{"location":"model/#Objective-function","page":"JuMP Model","title":"Objective function","text":"","category":"section"},{"location":"model/","page":"JuMP Model","title":"JuMP Model","text":"TODO","category":"page"},{"location":"model/#Constraints","page":"JuMP Model","title":"Constraints","text":"","category":"section"},{"location":"model/","page":"JuMP Model","title":"JuMP Model","text":"TODO","category":"page"},{"location":"model/#Inspecting-and-modifying-the-model","page":"JuMP Model","title":"Inspecting and modifying the model","text":"","category":"section"},{"location":"model/#Accessing-decision-variables","page":"JuMP Model","title":"Accessing decision variables","text":"","category":"section"},{"location":"model/","page":"JuMP Model","title":"JuMP Model","text":"After building a model using UnitCommitment.build_model, it is possible to obtain a reference to the decision variables by calling model[:varname][index]. For example, model[:is_on][\"g1\",1] returns a direct reference to the JuMP variable indicating whether generator named \"g1\" is on at time 1. The script below illustrates how to build a model, solve it and display the solution without using the function UnitCommitment.solution.","category":"page"},{"location":"model/","page":"JuMP Model","title":"JuMP Model","text":"using Cbc\nusing Printf\nusing JuMP\nusing UnitCommitment\n\n# Load benchmark instance\ninstance = UnitCommitment.read_benchmark(\"matpower/case118/2017-02-01\")\n\n# Build JuMP model\nmodel = UnitCommitment.build_model(\n    instance=instance,\n    optimizer=Cbc.Optimizer,\n)\n\n# Solve the model\nUnitCommitment.optimize!(model)\n\n# Display commitment status\nfor g in instance.units\n    for t in 1:instance.time\n        @printf(\n            \"%-10s %5d %5.1f %5.1f %5.1f\\n\",\n            g.name,\n            t,\n            value(model[:is_on][g.name, t]),\n            value(model[:switch_on][g.name, t]),\n            value(model[:switch_off][g.name, t]),\n        )\n    end\nend","category":"page"},{"location":"model/#Fixing-variables,-modifying-objective-function-and-adding-constraints","page":"JuMP Model","title":"Fixing variables, modifying objective function and adding constraints","text":"","category":"section"},{"location":"model/","page":"JuMP Model","title":"JuMP Model","text":"Since we now have a direct reference to the JuMP decision variables, it is possible to fix variables, change the coefficients in the objective function, or even add new constraints to the model before solving it. The script below shows how can this be accomplished. For more information on modifying an existing model, see the JuMP documentation.","category":"page"},{"location":"model/","page":"JuMP Model","title":"JuMP Model","text":"using Cbc\nusing JuMP\nusing UnitCommitment\n\n# Load benchmark instance\ninstance = UnitCommitment.read_benchmark(\"matpower/case118/2017-02-01\")\n\n# Construct JuMP model\nmodel = UnitCommitment.build_model(\n    instance=instance,\n    optimizer=Cbc.Optimizer,\n)\n\n# Fix a decision variable to 1.0\nJuMP.fix(\n    model[:is_on][\"g1\",1],\n    1.0,\n    force=true,\n)\n\n# Change the objective function\nJuMP.set_objective_coefficient(\n    model,\n    model[:switch_on][\"g2\",1],\n    1000.0,\n)\n\n# Create a new constraint\n@constraint(\n    model,\n    model[:is_on][\"g3\",1] + model[:is_on][\"g4\",1] <= 1,\n)\n\n# Solve the model\nUnitCommitment.optimize!(model)","category":"page"},{"location":"model/#Adding-new-component-to-a-bus","page":"JuMP Model","title":"Adding new component to a bus","text":"","category":"section"},{"location":"model/","page":"JuMP Model","title":"JuMP Model","text":"The following snippet shows how to add a new grid component to a particular bus. For each time step, we create decision variables for the new grid component, add these variables to the objective function, then attach the component to a particular bus by modifying some existing model constraints. ","category":"page"},{"location":"model/","page":"JuMP Model","title":"JuMP Model","text":"using Cbc\nusing JuMP\nusing UnitCommitment\n\n# Load instance and build base model\ninstance = UnitCommitment.read_benchmark(\"matpower/case118/2017-02-01\")\nmodel = UnitCommitment.build_model(\n    instance=instance,\n    optimizer=Cbc.Optimizer,\n)\n\n# Get the number of time steps in the original instance\nT = instance.time\n\n# Create decision variables for the new grid component.\n# In this example, we assume that the new component can\n# inject up to 10 MW of power at each time step, so we\n# create new continuous variables 0 ≤ x[t] ≤ 10.\n@variable(model, x[1:T], lower_bound=0.0, upper_bound=10.0)\n\n# For each time step\nfor t in 1:T\n\n    # Add production costs to the objective function.\n    # In this example, we assume a cost of $5/MW.\n    set_objective_coefficient(model, x[t], 5.0)\n\n    # Attach the new component to bus b1, by modifying the\n    # constraint `eq_net_injection`.\n    set_normalized_coefficient(\n        model[:eq_net_injection][\"b1\", t],\n        x[t],\n        1.0,\n    )\nend\n\n# Solve the model\nUnitCommitment.optimize!(model)\n\n# Show optimal values for the x variables\n@show value.(x)","category":"page"},{"location":"model/#References","page":"JuMP Model","title":"References","text":"","category":"section"},{"location":"model/","page":"JuMP Model","title":"JuMP Model","text":"[KnOsWa20] Bernard Knueven, James Ostrowski and Jean-Paul Watson. \"On Mixed-Integer Programming Formulations for the Unit Commitment Problem\". INFORMS Journal on Computing (2020). DOI: 10.1287/ijoc.2019.0944","category":"page"},{"location":"instances/#Instances","page":"Instances","title":"Instances","text":"","category":"section"},{"location":"instances/","page":"Instances","title":"Instances","text":"UnitCommitment.jl provides a large collection of benchmark instances collected from the literature and converted to a common data format. In some cases, as indicated below, the original instances have been extended, with realistic parameters, using data-driven methods. If you use these instances in your research, we request that you cite UnitCommitment.jl, as well as the original sources, as listed below. Benchmark instances can be loaded with UnitCommitment.read_benchmark(name), as explained in the usage section. Instance files can also be directly downloaded from our website.","category":"page"},{"location":"instances/","page":"Instances","title":"Instances","text":"warning: Warning\nThe instances included in UC.jl are still under development and may change in the future. If you use these instances in your research, for reproducibility, you should specify what version of UC.jl they came from.","category":"page"},{"location":"instances/#MATPOWER","page":"Instances","title":"MATPOWER","text":"","category":"section"},{"location":"instances/","page":"Instances","title":"Instances","text":"MATPOWER is an open-source package for solving power flow problems in MATLAB and Octave. It contains a number of power flow test cases, which have been widely used in the power systems literature.","category":"page"},{"location":"instances/","page":"Instances","title":"Instances","text":"Because most MATPOWER test cases were originally designed for power flow studies, they lack a number of important unit commitment parameters, such as time-varying loads, production cost curves, ramp limits, reserves and initial conditions. The test cases included in UnitCommitment.jl are extended versions of the original MATPOWER test cases, modified as following:","category":"page"},{"location":"instances/","page":"Instances","title":"Instances","text":"Production cost curves were generated using a data-driven approach, based on publicly available data. More specifically, machine learning models were trained to predict typical production cost curves, for each day of the year, based on a generator's maximum and minimum power output.\nLoad profiles were generated using a similar data-driven approach.\nRamp-up, ramp-down, startup and shutdown rates were set to a fixed proportion of the generator's maximum output.\nMinimum reserves were set to a fixed proportion of the total demand.\nContingencies were set to include all N-1 transmission line contingencies that do not generate islands or isolated buses. More specifically, there is one contingency for each transmission line, as long as that transmission line is not a bridge in the network graph.","category":"page"},{"location":"instances/","page":"Instances","title":"Instances","text":"For each MATPOWER test case, UC.jl provides 365 variations (2017-01-01 to 2017-12-31) corresponding different days of the year.","category":"page"},{"location":"instances/#MATPOWER/UW-PSTCA","page":"Instances","title":"MATPOWER/UW-PSTCA","text":"","category":"section"},{"location":"instances/","page":"Instances","title":"Instances","text":"A variety of smaller IEEE test cases, compiled by University of Washington, corresponding mostly to small portions of the American Electric Power System in the 1960s.","category":"page"},{"location":"instances/","page":"Instances","title":"Instances","text":"Name Buses Generators Lines Contingencies References\nmatpower/case14/2017-01-01 14 5 20 19 [MTPWR, PSTCA]\nmatpower/case30/2017-01-01 30 6 41 38 [MTPWR, PSTCA]\nmatpower/case57/2017-01-01 57 7 80 79 [MTPWR, PSTCA]\nmatpower/case118/2017-01-01 118 54 186 177 [MTPWR, PSTCA]\nmatpower/case300/2017-01-01 300 69 411 320 [MTPWR, PSTCA]","category":"page"},{"location":"instances/#MATPOWER/Polish","page":"Instances","title":"MATPOWER/Polish","text":"","category":"section"},{"location":"instances/","page":"Instances","title":"Instances","text":"Test cases based on the Polish 400, 220 and 110 kV networks, originally provided by Roman Korab (Politechnika Śląska) and corrected by the MATPOWER team.","category":"page"},{"location":"instances/","page":"Instances","title":"Instances","text":"Name Buses Generators Lines Contingencies References\nmatpower/case2383wp/2017-01-01 2383 323 2896 2240 [MTPWR]\nmatpower/case2736sp/2017-01-01 2736 289 3504 3159 [MTPWR]\nmatpower/case2737sop/2017-01-01 2737 267 3506 3161 [MTPWR]\nmatpower/case2746wop/2017-01-01 2746 443 3514 3155 [MTPWR]\nmatpower/case2746wp/2017-01-01 2746 457 3514 3156 [MTPWR]\nmatpower/case3012wp/2017-01-01 3012 496 3572 2854 [MTPWR]\nmatpower/case3120sp/2017-01-01 3120 483 3693 2950 [MTPWR]\nmatpower/case3375wp/2017-01-01 3374 590 4161 3245 [MTPWR]","category":"page"},{"location":"instances/#MATPOWER/PEGASE","page":"Instances","title":"MATPOWER/PEGASE","text":"","category":"section"},{"location":"instances/","page":"Instances","title":"Instances","text":"Test cases from the Pan European Grid Advanced Simulation and State Estimation (PEGASE) project, describing part of the European high voltage transmission network.","category":"page"},{"location":"instances/","page":"Instances","title":"Instances","text":"Name Buses Generators Lines Contingencies References\nmatpower/case89pegase/2017-01-01 89 12 210 192 [JoFlMa16, FlPaCa13, MTPWR]\nmatpower/case1354pegase/2017-01-01 1354 260 1991 1288 [JoFlMa16, FlPaCa13, MTPWR]\nmatpower/case2869pegase/2017-01-01 2869 510 4582 3579 [JoFlMa16, FlPaCa13, MTPWR]\nmatpower/case9241pegase/2017-01-01 9241 1445 16049 13932 [JoFlMa16, FlPaCa13, MTPWR]\nmatpower/case13659pegase/2017-01-01 13659 4092 20467 13932 [JoFlMa16, FlPaCa13, MTPWR]","category":"page"},{"location":"instances/#MATPOWER/RTE","page":"Instances","title":"MATPOWER/RTE","text":"","category":"section"},{"location":"instances/","page":"Instances","title":"Instances","text":"Test cases from the R&D Division at Reseau de Transport d'Electricite representing the size and complexity of the French very high voltage transmission network.","category":"page"},{"location":"instances/","page":"Instances","title":"Instances","text":"Name Buses Generators Lines Contingencies References\nmatpower/case1888rte/2017-01-01 1888 296 2531 1484 [MTPWR, JoFlMa16]\nmatpower/case1951rte/2017-01-01 1951 390 2596 1497 [MTPWR, JoFlMa16]\nmatpower/case2848rte/2017-01-01 2848 544 3776 2242 [MTPWR, JoFlMa16]\nmatpower/case2868rte/2017-01-01 2868 596 3808 2260 [MTPWR, JoFlMa16]\nmatpower/case6468rte/2017-01-01 6468 1262 9000 6094 [MTPWR, JoFlMa16]\nmatpower/case6470rte/2017-01-01 6470 1306 9005 6085 [MTPWR, JoFlMa16]\nmatpower/case6495rte/2017-01-01 6495 1352 9019 6060 [MTPWR, JoFlMa16]\nmatpower/case6515rte/2017-01-01 6515 1368 9037 6063 [MTPWR, JoFlMa16]","category":"page"},{"location":"instances/#PGLIB-UC-Instances","page":"Instances","title":"PGLIB-UC Instances","text":"","category":"section"},{"location":"instances/","page":"Instances","title":"Instances","text":"PGLIB-UC is a benchmark library curated and maintained by the IEEE PES Task Force on Benchmarks for Validation of Emerging Power System Algorithms. These test cases have been used in [KnOsWa20].","category":"page"},{"location":"instances/#PGLIB-UC/California","page":"Instances","title":"PGLIB-UC/California","text":"","category":"section"},{"location":"instances/","page":"Instances","title":"Instances","text":"Test cases based on publicly available data from the California ISO. For more details, see PGLIB-UC case file overview.","category":"page"},{"location":"instances/","page":"Instances","title":"Instances","text":"Name Buses Generators Lines Contingencies References\npglib-uc/ca/2014-09-01_reserves_0 1 610 0 0 [KnOsWa20]\npglib-uc/ca/2014-09-01_reserves_1 1 610 0 0 [KnOsWa20]\npglib-uc/ca/2014-09-01_reserves_3 1 610 0 0 [KnOsWa20]\npglib-uc/ca/2014-09-01_reserves_5 1 610 0 0 [KnOsWa20]\npglib-uc/ca/2014-12-01_reserves_0 1 610 0 0 [KnOsWa20]\npglib-uc/ca/2014-12-01_reserves_1 1 610 0 0 [KnOsWa20]\npglib-uc/ca/2014-12-01_reserves_3 1 610 0 0 [KnOsWa20]\npglib-uc/ca/2014-12-01_reserves_5 1 610 0 0 [KnOsWa20]\npglib-uc/ca/2015-03-01_reserves_0 1 610 0 0 [KnOsWa20]\npglib-uc/ca/2015-03-01_reserves_1 1 610 0 0 [KnOsWa20]\npglib-uc/ca/2015-03-01_reserves_3 1 610 0 0 [KnOsWa20]\npglib-uc/ca/2015-03-01_reserves_5 1 610 0 0 [KnOsWa20]\npglib-uc/ca/2015-06-01_reserves_0 1 610 0 0 [KnOsWa20]\npglib-uc/ca/2015-06-01_reserves_1 1 610 0 0 [KnOsWa20]\npglib-uc/ca/2015-06-01_reserves_3 1 610 0 0 [KnOsWa20]\npglib-uc/ca/2015-06-01_reserves_5 1 610 0 0 [KnOsWa20]\npglib-uc/ca/Scenario400_reserves_0 1 611 0 0 [KnOsWa20]\npglib-uc/ca/Scenario400_reserves_1 1 611 0 0 [KnOsWa20]\npglib-uc/ca/Scenario400_reserves_3 1 611 0 0 [KnOsWa20]\npglib-uc/ca/Scenario400_reserves_5 1 611 0 0 [KnOsWa20]","category":"page"},{"location":"instances/#PGLIB-UC/FERC","page":"Instances","title":"PGLIB-UC/FERC","text":"","category":"section"},{"location":"instances/","page":"Instances","title":"Instances","text":"Test cases based on a publicly available unit commitment test case produced by the Federal Energy Regulatory Commission. For more details, see PGLIB-UC case file overview.","category":"page"},{"location":"instances/","page":"Instances","title":"Instances","text":"Name Buses Generators Lines Contingencies References\npglib-uc/ferc/2015-01-01_hw 1 935 0 0 [KnOsWa20, KrHiOn12]\npglib-uc/ferc/2015-01-01_lw 1 935 0 0 [KnOsWa20, KrHiOn12]\npglib-uc/ferc/2015-02-01_hw 1 935 0 0 [KnOsWa20, KrHiOn12]\npglib-uc/ferc/2015-02-01_lw 1 935 0 0 [KnOsWa20, KrHiOn12]\npglib-uc/ferc/2015-03-01_hw 1 935 0 0 [KnOsWa20, KrHiOn12]\npglib-uc/ferc/2015-03-01_lw 1 935 0 0 [KnOsWa20, KrHiOn12]\npglib-uc/ferc/2015-04-01_hw 1 979 0 0 [KnOsWa20, KrHiOn12]\npglib-uc/ferc/2015-04-01_lw 1 979 0 0 [KnOsWa20, KrHiOn12]\npglib-uc/ferc/2015-05-01_hw 1 979 0 0 [KnOsWa20, KrHiOn12]\npglib-uc/ferc/2015-05-01_lw 1 979 0 0 [KnOsWa20, KrHiOn12]\npglib-uc/ferc/2015-06-01_hw 1 979 0 0 [KnOsWa20, KrHiOn12]\npglib-uc/ferc/2015-06-01_lw 1 979 0 0 [KnOsWa20, KrHiOn12]\npglib-uc/ferc/2015-07-01_hw 1 979 0 0 [KnOsWa20, KrHiOn12]\npglib-uc/ferc/2015-07-01_lw 1 979 0 0 [KnOsWa20, KrHiOn12]\npglib-uc/ferc/2015-08-01_hw 1 979 0 0 [KnOsWa20, KrHiOn12]\npglib-uc/ferc/2015-08-01_lw 1 979 0 0 [KnOsWa20, KrHiOn12]\npglib-uc/ferc/2015-09-01_hw 1 979 0 0 [KnOsWa20, KrHiOn12]\npglib-uc/ferc/2015-09-01_lw 1 979 0 0 [KnOsWa20, KrHiOn12]\npglib-uc/ferc/2015-10-01_hw 1 935 0 0 [KnOsWa20, KrHiOn12]\npglib-uc/ferc/2015-10-01_lw 1 935 0 0 [KnOsWa20, KrHiOn12]\npglib-uc/ferc/2015-11-02_hw 1 935 0 0 [KnOsWa20, KrHiOn12]\npglib-uc/ferc/2015-11-02_lw 1 935 0 0 [KnOsWa20, KrHiOn12]\npglib-uc/ferc/2015-12-01_hw 1 935 0 0 [KnOsWa20, KrHiOn12]\npglib-uc/ferc/2015-12-01_lw 1 935 0 0 [KnOsWa20, KrHiOn12]","category":"page"},{"location":"instances/#PGLIB-UC/RTS-GMLC","page":"Instances","title":"PGLIB-UC/RTS-GMLC","text":"","category":"section"},{"location":"instances/","page":"Instances","title":"Instances","text":"RTS-GMLC is an updated version of the RTS-96 test system produced by the United States Department of Energy's Grid Modernization Laboratory Consortium. The PGLIB-UC/RTS-GMLC instances are modified versions of the original RTS-GMLC instances, with modified ramp-rates and without a transmission network. For more details, see PGLIB-UC case file overview.","category":"page"},{"location":"instances/","page":"Instances","title":"Instances","text":"Name Buses Generators Lines Contingencies References\npglib-uc/rts_gmlc/2020-01-27 1 154 0 0 [BaBlEh19]\npglib-uc/rts_gmlc/2020-02-09 1 154 0 0 [BaBlEh19]\npglib-uc/rts_gmlc/2020-03-05 1 154 0 0 [BaBlEh19]\npglib-uc/rts_gmlc/2020-04-03 1 154 0 0 [BaBlEh19]\npglib-uc/rts_gmlc/2020-05-05 1 154 0 0 [BaBlEh19]\npglib-uc/rts_gmlc/2020-06-09 1 154 0 0 [BaBlEh19]\npglib-uc/rts_gmlc/2020-07-06 1 154 0 0 [BaBlEh19]\npglib-uc/rts_gmlc/2020-08-12 1 154 0 0 [BaBlEh19]\npglib-uc/rts_gmlc/2020-09-20 1 154 0 0 [BaBlEh19]\npglib-uc/rts_gmlc/2020-10-27 1 154 0 0 [BaBlEh19]\npglib-uc/rts_gmlc/2020-11-25 1 154 0 0 [BaBlEh19]\npglib-uc/rts_gmlc/2020-12-23 1 154 0 0 [BaBlEh19]","category":"page"},{"location":"instances/#OR-LIB/UC","page":"Instances","title":"OR-LIB/UC","text":"","category":"section"},{"location":"instances/","page":"Instances","title":"Instances","text":"OR-LIB is a collection of test data sets for a variety of operations research problems, including unit commitment. The UC instances in OR-LIB are synthetic instances generated by a random problem generator developed by the Operations Research Group at University of Pisa. These test cases have been used in [FrGe06] and many other publications.","category":"page"},{"location":"instances/","page":"Instances","title":"Instances","text":"Name Hours Buses Generators Lines Contingencies References\nor-lib/10_0_1_w 24 1 10 0 0 [ORLIB, FrGe06]\nor-lib/10_0_2_w 24 1 10 0 0 [ORLIB, FrGe06]\nor-lib/10_0_3_w 24 1 10 0 0 [ORLIB, FrGe06]\nor-lib/10_0_4_w 24 1 10 0 0 [ORLIB, FrGe06]\nor-lib/10_0_5_w 24 1 10 0 0 [ORLIB, FrGe06]\nor-lib/20_0_1_w 24 1 20 0 0 [ORLIB, FrGe06]\nor-lib/20_0_2_w 24 1 20 0 0 [ORLIB, FrGe06]\nor-lib/20_0_3_w 24 1 20 0 0 [ORLIB, FrGe06]\nor-lib/20_0_4_w 24 1 20 0 0 [ORLIB, FrGe06]\nor-lib/20_0_5_w 24 1 20 0 0 [ORLIB, FrGe06]\nor-lib/50_0_1_w 24 1 50 0 0 [ORLIB, FrGe06]\nor-lib/50_0_2_w 24 1 50 0 0 [ORLIB, FrGe06]\nor-lib/50_0_3_w 24 1 50 0 0 [ORLIB, FrGe06]\nor-lib/50_0_4_w 24 1 50 0 0 [ORLIB, FrGe06]\nor-lib/50_0_5_w 24 1 50 0 0 [ORLIB, FrGe06]\nor-lib/75_0_1_w 24 1 75 0 0 [ORLIB, FrGe06]\nor-lib/75_0_2_w 24 1 75 0 0 [ORLIB, FrGe06]\nor-lib/75_0_3_w 24 1 75 0 0 [ORLIB, FrGe06]\nor-lib/75_0_4_w 24 1 75 0 0 [ORLIB, FrGe06]\nor-lib/75_0_5_w 24 1 75 0 0 [ORLIB, FrGe06]\nor-lib/100_0_1_w 24 1 100 0 0 [ORLIB, FrGe06]\nor-lib/100_0_2_w 24 1 100 0 0 [ORLIB, FrGe06]\nor-lib/100_0_3_w 24 1 100 0 0 [ORLIB, FrGe06]\nor-lib/100_0_4_w 24 1 100 0 0 [ORLIB, FrGe06]\nor-lib/100_0_5_w 24 1 100 0 0 [ORLIB, FrGe06]\nor-lib/150_0_1_w 24 1 150 0 0 [ORLIB, FrGe06]\nor-lib/150_0_2_w 24 1 150 0 0 [ORLIB, FrGe06]\nor-lib/150_0_3_w 24 1 150 0 0 [ORLIB, FrGe06]\nor-lib/150_0_4_w 24 1 150 0 0 [ORLIB, FrGe06]\nor-lib/150_0_5_w 24 1 150 0 0 [ORLIB, FrGe06]\nor-lib/200_0_10_w 24 1 200 0 0 [ORLIB, FrGe06]\nor-lib/200_0_11_w 24 1 200 0 0 [ORLIB, FrGe06]\nor-lib/200_0_12_w 24 1 200 0 0 [ORLIB, FrGe06]\nor-lib/200_0_1_w 24 1 200 0 0 [ORLIB, FrGe06]\nor-lib/200_0_2_w 24 1 200 0 0 [ORLIB, FrGe06]\nor-lib/200_0_3_w 24 1 200 0 0 [ORLIB, FrGe06]\nor-lib/200_0_4_w 24 1 200 0 0 [ORLIB, FrGe06]\nor-lib/200_0_5_w 24 1 200 0 0 [ORLIB, FrGe06]\nor-lib/200_0_6_w 24 1 200 0 0 [ORLIB, FrGe06]\nor-lib/200_0_7_w 24 1 200 0 0 [ORLIB, FrGe06]\nor-lib/200_0_8_w 24 1 200 0 0 [ORLIB, FrGe06]\nor-lib/200_0_9_w 24 1 200 0 0 [ORLIB, FrGe06]","category":"page"},{"location":"instances/#Tejada19","page":"Instances","title":"Tejada19","text":"","category":"section"},{"location":"instances/","page":"Instances","title":"Instances","text":"Test cases used in [TeLuSa19]. These instances are similar to OR-LIB/UC, in the sense that they use the same random problem generator, but are much larger.","category":"page"},{"location":"instances/","page":"Instances","title":"Instances","text":"Name Hours Buses Generators Lines Contingencies References\ntejada19/UC_24h_214g 24 1 214 0 0 [TeLuSa19]\ntejada19/UC_24h_250g 24 1 250 0 0 [TeLuSa19]\ntejada19/UC_24h_290g 24 1 290 0 0 [TeLuSa19]\ntejada19/UC_24h_480g 24 1 480 0 0 [TeLuSa19]\ntejada19/UC_24h_505g 24 1 505 0 0 [TeLuSa19]\ntejada19/UC_24h_623g 24 1 623 0 0 [TeLuSa19]\ntejada19/UC_24h_647g 24 1 647 0 0 [TeLuSa19]\ntejada19/UC_24h_836g 24 1 836 0 0 [TeLuSa19]\ntejada19/UC_24h_850g 24 1 850 0 0 [TeLuSa19]\ntejada19/UC_24h_918g 24 1 918 0 0 [TeLuSa19]\ntejada19/UC_24h_931g 24 1 931 0 0 [TeLuSa19]\ntejada19/UC_24h_940g 24 1 940 0 0 [TeLuSa19]\ntejada19/UC_24h_957g 24 1 957 0 0 [TeLuSa19]\ntejada19/UC_24h_959g 24 1 959 0 0 [TeLuSa19]\ntejada19/UC_24h_1069g 24 1 1069 0 0 [TeLuSa19]\ntejada19/UC_24h_1130g 24 1 1130 0 0 [TeLuSa19]\ntejada19/UC_24h_1376g 24 1 1376 0 0 [TeLuSa19]\ntejada19/UC_24h_1393g 24 1 1393 0 0 [TeLuSa19]\ntejada19/UC_24h_1577g 24 1 1577 0 0 [TeLuSa19]\ntejada19/UC_24h_1615g 24 1 1615 0 0 [TeLuSa19]\ntejada19/UC_24h_1632g 24 1 1632 0 0 [TeLuSa19]\ntejada19/UC_24h_1768g 24 1 1768 0 0 [TeLuSa19]\ntejada19/UC_24h_1804g 24 1 1804 0 0 [TeLuSa19]\ntejada19/UC_24h_1820g 24 1 1820 0 0 [TeLuSa19]\ntejada19/UC_24h_1823g 24 1 1823 0 0 [TeLuSa19]\ntejada19/UC_24h_1888g 24 1 1888 0 0 [TeLuSa19]\ntejada19/UC_168h_36g 168 1 36 0 0 [TeLuSa19]\ntejada19/UC_168h_38g 168 1 38 0 0 [TeLuSa19]\ntejada19/UC_168h_40g 168 1 40 0 0 [TeLuSa19]\ntejada19/UC_168h_53g 168 1 53 0 0 [TeLuSa19]\ntejada19/UC_168h_58g 168 1 58 0 0 [TeLuSa19]\ntejada19/UC_168h_59g 168 1 59 0 0 [TeLuSa19]\ntejada19/UC_168h_72g 168 1 72 0 0 [TeLuSa19]\ntejada19/UC_168h_84g 168 1 84 0 0 [TeLuSa19]\ntejada19/UC_168h_86g 168 1 86 0 0 [TeLuSa19]\ntejada19/UC_168h_88g 168 1 88 0 0 [TeLuSa19]\ntejada19/UC_168h_93g 168 1 93 0 0 [TeLuSa19]\ntejada19/UC_168h_105g 168 1 105 0 0 [TeLuSa19]\ntejada19/UC_168h_110g 168 1 110 0 0 [TeLuSa19]\ntejada19/UC_168h_125g 168 1 125 0 0 [TeLuSa19]\ntejada19/UC_168h_130g 168 1 130 0 0 [TeLuSa19]\ntejada19/UC_168h_131g 168 1 131 0 0 [TeLuSa19]\ntejada19/UC_168h_140g 168 1 140 0 0 [TeLuSa19]\ntejada19/UC_168h_165g 168 1 165 0 0 [TeLuSa19]\ntejada19/UC_168h_175g 168 1 175 0 0 [TeLuSa19]\ntejada19/UC_168h_179g 168 1 179 0 0 [TeLuSa19]\ntejada19/UC_168h_188g 168 1 188 0 0 [TeLuSa19]\ntejada19/UC_168h_192g 168 1 192 0 0 [TeLuSa19]\ntejada19/UC_168h_199g 168 1 199 0 0 [TeLuSa19]","category":"page"},{"location":"instances/#References","page":"Instances","title":"References","text":"","category":"section"},{"location":"instances/","page":"Instances","title":"Instances","text":"[UCJL] Alinson S. Xavier, Aleksandr M. Kazachkov, Ogün Yurdakul, Feng Qiu. \"UnitCommitment.jl: A Julia/JuMP Optimization Package for Security-Constrained Unit Commitment (Version 0.3)\". Zenodo (2022). DOI: 10.5281/zenodo.4269874\n[KnOsWa20] Bernard Knueven, James Ostrowski and Jean-Paul Watson. \"On Mixed-Integer Programming Formulations for the Unit Commitment Problem\". INFORMS Journal on Computing (2020). DOI: 10.1287/ijoc.2019.0944\n[KrHiOn12] Eric Krall, Michael Higgins and Richard P. O’Neill. \"RTO unit commitment test system.\" Federal Energy Regulatory Commission. Available at: https://www.ferc.gov/industries-data/electric/power-sales-and-markets/increasing-efficiency-through-improved-software-1 (Accessed: Nov 14, 2020)\n[BaBlEh19] Clayton Barrows, Aaron Bloom, Ali Ehlen, Jussi Ikaheimo, Jennie Jorgenson, Dheepak Krishnamurthy, Jessica Lau et al. \"The IEEE Reliability Test System: A Proposed 2019 Update.\" IEEE Transactions on Power Systems (2019). DOI: 10.1109/TPWRS.2019.2925557\n[JoFlMa16] C. Josz, S. Fliscounakis, J. Maeght, and P. Panciatici. \"AC Power Flow Data in MATPOWER and QCQP Format: iTesla, RTE Snapshots, and PEGASE\". ArXiv (2016).\n[FlPaCa13] S. Fliscounakis, P. Panciatici, F. Capitanescu, and L. Wehenkel. \"Contingency ranking with respect to overloads in very large power systems taking into account uncertainty, preventive and corrective actions\", Power Systems, IEEE Trans. on, (28)4:4909-4917, 2013. DOI: 10.1109/TPWRS.2013.2251015\n[MTPWR] D. Zimmerman, C. E. Murillo-Sandnchez and R. J. Thomas. \"Matpower:  Steady-state  operations,  planning,  and  analysis  tools  forpower systems research and education\", IEEE Transactions on PowerSystems, vol. 26, no. 1, pp. 12 –19, Feb. 2011. DOI: 10.1109/TPWRS.2010.2051168\n[PSTCA] University of Washington, Dept. of Electrical Engineering. \"Power Systems Test Case Archive\". Available at: http://www.ee.washington.edu/research/pstca/ (Accessed: Nov 14, 2020)\n[ORLIB] J.E.Beasley. \"OR-Library: distributing test problems by electronic mail\", Journal of the Operational Research Society 41(11) (1990). DOI: 10.2307/2582903\n[FrGe06] A. Frangioni, C. Gentile. \"Solving nonlinear single-unit commitment problems with ramping constraints\" Operations Research 54(4), p. 767 - 775, 2006. DOI: 10.1287/opre.1060.0309\n[TeLuSa19] D. A. Tejada-Arango, S. Lumbreras, P. Sanchez-Martin and A. Ramos. \"Which Unit-Commitment Formulation is Best? A Systematic Comparison,\" in IEEE Transactions on Power Systems. DOI: 10.1109/TPWRS.2019.2962024.","category":"page"},{"location":"format/#Data-Format","page":"Data Format","title":"Data Format","text":"","category":"section"},{"location":"format/#Input-Data-Format","page":"Data Format","title":"Input Data Format","text":"","category":"section"},{"location":"format/","page":"Data Format","title":"Data Format","text":"Instances are specified by JSON files containing the following main sections:","category":"page"},{"location":"format/","page":"Data Format","title":"Data Format","text":"Parameters\nBuses\nGenerators\nPrice-sensitive loads\nTransmission lines\nReserves\nContingencies","category":"page"},{"location":"format/","page":"Data Format","title":"Data Format","text":"Each section is described in detail below. See case118/2017-01-01.json.gz for a complete example.","category":"page"},{"location":"format/#Parameters","page":"Data Format","title":"Parameters","text":"","category":"section"},{"location":"format/","page":"Data Format","title":"Data Format","text":"This section describes system-wide parameters, such as power balance penalty, and optimization parameters, such as the length of the planning horizon and the time.","category":"page"},{"location":"format/","page":"Data Format","title":"Data Format","text":"Key Description Default Time series?\nVersion Version of UnitCommitment.jl this file was written for. Required to ensure that the file remains readable in future versions of the package. If you are following this page to construct the file, this field should equal 0.3. Required N\nTime horizon (h) Length of the planning horizon (in hours). Required N\nTime step (min) Length of each time step (in minutes). Must be a divisor of 60 (e.g. 60, 30, 20, 15, etc). 60 N\nPower balance penalty ($/MW) Penalty for system-wide shortage or surplus in production (in /MW). This is charged per time step. For example, if there is a shortage of 1 MW for three time steps, three times this amount will be charged. 1000.0 Y","category":"page"},{"location":"format/#Example","page":"Data Format","title":"Example","text":"","category":"section"},{"location":"format/","page":"Data Format","title":"Data Format","text":"{\n    \"Parameters\": {\n        \"Version\": \"0.3\",\n        \"Time horizon (h)\": 4,\n        \"Power balance penalty ($/MW)\": 1000.0\n    }\n}","category":"page"},{"location":"format/#Buses","page":"Data Format","title":"Buses","text":"","category":"section"},{"location":"format/","page":"Data Format","title":"Data Format","text":"This section describes the characteristics of each bus in the system. ","category":"page"},{"location":"format/","page":"Data Format","title":"Data Format","text":"Key Description Default Time series?\nLoad (MW) Fixed load connected to the bus (in MW). Required Y","category":"page"},{"location":"format/#Example-2","page":"Data Format","title":"Example","text":"","category":"section"},{"location":"format/","page":"Data Format","title":"Data Format","text":"{\n    \"Buses\": {\n        \"b1\": {\n            \"Load (MW)\": 0.0\n        },\n        \"b2\": {\n            \"Load (MW)\": [\n                26.01527,\n                24.46212,\n                23.29725,\n                22.90897\n            ]\n        }\n    }\n}","category":"page"},{"location":"format/#Generators","page":"Data Format","title":"Generators","text":"","category":"section"},{"location":"format/","page":"Data Format","title":"Data Format","text":"This section describes all generators in the system, including thermal units, renewable units and virtual units.","category":"page"},{"location":"format/","page":"Data Format","title":"Data Format","text":"Key Description Default Time series?\nBus Identifier of the bus where this generator is located (string). Required N\nProduction cost curve (MW) and Production cost curve ($) Parameters describing the piecewise-linear production costs. See below for more details. Required Y\nStartup costs ($) and Startup delays (h) Parameters describing how much it costs to start the generator after it has been shut down for a certain amount of time. If Startup costs ($) and Startup delays (h) are set to [300.0, 400.0] and [1, 4], for example, and the generator is shut down at time 00:00 (h:min), then it costs $300 to start up the generator at any time between 01:00 and 03:59, and $400 to start the generator at time 04:00 or any time after that.  The number of startup cost points is unlimited, and may be different for each generator. Startup delays must be strictly increasing and the first entry must equal Minimum downtime (h). [0.0] and [1] N\nMinimum uptime (h) Minimum amount of time the generator must stay operational after starting up (in hours). For example, if the generator starts up at time 00:00 (h:min) and Minimum uptime (h) is set to 4, then the generator can only shut down at time 04:00. 1 N\nMinimum downtime (h) Minimum amount of time the generator must stay offline after shutting down (in hours). For example, if the generator shuts down at time 00:00 (h:min) and Minimum downtime (h) is set to 4, then the generator can only start producing power again at time 04:00. 1 N\nRamp up limit (MW) Maximum increase in production from one time step to the next (in MW). For example, if the generator is producing 100 MW at time step 1 and if this parameter is set to 40 MW, then the generator will produce at most 140 MW at time step 2. +inf N\nRamp down limit (MW) Maximum decrease in production from one time step to the next (in MW). For example, if the generator is producing 100 MW at time step 1 and this parameter is set to 40 MW, then the generator will produce at least 60 MW at time step 2. +inf N\nStartup limit (MW) Maximum amount of power a generator can produce immediately after starting up (in MW). For example, if Startup limit (MW) is set to 100 MW and the unit is off at time step 1, then it may produce at most 100 MW at time step 2. +inf N\nShutdown limit (MW) Maximum amount of power a generator can produce immediately before shutting down (in MW). Specifically, the generator can only shut down at time step t+1 if its production at time step t is below this limit. +inf N\nInitial status (h) If set to a positive number, indicates the amount of time (in hours) the generator has been on at the beginning of the simulation, and if set to a negative number, the amount of time the generator has been off. For example, if Initial status (h) is -2, this means that the generator was off since -02:00 (h:min). The simulation starts at time 00:00. If Initial status (h) is 3, this means that the generator was on since -03:00. A value of zero is not acceptable. Required N\nInitial power (MW) Amount of power the generator at time step -1, immediately before the planning horizon starts. Required N\nMust run? If true, the generator should be committed, even if that is not economical (Boolean). false Y\nReserve eligibility List of reserve products this generator is eligibe to provide. By default, the generator is not eligible to provide any reserves. [] N","category":"page"},{"location":"format/#Production-costs-and-limits","page":"Data Format","title":"Production costs and limits","text":"","category":"section"},{"location":"format/","page":"Data Format","title":"Data Format","text":"Production costs are represented as piecewise-linear curves. Figure 1 shows an example cost curve with three segments, where it costs $1400, $1600, $2200 and $2400 to generate, respectively, 100, 110, 130 and 135 MW of power. To model this generator, Production cost curve (MW) should be set to [100, 110, 130, 135], and Production cost curve ($)  should be set to [1400, 1600, 2200, 2400]. Note that this curve also specifies the production limits. Specifically, the first point identifies the minimum power output when the unit is operational, while the last point identifies the maximum power output.","category":"page"},{"location":"format/","page":"Data Format","title":"Data Format","text":"<center>\n    <img src=\"../assets/cost_curve.png\" style=\"max-width: 500px\"/>\n    <div><b>Figure 1.</b> Piecewise-linear production cost curve.</div>\n    <br/>\n</center>","category":"page"},{"location":"format/#Additional-remarks:","page":"Data Format","title":"Additional remarks:","text":"","category":"section"},{"location":"format/","page":"Data Format","title":"Data Format","text":"For time-dependent production limits or time-dependent production costs, the usage of nested arrays is allowed. For example,  if Production cost curve (MW) is set to [5.0, [10.0, 12.0, 15.0, 20.0]], then the unit may generate at most 10, 12, 15 and 20 MW of power during time steps 1, 2, 3 and 4, respectively. The minimum output for all time periods is fixed to at 5 MW.\nThere is no limit to the number of piecewise-linear segments, and different generators may have a different number of segments.\nIf Production cost curve (MW) and Production cost curve ($) both contain a single element, then the generator must produce exactly that amount of power when operational. To specify that the generator may produce any amount of power up to a certain limit P, the parameter Production cost curve (MW) should be set to [0, P]. \nProduction cost curves must be convex.","category":"page"},{"location":"format/#Example-3","page":"Data Format","title":"Example","text":"","category":"section"},{"location":"format/","page":"Data Format","title":"Data Format","text":"{\n    \"Generators\": {\n        \"gen1\": {\n            \"Bus\": \"b1\",\n            \"Production cost curve (MW)\": [100.0, 110.0, 130.0, 135.0],\n            \"Production cost curve ($)\": [1400.0, 1600.0, 2200.0, 2400.0],\n            \"Startup costs ($)\": [300.0, 400.0],\n            \"Startup delays (h)\": [1, 4],\n            \"Ramp up limit (MW)\": 232.68,\n            \"Ramp down limit (MW)\": 232.68,\n            \"Startup limit (MW)\": 232.68,\n            \"Shutdown limit (MW)\": 232.68,\n            \"Minimum downtime (h)\": 4,\n            \"Minimum uptime (h)\": 4,\n            \"Initial status (h)\": 12,\n            \"Must run?\": false,\n            \"Reserve eligibility\": [\"r1\"],\n        },\n        \"gen2\": {\n            \"Bus\": \"b5\",\n            \"Production cost curve (MW)\": [0.0, [10.0, 8.0, 0.0, 3.0]],\n            \"Production cost curve ($)\": [0.0, 0.0],\n            \"Reserve eligibility\": [\"r1\", \"r2\"],\n        }\n    }\n}","category":"page"},{"location":"format/#Price-sensitive-loads","page":"Data Format","title":"Price-sensitive loads","text":"","category":"section"},{"location":"format/","page":"Data Format","title":"Data Format","text":"This section describes components in the system which may increase or reduce their energy consumption according to the energy prices. Fixed loads (as described in the buses section) are always served, regardless of the price, unless there is significant congestion in the system or insufficient production capacity. Price-sensitive loads, on the other hand, are only served if it is economical to do so. ","category":"page"},{"location":"format/","page":"Data Format","title":"Data Format","text":"Key Description Default Time series?\nBus Bus where the load is located. Multiple price-sensitive loads may be placed at the same bus. Required N\nRevenue ($/MW) Revenue obtained for serving each MW of power to this load. Required Y\nDemand (MW) Maximum amount of power required by this load. Any amount lower than this may be served. Required Y","category":"page"},{"location":"format/#Example-4","page":"Data Format","title":"Example","text":"","category":"section"},{"location":"format/","page":"Data Format","title":"Data Format","text":"{\n    \"Price-sensitive loads\": {\n        \"p1\": {\n            \"Bus\": \"b3\",\n            \"Revenue ($/MW)\": 23.0,\n            \"Demand (MW)\": 50.0\n        }\n    }\n}","category":"page"},{"location":"format/#Transmission-lines","page":"Data Format","title":"Transmission lines","text":"","category":"section"},{"location":"format/","page":"Data Format","title":"Data Format","text":"This section describes the characteristics of transmission system, such as its topology and the susceptance of each transmission line.","category":"page"},{"location":"format/","page":"Data Format","title":"Data Format","text":"Key Description Default Time series?\nSource bus Identifier of the bus where the transmission line originates. Required N\nTarget bus Identifier of the bus where the transmission line reaches. Required N\nReactance (ohms) Reactance of the transmission line (in ohms). Required N\nSusceptance (S) Susceptance  of the transmission line (in siemens). Required N\nNormal flow limit (MW) Maximum amount of power (in MW) allowed to flow through the line when the system is in its regular, fully-operational state. +inf Y\nEmergency flow limit (MW) Maximum amount of power (in MW) allowed to flow through the line when the system is in degraded state (for example, after the failure of another transmission line). +inf Y\nFlow limit penalty ($/MW) Penalty for violating the flow limits of the transmission line (in /MW). This is charged per time step. For example, if there is a thermal violation of 1 MW for three time steps, then three times this amount will be charged. 5000.0 Y","category":"page"},{"location":"format/#Example-5","page":"Data Format","title":"Example","text":"","category":"section"},{"location":"format/","page":"Data Format","title":"Data Format","text":"{\n    \"Transmission lines\": {\n        \"l1\": {\n            \"Source bus\": \"b1\",\n            \"Target bus\": \"b2\",\n            \"Reactance (ohms)\": 0.05917,\n            \"Susceptance (S)\": 29.49686,\n            \"Normal flow limit (MW)\": 15000.0,\n            \"Emergency flow limit (MW)\": 20000.0,\n            \"Flow limit penalty ($/MW)\": 5000.0\n        }\n    }\n}","category":"page"},{"location":"format/#Reserves","page":"Data Format","title":"Reserves","text":"","category":"section"},{"location":"format/","page":"Data Format","title":"Data Format","text":"This section describes the hourly amount of reserves required.","category":"page"},{"location":"format/","page":"Data Format","title":"Data Format","text":"Key Description Default Time series?\nType Type of reserve product. Must be either \"spinning\" or \"flexiramp\". Required N\nAmount (MW) Amount of reserves required. Required Y\nShortfall penalty ($/MW) Penalty for shortage in meeting the reserve requirements (in /MW). This is charged per time step. Negative value implies reserve constraints must always be satisfied. -1 Y","category":"page"},{"location":"format/#Example-1","page":"Data Format","title":"Example 1","text":"","category":"section"},{"location":"format/","page":"Data Format","title":"Data Format","text":"{\n    \"Reserves\": {\n        \"r1\": {\n            \"Type\": \"spinning\",\n            \"Amount (MW)\": [\n                57.30552,\n                53.88429,\n                51.31838,\n                50.46307\n            ],\n            \"Shortfall penalty ($/MW)\": 5.0\n        },\n        \"r2\": {\n            \"Type\": \"flexiramp\",\n            \"Amount (MW)\": [\n                20.31042,\n                23.65273,\n                27.41784,\n                25.34057\n            ],\n        }\n    }\n}","category":"page"},{"location":"format/#Contingencies","page":"Data Format","title":"Contingencies","text":"","category":"section"},{"location":"format/","page":"Data Format","title":"Data Format","text":"This section describes credible contingency scenarios in the optimization, such as the loss of a transmission line or generator.","category":"page"},{"location":"format/","page":"Data Format","title":"Data Format","text":"Key Description Default\nAffected generators List of generators affected by this contingency. May be omitted if no generators are affected. []\nAffected lines List of transmission lines affected by this contingency. May be omitted if no lines are affected. []","category":"page"},{"location":"format/#Example-6","page":"Data Format","title":"Example","text":"","category":"section"},{"location":"format/","page":"Data Format","title":"Data Format","text":"{\n    \"Contingencies\": {\n        \"c1\": {\n            \"Affected lines\": [\"l1\", \"l2\", \"l3\"],\n            \"Affected generators\": [\"g1\"]\n        },\n        \"c2\": {\n            \"Affected lines\": [\"l4\"]\n        },\n    }\n}","category":"page"},{"location":"format/#Additional-remarks","page":"Data Format","title":"Additional remarks","text":"","category":"section"},{"location":"format/#Time-series-parameters","page":"Data Format","title":"Time series parameters","text":"","category":"section"},{"location":"format/","page":"Data Format","title":"Data Format","text":"Many numerical properties in the JSON file can be specified either as a single floating point number if they are time-independent, or as an array containing exactly T elements, if they are time-dependent, where T is the number of time steps in the planning horizon. For example, both formats below are valid when T=3:","category":"page"},{"location":"format/","page":"Data Format","title":"Data Format","text":"{\n    \"Load (MW)\": 800.0,\n    \"Load (MW)\": [800.0, 850.0, 730.0]\n}","category":"page"},{"location":"format/","page":"Data Format","title":"Data Format","text":"The value T depends on both Time horizon (h) and Time step (min), as the table below illustrates.","category":"page"},{"location":"format/","page":"Data Format","title":"Data Format","text":"Time horizon (h) Time step (min) T\n24 60 24\n24 15 96\n24 5 288\n36 60 36\n36 15 144\n36 5 432","category":"page"},{"location":"format/#Output-Data-Format","page":"Data Format","title":"Output Data Format","text":"","category":"section"},{"location":"format/","page":"Data Format","title":"Data Format","text":"The output data format is also JSON-based, but it is not currently documented since we expect it to change significantly in a future version of the package.","category":"page"},{"location":"format/#Current-limitations","page":"Data Format","title":"Current limitations","text":"","category":"section"},{"location":"format/","page":"Data Format","title":"Data Format","text":"Network topology remains the same for all time periods\nOnly N-1 transmission contingencies are supported. Generator contingencies are not currently supported.\nTime-varying minimum production amounts are not currently compatible with ramp/startup/shutdown limits.\nFlexible ramping products can only be acquired under the WanHob2016 formulation, which does not support spinning reserves. ","category":"page"},{"location":"#UnitCommitment.jl","page":"Home","title":"UnitCommitment.jl","text":"","category":"section"},{"location":"","page":"Home","title":"Home","text":"UnitCommitment.jl (UC.jl) is a Julia/JuMP optimization package for the Security-Constrained Unit Commitment Problem (SCUC), a fundamental optimization problem in power systems used, for example, to clear the day-ahead electricity markets. The package provides benchmark instances for the problem and Julia/JuMP implementations of state-of-the-art mixed-integer programming formulations.","category":"page"},{"location":"#Package-Components","page":"Home","title":"Package Components","text":"","category":"section"},{"location":"","page":"Home","title":"Home","text":"Data Format: The package proposes an extensible and fully-documented JSON-based data specification format for SCUC, developed in collaboration with Independent System Operators (ISOs), which describes the most important aspects of the problem. The format supports all the most common generator characteristics (including ramping, piecewise-linear production cost curves and time-dependent startup costs), as well as operating reserves, price-sensitive loads, transmission networks and contingencies.\nBenchmark Instances: The package provides a diverse collection of large-scale benchmark instances collected from the literature, converted into a common data format, and extended using data-driven methods to make them more challenging and realistic.\nModel Implementation: The package provides a Julia/JuMP implementations of state-of-the-art formulations and solution methods for SCUC, including multiple ramping formulations (ArrCon2000, MorLatRam2013, DamKucRajAta2016, PanGua2016), multiple piecewise-linear costs formulations (Gar1962, CarArr2006, KnuOstWat2018) and contingency screening methods (XavQiuWanThi2019). Our goal is to keep these implementations up-to-date as new methods are proposed in the literature.\nBenchmark Tools: The package provides automated benchmark scripts to accurately evaluate the performance impact of proposed code changes.","category":"page"},{"location":"#Table-of-Contents","page":"Home","title":"Table of Contents","text":"","category":"section"},{"location":"","page":"Home","title":"Home","text":"Pages = [\"usage.md\", \"format.md\", \"instances.md\", \"model.md\", \"api.md\"]\nDepth = 3","category":"page"},{"location":"#Authors","page":"Home","title":"Authors","text":"","category":"section"},{"location":"","page":"Home","title":"Home","text":"Alinson S. Xavier (Argonne National Laboratory)\nAleksandr M. Kazachkov (University of Florida)\nOgün Yurdakul (Technische Universität Berlin)\nFeng Qiu (Argonne National Laboratory)","category":"page"},{"location":"#Acknowledgments","page":"Home","title":"Acknowledgments","text":"","category":"section"},{"location":"","page":"Home","title":"Home","text":"We would like to thank Yonghong Chen (Midcontinent Independent System Operator), Feng Pan (Pacific Northwest National Laboratory) for valuable feedback on early versions of this package.\nBased upon work supported by Laboratory Directed Research and Development (LDRD) funding from Argonne National Laboratory, provided by the Director, Office of Science, of the U.S. Department of Energy under Contract No. DE-AC02-06CH11357\nBased upon work supported by the U.S. Department of Energy Advanced Grid Modeling Program under Grant DE-OE0000875.","category":"page"},{"location":"#Citing","page":"Home","title":"Citing","text":"","category":"section"},{"location":"","page":"Home","title":"Home","text":"If you use UnitCommitment.jl in your research (instances, models or algorithms), we kindly request that you cite the package as follows:","category":"page"},{"location":"","page":"Home","title":"Home","text":"Alinson S. Xavier, Aleksandr M. Kazachkov, Ogün Yurdakul, Feng Qiu, \"UnitCommitment.jl: A Julia/JuMP Optimization Package for Security-Constrained Unit Commitment (Version 0.3)\". Zenodo (2022). DOI: 10.5281/zenodo.4269874.","category":"page"},{"location":"","page":"Home","title":"Home","text":"If you use the instances, we additionally request that you cite the original sources, as described in the instances page.","category":"page"},{"location":"#License","page":"Home","title":"License","text":"","category":"section"},{"location":"","page":"Home","title":"Home","text":"UnitCommitment.jl: A Julia/JuMP Optimization Package for Security-Constrained Unit Commitment\nCopyright © 2020-2022, UChicago Argonne, LLC. All Rights Reserved.\n\nRedistribution and use in source and binary forms, with or without modification, are permitted\nprovided that the following conditions are met:\n\n1. Redistributions of source code must retain the above copyright notice, this list of\n   conditions and the following disclaimer.\n2. Redistributions in binary form must reproduce the above copyright notice, this list of\n   conditions and the following disclaimer in the documentation and/or other materials provided\n   with the distribution.\n3. Neither the name of the copyright holder nor the names of its contributors may be used to\n   endorse or promote products derived from this software without specific prior written\n   permission.\n\nTHIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS \"AS IS\" AND ANY EXPRESS OR\nIMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY\nAND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR\nCONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR\nCONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR\nSERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY\nTHEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR\nOTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE\nPOSSIBILITY OF SUCH DAMAGE.","category":"page"}]
}