diff --git a/0.1/404.html b/0.1/404.html
index 9f40ddd..6178a47 100644
--- a/0.1/404.html
+++ b/0.1/404.html
@@ -59,7 +59,9 @@
 
             <!-- Main title -->
 
-            <a class="navbar-brand" href="/.">UnitCommitment.jl</a>
+            
+              <a class="navbar-brand" href="/.">UnitCommitment.jl</a>
+            
         </div>
 
         <!-- Expanded navigation -->
@@ -85,6 +87,12 @@
                     </li>
                 
                 
+                
+                    <li >
+                        <a href="/instances/">Instances</a>
+                    </li>
+                
+                
                 </ul>
 
             <ul class="nav navbar-nav navbar-right">
@@ -115,18 +123,22 @@
 
     </div>
 
-    <footer class="col-md-12 text-center">
-        
-        <hr>
-        <p>
-        <small>Copyright © 2020, UChicago Argonne, LLC. All Rights Reserved.</small><br>
-        
-        <small>Documentation built with <a href="http://www.mkdocs.org/">MkDocs</a>.</small>
-        </p>
+    
+      <footer class="col-md-12 text-center">
+          
+          
+            <hr>
+            <p>
+            <small>Copyright © 2020, UChicago Argonne, LLC. All Rights Reserved.</small><br>
+            
+            <small>Documentation built with <a href="http://www.mkdocs.org/">MkDocs</a>.</small>
+            </p>
+          
 
-        
-        
-    </footer>
+          
+          
+      </footer>
+    
     <script src="//ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js"></script>
     <script src="/js/bootstrap-3.0.3.min.js"></script>
 
diff --git a/0.1/css/base.css b/0.1/css/base.css
index 7b45cbb..2d68482 100644
--- a/0.1/css/base.css
+++ b/0.1/css/base.css
@@ -1,12 +1,9 @@
-body {
-    padding-top: 70px;
+html {
+    scroll-padding-top: 70px;
 }
 
-h1[id]:before, h2[id]:before, h3[id]:before, h4[id]:before, h5[id]:before, h6[id]:before {
-    content: "";
-    display: block;
-    margin-top: -75px;
-    height: 75px;
+body {
+    padding-top: 70px;
 }
 
 p > img {
@@ -103,7 +100,8 @@ div.source-links {
     .bs-sidebar.affix {
         position: fixed; /* Undo the static from mobile first approach */
         top: 80px;
-        max-height: calc(100% - 90px);
+        max-height: calc(100% - 180px);
+        overflow-y: auto;
     }
     .bs-sidebar.affix-bottom {
         position: absolute; /* Undo the static from mobile first approach */
@@ -228,6 +226,16 @@ div.source-links {
 }
 /* End Bootstrap Callouts CSS Source by Chris Pratt */
 
+/* Headerlinks */
+.headerlink {
+    display: none;
+    padding-left: .5em;
+}
+
+h1:hover .headerlink, h2:hover .headerlink, h3:hover .headerlink, h4:hover .headerlink, h5:hover .headerlink, h6:hover .headerlink {
+    display: inline-block;
+}
+
 /* Admonitions */
 .admonition {
     padding: 20px;
diff --git a/0.1/css/base.min.css b/0.1/css/base.min.css
index c5454f8..f7e580f 100644
--- a/0.1/css/base.min.css
+++ b/0.1/css/base.min.css
@@ -1 +1 @@
-body{padding-top:70px}h1[id]:before,h2[id]:before,h3[id]:before,h4[id]:before,h5[id]:before,h6[id]:before{content:"";display:block;margin-top:-75px;height:75px}p>img{max-width:100%;height:auto}ul.nav li.first-level{font-weight:bold}ul.nav li.third-level{padding-left:12px}div.col-md-3{padding-left:0}div.col-md-9{padding-bottom:100px}div.source-links{float:right}.bs-sidebar.affix{position:static}.bs-sidebar.well{padding:0}.bs-sidenav{margin-top:30px;margin-bottom:30px;padding-top:10px;padding-bottom:10px;border-radius:5px}.bs-sidebar .nav>li>a{display:block;padding:5px 20px;z-index:1}.bs-sidebar .nav>li>a:hover,.bs-sidebar .nav>li>a:focus{text-decoration:none;border-right:1px solid}.bs-sidebar .nav>.active>a,.bs-sidebar .nav>.active:hover>a,.bs-sidebar .nav>.active:focus>a{font-weight:bold;background-color:transparent;border-right:1px solid}.bs-sidebar .nav .nav{display:none;margin-bottom:8px}.bs-sidebar .nav .nav>li>a{padding-top:3px;padding-bottom:3px;padding-left:30px;font-size:90%}@media(min-width:992px){.bs-sidebar .nav>.active>ul{display:block}.bs-sidebar.affix,.bs-sidebar.affix-bottom{width:213px}.bs-sidebar.affix{position:fixed;top:80px;max-height:calc(100% - 90px)}.bs-sidebar.affix-bottom{position:absolute}.bs-sidebar.affix-bottom .bs-sidenav,.bs-sidebar.affix .bs-sidenav{margin-top:0;margin-bottom:0}}@media(min-width:1200px){.bs-sidebar.affix-bottom,.bs-sidebar.affix{width:263px}}.dropdown-submenu{position:relative}.dropdown-submenu>.dropdown-menu{top:0;left:100%;margin-top:0;margin-left:0}.dropdown-submenu:hover>.dropdown-menu{display:block}.dropdown-submenu>a:after{display:block;content:" ";float:right;width:0;height:0;border-color:transparent;border-style:solid;border-width:5px 0 5px 5px;border-left-color:#ccc;margin-top:5px;margin-right:-10px}.dropdown-submenu:hover>a:after{border-left-color:#fff}.dropdown-submenu.pull-left{float:none}.dropdown-submenu.pull-left>.dropdown-menu{left:-100%;margin-left:00px}.bs-callout{padding:20px;margin:20px 0;border:1px solid #eee;border-left-width:5px;border-radius:3px;background-color:#fcfdff}.bs-callout h4{font-style:normal;font-weight:400;margin-top:0;margin-bottom:5px}.bs-callout p:last-child{margin-bottom:0}.bs-callout code{border-radius:3px}.bs-callout+.bs-callout{margin-top:-5px}.bs-callout-default{border-left-color:#fa023c}.bs-callout-default h4{color:#fa023c}.bs-callout-primary{border-left-color:#428bca}.bs-callout-primary h4{color:#428bca}.bs-callout-success{border-left-color:#5cb85c}.bs-callout-success h4{color:#5cb85c}.bs-callout-danger{border-left-color:#d9534f}.bs-callout-danger h4{color:#d9534f}.bs-callout-warning{border-left-color:#f0ad4e}.bs-callout-warning h4{color:#f0ad4e}.bs-callout-info{border-left-color:#5bc0de}.bs-callout-info h4{color:#5bc0de}.admonition{padding:20px;margin:20px 0;border:1px solid #eee;border-left-width:5px;border-radius:3px;background-color:#fcfdff}.admonition p:last-child{margin-bottom:0}.admonition code{border-radius:3px}.admonition+.admonition{margin-top:-5px}.admonition.note{border-left-color:#428bca}.admonition.warning{border-left-color:#f0ad4e}.admonition.danger{border-left-color:#d9534f}.admonition-title{font-size:19px;font-style:normal;font-weight:400;margin-top:0;margin-bottom:5px}.admonition.note>.admonition-title{color:#428bca}.admonition.warning>.admonition-title{color:#f0ad4e}.admonition.danger>.admonition-title{color:#d9534f}
+html{scroll-padding-top:70px}body{padding-top:70px}p>img{max-width:100%;height:auto}ul.nav li.first-level{font-weight:bold}ul.nav li.third-level{padding-left:12px}div.col-md-3{padding-left:0}div.col-md-9{padding-bottom:100px}div.source-links{float:right}.bs-sidebar.affix{position:static}.bs-sidebar.well{padding:0}.bs-sidenav{margin-top:30px;margin-bottom:30px;padding-top:10px;padding-bottom:10px;border-radius:5px}.bs-sidebar .nav>li>a{display:block;padding:5px 20px;z-index:1}.bs-sidebar .nav>li>a:hover,.bs-sidebar .nav>li>a:focus{text-decoration:none;border-right:1px solid}.bs-sidebar .nav>.active>a,.bs-sidebar .nav>.active:hover>a,.bs-sidebar .nav>.active:focus>a{font-weight:bold;background-color:transparent;border-right:1px solid}.bs-sidebar .nav .nav{display:none;margin-bottom:8px}.bs-sidebar .nav .nav>li>a{padding-top:3px;padding-bottom:3px;padding-left:30px;font-size:90%}@media(min-width:992px){.bs-sidebar .nav>.active>ul{display:block}.bs-sidebar.affix,.bs-sidebar.affix-bottom{width:213px}.bs-sidebar.affix{position:fixed;top:80px;max-height:calc(100% - 180px);overflow-y:auto}.bs-sidebar.affix-bottom{position:absolute}.bs-sidebar.affix-bottom .bs-sidenav,.bs-sidebar.affix .bs-sidenav{margin-top:0;margin-bottom:0}}@media(min-width:1200px){.bs-sidebar.affix-bottom,.bs-sidebar.affix{width:263px}}.dropdown-submenu{position:relative}.dropdown-submenu>.dropdown-menu{top:0;left:100%;margin-top:0;margin-left:0}.dropdown-submenu:hover>.dropdown-menu{display:block}.dropdown-submenu>a:after{display:block;content:" ";float:right;width:0;height:0;border-color:transparent;border-style:solid;border-width:5px 0 5px 5px;border-left-color:#ccc;margin-top:5px;margin-right:-10px}.dropdown-submenu:hover>a:after{border-left-color:#fff}.dropdown-submenu.pull-left{float:none}.dropdown-submenu.pull-left>.dropdown-menu{left:-100%;margin-left:00px}.bs-callout{padding:20px;margin:20px 0;border:1px solid #eee;border-left-width:5px;border-radius:3px;background-color:#fcfdff}.bs-callout h4{font-style:normal;font-weight:400;margin-top:0;margin-bottom:5px}.bs-callout p:last-child{margin-bottom:0}.bs-callout code{border-radius:3px}.bs-callout+.bs-callout{margin-top:-5px}.bs-callout-default{border-left-color:#fa023c}.bs-callout-default h4{color:#fa023c}.bs-callout-primary{border-left-color:#428bca}.bs-callout-primary h4{color:#428bca}.bs-callout-success{border-left-color:#5cb85c}.bs-callout-success h4{color:#5cb85c}.bs-callout-danger{border-left-color:#d9534f}.bs-callout-danger h4{color:#d9534f}.bs-callout-warning{border-left-color:#f0ad4e}.bs-callout-warning h4{color:#f0ad4e}.bs-callout-info{border-left-color:#5bc0de}.bs-callout-info h4{color:#5bc0de}.headerlink{display:none;padding-left:.5em}h1:hover .headerlink,h2:hover .headerlink,h3:hover .headerlink,h4:hover .headerlink,h5:hover .headerlink,h6:hover .headerlink{display:inline-block}.admonition{padding:20px;margin:20px 0;border:1px solid #eee;border-left-width:5px;border-radius:3px;background-color:#fcfdff}.admonition p:last-child{margin-bottom:0}.admonition code{border-radius:3px}.admonition+.admonition{margin-top:-5px}.admonition.note{border-left-color:#428bca}.admonition.warning{border-left-color:#f0ad4e}.admonition.danger{border-left-color:#d9534f}.admonition-title{font-size:19px;font-style:normal;font-weight:400;margin-top:0;margin-bottom:5px}.admonition.note>.admonition-title{color:#428bca}.admonition.warning>.admonition-title{color:#f0ad4e}.admonition.danger>.admonition-title{color:#d9534f}
diff --git a/0.1/format/index.html b/0.1/format/index.html
index 003e998..c513c5c 100644
--- a/0.1/format/index.html
+++ b/0.1/format/index.html
@@ -59,7 +59,9 @@
 
             <!-- Main title -->
 
-            <a class="navbar-brand" href="..">UnitCommitment.jl</a>
+            
+              <a class="navbar-brand" href="..">UnitCommitment.jl</a>
+            
         </div>
 
         <!-- Expanded navigation -->
@@ -85,6 +87,12 @@
                     </li>
                 
                 
+                
+                    <li >
+                        <a href="../instances/">Instances</a>
+                    </li>
+                
+                
                 </ul>
 
             <ul class="nav navbar-nav navbar-right">
@@ -98,8 +106,8 @@
                             <i class="fas fa-arrow-left"></i> Previous
                         </a>
                     </li>
-                    <li class="disabled">
-                        <a rel="next" >
+                    <li >
+                        <a rel="next" href="../instances/">
                             Next <i class="fas fa-arrow-right"></i>
                         </a>
                     </li>
@@ -173,14 +181,13 @@
 </tbody>
 </table>
 <h4 id="example">Example</h4>
-<pre><code class="json">{
+<pre><code class="language-json">{
     &quot;Parameters&quot;: {
         &quot;Time (h)&quot;: 4,
         &quot;Power balance penalty ($/MW)&quot;: 1000.0
     }
 }
 </code></pre>
-
 <h3 id="12-buses">1.2 Buses</h3>
 <p>This section describes the characteristics of each bus in the system. </p>
 <table>
@@ -202,7 +209,7 @@
 </tbody>
 </table>
 <h4 id="example_1">Example</h4>
-<pre><code class="json">{
+<pre><code class="language-json">{
     &quot;Buses&quot;: {
         &quot;b1&quot;: {
             &quot;Load (MW)&quot;: 0.0
@@ -218,7 +225,6 @@
     }
 }
 </code></pre>
-
 <h3 id="13-generators">1.3 Generators</h3>
 <p>This section describes all generators in the system, including thermal units, renewable units and virtual units.</p>
 <table>
@@ -327,7 +333,7 @@ Note that this curve also specifies the production limits. Specifically, the fir
 <li>Production cost curves must be convex.</li>
 </ul>
 <h4 id="example_2">Example</h4>
-<pre><code class="json">{
+<pre><code class="language-json">{
     &quot;Generators&quot;: {
         &quot;gen1&quot;: {
             &quot;Bus&quot;: &quot;b1&quot;,
@@ -354,7 +360,6 @@ Note that this curve also specifies the production limits. Specifically, the fir
     }
 }
 </code></pre>
-
 <h3 id="14-price-sensitive-loads">1.4 Price-sensitive loads</h3>
 <p>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 <code>buses</code> 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. </p>
 <table>
@@ -388,7 +393,7 @@ Note that this curve also specifies the production limits. Specifically, the fir
 </tbody>
 </table>
 <h4 id="example_3">Example</h4>
-<pre><code class="json">{
+<pre><code class="language-json">{
     &quot;Price-sensitive loads&quot;: {
         &quot;p1&quot;: {
             &quot;Bus&quot;: &quot;b3&quot;,
@@ -398,7 +403,6 @@ Note that this curve also specifies the production limits. Specifically, the fir
     }
 }
 </code></pre>
-
 <h3 id="15-transmission-lines">1.5 Transmission Lines</h3>
 <p>This section describes the characteristics of transmission system, such as its topology and the susceptance of each transmission line.</p>
 <table>
@@ -456,7 +460,7 @@ Note that this curve also specifies the production limits. Specifically, the fir
 </tbody>
 </table>
 <h4 id="example_4">Example</h4>
-<pre><code class="json">{
+<pre><code class="language-json">{
     &quot;Transmission lines&quot;: {
         &quot;l1&quot;: {
             &quot;Source bus&quot;: &quot;b1&quot;,
@@ -470,7 +474,6 @@ Note that this curve also specifies the production limits. Specifically, the fir
     }
 }
 </code></pre>
-
 <h3 id="16-reserves">1.6 Reserves</h3>
 <p>This section describes the hourly amount of operating reserves required.</p>
 <table>
@@ -492,7 +495,7 @@ Note that this curve also specifies the production limits. Specifically, the fir
 </tbody>
 </table>
 <h4 id="example_5">Example</h4>
-<pre><code class="json">{
+<pre><code class="language-json">{
     &quot;Reserves&quot;: {
         &quot;Spinning (MW)&quot;: [
             57.30552,
@@ -503,7 +506,6 @@ Note that this curve also specifies the production limits. Specifically, the fir
     }
 }
 </code></pre>
-
 <h3 id="17-contingencies">1.7 Contingencies</h3>
 <p>This section describes credible contingency scenarios in the optimization, such as the loss of a transmission line or generator.</p>
 <table>
@@ -528,7 +530,7 @@ Note that this curve also specifies the production limits. Specifically, the fir
 </tbody>
 </table>
 <h4 id="example_6">Example</h4>
-<pre><code class="json">{
+<pre><code class="language-json">{
     &quot;Contingencies&quot;: {
         &quot;c1&quot;: {
             &quot;Affected lines&quot;: [&quot;l1&quot;, &quot;l2&quot;, &quot;l3&quot;],
@@ -540,16 +542,14 @@ Note that this curve also specifies the production limits. Specifically, the fir
     }
 }
 </code></pre>
-
 <h3 id="18-additional-remarks">1.8 Additional remarks</h3>
 <h4 id="time-series-parameters">Time series parameters</h4>
 <p>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 <code>T</code> elements, where <code>T</code> is the length of the planning horizon, if they are time-dependent. For example, both formats below are valid when <code>T=3</code>:</p>
-<pre><code class="json">{
+<pre><code class="language-json">{
     &quot;Load (MW)&quot;: 800.0,
     &quot;Load (MW)&quot;: [800.0, 850.0, 730.0]
 }
 </code></pre>
-
 <h4 id="current-limitations">Current limitations</h4>
 <ul>
 <li>All reserves are system-wide (no zonal reserves)</li>
@@ -563,18 +563,22 @@ Note that this curve also specifies the production limits. Specifically, the fir
         
     </div>
 
-    <footer class="col-md-12 text-center">
-        
-        <hr>
-        <p>
-        <small>Copyright © 2020, UChicago Argonne, LLC. All Rights Reserved.</small><br>
-        
-        <small>Documentation built with <a href="http://www.mkdocs.org/">MkDocs</a>.</small>
-        </p>
+    
+      <footer class="col-md-12 text-center">
+          
+          
+            <hr>
+            <p>
+            <small>Copyright © 2020, UChicago Argonne, LLC. All Rights Reserved.</small><br>
+            
+            <small>Documentation built with <a href="http://www.mkdocs.org/">MkDocs</a>.</small>
+            </p>
+          
 
-        
-        
-    </footer>
+          
+          
+      </footer>
+    
     <script src="//ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js"></script>
     <script src="../js/bootstrap-3.0.3.min.js"></script>
 
diff --git a/0.1/index.html b/0.1/index.html
index 4849635..476668a 100644
--- a/0.1/index.html
+++ b/0.1/index.html
@@ -59,7 +59,9 @@
 
             <!-- Main title -->
 
-            <a class="navbar-brand" href=".">UnitCommitment.jl</a>
+            
+              <a class="navbar-brand" href=".">UnitCommitment.jl</a>
+            
         </div>
 
         <!-- Expanded navigation -->
@@ -85,6 +87,12 @@
                     </li>
                 
                 
+                
+                    <li >
+                        <a href="instances/">Instances</a>
+                    </li>
+                
+                
                 </ul>
 
             <ul class="nav navbar-nav navbar-right">
@@ -127,6 +135,8 @@
                 
             <li class="second-level"><a href="#acknowledgments">Acknowledgments</a></li>
                 
+            <li class="second-level"><a href="#citing">Citing</a></li>
+                
             <li class="second-level"><a href="#license">License</a></li>
                 
     </ul>
@@ -146,6 +156,7 @@
 <ul>
 <li><a href="usage/">Usage</a></li>
 <li><a href="format/">Data Format</a></li>
+<li><a href="instances/">Instances</a></li>
 </ul>
 <h3 id="source-code">Source code</h3>
 <ul>
@@ -165,24 +176,34 @@
 <p>Based upon work supported by <strong>Laboratory Directed Research and Development</strong> (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.</p>
 </li>
 </ul>
+<h3 id="citing">Citing</h3>
+<p>If you use UnitCommitment.jl in your research, we request that you cite the package as follows:</p>
+<ul>
+<li>Alinson S. Xavier, Feng Qiu, "UnitCommitment.jl: A Julia/JuMP Optimization Package for Security-Constrained Unit Commitment". Zenodo (2020). <a href="https://doi.org/10.5281/zenodo.4269874">DOI: 10.5281/zenodo.4269874</a>.</li>
+</ul>
+<p>If you make use of the provided instances files, we request that you additionally cite the original sources, as described in the <a href="instances/">instances page</a>.</p>
 <h3 id="license">License</h3>
 <p>Released under the modified BSD license. See <code>LICENSE.md</code> for more details.</p></div>
         
         
     </div>
 
-    <footer class="col-md-12 text-center">
-        
-        <hr>
-        <p>
-        <small>Copyright © 2020, UChicago Argonne, LLC. All Rights Reserved.</small><br>
-        
-        <small>Documentation built with <a href="http://www.mkdocs.org/">MkDocs</a>.</small>
-        </p>
+    
+      <footer class="col-md-12 text-center">
+          
+          
+            <hr>
+            <p>
+            <small>Copyright © 2020, UChicago Argonne, LLC. All Rights Reserved.</small><br>
+            
+            <small>Documentation built with <a href="http://www.mkdocs.org/">MkDocs</a>.</small>
+            </p>
+          
 
-        
-        
-    </footer>
+          
+          
+      </footer>
+    
     <script src="//ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js"></script>
     <script src="js/bootstrap-3.0.3.min.js"></script>
 
@@ -273,5 +294,5 @@
 
 <!--
 MkDocs version : 1.1.2
-Build Date UTC : 2020-11-06 19:44:10.310639+00:00
+Build Date UTC : 2020-11-13 17:20:05.182767+00:00
 -->
diff --git a/0.1/instances/index.html b/0.1/instances/index.html
new file mode 100644
index 0000000..017ae66
--- /dev/null
+++ b/0.1/instances/index.html
@@ -0,0 +1,1143 @@
+<!DOCTYPE html>
+<html lang="en">
+
+<head>
+    <meta charset="utf-8">
+    <meta http-equiv="X-UA-Compatible" content="IE=edge">
+    <meta name="viewport" content="width=device-width, initial-scale=1.0">
+    
+    
+    
+    <link rel="shortcut icon" href="../img/favicon.ico">
+
+    
+    <title>Instances - UnitCommitment.jl</title>
+    
+
+    <link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.12.0/css/all.css">
+    <link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.12.0/css/v4-shims.css">
+    <link rel="stylesheet" href="//cdn.jsdelivr.net/npm/hack-font@3.3.0/build/web/hack.min.css">
+    <link href='//rsms.me/inter/inter.css' rel='stylesheet' type='text/css'>
+    <link href='//fonts.googleapis.com/css?family=Open+Sans:300italic,400italic,700italic,400,300,600,700&subset=latin-ext,latin' rel='stylesheet' type='text/css'>
+    <link href="../css/bootstrap-custom.min.css" rel="stylesheet">
+    <link href="../css/base.min.css" rel="stylesheet">
+    <link href="../css/cinder.min.css" rel="stylesheet">
+
+    
+        
+        <link rel="stylesheet" href="//cdn.jsdelivr.net/gh/highlightjs/cdn-release@9.18.0/build/styles/github.min.css">
+        
+    
+    <link href="../css/custom.css" rel="stylesheet">
+
+    <!-- HTML5 shim and Respond.js IE8 support of HTML5 elements and media queries -->
+    <!--[if lt IE 9]>
+            <script src="https://cdn.jsdelivr.net/npm/html5shiv@3.7.3/dist/html5shiv.min.js"></script>
+            <script src="https://cdn.jsdelivr.net/npm/respond.js@1.4.2/dest/respond.min.js"></script>
+        <![endif]-->
+
+    
+
+     
+</head>
+
+<body>
+
+    <div class="navbar navbar-default navbar-fixed-top" role="navigation">
+    <div class="container">
+
+        <!-- Collapsed navigation -->
+        <div class="navbar-header">
+            <!-- Expander button -->
+            <button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".navbar-collapse">
+                <span class="sr-only">Toggle navigation</span>
+                <span class="icon-bar"></span>
+                <span class="icon-bar"></span>
+                <span class="icon-bar"></span>
+            </button>
+            
+
+            <!-- Main title -->
+
+            
+              <a class="navbar-brand" href="..">UnitCommitment.jl</a>
+            
+        </div>
+
+        <!-- Expanded navigation -->
+        <div class="navbar-collapse collapse">
+                <!-- Main navigation -->
+                <ul class="nav navbar-nav">
+                
+                
+                    <li >
+                        <a href="..">Home</a>
+                    </li>
+                
+                
+                
+                    <li >
+                        <a href="../usage/">Usage</a>
+                    </li>
+                
+                
+                
+                    <li >
+                        <a href="../format/">Format</a>
+                    </li>
+                
+                
+                
+                    <li class="active">
+                        <a href="./">Instances</a>
+                    </li>
+                
+                
+                </ul>
+
+            <ul class="nav navbar-nav navbar-right">
+                    <li>
+                        <a href="#" data-toggle="modal" data-target="#mkdocs_search_modal">
+                            <i class="fas fa-search"></i> Search
+                        </a>
+                    </li>
+                    <li >
+                        <a rel="prev" href="../format/">
+                            <i class="fas fa-arrow-left"></i> Previous
+                        </a>
+                    </li>
+                    <li class="disabled">
+                        <a rel="next" >
+                            Next <i class="fas fa-arrow-right"></i>
+                        </a>
+                    </li>
+                    <li>
+                        <a href="https://github.com/ANL-CEEESA/unitcommitment.jl/edit/dev/src/docs/instances.md"><i class="fab fa-github"></i> Edit on GitHub</a>
+                    </li>
+            </ul>
+        </div>
+    </div>
+</div>
+
+    <div class="container">
+        
+        
+        <div class="col-md-3"><div class="bs-sidebar hidden-print affix well" role="complementary">
+    <ul class="nav bs-sidenav">
+        <li class="first-level active"><a href="#instances">Instances</a></li>
+            <li class="second-level"><a href="#1-pglib-uc-instances">1. PGLIB-UC Instances</a></li>
+                
+                <li class="third-level"><a href="#11-pglib-uccalifornia">1.1 PGLIB-UC/California</a></li>
+                <li class="third-level"><a href="#12-pglib-ucferc">1.2 PGLIB-UC/FERC</a></li>
+                <li class="third-level"><a href="#13-pglib-ucrts-gmlc">1.3 PGLIB-UC/RTS-GMLC</a></li>
+            <li class="second-level"><a href="#2-matpower">2. MATPOWER</a></li>
+                
+                <li class="third-level"><a href="#21-matpoweruw-pstca">2.1 MATPOWER/UW-PSTCA</a></li>
+                <li class="third-level"><a href="#22-matpowerpolish">2.2 MATPOWER/Polish</a></li>
+                <li class="third-level"><a href="#23-matpowerpegase">2.3 MATPOWER/PEGASE</a></li>
+            <li class="second-level"><a href="#3-references">3. References</a></li>
+                
+    </ul>
+</div></div>
+        <div class="col-md-9" role="main">
+
+<h1 id="instances">Instances</h1>
+<p>UnitCommitment.jl provides a collection of large-scale benchmark instances collected
+from the literature in a <a href="../format/">standard data format</a> and, in some cases, extended with realistic unit commitment data, produced by 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).</p>
+<p>Raw instances files are <a href="https://github.com/ANL-CEEESA/UnitCommitment.jl/tree/dev/instances">available at our GitHub repository</a>. Benchmark instances can also be loaded with
+<code>UnitCommitment.read_benchmark(name)</code>, as explained in the <a href="../usage/">usage section</a>, where <code>name</code> is one of the names below.</p>
+<h2 id="1-pglib-uc-instances">1. PGLIB-UC Instances</h2>
+<p><a href="https://github.com/power-grid-lib/pglib-uc">PGLIB-UC</a> is a benchmark library curated and maintained by the <a href="https://power-grid-lib.github.io/">IEEE PES Task Force on Benchmarks for Validation of Emerging Power System Algorithms</a>.</p>
+<h3 id="11-pglib-uccalifornia">1.1 PGLIB-UC/California</h3>
+<p>Test cases based on publicly available data from the California ISO. For more details, see <a href="https://github.com/power-grid-lib/pglib-uc">PGLIB-UC case file overview</a>.</p>
+<table>
+<thead>
+<tr>
+<th>Name</th>
+<th>Buses</th>
+<th>Generators</th>
+<th>Lines</th>
+<th>Contingencies</th>
+<th>References</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td><code>pglib-uc/ca/2014-09-01_reserves_0</code></td>
+<td>1</td>
+<td>610</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18], [KrHiOn12]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ca/2014-09-01_reserves_1</code></td>
+<td>1</td>
+<td>610</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18], [KrHiOn12]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ca/2014-09-01_reserves_3</code></td>
+<td>1</td>
+<td>610</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18], [KrHiOn12]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ca/2014-09-01_reserves_5</code></td>
+<td>1</td>
+<td>610</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18], [KrHiOn12]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ca/2014-12-01_reserves_0</code></td>
+<td>1</td>
+<td>610</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18], [KrHiOn12]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ca/2014-12-01_reserves_1</code></td>
+<td>1</td>
+<td>610</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18], [KrHiOn12]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ca/2014-12-01_reserves_3</code></td>
+<td>1</td>
+<td>610</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18], [KrHiOn12]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ca/2014-12-01_reserves_5</code></td>
+<td>1</td>
+<td>610</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18], [KrHiOn12]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ca/2015-03-01_reserves_0</code></td>
+<td>1</td>
+<td>610</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18], [KrHiOn12]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ca/2015-03-01_reserves_1</code></td>
+<td>1</td>
+<td>610</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18], [KrHiOn12]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ca/2015-03-01_reserves_3</code></td>
+<td>1</td>
+<td>610</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18], [KrHiOn12]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ca/2015-03-01_reserves_5</code></td>
+<td>1</td>
+<td>610</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18], [KrHiOn12]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ca/2015-06-01_reserves_0</code></td>
+<td>1</td>
+<td>610</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18], [KrHiOn12]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ca/2015-06-01_reserves_1</code></td>
+<td>1</td>
+<td>610</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18], [KrHiOn12]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ca/2015-06-01_reserves_3</code></td>
+<td>1</td>
+<td>610</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18], [KrHiOn12]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ca/2015-06-01_reserves_5</code></td>
+<td>1</td>
+<td>610</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18], [KrHiOn12]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ca/Scenario400_reserves_0</code></td>
+<td>1</td>
+<td>611</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18], [KrHiOn12]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ca/Scenario400_reserves_1</code></td>
+<td>1</td>
+<td>611</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18], [KrHiOn12]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ca/Scenario400_reserves_3</code></td>
+<td>1</td>
+<td>611</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18], [KrHiOn12]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ca/Scenario400_reserves_5</code></td>
+<td>1</td>
+<td>611</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18], [KrHiOn12]</td>
+</tr>
+</tbody>
+</table>
+<h3 id="12-pglib-ucferc">1.2 PGLIB-UC/FERC</h3>
+<p>Test cases based on publicly available unit commitment test instance from the Federal Energy Regulatory Commission. For more details, see <a href="https://github.com/power-grid-lib/pglib-uc">PGLIB-UC case file overview</a>.</p>
+<table>
+<thead>
+<tr>
+<th>Name</th>
+<th>Buses</th>
+<th>Generators</th>
+<th>Lines</th>
+<th>Contingencies</th>
+<th>References</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td><code>pglib-uc/ferc/2015-01-01_hw</code></td>
+<td>1</td>
+<td>935</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ferc/2015-01-01_lw</code></td>
+<td>1</td>
+<td>935</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ferc/2015-02-01_hw</code></td>
+<td>1</td>
+<td>935</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ferc/2015-02-01_lw</code></td>
+<td>1</td>
+<td>935</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ferc/2015-03-01_hw</code></td>
+<td>1</td>
+<td>935</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ferc/2015-03-01_lw</code></td>
+<td>1</td>
+<td>935</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ferc/2015-04-01_hw</code></td>
+<td>1</td>
+<td>979</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ferc/2015-04-01_lw</code></td>
+<td>1</td>
+<td>979</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ferc/2015-05-01_hw</code></td>
+<td>1</td>
+<td>979</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ferc/2015-05-01_lw</code></td>
+<td>1</td>
+<td>979</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ferc/2015-06-01_hw</code></td>
+<td>1</td>
+<td>979</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ferc/2015-06-01_lw</code></td>
+<td>1</td>
+<td>979</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ferc/2015-07-01_hw</code></td>
+<td>1</td>
+<td>979</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ferc/2015-07-01_lw</code></td>
+<td>1</td>
+<td>979</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ferc/2015-08-01_hw</code></td>
+<td>1</td>
+<td>979</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ferc/2015-08-01_lw</code></td>
+<td>1</td>
+<td>979</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ferc/2015-09-01_hw</code></td>
+<td>1</td>
+<td>979</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ferc/2015-09-01_lw</code></td>
+<td>1</td>
+<td>979</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ferc/2015-10-01_hw</code></td>
+<td>1</td>
+<td>935</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ferc/2015-10-01_lw</code></td>
+<td>1</td>
+<td>935</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ferc/2015-11-02_hw</code></td>
+<td>1</td>
+<td>935</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ferc/2015-11-02_lw</code></td>
+<td>1</td>
+<td>935</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ferc/2015-12-01_hw</code></td>
+<td>1</td>
+<td>935</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/ferc/2015-12-01_lw</code></td>
+<td>1</td>
+<td>935</td>
+<td>0</td>
+<td>0</td>
+<td>[KnOsWa18]</td>
+</tr>
+</tbody>
+</table>
+<h3 id="13-pglib-ucrts-gmlc">1.3 PGLIB-UC/RTS-GMLC</h3>
+<p><a href="https://github.com/GridMod/RTS-GMLC">RTS-GMLC</a> is an updated version of the RTS-96 test system produced by the United States Department of Energy's <a href="https://gmlc.doe.gov/">Grid Modernization Laboratory Consortium</a>. 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 <a href="https://github.com/power-grid-lib/pglib-uc">PGLIB-UC case file overview</a>.</p>
+<table>
+<thead>
+<tr>
+<th>Name</th>
+<th>Buses</th>
+<th>Generators</th>
+<th>Lines</th>
+<th>Contingencies</th>
+<th>References</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td><code>pglib-uc/rts_gmlc/2020-01-27</code></td>
+<td>1</td>
+<td>154</td>
+<td>0</td>
+<td>0</td>
+<td>[BaBlEh19]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/rts_gmlc/2020-02-09</code></td>
+<td>1</td>
+<td>154</td>
+<td>0</td>
+<td>0</td>
+<td>[BaBlEh19]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/rts_gmlc/2020-03-05</code></td>
+<td>1</td>
+<td>154</td>
+<td>0</td>
+<td>0</td>
+<td>[BaBlEh19]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/rts_gmlc/2020-04-03</code></td>
+<td>1</td>
+<td>154</td>
+<td>0</td>
+<td>0</td>
+<td>[BaBlEh19]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/rts_gmlc/2020-05-05</code></td>
+<td>1</td>
+<td>154</td>
+<td>0</td>
+<td>0</td>
+<td>[BaBlEh19]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/rts_gmlc/2020-06-09</code></td>
+<td>1</td>
+<td>154</td>
+<td>0</td>
+<td>0</td>
+<td>[BaBlEh19]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/rts_gmlc/2020-07-06</code></td>
+<td>1</td>
+<td>154</td>
+<td>0</td>
+<td>0</td>
+<td>[BaBlEh19]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/rts_gmlc/2020-08-12</code></td>
+<td>1</td>
+<td>154</td>
+<td>0</td>
+<td>0</td>
+<td>[BaBlEh19]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/rts_gmlc/2020-09-20</code></td>
+<td>1</td>
+<td>154</td>
+<td>0</td>
+<td>0</td>
+<td>[BaBlEh19]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/rts_gmlc/2020-10-27</code></td>
+<td>1</td>
+<td>154</td>
+<td>0</td>
+<td>0</td>
+<td>[BaBlEh19]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/rts_gmlc/2020-11-25</code></td>
+<td>1</td>
+<td>154</td>
+<td>0</td>
+<td>0</td>
+<td>[BaBlEh19]</td>
+</tr>
+<tr>
+<td><code>pglib-uc/rts_gmlc/2020-12-23</code></td>
+<td>1</td>
+<td>154</td>
+<td>0</td>
+<td>0</td>
+<td>[BaBlEh19]</td>
+</tr>
+</tbody>
+</table>
+<h2 id="2-matpower">2. MATPOWER</h2>
+<p><a href="https://github.com/MATPOWER/matpower">MATPOWER</a> 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.</p>
+<p>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:</p>
+<ul>
+<li>
+<p><strong>Production cost</strong> 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.</p>
+</li>
+<li>
+<p><strong>Load profiles</strong> were generated using a similar data-driven approach.</p>
+</li>
+<li>
+<p><strong>Ramp-up, ramp-down, startup and shutdown rates</strong> were set to fixed proportion of the generator's maximum output.</p>
+</li>
+<li>
+<p><strong>Minimum reserves</strong> were set to a fixed proportion of the total demand.</p>
+</li>
+<li>
+<p><strong>Contingencies</strong> 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.</p>
+</li>
+</ul>
+<p>For each MATPOWER test case, UC.jl provides two variations (<code>2017-02-01</code> and <code>2017-08-01</code>) corresponding respectively to a winter and to a summer test case.</p>
+<h3 id="21-matpoweruw-pstca">2.1 MATPOWER/UW-PSTCA</h3>
+<p>A variety of smaller IEEE test cases, <a href="http://labs.ece.uw.edu/pstca/">compiled by University of Wisconsin</a>, corresponding mostly to small portions of the American Electric Power System in the 1960s.</p>
+<table>
+<thead>
+<tr>
+<th>Name</th>
+<th>Buses</th>
+<th>Generators</th>
+<th>Lines</th>
+<th>Contingencies</th>
+<th>References</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td><code>matpower/case14/2017-02-01</code></td>
+<td>14</td>
+<td>5</td>
+<td>20</td>
+<td>19</td>
+<td>[ZiMSTh11], [PSTCA]</td>
+</tr>
+<tr>
+<td><code>matpower/case14/2017-08-01</code></td>
+<td>14</td>
+<td>5</td>
+<td>20</td>
+<td>19</td>
+<td>[ZiMSTh11], [PSTCA]</td>
+</tr>
+<tr>
+<td><code>matpower/case30/2017-02-01</code></td>
+<td>30</td>
+<td>6</td>
+<td>41</td>
+<td>38</td>
+<td>[ZiMSTh11], [PSTCA]</td>
+</tr>
+<tr>
+<td><code>matpower/case30/2017-08-01</code></td>
+<td>30</td>
+<td>6</td>
+<td>41</td>
+<td>38</td>
+<td>[ZiMSTh11], [PSTCA]</td>
+</tr>
+<tr>
+<td><code>matpower/case57/2017-02-01</code></td>
+<td>57</td>
+<td>7</td>
+<td>80</td>
+<td>79</td>
+<td>[ZiMSTh11], [PSTCA]</td>
+</tr>
+<tr>
+<td><code>matpower/case57/2017-08-01</code></td>
+<td>57</td>
+<td>7</td>
+<td>80</td>
+<td>79</td>
+<td>[ZiMSTh11], [PSTCA]</td>
+</tr>
+<tr>
+<td><code>matpower/case118/2017-02-01</code></td>
+<td>118</td>
+<td>54</td>
+<td>186</td>
+<td>177</td>
+<td>[ZiMSTh11], [PSTCA]</td>
+</tr>
+<tr>
+<td><code>matpower/case118/2017-08-01</code></td>
+<td>118</td>
+<td>54</td>
+<td>186</td>
+<td>177</td>
+<td>[ZiMSTh11], [PSTCA]</td>
+</tr>
+<tr>
+<td><code>matpower/case300/2017-02-01</code></td>
+<td>300</td>
+<td>69</td>
+<td>411</td>
+<td>320</td>
+<td>[ZiMSTh11], [PSTCA]</td>
+</tr>
+<tr>
+<td><code>matpower/case300/2017-08-01</code></td>
+<td>300</td>
+<td>69</td>
+<td>411</td>
+<td>320</td>
+<td>[ZiMSTh11], [PSTCA]</td>
+</tr>
+</tbody>
+</table>
+<h3 id="22-matpowerpolish">2.2 MATPOWER/Polish</h3>
+<p>Test cases based on the Polish 400, 220 and 110 kV networks, originally provided by <strong>Roman Korab</strong> (Politechnika Śląska) and corrected by the MATPOWER team.</p>
+<table>
+<thead>
+<tr>
+<th>Name</th>
+<th>Buses</th>
+<th>Generators</th>
+<th>Lines</th>
+<th>Contingencies</th>
+<th>References</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td><code>matpower/case2383wp/2017-02-01</code></td>
+<td>2383</td>
+<td>323</td>
+<td>2896</td>
+<td>2240</td>
+<td>[ZiMSTh11]</td>
+</tr>
+<tr>
+<td><code>matpower/case2383wp/2017-08-01</code></td>
+<td>2383</td>
+<td>323</td>
+<td>2896</td>
+<td>2240</td>
+<td>[ZiMSTh11]</td>
+</tr>
+<tr>
+<td><code>matpower/case2736sp/2017-02-01</code></td>
+<td>2736</td>
+<td>289</td>
+<td>3504</td>
+<td>3159</td>
+<td>[ZiMSTh11]</td>
+</tr>
+<tr>
+<td><code>matpower/case2736sp/2017-08-01</code></td>
+<td>2736</td>
+<td>289</td>
+<td>3504</td>
+<td>3159</td>
+<td>[ZiMSTh11]</td>
+</tr>
+<tr>
+<td><code>matpower/case2737sop/2017-02-01</code></td>
+<td>2737</td>
+<td>267</td>
+<td>3506</td>
+<td>3161</td>
+<td>[ZiMSTh11]</td>
+</tr>
+<tr>
+<td><code>matpower/case2737sop/2017-08-01</code></td>
+<td>2737</td>
+<td>267</td>
+<td>3506</td>
+<td>3161</td>
+<td>[ZiMSTh11]</td>
+</tr>
+<tr>
+<td><code>matpower/case2746wop/2017-02-01</code></td>
+<td>2746</td>
+<td>443</td>
+<td>3514</td>
+<td>3155</td>
+<td>[ZiMSTh11]</td>
+</tr>
+<tr>
+<td><code>matpower/case2746wop/2017-08-01</code></td>
+<td>2746</td>
+<td>443</td>
+<td>3514</td>
+<td>3155</td>
+<td>[ZiMSTh11]</td>
+</tr>
+<tr>
+<td><code>matpower/case2746wp/2017-02-01</code></td>
+<td>2746</td>
+<td>457</td>
+<td>3514</td>
+<td>3156</td>
+<td>[ZiMSTh11]</td>
+</tr>
+<tr>
+<td><code>matpower/case2746wp/2017-08-01</code></td>
+<td>2746</td>
+<td>457</td>
+<td>3514</td>
+<td>3156</td>
+<td>[ZiMSTh11]</td>
+</tr>
+<tr>
+<td><code>matpower/case3012wp/2017-02-01</code></td>
+<td>3012</td>
+<td>496</td>
+<td>3572</td>
+<td>2854</td>
+<td>[ZiMSTh11]</td>
+</tr>
+<tr>
+<td><code>matpower/case3012wp/2017-08-01</code></td>
+<td>3012</td>
+<td>496</td>
+<td>3572</td>
+<td>2854</td>
+<td>[ZiMSTh11]</td>
+</tr>
+<tr>
+<td><code>matpower/case3120sp/2017-02-01</code></td>
+<td>3120</td>
+<td>483</td>
+<td>3693</td>
+<td>2950</td>
+<td>[ZiMSTh11]</td>
+</tr>
+<tr>
+<td><code>matpower/case3120sp/2017-08-01</code></td>
+<td>3120</td>
+<td>483</td>
+<td>3693</td>
+<td>2950</td>
+<td>[ZiMSTh11]</td>
+</tr>
+<tr>
+<td><code>matpower/case3375wp/2017-02-01</code></td>
+<td>3374</td>
+<td>590</td>
+<td>4161</td>
+<td>3245</td>
+<td>[ZiMSTh11]</td>
+</tr>
+<tr>
+<td><code>matpower/case3375wp/2017-08-01</code></td>
+<td>3374</td>
+<td>590</td>
+<td>4161</td>
+<td>3245</td>
+<td>[ZiMSTh11]</td>
+</tr>
+</tbody>
+</table>
+<h3 id="23-matpowerpegase">2.3 MATPOWER/PEGASE</h3>
+<p>Test cases from the <a href="https://www.fp7-pegase.com/">Pan European Grid Advanced Simulation and State Estimation (PEGASE) project</a>, describing part of the European high voltage transmission network.</p>
+<table>
+<thead>
+<tr>
+<th>Name</th>
+<th>Buses</th>
+<th>Generators</th>
+<th>Lines</th>
+<th>Contingencies</th>
+<th>References</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td><code>matpower/case89pegase/2017-02-01</code></td>
+<td>89</td>
+<td>12</td>
+<td>210</td>
+<td>192</td>
+<td>[JoFlMa16], [FlPaCa13], [ZiMSTh11]</td>
+</tr>
+<tr>
+<td><code>matpower/case89pegase/2017-08-01</code></td>
+<td>89</td>
+<td>12</td>
+<td>210</td>
+<td>192</td>
+<td>[JoFlMa16], [FlPaCa13], [ZiMSTh11]</td>
+</tr>
+<tr>
+<td><code>matpower/case2869pegase/2017-02-01</code></td>
+<td>2869</td>
+<td>510</td>
+<td>4582</td>
+<td>3579</td>
+<td>[JoFlMa16], [FlPaCa13], [ZiMSTh11]</td>
+</tr>
+<tr>
+<td><code>matpower/case2869pegase/2017-08-01</code></td>
+<td>2869</td>
+<td>510</td>
+<td>4582</td>
+<td>3579</td>
+<td>[JoFlMa16], [FlPaCa13], [ZiMSTh11]</td>
+</tr>
+<tr>
+<td><code>matpower/case9241pegase/2017-02-01</code></td>
+<td>9241</td>
+<td>1445</td>
+<td>16049</td>
+<td>13932</td>
+<td>[JoFlMa16], [FlPaCa13], [ZiMSTh11]</td>
+</tr>
+<tr>
+<td><code>matpower/case9241pegase/2017-08-01</code></td>
+<td>9241</td>
+<td>1445</td>
+<td>16049</td>
+<td>13932</td>
+<td>[JoFlMa16], [FlPaCa13], [ZiMSTh11]</td>
+</tr>
+<tr>
+<td><code>matpower/case1354pegase/2017-02-01</code></td>
+<td>1354</td>
+<td>260</td>
+<td>1991</td>
+<td>1288</td>
+<td>[JoFlMa16], [FlPaCa13], [ZiMSTh11]</td>
+</tr>
+<tr>
+<td><code>matpower/case1354pegase/2017-08-01</code></td>
+<td>1354</td>
+<td>260</td>
+<td>1991</td>
+<td>1288</td>
+<td>[JoFlMa16], [FlPaCa13], [ZiMSTh11]</td>
+</tr>
+<tr>
+<td><code>matpower/case13659pegase/2017-02-01</code></td>
+<td>13659</td>
+<td>4092</td>
+<td>20467</td>
+<td>13932</td>
+<td>[JoFlMa16], [FlPaCa13], [ZiMSTh11]</td>
+</tr>
+<tr>
+<td><code>matpower/case13659pegase/2017-08-01</code></td>
+<td>13659</td>
+<td>4092</td>
+<td>20467</td>
+<td>13932</td>
+<td>[JoFlMa16], [FlPaCa13], [ZiMSTh11]</td>
+</tr>
+</tbody>
+</table>
+<h2 id="3-references">3. References</h2>
+<ul>
+<li>
+<p>[UCJL] Alinson S. Xavier, Feng Qiu, "UnitCommitment.jl: A Julia/JuMP Optimization Package for Security-Constrained Unit Commitment". Zenodo (2020). <a href="https://doi.org/10.5281/zenodo.4269874">DOI: 10.5281/zenodo.4269874</a>.</p>
+</li>
+<li>
+<p>[KnOsWa18] Bernard Knueven, James Ostrowski and Jean-Paul Watson. "On mixed integer programming formulations for the unit commitment problem." Pre-print available at http://www.optimization-online.org/DB_HTML/2018/11/6930.pdf (2018).</p>
+</li>
+<li>
+<p>[KrHiOn12] Eric Krall, Michael Higgins and Richard P. O’Neill. "RTO unit commitment test system." Federal Energy Regulatory Commission. Available: http://ferc.gov/legal/staff-reports/rto-COMMITMENT-TEST.pdf (2012).</p>
+</li>
+<li>
+<p>[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).</p>
+</li>
+<li>
+<p>[JoFlMa16] C. Josz, S. Fliscounakis, J. Maeght, and P. Panciatici, "AC Power Flow
+Data in MATPOWER and QCQP Format: iTesla, RTE Snapshots, and PEGASE"
+https://arxiv.org/abs/1603.01533</p>
+</li>
+<li>
+<p>[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.
+https://doi.org/10.1109/TPWRS.2013.2251015</p>
+</li>
+<li>
+<p>[ZiMSTh11] 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.</p>
+</li>
+<li>
+<p>[PSTCA] University of Washington, Dept. of Electrical Engineering, "Power Systems Test Case Archive", Published online at http://www.ee.washington.edu/research/pstca/, 1999.</p>
+</li>
+</ul></div>
+        
+        
+    </div>
+
+    
+      <footer class="col-md-12 text-center">
+          
+          
+            <hr>
+            <p>
+            <small>Copyright © 2020, UChicago Argonne, LLC. All Rights Reserved.</small><br>
+            
+            <small>Documentation built with <a href="http://www.mkdocs.org/">MkDocs</a>.</small>
+            </p>
+          
+
+          
+          
+      </footer>
+    
+    <script src="//ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js"></script>
+    <script src="../js/bootstrap-3.0.3.min.js"></script>
+
+    
+    <script src="//cdn.jsdelivr.net/gh/highlightjs/cdn-release@9.18.0/build/highlight.min.js"></script>
+        
+                <script src="//cdn.jsdelivr.net/gh/highlightjs/cdn-release@9.18.0/build/languages/julia.min.js"></script>
+        
+    <script>hljs.initHighlightingOnLoad();</script>
+    
+
+    <script>var base_url = ".."</script>
+    
+    <script src="../js/base.js"></script>
+    <script src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
+    <script src="../js/mathjax.js"></script>
+    <script src="../search/main.js"></script>
+
+    <div class="modal" id="mkdocs_search_modal" tabindex="-1" role="dialog" aria-labelledby="searchModalLabel" aria-hidden="true">
+    <div class="modal-dialog modal-lg">
+        <div class="modal-content">
+            <div class="modal-header">
+                <button type="button" class="close" data-dismiss="modal">
+                    <span aria-hidden="true">&times;</span>
+                    <span class="sr-only">Close</span>
+                </button>
+                <h4 class="modal-title" id="searchModalLabel">Search</h4>
+            </div>
+            <div class="modal-body">
+                <p>
+                    From here you can search these documents. Enter
+                    your search terms below.
+                </p>
+                <form>
+                    <div class="form-group">
+                        <input type="text" class="form-control" placeholder="Search..." id="mkdocs-search-query" title="Type search term here">
+                    </div>
+                </form>
+                <div id="mkdocs-search-results"></div>
+            </div>
+            <div class="modal-footer">
+            </div>
+        </div>
+    </div>
+</div><div class="modal" id="mkdocs_keyboard_modal" tabindex="-1" role="dialog" aria-labelledby="keyboardModalLabel" aria-hidden="true">
+    <div class="modal-dialog">
+        <div class="modal-content">
+            <div class="modal-header">
+                <h4 class="modal-title" id="keyboardModalLabel">Keyboard Shortcuts</h4>
+                <button type="button" class="close" data-dismiss="modal"><span aria-hidden="true">&times;</span><span class="sr-only">Close</span></button>
+            </div>
+            <div class="modal-body">
+              <table class="table">
+                <thead>
+                  <tr>
+                    <th style="width: 20%;">Keys</th>
+                    <th>Action</th>
+                  </tr>
+                </thead>
+                <tbody>
+                  <tr>
+                    <td class="help shortcut"><kbd>?</kbd></td>
+                    <td>Open this help</td>
+                  </tr>
+                  <tr>
+                    <td class="next shortcut"><kbd>n</kbd></td>
+                    <td>Next page</td>
+                  </tr>
+                  <tr>
+                    <td class="prev shortcut"><kbd>p</kbd></td>
+                    <td>Previous page</td>
+                  </tr>
+                  <tr>
+                    <td class="search shortcut"><kbd>s</kbd></td>
+                    <td>Search</td>
+                  </tr>
+                </tbody>
+              </table>
+            </div>
+            <div class="modal-footer">
+            </div>
+        </div>
+    </div>
+</div>
+    </body>
+
+</html>
diff --git a/0.1/search/search_index.json b/0.1/search/search_index.json
index 3a3f913..c5482d3 100644
--- a/0.1/search/search_index.json
+++ b/0.1/search/search_index.json
@@ -1 +1 @@
-{"config":{"lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"UnitCommitment.jl UnitCommitment.jl (UC.jl) is a Julia 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. Package Components 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. Benchmark Instances: The package provides a diverse collection of large-scale benchmark instances collected from the literature and extended to make them more challenging and realistic. Model Implementation : The package provides a Julia/JuMP implementation of state-of-the-art formulations and solution methods for SCUC. Our goal is to keep this implementation up-to-date, as new methods are proposed in the literature. Benchmark Tools: The package provides automated benchmark scripts to accurately evaluate the performance impact of proposed code changes. Documentation Usage Data Format Source code https://github.com/ANL-CEEESA/unitcommitment.jl Authors Alinson Santos Xavier (Argonne National Laboratory) Feng Qiu (Argonne National Laboratory) Acknowledgments We would like to thank Aleksandr M. Kazachkov (University of Florida), Yonghong Chen (Midcontinent Independent System Operator), Feng Pan (Pacific Northwest National Laboratory) for valuable feedback on early versions of this package. Based 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. License Released under the modified BSD license. See LICENSE.md for more details.","title":"Home"},{"location":"#unitcommitmentjl","text":"UnitCommitment.jl (UC.jl) is a Julia 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.","title":"UnitCommitment.jl"},{"location":"#package-components","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. Benchmark Instances: The package provides a diverse collection of large-scale benchmark instances collected from the literature and extended to make them more challenging and realistic. Model Implementation : The package provides a Julia/JuMP implementation of state-of-the-art formulations and solution methods for SCUC. Our goal is to keep this implementation up-to-date, as new methods are proposed in the literature. Benchmark Tools: The package provides automated benchmark scripts to accurately evaluate the performance impact of proposed code changes.","title":"Package Components"},{"location":"#documentation","text":"Usage Data Format","title":"Documentation"},{"location":"#source-code","text":"https://github.com/ANL-CEEESA/unitcommitment.jl","title":"Source code"},{"location":"#authors","text":"Alinson Santos Xavier (Argonne National Laboratory) Feng Qiu (Argonne National Laboratory)","title":"Authors"},{"location":"#acknowledgments","text":"We would like to thank Aleksandr M. Kazachkov (University of Florida), Yonghong Chen (Midcontinent Independent System Operator), Feng Pan (Pacific Northwest National Laboratory) for valuable feedback on early versions of this package. Based 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.","title":"Acknowledgments"},{"location":"#license","text":"Released under the modified BSD license. See LICENSE.md for more details.","title":"License"},{"location":"format/","text":"Data Format 1. Input Data Format Instances are specified by JSON files containing the following main sections: Parameters Buses Generators Price-sensitive loads Transmission lines Reserves Contingencies Each section is described in detail below. For a complete example, see case14.json . 1.1 Parameters This section describes system-wide parameters, such as power balance penalties, and optimization parameters, such as the length of the planning horizon. Key Description Default Time series? Time (h) Length of the planning horizon (in hours) Required N Power balance penalty ($/MW) Penalty for system-wide shortage or surplus in production (in $/MW). This is charged per time period. For example, if there is a shortage of 1 MW for three time periods, three times this amount will be charged. 1000.0 Y Example { \"Parameters\": { \"Time (h)\": 4, \"Power balance penalty ($/MW)\": 1000.0 } } 1.2 Buses This section describes the characteristics of each bus in the system. Key Description Default Time series? Load (MW) Fixed load connected to the bus (in MW). Required Y Example { \"Buses\": { \"b1\": { \"Load (MW)\": 0.0 }, \"b2\": { \"Load (MW)\": [ 26.01527, 24.46212, 23.29725, 22.90897 ] } } } 1.3 Generators This section describes all generators in the system, including thermal units, renewable units and virtual units. Key Description Default Time series? Bus Identifier of the bus where this generator is located (string) Required N Production cost curve (MW) and Production cost curve ($) Parameters describing the piecewise-linear production costs. See below for more details. Required Y Startup 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 t , then it costs 300 to start up the generator at times t+1 , t+2 or t+3 , and 400 to start the generator at time t+4 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. [0.0] and [1] N Minimum 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 1 and Minimum uptime (h) is set to 4, then the generator can only shut down at time 5. 1 N Minimum 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 1 and Minimum downtime (h) is set to 4, then the generator can only start producing power again at time 5. 1 N Ramp up limit (MW) Maximum increase in production from one time period to the next (in MW). For example, if the generator is producing 100 MW at time 1 and if this parameter is set to 40 MW, then the generator will produce at most 140 MW at time 2. +inf N Ramp down limit (MW) Maximum decrease in production from one time period to the next (in MW). For example, if the generator is producing 100 MW at time 1 and this parameter is set to 40 MW, then the generator will produce at least 60 MW at time 2. +inf N Startup limit (MW) Maximum amount of power a generator can produce immediately after starting up (in MW). +inf N Shutdown 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 t+1 if its production at time t is below this limit. +inf N Initial status (h) If set to a positive number, indicates the amount of time 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 at simulation time -2 and -1 . The simulation starts at time 0 . Required N Initial power (MW) Amount of power the generator at time period -1 , immediately before the planning horizon starts. Required N Must run? If true , the generator should be committed, even that is not economical (Boolean). false Y Provides spinning reserves? If true , this generator may provide spinning reserves (Boolean). true Y Production costs and limits 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 dollars 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. Figure 1. Piecewise-linear production cost curve. Additional remarks: 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 periods 1, 2, 3 and 4, respectively. The minimum output for all time periods is fixed to at 5 MW. There is no limit to the number of piecewise-linear segments, and different generators may have a different number of segments. If 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] . Production cost curves must be convex. Example { \"Generators\": { \"gen1\": { \"Bus\": \"b1\", \"Production cost curve (MW)\": [100.0, 110.0, 130.0, 135.0], \"Production cost curve ($)\": [1400.0, 1600.0, 2200.0, 2400.0], \"Startup costs ($)\": [300.0, 400.0], \"Startup delays (h)\": [1, 4], \"Ramp up limit (MW)\": 232.68, \"Ramp down limit (MW)\": 232.68, \"Startup limit (MW)\": 232.68, \"Shutdown limit (MW)\": 232.68, \"Minimum downtime (h)\": 4, \"Minimum uptime (h)\": 4, \"Initial status (h)\": 12, \"Must run?\": false, \"Provides spinning reserves?\": true, }, \"gen2\": { \"Bus\": \"b5\", \"Production cost curve (MW)\": [0.0, [10.0, 8.0, 0.0, 3.0]], \"Production cost curve ($)\": [0.0, 0.0], \"Provides spinning reserves?\": true, } } } 1.4 Price-sensitive loads 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. Key Description Default Time series? Bus Bus where the load is located. Multiple price-sensitive loads may be placed at the same bus. Required N Revenue ($/MW) Revenue obtained for serving each MW of power to this load. Required Y Demand (MW) Maximum amount of power required by this load. Any amount lower than this may be served. Required Y Example { \"Price-sensitive loads\": { \"p1\": { \"Bus\": \"b3\", \"Revenue ($/MW)\": 23.0, \"Demand (MW)\": 50.0 } } } 1.5 Transmission Lines This section describes the characteristics of transmission system, such as its topology and the susceptance of each transmission line. Key Description Default Time series? Source bus Identifier of the bus where the transmission line originates. Required N Target bus Identifier of the bus where the transmission line reaches. Required N Reactance (ohms) Reactance of the transmission line (in ohms). Required N Susceptance (S) Susceptance of the transmission line (in siemens). Required N Normal 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. May be null is there is no limit. +inf Y Emergency 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 Flow limit penalty ($/MW) Penalty for violating the flow limits of the transmission line (in $/MW). This is charged per time period. For example, if there is a thermal violation of 1 MW for three time periods, three times this amount will be charged. 5000.0 Y Example { \"Transmission lines\": { \"l1\": { \"Source bus\": \"b1\", \"Target bus\": \"b2\", \"Reactance (ohms)\": 0.05917, \"Susceptance (S)\": 29.49686, \"Normal flow limit (MW)\": 15000.0, \"Emergency flow limit (MW)\": 20000.0, \"Flow limit penalty ($/MW)\": 5000.0 } } } 1.6 Reserves This section describes the hourly amount of operating reserves required. Key Description Default Time series? Spinning (MW) Minimum amount of system-wide spinning reserves (in MW). Only generators which are online may provide this reserve. 0.0 Y Example { \"Reserves\": { \"Spinning (MW)\": [ 57.30552, 53.88429, 51.31838, 50.46307 ] } } 1.7 Contingencies This section describes credible contingency scenarios in the optimization, such as the loss of a transmission line or generator. Key Description Default Affected generators List of generators affected by this contingency. May be omitted if no generators are affected. [] Affected lines List of transmission lines affected by this contingency. May be omitted if no lines are affected. [] Example { \"Contingencies\": { \"c1\": { \"Affected lines\": [\"l1\", \"l2\", \"l3\"], \"Affected generators\": [\"g1\"] }, \"c2\": { \"Affected lines\": [\"l4\"] }, } } 1.8 Additional remarks Time series parameters 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, where T is the length of the planning horizon, if they are time-dependent. For example, both formats below are valid when T=3 : { \"Load (MW)\": 800.0, \"Load (MW)\": [800.0, 850.0, 730.0] } Current limitations All reserves are system-wide (no zonal reserves) Network topology remains the same for all time periods Only N-1 transmission contingencies are supported. Generator contingencies are not supported. Time-varying minimum production amounts are not currently compatible with ramp/startup/shutdown limits. 2. Output Data Format 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.","title":"Format"},{"location":"format/#data-format","text":"","title":"Data Format"},{"location":"format/#1-input-data-format","text":"Instances are specified by JSON files containing the following main sections: Parameters Buses Generators Price-sensitive loads Transmission lines Reserves Contingencies Each section is described in detail below. For a complete example, see case14.json .","title":"1. Input Data Format"},{"location":"format/#11-parameters","text":"This section describes system-wide parameters, such as power balance penalties, and optimization parameters, such as the length of the planning horizon. Key Description Default Time series? Time (h) Length of the planning horizon (in hours) Required N Power balance penalty ($/MW) Penalty for system-wide shortage or surplus in production (in $/MW). This is charged per time period. For example, if there is a shortage of 1 MW for three time periods, three times this amount will be charged. 1000.0 Y","title":"1.1 Parameters"},{"location":"format/#example","text":"{ \"Parameters\": { \"Time (h)\": 4, \"Power balance penalty ($/MW)\": 1000.0 } }","title":"Example"},{"location":"format/#12-buses","text":"This section describes the characteristics of each bus in the system. Key Description Default Time series? Load (MW) Fixed load connected to the bus (in MW). Required Y","title":"1.2 Buses"},{"location":"format/#example_1","text":"{ \"Buses\": { \"b1\": { \"Load (MW)\": 0.0 }, \"b2\": { \"Load (MW)\": [ 26.01527, 24.46212, 23.29725, 22.90897 ] } } }","title":"Example"},{"location":"format/#13-generators","text":"This section describes all generators in the system, including thermal units, renewable units and virtual units. Key Description Default Time series? Bus Identifier of the bus where this generator is located (string) Required N Production cost curve (MW) and Production cost curve ($) Parameters describing the piecewise-linear production costs. See below for more details. Required Y Startup 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 t , then it costs 300 to start up the generator at times t+1 , t+2 or t+3 , and 400 to start the generator at time t+4 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. [0.0] and [1] N Minimum 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 1 and Minimum uptime (h) is set to 4, then the generator can only shut down at time 5. 1 N Minimum 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 1 and Minimum downtime (h) is set to 4, then the generator can only start producing power again at time 5. 1 N Ramp up limit (MW) Maximum increase in production from one time period to the next (in MW). For example, if the generator is producing 100 MW at time 1 and if this parameter is set to 40 MW, then the generator will produce at most 140 MW at time 2. +inf N Ramp down limit (MW) Maximum decrease in production from one time period to the next (in MW). For example, if the generator is producing 100 MW at time 1 and this parameter is set to 40 MW, then the generator will produce at least 60 MW at time 2. +inf N Startup limit (MW) Maximum amount of power a generator can produce immediately after starting up (in MW). +inf N Shutdown 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 t+1 if its production at time t is below this limit. +inf N Initial status (h) If set to a positive number, indicates the amount of time 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 at simulation time -2 and -1 . The simulation starts at time 0 . Required N Initial power (MW) Amount of power the generator at time period -1 , immediately before the planning horizon starts. Required N Must run? If true , the generator should be committed, even that is not economical (Boolean). false Y Provides spinning reserves? If true , this generator may provide spinning reserves (Boolean). true Y","title":"1.3 Generators"},{"location":"format/#production-costs-and-limits","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 dollars 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. Figure 1. Piecewise-linear production cost curve.","title":"Production costs and limits"},{"location":"format/#additional-remarks","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 periods 1, 2, 3 and 4, respectively. The minimum output for all time periods is fixed to at 5 MW. There is no limit to the number of piecewise-linear segments, and different generators may have a different number of segments. If 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] . Production cost curves must be convex.","title":"Additional remarks:"},{"location":"format/#example_2","text":"{ \"Generators\": { \"gen1\": { \"Bus\": \"b1\", \"Production cost curve (MW)\": [100.0, 110.0, 130.0, 135.0], \"Production cost curve ($)\": [1400.0, 1600.0, 2200.0, 2400.0], \"Startup costs ($)\": [300.0, 400.0], \"Startup delays (h)\": [1, 4], \"Ramp up limit (MW)\": 232.68, \"Ramp down limit (MW)\": 232.68, \"Startup limit (MW)\": 232.68, \"Shutdown limit (MW)\": 232.68, \"Minimum downtime (h)\": 4, \"Minimum uptime (h)\": 4, \"Initial status (h)\": 12, \"Must run?\": false, \"Provides spinning reserves?\": true, }, \"gen2\": { \"Bus\": \"b5\", \"Production cost curve (MW)\": [0.0, [10.0, 8.0, 0.0, 3.0]], \"Production cost curve ($)\": [0.0, 0.0], \"Provides spinning reserves?\": true, } } }","title":"Example"},{"location":"format/#14-price-sensitive-loads","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. Key Description Default Time series? Bus Bus where the load is located. Multiple price-sensitive loads may be placed at the same bus. Required N Revenue ($/MW) Revenue obtained for serving each MW of power to this load. Required Y Demand (MW) Maximum amount of power required by this load. Any amount lower than this may be served. Required Y","title":"1.4 Price-sensitive loads"},{"location":"format/#example_3","text":"{ \"Price-sensitive loads\": { \"p1\": { \"Bus\": \"b3\", \"Revenue ($/MW)\": 23.0, \"Demand (MW)\": 50.0 } } }","title":"Example"},{"location":"format/#15-transmission-lines","text":"This section describes the characteristics of transmission system, such as its topology and the susceptance of each transmission line. Key Description Default Time series? Source bus Identifier of the bus where the transmission line originates. Required N Target bus Identifier of the bus where the transmission line reaches. Required N Reactance (ohms) Reactance of the transmission line (in ohms). Required N Susceptance (S) Susceptance of the transmission line (in siemens). Required N Normal 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. May be null is there is no limit. +inf Y Emergency 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 Flow limit penalty ($/MW) Penalty for violating the flow limits of the transmission line (in $/MW). This is charged per time period. For example, if there is a thermal violation of 1 MW for three time periods, three times this amount will be charged. 5000.0 Y","title":"1.5 Transmission Lines"},{"location":"format/#example_4","text":"{ \"Transmission lines\": { \"l1\": { \"Source bus\": \"b1\", \"Target bus\": \"b2\", \"Reactance (ohms)\": 0.05917, \"Susceptance (S)\": 29.49686, \"Normal flow limit (MW)\": 15000.0, \"Emergency flow limit (MW)\": 20000.0, \"Flow limit penalty ($/MW)\": 5000.0 } } }","title":"Example"},{"location":"format/#16-reserves","text":"This section describes the hourly amount of operating reserves required. Key Description Default Time series? Spinning (MW) Minimum amount of system-wide spinning reserves (in MW). Only generators which are online may provide this reserve. 0.0 Y","title":"1.6 Reserves"},{"location":"format/#example_5","text":"{ \"Reserves\": { \"Spinning (MW)\": [ 57.30552, 53.88429, 51.31838, 50.46307 ] } }","title":"Example"},{"location":"format/#17-contingencies","text":"This section describes credible contingency scenarios in the optimization, such as the loss of a transmission line or generator. Key Description Default Affected generators List of generators affected by this contingency. May be omitted if no generators are affected. [] Affected lines List of transmission lines affected by this contingency. May be omitted if no lines are affected. []","title":"1.7 Contingencies"},{"location":"format/#example_6","text":"{ \"Contingencies\": { \"c1\": { \"Affected lines\": [\"l1\", \"l2\", \"l3\"], \"Affected generators\": [\"g1\"] }, \"c2\": { \"Affected lines\": [\"l4\"] }, } }","title":"Example"},{"location":"format/#18-additional-remarks","text":"","title":"1.8 Additional remarks"},{"location":"format/#time-series-parameters","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, where T is the length of the planning horizon, if they are time-dependent. For example, both formats below are valid when T=3 : { \"Load (MW)\": 800.0, \"Load (MW)\": [800.0, 850.0, 730.0] }","title":"Time series parameters"},{"location":"format/#current-limitations","text":"All reserves are system-wide (no zonal reserves) Network topology remains the same for all time periods Only N-1 transmission contingencies are supported. Generator contingencies are not supported. Time-varying minimum production amounts are not currently compatible with ramp/startup/shutdown limits.","title":"Current limitations"},{"location":"format/#2-output-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.","title":"2. Output Data Format"},{"location":"usage/","text":"Usage 1. Installation UnitCommitment.jl was tested and developed with Julia 1.5 . 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: pkg> add https://github.com/ANL-CEEESA/UnitCommitment.jl.git To test that the package has been correctly installed, run: pkg> test UnitCommitment If all tests pass, the package should now be ready to be used by any Julia script on the machine. 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. 2. Typical Usage 2.1 Solving user-provided instances The first step to use UC.jl is to construct a JSON file describing your unit commitment instance. See the data format page for a complete description of the data format UC.jl expects. The next steps, as shown below, are to read the instance from file, construct the optimization model, run the optimization and extract the optimal solution. using Cbc using UnitCommitment # Read instance instance = UnitCommitment.read(\"/path/to/input.json\") # Construct optimization model model = UnitCommitment.build_model(instance, Cbc.Optimizer) # Solve model UnitCommitment.optimize!(model) # Extract solution and write it to a file solution = UnitCommitment.get_solution(model) open(\"/path/to/output.json\", \"w\") do file JSON.print(file, solution, 2) end 2.2 Solving benchmark instances As described in the instances page , UnitCommitment.jl contains a number of benchmark instances collected from the literature. To solve one of these instances individually, instead of constructing your own, the function read_benchmark can be used: using UnitCommitment instance = UnitCommitment.read_benchmark(\"matpower/case3375wp/2017-01-01\") 3. Advanced usage 3.1 Modifying the formulation For the time being, the recommended way of modifying the MILP formulation used by UC.jl is to create a local copy of our git repository and directly modify the source code of the package. In a future version, it will be possible to switch between multiple formulations, or to simply add/remove constraints after the model has been generated. 3.2 Generating initial conditions 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. 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: using Cbc using UnitCommitment # Read original instance instance = UnitCommitment.read(\"instance.json\") # Generate initial conditions (in-place) UnitCommitment.generate_initial_conditions!(instance, Cbc.Optimizer) # Construct and solve optimization model model = UnitCommitment.build_model(instance, Cbc.Optimizer) UnitCommitment.optimize!(model) Warning The 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. 3.3 Verifying solutions 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 . using JSON using UnitCommitment # Read instance instance = UnitCommitment.read(\"instance.json\") # Read solution (potentially produced by other packages) solution = JSON.parsefile(\"solution.json\") # Validate solution and print validation errors UnitCommitment.validate(instance, solution)","title":"Usage"},{"location":"usage/#usage","text":"","title":"Usage"},{"location":"usage/#1-installation","text":"UnitCommitment.jl was tested and developed with Julia 1.5 . 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: pkg> add https://github.com/ANL-CEEESA/UnitCommitment.jl.git To test that the package has been correctly installed, run: pkg> test UnitCommitment If all tests pass, the package should now be ready to be used by any Julia script on the machine. 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.","title":"1. Installation"},{"location":"usage/#2-typical-usage","text":"","title":"2. Typical Usage"},{"location":"usage/#21-solving-user-provided-instances","text":"The first step to use UC.jl is to construct a JSON file describing your unit commitment instance. See the data format page for a complete description of the data format UC.jl expects. The next steps, as shown below, are to read the instance from file, construct the optimization model, run the optimization and extract the optimal solution. using Cbc using UnitCommitment # Read instance instance = UnitCommitment.read(\"/path/to/input.json\") # Construct optimization model model = UnitCommitment.build_model(instance, Cbc.Optimizer) # Solve model UnitCommitment.optimize!(model) # Extract solution and write it to a file solution = UnitCommitment.get_solution(model) open(\"/path/to/output.json\", \"w\") do file JSON.print(file, solution, 2) end","title":"2.1 Solving user-provided instances"},{"location":"usage/#22-solving-benchmark-instances","text":"As described in the instances page , UnitCommitment.jl contains a number of benchmark instances collected from the literature. To solve one of these instances individually, instead of constructing your own, the function read_benchmark can be used: using UnitCommitment instance = UnitCommitment.read_benchmark(\"matpower/case3375wp/2017-01-01\")","title":"2.2 Solving benchmark instances"},{"location":"usage/#3-advanced-usage","text":"","title":"3. Advanced usage"},{"location":"usage/#31-modifying-the-formulation","text":"For the time being, the recommended way of modifying the MILP formulation used by UC.jl is to create a local copy of our git repository and directly modify the source code of the package. In a future version, it will be possible to switch between multiple formulations, or to simply add/remove constraints after the model has been generated.","title":"3.1 Modifying the formulation"},{"location":"usage/#32-generating-initial-conditions","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. 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: using Cbc using UnitCommitment # Read original instance instance = UnitCommitment.read(\"instance.json\") # Generate initial conditions (in-place) UnitCommitment.generate_initial_conditions!(instance, Cbc.Optimizer) # Construct and solve optimization model model = UnitCommitment.build_model(instance, Cbc.Optimizer) UnitCommitment.optimize!(model) Warning The 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.","title":"3.2 Generating initial conditions"},{"location":"usage/#33-verifying-solutions","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 . using JSON using UnitCommitment # Read instance instance = UnitCommitment.read(\"instance.json\") # Read solution (potentially produced by other packages) solution = JSON.parsefile(\"solution.json\") # Validate solution and print validation errors UnitCommitment.validate(instance, solution)","title":"3.3 Verifying solutions"}]}
\ No newline at end of file
+{"config":{"lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"UnitCommitment.jl UnitCommitment.jl (UC.jl) is a Julia 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. Package Components 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. Benchmark Instances: The package provides a diverse collection of large-scale benchmark instances collected from the literature and extended to make them more challenging and realistic. Model Implementation : The package provides a Julia/JuMP implementation of state-of-the-art formulations and solution methods for SCUC. Our goal is to keep this implementation up-to-date, as new methods are proposed in the literature. Benchmark Tools: The package provides automated benchmark scripts to accurately evaluate the performance impact of proposed code changes. Documentation Usage Data Format Instances Source code https://github.com/ANL-CEEESA/unitcommitment.jl Authors Alinson Santos Xavier (Argonne National Laboratory) Feng Qiu (Argonne National Laboratory) Acknowledgments We would like to thank Aleksandr M. Kazachkov (University of Florida), Yonghong Chen (Midcontinent Independent System Operator), Feng Pan (Pacific Northwest National Laboratory) for valuable feedback on early versions of this package. Based 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. Citing If you use UnitCommitment.jl in your research, we request that you cite the package as follows: Alinson S. Xavier, Feng Qiu, \"UnitCommitment.jl: A Julia/JuMP Optimization Package for Security-Constrained Unit Commitment\". Zenodo (2020). DOI: 10.5281/zenodo.4269874 . If you make use of the provided instances files, we request that you additionally cite the original sources, as described in the instances page . License Released under the modified BSD license. See LICENSE.md for more details.","title":"Home"},{"location":"#unitcommitmentjl","text":"UnitCommitment.jl (UC.jl) is a Julia 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.","title":"UnitCommitment.jl"},{"location":"#package-components","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. Benchmark Instances: The package provides a diverse collection of large-scale benchmark instances collected from the literature and extended to make them more challenging and realistic. Model Implementation : The package provides a Julia/JuMP implementation of state-of-the-art formulations and solution methods for SCUC. Our goal is to keep this implementation up-to-date, as new methods are proposed in the literature. Benchmark Tools: The package provides automated benchmark scripts to accurately evaluate the performance impact of proposed code changes.","title":"Package Components"},{"location":"#documentation","text":"Usage Data Format Instances","title":"Documentation"},{"location":"#source-code","text":"https://github.com/ANL-CEEESA/unitcommitment.jl","title":"Source code"},{"location":"#authors","text":"Alinson Santos Xavier (Argonne National Laboratory) Feng Qiu (Argonne National Laboratory)","title":"Authors"},{"location":"#acknowledgments","text":"We would like to thank Aleksandr M. Kazachkov (University of Florida), Yonghong Chen (Midcontinent Independent System Operator), Feng Pan (Pacific Northwest National Laboratory) for valuable feedback on early versions of this package. Based 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.","title":"Acknowledgments"},{"location":"#citing","text":"If you use UnitCommitment.jl in your research, we request that you cite the package as follows: Alinson S. Xavier, Feng Qiu, \"UnitCommitment.jl: A Julia/JuMP Optimization Package for Security-Constrained Unit Commitment\". Zenodo (2020). DOI: 10.5281/zenodo.4269874 . If you make use of the provided instances files, we request that you additionally cite the original sources, as described in the instances page .","title":"Citing"},{"location":"#license","text":"Released under the modified BSD license. See LICENSE.md for more details.","title":"License"},{"location":"format/","text":"Data Format 1. Input Data Format Instances are specified by JSON files containing the following main sections: Parameters Buses Generators Price-sensitive loads Transmission lines Reserves Contingencies Each section is described in detail below. For a complete example, see case14.json . 1.1 Parameters This section describes system-wide parameters, such as power balance penalties, and optimization parameters, such as the length of the planning horizon. Key Description Default Time series? Time (h) Length of the planning horizon (in hours) Required N Power balance penalty ($/MW) Penalty for system-wide shortage or surplus in production (in $/MW). This is charged per time period. For example, if there is a shortage of 1 MW for three time periods, three times this amount will be charged. 1000.0 Y Example { \"Parameters\": { \"Time (h)\": 4, \"Power balance penalty ($/MW)\": 1000.0 } } 1.2 Buses This section describes the characteristics of each bus in the system. Key Description Default Time series? Load (MW) Fixed load connected to the bus (in MW). Required Y Example { \"Buses\": { \"b1\": { \"Load (MW)\": 0.0 }, \"b2\": { \"Load (MW)\": [ 26.01527, 24.46212, 23.29725, 22.90897 ] } } } 1.3 Generators This section describes all generators in the system, including thermal units, renewable units and virtual units. Key Description Default Time series? Bus Identifier of the bus where this generator is located (string) Required N Production cost curve (MW) and Production cost curve ($) Parameters describing the piecewise-linear production costs. See below for more details. Required Y Startup 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 t , then it costs 300 to start up the generator at times t+1 , t+2 or t+3 , and 400 to start the generator at time t+4 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. [0.0] and [1] N Minimum 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 1 and Minimum uptime (h) is set to 4, then the generator can only shut down at time 5. 1 N Minimum 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 1 and Minimum downtime (h) is set to 4, then the generator can only start producing power again at time 5. 1 N Ramp up limit (MW) Maximum increase in production from one time period to the next (in MW). For example, if the generator is producing 100 MW at time 1 and if this parameter is set to 40 MW, then the generator will produce at most 140 MW at time 2. +inf N Ramp down limit (MW) Maximum decrease in production from one time period to the next (in MW). For example, if the generator is producing 100 MW at time 1 and this parameter is set to 40 MW, then the generator will produce at least 60 MW at time 2. +inf N Startup limit (MW) Maximum amount of power a generator can produce immediately after starting up (in MW). +inf N Shutdown 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 t+1 if its production at time t is below this limit. +inf N Initial status (h) If set to a positive number, indicates the amount of time 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 at simulation time -2 and -1 . The simulation starts at time 0 . Required N Initial power (MW) Amount of power the generator at time period -1 , immediately before the planning horizon starts. Required N Must run? If true , the generator should be committed, even that is not economical (Boolean). false Y Provides spinning reserves? If true , this generator may provide spinning reserves (Boolean). true Y Production costs and limits 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 dollars 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. Figure 1. Piecewise-linear production cost curve. Additional remarks: 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 periods 1, 2, 3 and 4, respectively. The minimum output for all time periods is fixed to at 5 MW. There is no limit to the number of piecewise-linear segments, and different generators may have a different number of segments. If 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] . Production cost curves must be convex. Example { \"Generators\": { \"gen1\": { \"Bus\": \"b1\", \"Production cost curve (MW)\": [100.0, 110.0, 130.0, 135.0], \"Production cost curve ($)\": [1400.0, 1600.0, 2200.0, 2400.0], \"Startup costs ($)\": [300.0, 400.0], \"Startup delays (h)\": [1, 4], \"Ramp up limit (MW)\": 232.68, \"Ramp down limit (MW)\": 232.68, \"Startup limit (MW)\": 232.68, \"Shutdown limit (MW)\": 232.68, \"Minimum downtime (h)\": 4, \"Minimum uptime (h)\": 4, \"Initial status (h)\": 12, \"Must run?\": false, \"Provides spinning reserves?\": true, }, \"gen2\": { \"Bus\": \"b5\", \"Production cost curve (MW)\": [0.0, [10.0, 8.0, 0.0, 3.0]], \"Production cost curve ($)\": [0.0, 0.0], \"Provides spinning reserves?\": true, } } } 1.4 Price-sensitive loads 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. Key Description Default Time series? Bus Bus where the load is located. Multiple price-sensitive loads may be placed at the same bus. Required N Revenue ($/MW) Revenue obtained for serving each MW of power to this load. Required Y Demand (MW) Maximum amount of power required by this load. Any amount lower than this may be served. Required Y Example { \"Price-sensitive loads\": { \"p1\": { \"Bus\": \"b3\", \"Revenue ($/MW)\": 23.0, \"Demand (MW)\": 50.0 } } } 1.5 Transmission Lines This section describes the characteristics of transmission system, such as its topology and the susceptance of each transmission line. Key Description Default Time series? Source bus Identifier of the bus where the transmission line originates. Required N Target bus Identifier of the bus where the transmission line reaches. Required N Reactance (ohms) Reactance of the transmission line (in ohms). Required N Susceptance (S) Susceptance of the transmission line (in siemens). Required N Normal 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. May be null is there is no limit. +inf Y Emergency 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 Flow limit penalty ($/MW) Penalty for violating the flow limits of the transmission line (in $/MW). This is charged per time period. For example, if there is a thermal violation of 1 MW for three time periods, three times this amount will be charged. 5000.0 Y Example { \"Transmission lines\": { \"l1\": { \"Source bus\": \"b1\", \"Target bus\": \"b2\", \"Reactance (ohms)\": 0.05917, \"Susceptance (S)\": 29.49686, \"Normal flow limit (MW)\": 15000.0, \"Emergency flow limit (MW)\": 20000.0, \"Flow limit penalty ($/MW)\": 5000.0 } } } 1.6 Reserves This section describes the hourly amount of operating reserves required. Key Description Default Time series? Spinning (MW) Minimum amount of system-wide spinning reserves (in MW). Only generators which are online may provide this reserve. 0.0 Y Example { \"Reserves\": { \"Spinning (MW)\": [ 57.30552, 53.88429, 51.31838, 50.46307 ] } } 1.7 Contingencies This section describes credible contingency scenarios in the optimization, such as the loss of a transmission line or generator. Key Description Default Affected generators List of generators affected by this contingency. May be omitted if no generators are affected. [] Affected lines List of transmission lines affected by this contingency. May be omitted if no lines are affected. [] Example { \"Contingencies\": { \"c1\": { \"Affected lines\": [\"l1\", \"l2\", \"l3\"], \"Affected generators\": [\"g1\"] }, \"c2\": { \"Affected lines\": [\"l4\"] }, } } 1.8 Additional remarks Time series parameters 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, where T is the length of the planning horizon, if they are time-dependent. For example, both formats below are valid when T=3 : { \"Load (MW)\": 800.0, \"Load (MW)\": [800.0, 850.0, 730.0] } Current limitations All reserves are system-wide (no zonal reserves) Network topology remains the same for all time periods Only N-1 transmission contingencies are supported. Generator contingencies are not supported. Time-varying minimum production amounts are not currently compatible with ramp/startup/shutdown limits. 2. Output Data Format 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.","title":"Format"},{"location":"format/#data-format","text":"","title":"Data Format"},{"location":"format/#1-input-data-format","text":"Instances are specified by JSON files containing the following main sections: Parameters Buses Generators Price-sensitive loads Transmission lines Reserves Contingencies Each section is described in detail below. For a complete example, see case14.json .","title":"1. Input Data Format"},{"location":"format/#11-parameters","text":"This section describes system-wide parameters, such as power balance penalties, and optimization parameters, such as the length of the planning horizon. Key Description Default Time series? Time (h) Length of the planning horizon (in hours) Required N Power balance penalty ($/MW) Penalty for system-wide shortage or surplus in production (in $/MW). This is charged per time period. For example, if there is a shortage of 1 MW for three time periods, three times this amount will be charged. 1000.0 Y","title":"1.1 Parameters"},{"location":"format/#example","text":"{ \"Parameters\": { \"Time (h)\": 4, \"Power balance penalty ($/MW)\": 1000.0 } }","title":"Example"},{"location":"format/#12-buses","text":"This section describes the characteristics of each bus in the system. Key Description Default Time series? Load (MW) Fixed load connected to the bus (in MW). Required Y","title":"1.2 Buses"},{"location":"format/#example_1","text":"{ \"Buses\": { \"b1\": { \"Load (MW)\": 0.0 }, \"b2\": { \"Load (MW)\": [ 26.01527, 24.46212, 23.29725, 22.90897 ] } } }","title":"Example"},{"location":"format/#13-generators","text":"This section describes all generators in the system, including thermal units, renewable units and virtual units. Key Description Default Time series? Bus Identifier of the bus where this generator is located (string) Required N Production cost curve (MW) and Production cost curve ($) Parameters describing the piecewise-linear production costs. See below for more details. Required Y Startup 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 t , then it costs 300 to start up the generator at times t+1 , t+2 or t+3 , and 400 to start the generator at time t+4 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. [0.0] and [1] N Minimum 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 1 and Minimum uptime (h) is set to 4, then the generator can only shut down at time 5. 1 N Minimum 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 1 and Minimum downtime (h) is set to 4, then the generator can only start producing power again at time 5. 1 N Ramp up limit (MW) Maximum increase in production from one time period to the next (in MW). For example, if the generator is producing 100 MW at time 1 and if this parameter is set to 40 MW, then the generator will produce at most 140 MW at time 2. +inf N Ramp down limit (MW) Maximum decrease in production from one time period to the next (in MW). For example, if the generator is producing 100 MW at time 1 and this parameter is set to 40 MW, then the generator will produce at least 60 MW at time 2. +inf N Startup limit (MW) Maximum amount of power a generator can produce immediately after starting up (in MW). +inf N Shutdown 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 t+1 if its production at time t is below this limit. +inf N Initial status (h) If set to a positive number, indicates the amount of time 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 at simulation time -2 and -1 . The simulation starts at time 0 . Required N Initial power (MW) Amount of power the generator at time period -1 , immediately before the planning horizon starts. Required N Must run? If true , the generator should be committed, even that is not economical (Boolean). false Y Provides spinning reserves? If true , this generator may provide spinning reserves (Boolean). true Y","title":"1.3 Generators"},{"location":"format/#production-costs-and-limits","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 dollars 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. Figure 1. Piecewise-linear production cost curve.","title":"Production costs and limits"},{"location":"format/#additional-remarks","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 periods 1, 2, 3 and 4, respectively. The minimum output for all time periods is fixed to at 5 MW. There is no limit to the number of piecewise-linear segments, and different generators may have a different number of segments. If 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] . Production cost curves must be convex.","title":"Additional remarks:"},{"location":"format/#example_2","text":"{ \"Generators\": { \"gen1\": { \"Bus\": \"b1\", \"Production cost curve (MW)\": [100.0, 110.0, 130.0, 135.0], \"Production cost curve ($)\": [1400.0, 1600.0, 2200.0, 2400.0], \"Startup costs ($)\": [300.0, 400.0], \"Startup delays (h)\": [1, 4], \"Ramp up limit (MW)\": 232.68, \"Ramp down limit (MW)\": 232.68, \"Startup limit (MW)\": 232.68, \"Shutdown limit (MW)\": 232.68, \"Minimum downtime (h)\": 4, \"Minimum uptime (h)\": 4, \"Initial status (h)\": 12, \"Must run?\": false, \"Provides spinning reserves?\": true, }, \"gen2\": { \"Bus\": \"b5\", \"Production cost curve (MW)\": [0.0, [10.0, 8.0, 0.0, 3.0]], \"Production cost curve ($)\": [0.0, 0.0], \"Provides spinning reserves?\": true, } } }","title":"Example"},{"location":"format/#14-price-sensitive-loads","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. Key Description Default Time series? Bus Bus where the load is located. Multiple price-sensitive loads may be placed at the same bus. Required N Revenue ($/MW) Revenue obtained for serving each MW of power to this load. Required Y Demand (MW) Maximum amount of power required by this load. Any amount lower than this may be served. Required Y","title":"1.4 Price-sensitive loads"},{"location":"format/#example_3","text":"{ \"Price-sensitive loads\": { \"p1\": { \"Bus\": \"b3\", \"Revenue ($/MW)\": 23.0, \"Demand (MW)\": 50.0 } } }","title":"Example"},{"location":"format/#15-transmission-lines","text":"This section describes the characteristics of transmission system, such as its topology and the susceptance of each transmission line. Key Description Default Time series? Source bus Identifier of the bus where the transmission line originates. Required N Target bus Identifier of the bus where the transmission line reaches. Required N Reactance (ohms) Reactance of the transmission line (in ohms). Required N Susceptance (S) Susceptance of the transmission line (in siemens). Required N Normal 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. May be null is there is no limit. +inf Y Emergency 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 Flow limit penalty ($/MW) Penalty for violating the flow limits of the transmission line (in $/MW). This is charged per time period. For example, if there is a thermal violation of 1 MW for three time periods, three times this amount will be charged. 5000.0 Y","title":"1.5 Transmission Lines"},{"location":"format/#example_4","text":"{ \"Transmission lines\": { \"l1\": { \"Source bus\": \"b1\", \"Target bus\": \"b2\", \"Reactance (ohms)\": 0.05917, \"Susceptance (S)\": 29.49686, \"Normal flow limit (MW)\": 15000.0, \"Emergency flow limit (MW)\": 20000.0, \"Flow limit penalty ($/MW)\": 5000.0 } } }","title":"Example"},{"location":"format/#16-reserves","text":"This section describes the hourly amount of operating reserves required. Key Description Default Time series? Spinning (MW) Minimum amount of system-wide spinning reserves (in MW). Only generators which are online may provide this reserve. 0.0 Y","title":"1.6 Reserves"},{"location":"format/#example_5","text":"{ \"Reserves\": { \"Spinning (MW)\": [ 57.30552, 53.88429, 51.31838, 50.46307 ] } }","title":"Example"},{"location":"format/#17-contingencies","text":"This section describes credible contingency scenarios in the optimization, such as the loss of a transmission line or generator. Key Description Default Affected generators List of generators affected by this contingency. May be omitted if no generators are affected. [] Affected lines List of transmission lines affected by this contingency. May be omitted if no lines are affected. []","title":"1.7 Contingencies"},{"location":"format/#example_6","text":"{ \"Contingencies\": { \"c1\": { \"Affected lines\": [\"l1\", \"l2\", \"l3\"], \"Affected generators\": [\"g1\"] }, \"c2\": { \"Affected lines\": [\"l4\"] }, } }","title":"Example"},{"location":"format/#18-additional-remarks","text":"","title":"1.8 Additional remarks"},{"location":"format/#time-series-parameters","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, where T is the length of the planning horizon, if they are time-dependent. For example, both formats below are valid when T=3 : { \"Load (MW)\": 800.0, \"Load (MW)\": [800.0, 850.0, 730.0] }","title":"Time series parameters"},{"location":"format/#current-limitations","text":"All reserves are system-wide (no zonal reserves) Network topology remains the same for all time periods Only N-1 transmission contingencies are supported. Generator contingencies are not supported. Time-varying minimum production amounts are not currently compatible with ramp/startup/shutdown limits.","title":"Current limitations"},{"location":"format/#2-output-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.","title":"2. Output Data Format"},{"location":"instances/","text":"Instances UnitCommitment.jl provides a collection of large-scale benchmark instances collected from the literature in a standard data format and, in some cases, extended with realistic unit commitment data, produced by 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). Raw instances files are available at our GitHub repository . Benchmark instances can also be loaded with UnitCommitment.read_benchmark(name) , as explained in the usage section , where name is one of the names below. 1. PGLIB-UC Instances PGLIB-UC is a benchmark library curated and maintained by the IEEE PES Task Force on Benchmarks for Validation of Emerging Power System Algorithms . 1.1 PGLIB-UC/California Test cases based on publicly available data from the California ISO. For more details, see PGLIB-UC case file overview . Name Buses Generators Lines Contingencies References pglib-uc/ca/2014-09-01_reserves_0 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2014-09-01_reserves_1 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2014-09-01_reserves_3 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2014-09-01_reserves_5 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2014-12-01_reserves_0 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2014-12-01_reserves_1 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2014-12-01_reserves_3 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2014-12-01_reserves_5 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2015-03-01_reserves_0 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2015-03-01_reserves_1 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2015-03-01_reserves_3 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2015-03-01_reserves_5 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2015-06-01_reserves_0 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2015-06-01_reserves_1 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2015-06-01_reserves_3 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2015-06-01_reserves_5 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/Scenario400_reserves_0 1 611 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/Scenario400_reserves_1 1 611 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/Scenario400_reserves_3 1 611 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/Scenario400_reserves_5 1 611 0 0 [KnOsWa18], [KrHiOn12] 1.2 PGLIB-UC/FERC Test cases based on publicly available unit commitment test instance from the Federal Energy Regulatory Commission. For more details, see PGLIB-UC case file overview . Name Buses Generators Lines Contingencies References pglib-uc/ferc/2015-01-01_hw 1 935 0 0 [KnOsWa18] pglib-uc/ferc/2015-01-01_lw 1 935 0 0 [KnOsWa18] pglib-uc/ferc/2015-02-01_hw 1 935 0 0 [KnOsWa18] pglib-uc/ferc/2015-02-01_lw 1 935 0 0 [KnOsWa18] pglib-uc/ferc/2015-03-01_hw 1 935 0 0 [KnOsWa18] pglib-uc/ferc/2015-03-01_lw 1 935 0 0 [KnOsWa18] pglib-uc/ferc/2015-04-01_hw 1 979 0 0 [KnOsWa18] pglib-uc/ferc/2015-04-01_lw 1 979 0 0 [KnOsWa18] pglib-uc/ferc/2015-05-01_hw 1 979 0 0 [KnOsWa18] pglib-uc/ferc/2015-05-01_lw 1 979 0 0 [KnOsWa18] pglib-uc/ferc/2015-06-01_hw 1 979 0 0 [KnOsWa18] pglib-uc/ferc/2015-06-01_lw 1 979 0 0 [KnOsWa18] pglib-uc/ferc/2015-07-01_hw 1 979 0 0 [KnOsWa18] pglib-uc/ferc/2015-07-01_lw 1 979 0 0 [KnOsWa18] pglib-uc/ferc/2015-08-01_hw 1 979 0 0 [KnOsWa18] pglib-uc/ferc/2015-08-01_lw 1 979 0 0 [KnOsWa18] pglib-uc/ferc/2015-09-01_hw 1 979 0 0 [KnOsWa18] pglib-uc/ferc/2015-09-01_lw 1 979 0 0 [KnOsWa18] pglib-uc/ferc/2015-10-01_hw 1 935 0 0 [KnOsWa18] pglib-uc/ferc/2015-10-01_lw 1 935 0 0 [KnOsWa18] pglib-uc/ferc/2015-11-02_hw 1 935 0 0 [KnOsWa18] pglib-uc/ferc/2015-11-02_lw 1 935 0 0 [KnOsWa18] pglib-uc/ferc/2015-12-01_hw 1 935 0 0 [KnOsWa18] pglib-uc/ferc/2015-12-01_lw 1 935 0 0 [KnOsWa18] 1.3 PGLIB-UC/RTS-GMLC 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 . Name Buses Generators Lines Contingencies References pglib-uc/rts_gmlc/2020-01-27 1 154 0 0 [BaBlEh19] pglib-uc/rts_gmlc/2020-02-09 1 154 0 0 [BaBlEh19] pglib-uc/rts_gmlc/2020-03-05 1 154 0 0 [BaBlEh19] pglib-uc/rts_gmlc/2020-04-03 1 154 0 0 [BaBlEh19] pglib-uc/rts_gmlc/2020-05-05 1 154 0 0 [BaBlEh19] pglib-uc/rts_gmlc/2020-06-09 1 154 0 0 [BaBlEh19] pglib-uc/rts_gmlc/2020-07-06 1 154 0 0 [BaBlEh19] pglib-uc/rts_gmlc/2020-08-12 1 154 0 0 [BaBlEh19] pglib-uc/rts_gmlc/2020-09-20 1 154 0 0 [BaBlEh19] pglib-uc/rts_gmlc/2020-10-27 1 154 0 0 [BaBlEh19] pglib-uc/rts_gmlc/2020-11-25 1 154 0 0 [BaBlEh19] pglib-uc/rts_gmlc/2020-12-23 1 154 0 0 [BaBlEh19] 2. MATPOWER 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. 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: 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. Load profiles were generated using a similar data-driven approach. Ramp-up, ramp-down, startup and shutdown rates were set to fixed proportion of the generator's maximum output. Minimum reserves were set to a fixed proportion of the total demand. Contingencies 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. For each MATPOWER test case, UC.jl provides two variations ( 2017-02-01 and 2017-08-01 ) corresponding respectively to a winter and to a summer test case. 2.1 MATPOWER/UW-PSTCA A variety of smaller IEEE test cases, compiled by University of Wisconsin , corresponding mostly to small portions of the American Electric Power System in the 1960s. Name Buses Generators Lines Contingencies References matpower/case14/2017-02-01 14 5 20 19 [ZiMSTh11], [PSTCA] matpower/case14/2017-08-01 14 5 20 19 [ZiMSTh11], [PSTCA] matpower/case30/2017-02-01 30 6 41 38 [ZiMSTh11], [PSTCA] matpower/case30/2017-08-01 30 6 41 38 [ZiMSTh11], [PSTCA] matpower/case57/2017-02-01 57 7 80 79 [ZiMSTh11], [PSTCA] matpower/case57/2017-08-01 57 7 80 79 [ZiMSTh11], [PSTCA] matpower/case118/2017-02-01 118 54 186 177 [ZiMSTh11], [PSTCA] matpower/case118/2017-08-01 118 54 186 177 [ZiMSTh11], [PSTCA] matpower/case300/2017-02-01 300 69 411 320 [ZiMSTh11], [PSTCA] matpower/case300/2017-08-01 300 69 411 320 [ZiMSTh11], [PSTCA] 2.2 MATPOWER/Polish Test cases based on the Polish 400, 220 and 110 kV networks, originally provided by Roman Korab (Politechnika \u015al\u0105ska) and corrected by the MATPOWER team. Name Buses Generators Lines Contingencies References matpower/case2383wp/2017-02-01 2383 323 2896 2240 [ZiMSTh11] matpower/case2383wp/2017-08-01 2383 323 2896 2240 [ZiMSTh11] matpower/case2736sp/2017-02-01 2736 289 3504 3159 [ZiMSTh11] matpower/case2736sp/2017-08-01 2736 289 3504 3159 [ZiMSTh11] matpower/case2737sop/2017-02-01 2737 267 3506 3161 [ZiMSTh11] matpower/case2737sop/2017-08-01 2737 267 3506 3161 [ZiMSTh11] matpower/case2746wop/2017-02-01 2746 443 3514 3155 [ZiMSTh11] matpower/case2746wop/2017-08-01 2746 443 3514 3155 [ZiMSTh11] matpower/case2746wp/2017-02-01 2746 457 3514 3156 [ZiMSTh11] matpower/case2746wp/2017-08-01 2746 457 3514 3156 [ZiMSTh11] matpower/case3012wp/2017-02-01 3012 496 3572 2854 [ZiMSTh11] matpower/case3012wp/2017-08-01 3012 496 3572 2854 [ZiMSTh11] matpower/case3120sp/2017-02-01 3120 483 3693 2950 [ZiMSTh11] matpower/case3120sp/2017-08-01 3120 483 3693 2950 [ZiMSTh11] matpower/case3375wp/2017-02-01 3374 590 4161 3245 [ZiMSTh11] matpower/case3375wp/2017-08-01 3374 590 4161 3245 [ZiMSTh11] 2.3 MATPOWER/PEGASE Test cases from the Pan European Grid Advanced Simulation and State Estimation (PEGASE) project , describing part of the European high voltage transmission network. Name Buses Generators Lines Contingencies References matpower/case89pegase/2017-02-01 89 12 210 192 [JoFlMa16], [FlPaCa13], [ZiMSTh11] matpower/case89pegase/2017-08-01 89 12 210 192 [JoFlMa16], [FlPaCa13], [ZiMSTh11] matpower/case2869pegase/2017-02-01 2869 510 4582 3579 [JoFlMa16], [FlPaCa13], [ZiMSTh11] matpower/case2869pegase/2017-08-01 2869 510 4582 3579 [JoFlMa16], [FlPaCa13], [ZiMSTh11] matpower/case9241pegase/2017-02-01 9241 1445 16049 13932 [JoFlMa16], [FlPaCa13], [ZiMSTh11] matpower/case9241pegase/2017-08-01 9241 1445 16049 13932 [JoFlMa16], [FlPaCa13], [ZiMSTh11] matpower/case1354pegase/2017-02-01 1354 260 1991 1288 [JoFlMa16], [FlPaCa13], [ZiMSTh11] matpower/case1354pegase/2017-08-01 1354 260 1991 1288 [JoFlMa16], [FlPaCa13], [ZiMSTh11] matpower/case13659pegase/2017-02-01 13659 4092 20467 13932 [JoFlMa16], [FlPaCa13], [ZiMSTh11] matpower/case13659pegase/2017-08-01 13659 4092 20467 13932 [JoFlMa16], [FlPaCa13], [ZiMSTh11] 3. References [UCJL] Alinson S. Xavier, Feng Qiu, \"UnitCommitment.jl: A Julia/JuMP Optimization Package for Security-Constrained Unit Commitment\". Zenodo (2020). DOI: 10.5281/zenodo.4269874 . [KnOsWa18] Bernard Knueven, James Ostrowski and Jean-Paul Watson. \"On mixed integer programming formulations for the unit commitment problem.\" Pre-print available at http://www.optimization-online.org/DB_HTML/2018/11/6930.pdf (2018). [KrHiOn12] Eric Krall, Michael Higgins and Richard P. O\u2019Neill. \"RTO unit commitment test system.\" Federal Energy Regulatory Commission. Available: http://ferc.gov/legal/staff-reports/rto-COMMITMENT-TEST.pdf (2012). [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). [JoFlMa16] C. Josz, S. Fliscounakis, J. Maeght, and P. Panciatici, \"AC Power Flow Data in MATPOWER and QCQP Format: iTesla, RTE Snapshots, and PEGASE\" https://arxiv.org/abs/1603.01533 [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. https://doi.org/10.1109/TPWRS.2013.2251015 [ZiMSTh11] 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 \u201319, Feb. 2011. [PSTCA] University of Washington, Dept. of Electrical Engineering, \"Power Systems Test Case Archive\", Published online at http://www.ee.washington.edu/research/pstca/, 1999.","title":"Instances"},{"location":"instances/#instances","text":"UnitCommitment.jl provides a collection of large-scale benchmark instances collected from the literature in a standard data format and, in some cases, extended with realistic unit commitment data, produced by 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). Raw instances files are available at our GitHub repository . Benchmark instances can also be loaded with UnitCommitment.read_benchmark(name) , as explained in the usage section , where name is one of the names below.","title":"Instances"},{"location":"instances/#1-pglib-uc-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 .","title":"1. PGLIB-UC Instances"},{"location":"instances/#11-pglib-uccalifornia","text":"Test cases based on publicly available data from the California ISO. For more details, see PGLIB-UC case file overview . Name Buses Generators Lines Contingencies References pglib-uc/ca/2014-09-01_reserves_0 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2014-09-01_reserves_1 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2014-09-01_reserves_3 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2014-09-01_reserves_5 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2014-12-01_reserves_0 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2014-12-01_reserves_1 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2014-12-01_reserves_3 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2014-12-01_reserves_5 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2015-03-01_reserves_0 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2015-03-01_reserves_1 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2015-03-01_reserves_3 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2015-03-01_reserves_5 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2015-06-01_reserves_0 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2015-06-01_reserves_1 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2015-06-01_reserves_3 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/2015-06-01_reserves_5 1 610 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/Scenario400_reserves_0 1 611 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/Scenario400_reserves_1 1 611 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/Scenario400_reserves_3 1 611 0 0 [KnOsWa18], [KrHiOn12] pglib-uc/ca/Scenario400_reserves_5 1 611 0 0 [KnOsWa18], [KrHiOn12]","title":"1.1 PGLIB-UC/California"},{"location":"instances/#12-pglib-ucferc","text":"Test cases based on publicly available unit commitment test instance from the Federal Energy Regulatory Commission. For more details, see PGLIB-UC case file overview . Name Buses Generators Lines Contingencies References pglib-uc/ferc/2015-01-01_hw 1 935 0 0 [KnOsWa18] pglib-uc/ferc/2015-01-01_lw 1 935 0 0 [KnOsWa18] pglib-uc/ferc/2015-02-01_hw 1 935 0 0 [KnOsWa18] pglib-uc/ferc/2015-02-01_lw 1 935 0 0 [KnOsWa18] pglib-uc/ferc/2015-03-01_hw 1 935 0 0 [KnOsWa18] pglib-uc/ferc/2015-03-01_lw 1 935 0 0 [KnOsWa18] pglib-uc/ferc/2015-04-01_hw 1 979 0 0 [KnOsWa18] pglib-uc/ferc/2015-04-01_lw 1 979 0 0 [KnOsWa18] pglib-uc/ferc/2015-05-01_hw 1 979 0 0 [KnOsWa18] pglib-uc/ferc/2015-05-01_lw 1 979 0 0 [KnOsWa18] pglib-uc/ferc/2015-06-01_hw 1 979 0 0 [KnOsWa18] pglib-uc/ferc/2015-06-01_lw 1 979 0 0 [KnOsWa18] pglib-uc/ferc/2015-07-01_hw 1 979 0 0 [KnOsWa18] pglib-uc/ferc/2015-07-01_lw 1 979 0 0 [KnOsWa18] pglib-uc/ferc/2015-08-01_hw 1 979 0 0 [KnOsWa18] pglib-uc/ferc/2015-08-01_lw 1 979 0 0 [KnOsWa18] pglib-uc/ferc/2015-09-01_hw 1 979 0 0 [KnOsWa18] pglib-uc/ferc/2015-09-01_lw 1 979 0 0 [KnOsWa18] pglib-uc/ferc/2015-10-01_hw 1 935 0 0 [KnOsWa18] pglib-uc/ferc/2015-10-01_lw 1 935 0 0 [KnOsWa18] pglib-uc/ferc/2015-11-02_hw 1 935 0 0 [KnOsWa18] pglib-uc/ferc/2015-11-02_lw 1 935 0 0 [KnOsWa18] pglib-uc/ferc/2015-12-01_hw 1 935 0 0 [KnOsWa18] pglib-uc/ferc/2015-12-01_lw 1 935 0 0 [KnOsWa18]","title":"1.2 PGLIB-UC/FERC"},{"location":"instances/#13-pglib-ucrts-gmlc","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 . Name Buses Generators Lines Contingencies References pglib-uc/rts_gmlc/2020-01-27 1 154 0 0 [BaBlEh19] pglib-uc/rts_gmlc/2020-02-09 1 154 0 0 [BaBlEh19] pglib-uc/rts_gmlc/2020-03-05 1 154 0 0 [BaBlEh19] pglib-uc/rts_gmlc/2020-04-03 1 154 0 0 [BaBlEh19] pglib-uc/rts_gmlc/2020-05-05 1 154 0 0 [BaBlEh19] pglib-uc/rts_gmlc/2020-06-09 1 154 0 0 [BaBlEh19] pglib-uc/rts_gmlc/2020-07-06 1 154 0 0 [BaBlEh19] pglib-uc/rts_gmlc/2020-08-12 1 154 0 0 [BaBlEh19] pglib-uc/rts_gmlc/2020-09-20 1 154 0 0 [BaBlEh19] pglib-uc/rts_gmlc/2020-10-27 1 154 0 0 [BaBlEh19] pglib-uc/rts_gmlc/2020-11-25 1 154 0 0 [BaBlEh19] pglib-uc/rts_gmlc/2020-12-23 1 154 0 0 [BaBlEh19]","title":"1.3 PGLIB-UC/RTS-GMLC"},{"location":"instances/#2-matpower","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. 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: 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. Load profiles were generated using a similar data-driven approach. Ramp-up, ramp-down, startup and shutdown rates were set to fixed proportion of the generator's maximum output. Minimum reserves were set to a fixed proportion of the total demand. Contingencies 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. For each MATPOWER test case, UC.jl provides two variations ( 2017-02-01 and 2017-08-01 ) corresponding respectively to a winter and to a summer test case.","title":"2. MATPOWER"},{"location":"instances/#21-matpoweruw-pstca","text":"A variety of smaller IEEE test cases, compiled by University of Wisconsin , corresponding mostly to small portions of the American Electric Power System in the 1960s. Name Buses Generators Lines Contingencies References matpower/case14/2017-02-01 14 5 20 19 [ZiMSTh11], [PSTCA] matpower/case14/2017-08-01 14 5 20 19 [ZiMSTh11], [PSTCA] matpower/case30/2017-02-01 30 6 41 38 [ZiMSTh11], [PSTCA] matpower/case30/2017-08-01 30 6 41 38 [ZiMSTh11], [PSTCA] matpower/case57/2017-02-01 57 7 80 79 [ZiMSTh11], [PSTCA] matpower/case57/2017-08-01 57 7 80 79 [ZiMSTh11], [PSTCA] matpower/case118/2017-02-01 118 54 186 177 [ZiMSTh11], [PSTCA] matpower/case118/2017-08-01 118 54 186 177 [ZiMSTh11], [PSTCA] matpower/case300/2017-02-01 300 69 411 320 [ZiMSTh11], [PSTCA] matpower/case300/2017-08-01 300 69 411 320 [ZiMSTh11], [PSTCA]","title":"2.1 MATPOWER/UW-PSTCA"},{"location":"instances/#22-matpowerpolish","text":"Test cases based on the Polish 400, 220 and 110 kV networks, originally provided by Roman Korab (Politechnika \u015al\u0105ska) and corrected by the MATPOWER team. Name Buses Generators Lines Contingencies References matpower/case2383wp/2017-02-01 2383 323 2896 2240 [ZiMSTh11] matpower/case2383wp/2017-08-01 2383 323 2896 2240 [ZiMSTh11] matpower/case2736sp/2017-02-01 2736 289 3504 3159 [ZiMSTh11] matpower/case2736sp/2017-08-01 2736 289 3504 3159 [ZiMSTh11] matpower/case2737sop/2017-02-01 2737 267 3506 3161 [ZiMSTh11] matpower/case2737sop/2017-08-01 2737 267 3506 3161 [ZiMSTh11] matpower/case2746wop/2017-02-01 2746 443 3514 3155 [ZiMSTh11] matpower/case2746wop/2017-08-01 2746 443 3514 3155 [ZiMSTh11] matpower/case2746wp/2017-02-01 2746 457 3514 3156 [ZiMSTh11] matpower/case2746wp/2017-08-01 2746 457 3514 3156 [ZiMSTh11] matpower/case3012wp/2017-02-01 3012 496 3572 2854 [ZiMSTh11] matpower/case3012wp/2017-08-01 3012 496 3572 2854 [ZiMSTh11] matpower/case3120sp/2017-02-01 3120 483 3693 2950 [ZiMSTh11] matpower/case3120sp/2017-08-01 3120 483 3693 2950 [ZiMSTh11] matpower/case3375wp/2017-02-01 3374 590 4161 3245 [ZiMSTh11] matpower/case3375wp/2017-08-01 3374 590 4161 3245 [ZiMSTh11]","title":"2.2 MATPOWER/Polish"},{"location":"instances/#23-matpowerpegase","text":"Test cases from the Pan European Grid Advanced Simulation and State Estimation (PEGASE) project , describing part of the European high voltage transmission network. Name Buses Generators Lines Contingencies References matpower/case89pegase/2017-02-01 89 12 210 192 [JoFlMa16], [FlPaCa13], [ZiMSTh11] matpower/case89pegase/2017-08-01 89 12 210 192 [JoFlMa16], [FlPaCa13], [ZiMSTh11] matpower/case2869pegase/2017-02-01 2869 510 4582 3579 [JoFlMa16], [FlPaCa13], [ZiMSTh11] matpower/case2869pegase/2017-08-01 2869 510 4582 3579 [JoFlMa16], [FlPaCa13], [ZiMSTh11] matpower/case9241pegase/2017-02-01 9241 1445 16049 13932 [JoFlMa16], [FlPaCa13], [ZiMSTh11] matpower/case9241pegase/2017-08-01 9241 1445 16049 13932 [JoFlMa16], [FlPaCa13], [ZiMSTh11] matpower/case1354pegase/2017-02-01 1354 260 1991 1288 [JoFlMa16], [FlPaCa13], [ZiMSTh11] matpower/case1354pegase/2017-08-01 1354 260 1991 1288 [JoFlMa16], [FlPaCa13], [ZiMSTh11] matpower/case13659pegase/2017-02-01 13659 4092 20467 13932 [JoFlMa16], [FlPaCa13], [ZiMSTh11] matpower/case13659pegase/2017-08-01 13659 4092 20467 13932 [JoFlMa16], [FlPaCa13], [ZiMSTh11]","title":"2.3 MATPOWER/PEGASE"},{"location":"instances/#3-references","text":"[UCJL] Alinson S. Xavier, Feng Qiu, \"UnitCommitment.jl: A Julia/JuMP Optimization Package for Security-Constrained Unit Commitment\". Zenodo (2020). DOI: 10.5281/zenodo.4269874 . [KnOsWa18] Bernard Knueven, James Ostrowski and Jean-Paul Watson. \"On mixed integer programming formulations for the unit commitment problem.\" Pre-print available at http://www.optimization-online.org/DB_HTML/2018/11/6930.pdf (2018). [KrHiOn12] Eric Krall, Michael Higgins and Richard P. O\u2019Neill. \"RTO unit commitment test system.\" Federal Energy Regulatory Commission. Available: http://ferc.gov/legal/staff-reports/rto-COMMITMENT-TEST.pdf (2012). [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). [JoFlMa16] C. Josz, S. Fliscounakis, J. Maeght, and P. Panciatici, \"AC Power Flow Data in MATPOWER and QCQP Format: iTesla, RTE Snapshots, and PEGASE\" https://arxiv.org/abs/1603.01533 [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. https://doi.org/10.1109/TPWRS.2013.2251015 [ZiMSTh11] 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 \u201319, Feb. 2011. [PSTCA] University of Washington, Dept. of Electrical Engineering, \"Power Systems Test Case Archive\", Published online at http://www.ee.washington.edu/research/pstca/, 1999.","title":"3. References"},{"location":"usage/","text":"Usage 1. Installation UnitCommitment.jl was tested and developed with Julia 1.5 . 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: pkg> add https://github.com/ANL-CEEESA/UnitCommitment.jl.git To test that the package has been correctly installed, run: pkg> test UnitCommitment If all tests pass, the package should now be ready to be used by any Julia script on the machine. 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. 2. Typical Usage 2.1 Solving user-provided instances The first step to use UC.jl is to construct a JSON file describing your unit commitment instance. See the data format page for a complete description of the data format UC.jl expects. The next steps, as shown below, are to read the instance from file, construct the optimization model, run the optimization and extract the optimal solution. using Cbc using UnitCommitment # Read instance instance = UnitCommitment.read(\"/path/to/input.json\") # Construct optimization model model = UnitCommitment.build_model(instance, Cbc.Optimizer) # Solve model UnitCommitment.optimize!(model) # Extract solution and write it to a file solution = UnitCommitment.get_solution(model) open(\"/path/to/output.json\", \"w\") do file JSON.print(file, solution, 2) end 2.2 Solving benchmark instances As described in the Instances page , UnitCommitment.jl contains a number of benchmark instances collected from the literature. To solve one of these instances individually, instead of constructing your own, the function read_benchmark can be used: using UnitCommitment instance = UnitCommitment.read_benchmark(\"matpower/case3375wp/2017-01-01\") 3. Advanced usage 3.1 Modifying the formulation For the time being, the recommended way of modifying the MILP formulation used by UC.jl is to create a local copy of our git repository and directly modify the source code of the package. In a future version, it will be possible to switch between multiple formulations, or to simply add/remove constraints after the model has been generated. 3.2 Generating initial conditions 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. 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: using Cbc using UnitCommitment # Read original instance instance = UnitCommitment.read(\"instance.json\") # Generate initial conditions (in-place) UnitCommitment.generate_initial_conditions!(instance, Cbc.Optimizer) # Construct and solve optimization model model = UnitCommitment.build_model(instance, Cbc.Optimizer) UnitCommitment.optimize!(model) Warning The 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. 3.3 Verifying solutions 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 . using JSON using UnitCommitment # Read instance instance = UnitCommitment.read(\"instance.json\") # Read solution (potentially produced by other packages) solution = JSON.parsefile(\"solution.json\") # Validate solution and print validation errors UnitCommitment.validate(instance, solution)","title":"Usage"},{"location":"usage/#usage","text":"","title":"Usage"},{"location":"usage/#1-installation","text":"UnitCommitment.jl was tested and developed with Julia 1.5 . 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: pkg> add https://github.com/ANL-CEEESA/UnitCommitment.jl.git To test that the package has been correctly installed, run: pkg> test UnitCommitment If all tests pass, the package should now be ready to be used by any Julia script on the machine. 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.","title":"1. Installation"},{"location":"usage/#2-typical-usage","text":"","title":"2. Typical Usage"},{"location":"usage/#21-solving-user-provided-instances","text":"The first step to use UC.jl is to construct a JSON file describing your unit commitment instance. See the data format page for a complete description of the data format UC.jl expects. The next steps, as shown below, are to read the instance from file, construct the optimization model, run the optimization and extract the optimal solution. using Cbc using UnitCommitment # Read instance instance = UnitCommitment.read(\"/path/to/input.json\") # Construct optimization model model = UnitCommitment.build_model(instance, Cbc.Optimizer) # Solve model UnitCommitment.optimize!(model) # Extract solution and write it to a file solution = UnitCommitment.get_solution(model) open(\"/path/to/output.json\", \"w\") do file JSON.print(file, solution, 2) end","title":"2.1 Solving user-provided instances"},{"location":"usage/#22-solving-benchmark-instances","text":"As described in the Instances page , UnitCommitment.jl contains a number of benchmark instances collected from the literature. To solve one of these instances individually, instead of constructing your own, the function read_benchmark can be used: using UnitCommitment instance = UnitCommitment.read_benchmark(\"matpower/case3375wp/2017-01-01\")","title":"2.2 Solving benchmark instances"},{"location":"usage/#3-advanced-usage","text":"","title":"3. Advanced usage"},{"location":"usage/#31-modifying-the-formulation","text":"For the time being, the recommended way of modifying the MILP formulation used by UC.jl is to create a local copy of our git repository and directly modify the source code of the package. In a future version, it will be possible to switch between multiple formulations, or to simply add/remove constraints after the model has been generated.","title":"3.1 Modifying the formulation"},{"location":"usage/#32-generating-initial-conditions","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. 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: using Cbc using UnitCommitment # Read original instance instance = UnitCommitment.read(\"instance.json\") # Generate initial conditions (in-place) UnitCommitment.generate_initial_conditions!(instance, Cbc.Optimizer) # Construct and solve optimization model model = UnitCommitment.build_model(instance, Cbc.Optimizer) UnitCommitment.optimize!(model) Warning The 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.","title":"3.2 Generating initial conditions"},{"location":"usage/#33-verifying-solutions","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 . using JSON using UnitCommitment # Read instance instance = UnitCommitment.read(\"instance.json\") # Read solution (potentially produced by other packages) solution = JSON.parsefile(\"solution.json\") # Validate solution and print validation errors UnitCommitment.validate(instance, solution)","title":"3.3 Verifying solutions"}]}
\ No newline at end of file
diff --git a/0.1/sitemap.xml b/0.1/sitemap.xml
index a0fabc4..1ecd298 100644
--- a/0.1/sitemap.xml
+++ b/0.1/sitemap.xml
@@ -1,15 +1,19 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"><url>
      <loc>None</loc>
-     <lastmod>2020-11-06</lastmod>
+     <lastmod>2020-11-13</lastmod>
      <changefreq>daily</changefreq>
     </url><url>
      <loc>None</loc>
-     <lastmod>2020-11-06</lastmod>
+     <lastmod>2020-11-13</lastmod>
      <changefreq>daily</changefreq>
     </url><url>
      <loc>None</loc>
-     <lastmod>2020-11-06</lastmod>
+     <lastmod>2020-11-13</lastmod>
+     <changefreq>daily</changefreq>
+    </url><url>
+     <loc>None</loc>
+     <lastmod>2020-11-13</lastmod>
      <changefreq>daily</changefreq>
     </url>
 </urlset>
\ No newline at end of file
diff --git a/0.1/sitemap.xml.gz b/0.1/sitemap.xml.gz
index d304265..6b7a328 100644
Binary files a/0.1/sitemap.xml.gz and b/0.1/sitemap.xml.gz differ
diff --git a/0.1/usage/index.html b/0.1/usage/index.html
index f8f4eed..6406b2b 100644
--- a/0.1/usage/index.html
+++ b/0.1/usage/index.html
@@ -59,7 +59,9 @@
 
             <!-- Main title -->
 
-            <a class="navbar-brand" href="..">UnitCommitment.jl</a>
+            
+              <a class="navbar-brand" href="..">UnitCommitment.jl</a>
+            
         </div>
 
         <!-- Expanded navigation -->
@@ -85,6 +87,12 @@
                     </li>
                 
                 
+                
+                    <li >
+                        <a href="../instances/">Instances</a>
+                    </li>
+                
+                
                 </ul>
 
             <ul class="nav navbar-nav navbar-right">
@@ -135,19 +143,17 @@
 <h1 id="usage">Usage</h1>
 <h2 id="1-installation">1. Installation</h2>
 <p>UnitCommitment.jl was tested and developed with <a href="https://julialang.org/">Julia 1.5</a>. To install Julia, please follow the <a href="https://julialang.org/downloads/platform.html">installation guide on the official Julia website</a>. To install UnitCommitment.jl, run the Julia interpreter, type <code>]</code> to open the package manager, then type:</p>
-<pre><code class="text">pkg&gt; add https://github.com/ANL-CEEESA/UnitCommitment.jl.git
+<pre><code class="language-text">pkg&gt; add https://github.com/ANL-CEEESA/UnitCommitment.jl.git
 </code></pre>
-
 <p>To test that the package has been correctly installed, run:</p>
-<pre><code class="text">pkg&gt; test UnitCommitment
+<pre><code class="language-text">pkg&gt; test UnitCommitment
 </code></pre>
-
 <p>If all tests pass, the package should now be ready to be used by any Julia script on the machine.</p>
 <p>To solve the optimization models, a mixed-integer linear programming (MILP) solver is also required. Please see the <a href="https://jump.dev/JuMP.jl/stable/installation/">JuMP installation guide</a> for more instructions on installing a solver. Typical open-source choices are <a href="https://github.com/JuliaOpt/Cbc.jl">Cbc</a> and <a href="https://github.com/JuliaOpt/GLPK.jl">GLPK</a>. In the instructions below, Cbc will be used, but any other MILP solver listed in JuMP installation guide should also be compatible.</p>
 <h2 id="2-typical-usage">2. Typical Usage</h2>
 <h3 id="21-solving-user-provided-instances">2.1 Solving user-provided instances</h3>
 <p>The first step to use UC.jl is to construct a JSON file describing your unit commitment instance. See the <a href="">data format page</a> for a complete description of the data format UC.jl expects. The next steps, as shown below, are to read the instance from file, construct the optimization model, run the optimization and extract the optimal solution.</p>
-<pre><code class="julia">using Cbc
+<pre><code class="language-julia">using Cbc
 using UnitCommitment
 
 # Read instance
@@ -165,20 +171,18 @@ open(&quot;/path/to/output.json&quot;, &quot;w&quot;) do file
     JSON.print(file, solution, 2)
 end
 </code></pre>
-
 <h3 id="22-solving-benchmark-instances">2.2 Solving benchmark instances</h3>
-<p>As described in the <a href="">instances page</a>, UnitCommitment.jl contains a number of benchmark instances collected from the literature. To solve one of these instances individually, instead of constructing your own, the function <code>read_benchmark</code> can be used:</p>
-<pre><code class="julia">using UnitCommitment
+<p>As described in the <a href="../instances/">Instances page</a>, UnitCommitment.jl contains a number of benchmark instances collected from the literature. To solve one of these instances individually, instead of constructing your own, the function <code>read_benchmark</code> can be used:</p>
+<pre><code class="language-julia">using UnitCommitment
 instance = UnitCommitment.read_benchmark(&quot;matpower/case3375wp/2017-01-01&quot;)
 </code></pre>
-
 <h2 id="3-advanced-usage">3. Advanced usage</h2>
 <h3 id="31-modifying-the-formulation">3.1 Modifying the formulation</h3>
 <p>For the time being, the recommended way of modifying the MILP formulation used by UC.jl is to create a local copy of our git repository and directly modify the source code of the package. In a future version, it will be possible to switch between multiple formulations, or to simply add/remove constraints after the model has been generated.</p>
 <h3 id="32-generating-initial-conditions">3.2 Generating initial conditions</h3>
 <p>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.</p>
 <p>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:</p>
-<pre><code class="julia">using Cbc
+<pre><code class="language-julia">using Cbc
 using UnitCommitment
 
 # Read original instance
@@ -191,14 +195,13 @@ UnitCommitment.generate_initial_conditions!(instance, Cbc.Optimizer)
 model = UnitCommitment.build_model(instance, Cbc.Optimizer)
 UnitCommitment.optimize!(model)
 </code></pre>
-
 <div class="admonition warning">
 <p class="admonition-title">Warning</p>
 <p>The function <code>generate_initial_conditions!</code> 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.</p>
 </div>
 <h3 id="33-verifying-solutions">3.3 Verifying solutions</h3>
 <p>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 <a href="../format/">UC.jl data format</a>.</p>
-<pre><code class="julia">using JSON
+<pre><code class="language-julia">using JSON
 using UnitCommitment
 
 # Read instance
@@ -214,18 +217,22 @@ UnitCommitment.validate(instance, solution)
         
     </div>
 
-    <footer class="col-md-12 text-center">
-        
-        <hr>
-        <p>
-        <small>Copyright © 2020, UChicago Argonne, LLC. All Rights Reserved.</small><br>
-        
-        <small>Documentation built with <a href="http://www.mkdocs.org/">MkDocs</a>.</small>
-        </p>
+    
+      <footer class="col-md-12 text-center">
+          
+          
+            <hr>
+            <p>
+            <small>Copyright © 2020, UChicago Argonne, LLC. All Rights Reserved.</small><br>
+            
+            <small>Documentation built with <a href="http://www.mkdocs.org/">MkDocs</a>.</small>
+            </p>
+          
 
-        
-        
-    </footer>
+          
+          
+      </footer>
+    
     <script src="//ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js"></script>
     <script src="../js/bootstrap-3.0.3.min.js"></script>